“The more constraints one imposes on oneself, the more one frees oneself of the chains that shackle the spirit.” — Igor Stravinsky, Poetics of Music
The story we’ve been told
A story has settled, in recent years, at the centre of the European debate about technology. You all know it. In its compressed form it goes: “America innovates, China copies, Europe regulates.” It’s a quip you hear at conferences, read in newspapers, find in think-tank reports, and that found its formal consecration in the Draghi report on European competitiveness — an honest, dramatic document that named regulatory fragmentation as one of the causes of our structural lag.
There’s a kernel of truth in it. The European regulatory frame is dense. The piling up of requirements — AI Act, Cyber Resilience Act, Product Liability Directive, European Accessibility Act, NIS2, GDPR, Data Act, DSA, DMA — does produce non-trivial cognitive load on whoever builds software. Many Italian SMEs are gasping for air, specialised consultancy is expensive, mature tooling is still missing.
But the story, as often happens, is more interesting than how it’s told to us. Because there is another way to read the same scenario, and that’s what I want to articulate in these pages. A reading that doesn’t deny the difficulties but rejects the apparently obvious conclusion: that regulation and innovation are opposed, and that being in Europe means losing simply by being there.
The thesis I’m defending is simple at its core, complex in its implications. Regulatory compliance, properly understood, is not a cost of the competition: it is one of its terrains. And the European framework, read as a coherent technical project, configures a competitive advantage that companies who understood it are already monetising — while those who keep treating it as a nuisance are progressively excluding themselves from the higher-value markets.
The category error
The first step in defusing the false dilemma “regulation versus innovation” is to recognise that the dilemma is, before being a debatable position, a category error.
When an architect designs a building, she works inside a tight web of constraints: laws of physics, seismic codes, urban planning rules, energy requirements, accessibility, fire safety, landscape protections. Nobody, looking at a well-designed building, says it would have been “more innovative without the laws of statics.” It would be absurd. Gravity isn’t a brake on architecture: it’s the condition that makes architecture possible as a discipline. It is what distinguishes building from piling up materials.
The same is true of software. The constants, standards, protocols, specifications — TCP/IP, ANSI SQL, POSIX, IEEE 754, RFC 7231 — are constraints. Severe constraints. And yet no serious engineer treats them as obstacles to innovation. They are the opposite: the shared grammar that makes it possible to compose complex systems out of independent pieces. Without those constraints we wouldn’t have the Internet, we wouldn’t have databases, we wouldn’t have interoperability. We’d have an archipelago of incompatible proprietary solutions — exactly what European regulation, in its intent, is trying to prevent for the next layer of the technology stack: data, AI, security, accessibility.
Constraint, in other words, isn’t design’s enemy: it’s its shape. Schönberg knew it with the twelve-tone system, the Oulipo knew it with their literary algorithms, Calvino knew it when he praised exactness as a value of literature, every experienced developer knows it when she finally understands that static types don’t slow development down — they structure it. Absolute freedom in engineering is called chaos, and it produces fragile systems, incomparable, unmaintainable. Disciplined freedom produces architecture.
Treating compliance as the adversary of the technical project means you haven’t understood what the technical project is.
The European framework as a system, not a list
The second step is to read the European regulatory body the right way. Almost all the conventional critique — even the well-intentioned kind — makes the same mistake: it treats the regulations as a list. A list of disconnected obligations, each one adding friction, each one to be assessed individually on cost-benefit terms.
But that isn’t the shape the European framework has actually taken. If you look at the overall weave of the regulations of the past decade — from GDPR to the AI Act, through CRA, PLD, EAA, NIS2, Data Act, DSA, DMA — it isn’t a list, it’s a system. And like every designed system, it has its own architectural logic.
That logic can be summed up in one sentence: make accountable, by design, the technical systems that materially affect people’s rights and goods. Everything else is a domain-specific declension of that principle.
GDPR makes flows of personal data accountable. GDPR doesn’t tell you how to design the database: it tells you that you must be able to answer — always, for anyone who asks — who touches whose data, why, for how long, on what legal basis. The Cyber Resilience Act does the same thing for software product security: it doesn’t tell you which language to use, but it requires you to know and demonstrate what’s inside your product, to keep it secure over time, to manage vulnerabilities through traceable processes. The Product Liability Directive extends the producer’s liability to software itself, declaring explicitly that a bug can be a product defect. The European Accessibility Act extends accountability to inclusion: digital products above a certain market threshold must be usable by anyone. NIS2 does it for critical infrastructure. The AI Act does it for systems that meaningfully decide on, or influence, human choices.
Seen this way, European compliance isn’t a jungle of rules. It is one grammar applied to different domains: design things so you can answer for what you do, by design. Not as a fallback. Not as a coat of paint added later. As architecture.
And here is the often-missed point: once you have built an organisation that thinks in accountability terms — with SBOM, audit trails, threat modelling, privacy impact assessments, tested accessibility, formalised vulnerability management — the marginal cost of conforming to regulation N+1 drops sharply. The cost curve is the inverse of what naive critique imagines: high at the start, falling over time, while for whoever treats every regulation as a fresh emergency the curve starts low but diverges.
Organisations that understand this don’t “get compliant.” They are compliant, in the strong sense: they have a shape compatible with the framework. The others chase.
The Brussels Effect, ten years on
There is also a market dimension we tend to forget, and which on its own should dissuade anyone from dismissing European regulation as ballast.
Anu Bradford, a Columbia legal scholar, coined the term Brussels Effect to describe a well-documented empirical phenomenon: when the European Union regulates a market this size — second by nominal GDP, third on a purchasing-power basis, in any case one of the three biggest markets in the world — multinationals tend to adopt the European standard as their global standard, because maintaining two parallel regimes costs more than adopting the stricter one everywhere.
The paradigmatic case is the GDPR. Approved in 2016, applicable from 2018, it is today the de facto regulatory base orienting privacy policies at the largest tech companies in the world. You see it in cookie banners everywhere, in the privacy dashboards of the big tech platforms, in the California Consumer Privacy Act (which echoes its principles and structure with a lighter, opt-out-based architecture), in the Brazilian, South African, and Indian laws. Almost eight years after enforcement began, we can say with reasonable certainty: the grammar of global privacy speaks European.
The AI Act looks set on the same trajectory. Not because it’s perfect — it isn’t — but because it’s the first horizontal and organic regulatory framework in the world for AI systems. China got there first, in 2023, with binding rules on generative AI: but those are sectoral rules with a different emphasis — mandatory labelling, registration with the authority, user identity verification, content control — more oriented to informational stability than to fundamental-rights protection. The AI Act was the first attempt at a general, risk-tiered architecture, applicable to all AI systems across all sectors. The major AI companies are already structuring their internal processes against European requirements. In the United States, in a turn few would have predicted, state-level regulation is picking up — particularly in Colorado, with echoes in California and in some local New York legislation — the risk-categorisation logic, although the path has not been linear: the Colorado AI Act, originally in force from 2026, has been postponed and is being reworked as I write.
For a European company designing software, this means something very concrete: you are already working inside the standard that, statistically, will be the global standard within five years. Your American and Asian competitors will have to adapt to a frame you have already metabolised. This isn’t a detail: it is the operational definition of first-mover advantage.
The reply usually is: but if the Brussels Effect is so powerful, why are European companies struggling? The honest answer is that many European companies have not in fact metabolised the framework — they suffer it. They treat the GDPR as a nuisance to minimise, the AI Act as an unknown to defer, the EAA as something to do when the inspection comes. They pay twice that way: the cost of compliance (which, badly run, is high) and the missed opportunity of turning that compliance into positioning. Meanwhile non-European companies, forced to comply to access the market, do so structurally — and the competitive advantage that could have been ours becomes theirs.
The Brussels Effect is an arrow flying toward a target. We get to decide whether the target is us or them.
The asymmetry that decides
Now to the heart of the argument, the operational part. There’s a fundamental asymmetry between two kinds of company operating in the European market, and that asymmetry — silent, accumulating, today barely visible, tomorrow decisive — will determine who wins and who exits the higher-value segments.
The first kind treats compliance as paperwork. It’s the default position, and perfectly understandable: the regulation arrives, you appoint a person responsible, you fill in checklists, you produce documents, you update the privacy policy, you add the banners, you commission assessments when needed. Compliance is a cost to minimise, a defensive activity, something you do to avoid fines. It’s an activity outsourced as soon as possible: an on-demand consultant beats a structured internal process.
The second kind treats compliance as architecture. The difference is that regulatory requirements are not addressed at the moment of their applicability but taken as project constraints from the start. The SBOM isn’t a document produced after the fact: it’s an artefact generated by the CI/CD pipeline at every build. Privacy isn’t a checklist to fill in: it’s a dimension of the data model. Accessibility isn’t a final check: it’s a UI component set that guarantees it. Security isn’t an annual audit: it’s a threat model revisited at every meaningful architectural change. AI accountability isn’t a response to an inspection: it’s a battery of tests, training documentation, evaluation suites.
For the first two or three years, the difference between the two is hard to spot from the outside. The first company even looks more efficient: it ships the same products with less overhead. The second invests in things that can’t yet be seen: pipelines, frameworks, processes, training, structured documentation.
Then something changes. It changes when the relevant market becomes healthcare, public administration, finance, energy, critical infrastructure — the segments where the customers have their own regulatory exposure, and where their compliance depends on their suppliers’. At that point something happens that anyone who works in regulated B2B has already seen: the RFP arrives with a thirty-page technical annex, and the “paperwork” company discovers that many of the requirements are not incremental but structural. Full SBOM for every component. Vulnerability traceability with remediation SLAs. Documented and audited SDLC processes. Annual penetration tests with traceable remediation. Backup, disaster recovery, business continuity policies that have actually been tested. Demonstrable privacy by design for every flow. Verified accessibility. Auditability of any AI models in use.
The “paperwork” company has two options: either it transforms into an “architecture” company — investing suddenly, under pressure, in everything it never built — or it withdraws. Transforming under pressure is expensive, slow, and never clean: it produces approximate documentation, processes that survive at most until contract renewal, fragility that surfaces at the first serious audit. Withdrawing means stepping down a market tier.
The “architecture” company participates, wins, and — this is the point — wins at higher margins, because in those segments pricing rewards demonstrability, not just functionality.
I’m describing, as should be clear, something I live first-hand. Over the last three years I’ve watched healthcare projects where the discriminator was neither price nor feature parity but the ability to produce, on time, governance, security and accessibility documentation coherent with the customer’s requirements. I’ve seen public-administration tenders where ACN qualification was a gate, and where the absence of a qualified vendor translated into mechanical exclusion. I’ve seen negotiations where a security-focused technical annex redefined the entire axis of the conversation: no longer “what does your product do,” but “how do you demonstrate you can run it for years.”
In these contexts, compliance isn’t the final irritation of the negotiation. It is the terrain of the negotiation.
Trust as product
There’s a phrasing I find useful: in regulated B2B you don’t sell features, you sell documented trust.
Features matter, obviously. But features become commodity faster than people think. All CRMs look alike. All LMSs look alike. All telemetry platforms look alike. Differences are incremental, and after a certain level they stop being the buying discriminator. What becomes the discriminator is what isn’t a feature in the classical sense: the ability to sign a contract with precise liability clauses, to pass an audit, to guarantee operational continuity, to document your software supply chain, to respond within 24 hours to a data-subject request, to demonstrate the non-discriminatory behaviour of a decision system, to keep your products accessible for years.
None of these is a feature in the classical sense. They are demonstrable organisational capabilities. And they are exactly what the European regulatory framework forces you to build.
Here, in my view, lies the fundamental conceptual inversion. For a paperwork company, documentation is a by-product: the thing you produce so that inspectors are content. For an architecture company, documentation is the product — or rather, it is a constitutive part of the product, because what you sell isn’t the software but the organised capacity to run it over time, and that capacity is demonstrable only through documentation.
You see, from this angle, why the SBOM isn’t a paper exercise: it’s the manifest of your software supply chain, and it’s what lets the customer manage their own exposure. You see why the audit log isn’t a cost: it’s a reliability property the customer will buy anyway, and one that will be mandatory soon. You see why an EN 301 549-conforming accessibility report isn’t a formality: it’s what lets the public-sector customer win their own tender, and so it’s what makes you a preferred supplier.
When you sell trust, the documentation is the product, and compliance is the product’s instruction manual.
The honest objection
It would be dishonest to lay out this reading without acknowledging the serious objections. There are at least three, and they deserve to be taken seriously.
The first is disproportion. The regulatory load resting today on a ten-person software house is, structurally, very close to the load on a major corporation. Not in absolute terms — there are thresholds and exemptions — but structurally: the processes required to be genuinely compliant with the CRA, AI Act, GDPR are at points the same as a multinational’s, simply with fewer people running them. This disproportion is real, and it’s the main reason many European SMEs are struggling. It’s a serious problem, and it asks Brussels to do better on proportionality, on simplified regimes for SMEs, on the availability of accessible compliance tooling. It is not, however, an argument against compliance as such: it is an argument for implementing it better.
The second objection is implementation heterogeneity. The European regulation, once it lands in national legal systems, gets translated in ways that vary from country to country — competent authorities, certification schemes, supervisory tools, thresholds. That heterogeneity is genuinely a cost, especially for cross-border work. It is a specifically European weakness, tied to our institutional history, and it isn’t easily resolved. But — and this is the point — it isn’t a weakness of compliance: it is a weakness of single-market integration. Two different problems. Dismissing European regulation because it gets applied unevenly is a bit like dismissing the idea of a language because dialects exist.
The third objection is the most interesting, and deserves the most articulated answer. It is the time-to-market objection: if our American competitors don’t have to do AI Act compliance, and we do, they get to market first. This collides with the Brussels Effect but doesn’t entirely cancel it: there is a real window where asymmetry of constraint produces asymmetry of speed. The thing is, that window applies to a specific subset of products — the ones aimed at the consumer mass market, where time-to-market often beats robustness — and not to those aimed at regulated segments. For whoever sells to hospitals, banks, public administration, critical infrastructure, speed is rarely the discriminator: demonstrable robustness is. And there the European framework is an advantage, not a handicap. There are European companies winning in regulated B2B precisely because the American product arrives without the documentation, without the processes, without the culture — and has to be rebuilt under pressure to pass audits. Rebuilding under pressure is expensive: their margins drop, ours go up.
All three objections, in short, have a kernel of truth, but none of them justifies the catastrophist conclusion that often comes attached. The right answer is: implement compliance better, not refuse it.
What a compliant-by-design organisation does
So far, the conceptual level. I want to close with something more operational, because an essay on compliance that doesn’t go down to specifics risks being appreciated and then forgotten.
An organisation that has turned compliance into competitive advantage, in my experience, has these traits.
It has one accountability model spanning the software lifecycle. Not one model for security, one for privacy, one for accessibility, one for AI: a single model with domain-specific declensions, where all requirements converge on the same pipelines and the same documentation. The SBOM, the PIA, the threat model, the accessibility test record, the model card live in the same repository, are versioned, are updated at every release, are linkable from anywhere else in the organisation.
It has automation of the compliance artefact. Generation of SBOM, SPDX, license reports, vulnerability reports, accessibility scans, model evaluation reports is automatic. Not something someone produces by hand in anticipation of an audit: something the pipeline produces at every build, with timestamp and reference commit. The result is that, when a customer request lands, the answer is available in minutes, not weeks.
It has contracts as specifications. Customer contracts — especially in healthcare and public administration — are not legal texts disjoint from technical work, but technical specifications living inside the backlog. Security clauses are mapped onto requirements, requirements onto tests, tests onto pipelines. When a customer asks you to certify conformity to a clause, the answer isn’t “let’s ask the consultant”: it’s a query against your own system.
It has internalised legal competence. That doesn’t mean having a lawyer on the org chart. It means tech leads know the regulations applying to their domain, understand their logic, know how to translate their requirements into architectural choices. The external consultant is a resource for specialised cases, not the owner of compliance.
It has a culture of explicit trade-offs. It knows when a compliance requirement imposes a cost, declares it, debates it, makes a motivated decision. It doesn’t pretend compliance is free. It doesn’t pretend it’s impossible. It treats compliance as one of the project’s constraints, to be balanced against the others.
And, above all, it has a commercial narrative grounded in compliance. It can tell customers why its product is better, and that “why” includes — alongside the features — the documented reliability structure. It knows that the healthcare customer, the public-sector customer, the banking customer is buying exactly that: the guarantee that, three years out, five years out, in front of an inspection, in front of an incident, in front of a regulatory shift, you will still be a solid supplier. That isn’t a concession to marketing: it is the product.
Europe’s civic signature
I want to close by stepping out of the operational terrain and returning to the conceptual one, because there is a further dimension — civic, almost political — that is worth naming.
Europe, as a project, is a singular historical experiment: a union of states that decided, after the catastrophes of the twentieth century, to pool sovereignty in exchange for rules. It isn’t a union of force: it’s a union of norms. Our symbolic wealth, our capacity to project values, our international credibility, depend in large measure on the idea that we make rules, abide by them, and apply them to ourselves. When we export them, we don’t do it through force, we do it through the market.
What we are doing in the digital domain is precisely this: transposing our civic signature into cyberspace. The idea, scandalous to part of the world, that technology should answer to those who suffer it, not only to those who produce it. That the effects of technical systems on individuals are not an externality but a legitimate object of regulation. That innovation producing unrepaired harms, unremedied exclusions, unexplainable opacities is not innovation: it’s a transfer of costs from producer to citizen, dressed up as progress.
You don’t have to share this view. There are legal systems that have made other choices, and we respect them. But arguing — as some of us still do — that our view is a brake, and that real progress is somewhere else, means not having understood the game we’re playing. The game isn’t who reaches the consumer market first with a new gadget. The game is who defines the grammar inside which technical systems will operate for the next fifty years. The GDPR is already the grammar of global privacy. The AI Act is becoming the grammar of global algorithmic accountability. The CRA is becoming the grammar of global software product security.
For whoever designs software in Europe, taking part in this game is a privilege we pay for with a specific cost — the cost of building first — but it is also, precisely for that reason, our principal structural competitive advantage. Whoever stays out, inside Europe itself, because the framework is a nuisance, is making a short-sighted bet: removing themselves from the only advantage we have, in pursuit of a competitive model — pure time-to-market — in which we cannot win anyway, because we don’t have the capital mass of those who define it.
Compliance, properly understood, is not our burden. It is our shape. Our shape of building, our shape of doing business, our shape of projecting values. Treating it as ballast is, for a musician, like treating the key signature as a bother. You can do that, sure. But you’ll be playing something else, and you’ll be playing it worse.
Constraint, once again, is shape. And shape, for those who learn to inhabit it, is an advantage.
Key takeaways
Treating compliance as the adversary of the technical project is a category error: constraint is not the enemy of design, it is its shape.
The European framework isn’t a list of disconnected obligations: it’s a system with one grammar — make technical systems that materially affect rights and goods accountable, by design.
The Brussels Effect turns the European standard into the global standard; whoever already builds inside that frame holds the first-mover advantage.
The compliance-as-architecture company wins regulated segments at higher margins; the compliance-as-paperwork company exits at the first serious technical annex.
In regulated B2B you don’t sell features, you sell documented trust: the documentation is part of the product, not a by-product.
Questions & answers
Why would European compliance be a competitive advantage rather than a cost?
Because the European framework, read as a system, codifies an organisational capability — accountability by design — that regulated markets (healthcare, public administration, finance, critical infrastructure) demand from their suppliers anyway, and that is progressively becoming a global standard via the Brussels Effect. Companies that build it in time win access to higher-value segments at higher margins. Companies that chase it as paperwork pay twice: the cost of panicked compliance, and the missed opportunity of turning that compliance into market position.
What is the Brussels Effect, and why does it matter for software builders?
It’s the well-documented phenomenon that, when the EU regulates a market this size, multinationals tend to adopt the European standard as their global one because running two parallel regimes costs more than adopting the stricter one everywhere. The GDPR is now the de facto grammar of global privacy; the AI Act is on the same trajectory. For European software builders this means something concrete: you’re already working inside the standard that, statistically, will be the global standard in five years. That’s the operational definition of first-mover advantage.
What's the difference between compliance-as-paperwork and compliance-as-architecture?
Paperwork: you appoint someone responsible, fill in checklists, produce documents to dodge fines. Compliance is a cost to minimise, outsourced as soon as possible. Architecture: regulatory requirements are taken as project constraints from day one. SBOM generated by the pipeline at every build, privacy as a dimension of the data model, accessibility as UI components, threat models reviewed at every meaningful architectural change. For two or three years the first company looks more efficient. Then the thirty-page technical annex arrives, and the difference becomes decisive.
Aren't European SMEs crushed by the regulatory load anyway?
The disproportion between what compliance weighs on a ten-person software house and on a multinational is real, and it’s the main reason many Italian SMEs are struggling. It’s a serious problem, and Brussels needs to do better on proportionality and simplified regimes. But it isn’t an argument against compliance: it’s an argument for implementing it better. The SMEs that treat compliance as architecture rather than as recurring emergency are the same ones winning public-administration tenders and regulated RFPs where price isn’t the discriminator.
What does «documented trust» actually mean in regulated B2B?
It means the buying discriminator is no longer the feature — features become commodity quickly — but the ability to sign a contract with precise liability clauses, to pass an audit, to document your software supply chain, to respond within 24 hours to a data-subject request, to keep your products accessible for years. These are demonstrable organisational capabilities. When you sell trust, the documentation is the product and compliance is the product’s instruction manual.
The author
