Buyers and vendors of AI systems ask each other a lot of questions. Unless the system is off-the-shelf software, they also negotiate a contract. Both sides want to protect their rights. The buyer wants to make sure the vendor delivers what it promised, and the vendor wants a customer who stays happy.

And with AI, it gets more complicated. Under the EU AI Act, the obligations of each side depend on its role, and the role depends on what the system is for and what each side does with it. Much of what the buyer needs for its own obligations (documentation, logs, notice of changes) only the vendor has. The vendor, in turn, can’t classify the system without knowing how the buyer will use it. Neither side can meet its obligations without the other, and the contract is where they agree how.

That’s why these questions should be asked before signing any contract. Many of the obligations start in December 2027, so a three-year contract signed this year will still be running once they do. Agreed now, they’re part of the deal. Raised in 2027, they’re a renegotiation of a contract.

A buyer doesn’t need all twenty questions for every AI system. The first three questions (what the system is for, whether it’s high-risk in this use, and who is provider and who is deployer) decide which of the other seventeen apply. A chatbot on the support page and a tool that ranks job applicants shouldn’t get the same questionnaire.

If you buy AI systems, this list of questions includes what to ask and what a good answer contains. If you sell them, it’s the questionnaire that’s coming. Answer all twenty questions for one of your products to see where you stand. Where you don’t have the answer yet, write down when you will.

Below in the article: twenty questions, grouped into four parts, each with when it becomes an obligation, the provisions behind it, and what a good answer contains. The article also explains what the vendor needs from the customer and what goes into the contract.

There’s also a handout version of the twenty to download for your reference.

Read more

For about thirty years, globalization looked like the obviously sensible idea. Make each thing where it’s made best, ship it wherever it’s needed, and let trade tie countries together so closely that falling out becomes too expensive. Slovakia, where I live, joined the EU in 2004 and the euro in 2009, right in the middle of that era, and built much of its economy on car factories that run on parts from everywhere.

It worked well enough that the dependencies stopped feeling like dependencies.

Then they started showing up, one at a time. Before Russia’s full-scale invasion of Ukraine, about 45% of the EU’s gas imports came from Russia. The Commission’s own factsheet on critical raw materials notes that “100% of the rare earths used for permanent magnets globally are refined in China”, and in October 2025 Beijing tightened its export controls on them. The same month, a fight over Nexperia, a Dutch chipmaker owned by a Chinese group, ended with China blocking exports from Nexperia’s Chinese plants and European car production at risk over some of the most basic chips in a car.

The law has its own version. In June 2025, Microsoft France’s director of public and legal affairs was asked at a French Senate inquiry whether he could guarantee that French citizens’ data would never be handed to US authorities without France’s authorization. His answer, as reported: “No, I cannot guarantee it.” Amazon, Microsoft and Google hold about 70% of Europe’s cloud market. European providers hold about 15%.

AI already had its moment too. In January 2025, the outgoing US administration published a rule on exporting advanced AI chips. Ten EU member states made its list of trusted destinations. The other seventeen, Slovakia among them, would have needed licenses, with limits on how much computing power they could buy. The rule was withdrawn on May 13, 2025, two days before it would have applied. For four months, the question of how many AI chips a Slovak company could buy had an answer in Washington.

AI raises the stakes for a simple reason. Gas gets burned and a chip gets installed. An AI model you use through someone else’s cloud is never really delivered. It keeps running on someone else’s hardware, under someone else’s law, and it can be updated, repriced or switched off without you. As more of what banks, hospitals and public administrations do runs through these models, the question of who can switch them off stops being theoretical.

So is sovereign AI a utopia?

If it means owning everything from the mine to the model, yes. If it means something smaller, it may be the most practical idea in European AI policy. And if you build smaller or specialized models in Europe, or write the strategy that decides what gets funded, the EU AI Act has something specific to say about the smaller version.

Subscribe now

What Sovereign AI Means

There's no legal definition. The AI Act doesn't use the term, and neither does any other EU law I know of. It's a political label, and it gets attached to very different plans, from building a national frontier model to running an open one on servers at home.

The Tony Blair Institute, in a January report on sovereignty in AI, is blunt about the starting point:

"Full self-sufficiency is too expensive, too slow and, for most countries, simply impossible."

Its version of the goal is more modest. Sovereignty, the report says, is "not a binary condition to be achieved or lost. It is fundamentally a question of agency and choice." It also recommends fine-tuning open-weight models for national languages and sectors, as a way to build capability without entering the race for frontier models.

I believe that sovereignty isn’t owning the whole stack. It’s being able to walk away from any one piece of it.

Under that definition, small and open models aren’t the consolation prize. A model small enough to run on hardware you already have needs fewer of the chips someone else can ration. If you can also adapt it to your own language and replace it when something better comes along, it's about as sovereign as AI gets.

Europe Is Betting on Scale

The money says Europe reads the word differently.

When the Commission launched InvestAI in February 2025, it announced a €20 billion fund for AI gigafactories, each with “around 100 000 last-generation AI chips” and built to train “the most complex, very large, AI models.” The call for tenders to build them closes in December. Europe doesn’t manufacture the advanced AI chips these sites run on, so the first step toward sovereignty at this scale is a very large order from abroad.

To put the gigafactories in AI Act terms: the AI Act presumes a general-purpose model belongs in its top tier, the one for systemic risk, once its training used more than 10²⁵ floating-point operations (FLOP), a measure of total computation. By a rough estimate, a cluster of 100,000 top-end chips running at 40% of peak could get there in about three days. It still shows what the infrastructure is for: the models the AI Act watches most closely.

Europe’s best-known model developer is moving the same way. Mistral raised €3 billion in September, in part to build its own computing capacity.

The smaller path gets smaller checks. OpenEuroLLM, a consortium led by Charles University in Prague that is building open models for all official EU languages, has €20.65 million in EU funding. Switzerland, outside the EU, went smaller and more open: in September 2025, EPFL, ETH Zurich and the Swiss national supercomputing center released Apertus, fully open models trained on more than 1,000 languages and developed, in EPFL’s words, with “due consideration” to “the transparency obligations under the EU AI Act.”

The scale bet may well be the right one for Europe as a whole.

How the AI Act Sorts the Two Paths

The AI Act regulates AI systems by what they’re used for. On top of that, it adds a separate regime for general-purpose models, where the top tier is presumed by training compute.

The first layer covers every AI system, whatever model sits underneath:

• Prohibited practices in Article 5, which have applied since February 2, 2025.

• High-risk uses, such as credit scoring and life and health insurance pricing in Annex III, from December 2, 2027. AI built into regulated products like medical devices follows from August 2, 2028.

• Transparency duties in Article 50, which have applied since August 2, 2026.

The second layer covers general-purpose AI models. Under Article 3(63), that’s a model that

“displays significant generality and is capable of competently performing a wide range of distinct tasks.”

The Commission’s guidelines add an indicative test: training compute above 10²³ FLOP, plus the ability to generate language, as text or audio, or images or video from text. They also list large models that aren’t general-purpose: some because they do only one kind of thing, such as speech transcription or image upscaling, and some because they don’t generate language, images or video at all, such as models that play chess or video games or that are “modelling weather patterns or physical systems.”

A model that plays chess brilliantly is not a general-purpose AI model. The Commission has put that in writing.

General-purpose models have the duties listed in Article 53: technical documentation, information for the companies building on them, a copyright policy and a public summary of the training content. Those with systemic risk have more under Article 55: evaluations, risk mitigation, incident reporting and cybersecurity.

Those duties sit with the company that provides the model. If a European bank or ministry runs on a foreign general-purpose model, the duties sit with the foreign provider, and so does the control. Build or adapt your own, and some of them come home with it. The question for anyone weighing the sovereign option is how many of the duties land on you.

For the smaller path, not many. A narrow model built for one job isn’t a general-purpose model, so Article 53 doesn’t apply to it at all. Take an open model and fine-tune it on your own data, and under the Commission’s guidelines you only become its provider if the modification uses more than a third of the original’s training compute, which, by the Commission’s own account, few modifications currently do. And the rules on how you use AI don’t care where the model came from. A credit scoring system is high-risk whether it runs on a home-grown model or an American one. Choosing the sovereign option doesn’t add regulatory cost. In the same use, it usually removes some.

Releasing your own model openly, the way OpenEuroLLM and Apertus do, comes with an exemption too. Open general-purpose models that aren’t monetized are spared the documentation duties in Article 53, though they still need the copyright policy and the training summary. Above the top-tier threshold, the exemption disappears. The AI Act makes openness cheaper right up to the point where a model joins the top tier.

Where the Top Tier Starts

So where is that point, and does the smaller path ever reach it?

Article 51 puts a general-purpose model in the top tier if it has “high impact capabilities”, and presumes those capabilities above 10²⁵ FLOP, the line the gigafactories are built to cross in days. Article 3(64) defines high-impact capabilities as “capabilities that match or exceed the capabilities recorded in the most advanced general-purpose AI models.”

The definition is relative: a capability counts as high-impact only while it sits near the top, so the bar moves with the frontier. And capabilities don’t stay at the top for long. As of August 2025, Epoch AI found that open models small enough to run on a single consumer graphics card matched frontier performance after an average lag of six to twelve months.

Part of how that happens is distillation, training a small model on a large one’s outputs. The Commission’s guidelines count the computation used to generate that training data, unless the data is publicly available, but they exclude “compute used to train parent model(s) used in distillation.” A small model can inherit a large model’s abilities without inheriting its compute count. (When a provider distills its own model, the guidelines may treat the result as part of the same model’s lifecycle, so the clean case is distilling from someone else’s.)

For a European team on the smaller path, that’s mostly good news. A small model that catches up with last year’s frontier stays out of the top tier by definition, and even one that matches today’s frontier isn’t presumed into it, because the presumption counts compute. For now, the guidelines also make compute the only trigger for a provider’s own duty to tell the Commission. The AI Act isn’t blind to this. Under Article 51(1)(b), the Commission can designate a model with “capabilities or an impact equivalent” to the top tier, using the criteria in Annex XIII, and those include reach: high impact on the EU market is presumed once a model is available to 10,000 registered business users in the EU. As far as I can find, the Commission hasn’t publicly designated any model that way yet.

For anyone worried about what widely available, capable models can do, the same default is a gap. Researchers disagree about how long compute thresholds can keep up: Sara Hooker argued in 2024 that, “as currently implemented”, they’re “shortsighted and likely to fail to mitigate risk”, while a 2026 analysis from MIRI’s technical governance fellowship concluded they “remain a viable governance instrument.”

What the AI Act Doesn’t Reward

That debate is mostly about where to draw the line. A different question is what the line should measure, and the smaller path has the most at stake in the answer.

One influential view in AI safety locates the risk in a combination: how capable a system is, how general, and how much it can do on its own. A capable model doing one bounded job under a human’s control is a different thing from one that can take on any task and act without asking.

Annex XIII, the list the Commission uses to designate models, already names those properties: how many tasks a model can take on without retraining, how well it adapts to new ones, how autonomous it is and which tools it can use.

But the list works mainly in one direction. The Commission uses it to put a model into the top tier, or to reconsider that decision later.

A provider above the compute line can argue that its model doesn’t actually present systemic risk, but the bar is high. The Commission’s guidelines accept two kinds of argument: the model isn’t as capable as its compute suggests, or it’s that capable and still not risky. For the second, safeguards the provider has built or plans to build don’t count, and “we designed it to be controllable” is mostly a safeguard. The top-tier obligations apply in the meantime.

What doesn’t exist is a lighter regime, set out in advance, for models designed to be controllable.

The tool for fixing this is already in the text. Article 51(3) tells the Commission to update the compute threshold and add new benchmarks and indicators “when necessary”, so the law keeps up with the technology, and it names better algorithms as one of the developments to watch. Better algorithms are the smaller path.

The Commission’s own guidelines admit that training compute is an imperfect stand-in for what a model can do, and say it will keep looking for other measures, especially ones smaller companies can apply easily.

In my view, that moment has come. The Commission should start measuring what a model can do, not only how much computing power went into training it. Annex XIII already lists what to measure: how many tasks a model can handle, how much it can do on its own and which tools it can use. Measured that way, a small model as capable as the frontier wouldn't slip under the line, and a model built to stay within limits would finally get credit for it.

It won't be easy to write, because autonomy depends partly on how a model is deployed. It would still be closer to the real risk than counting operations. And for a Europe that won't win on scale, it would mean a law that rewards the kind of AI it can realistically build.

Subscribe now

What to Do With This

If you build or fine-tune smaller models, or decide whether to fund them:

• Check whether your model is general-purpose at all. The 10²³ FLOP test is indicative. A model that does one kind of task can fall outside the definition even above that line, and a small model that’s genuinely general can, exceptionally, fall inside it below the line. The guidelines’ examples are the best place to start.

• Keep your compute records. Count the computation used to generate synthetic training data, including data you threw away, unless that data is publicly available. Distillation from someone else’s model doesn’t add the parent’s training compute to yours. If you’re anywhere near 10²⁵, the guidelines expect you to estimate the total before the large training run starts, within a 30% margin, and to document how you estimated it.

• If you modify someone else’s general-purpose model, the Commission’s guidelines use an indicative line: you become the provider of the modified model when the modification uses more than a third of the original’s training compute. Your documentation, copyright and training-summary duties then cover only the modification. If the original was in the top tier, though, your modified model is presumed to be in it too, with the full top-tier obligations. Below the line, you can still be the provider of the AI system you build with it.

• If you release openly, check the license and monetization conditions before you rely on the exemption, and plan for the copyright policy and training summary anyway.

• If your system lands on the Annex III list, the choice of model won’t change the high-risk rules. Check the Article 6(3) exceptions, including the narrow procedural task, unless the system profiles people. If you rely on one, document why before you place the system on the market or put it into service, and register it. Those rules apply from December 2, 2027 too.

• If you write sovereignty strategy, look at what each investment lets you walk away from, and know which path the AI Act watches. The open, specialized models carry lighter obligations at the model level and keep more choice at home.

So is sovereign AI a utopia?

I would say only if it means building everything Europe now imports.

The smaller version, a model Europe can run, adapt and walk away from, is already being built in Prague and Lausanne, and the AI Act already makes it cheap.

What the AI Act doesn't do yet is treat it as the safer choice.

Like this article? The AI Governance Roadmap is something you can use in practice. It’s a company’s roadmap with steps and working documents. It includes the classification, the inventory spreadsheet, the role assignment, the vendor questions, the AI policy template. Everything a company needs to govern AI, at one place.

You might have read Article 2 of the EU AI Act and know the routes into scope well enough to recite them. But what you might struggle with is the question that comes after it, which isn’t whether the AI Act applies to you but what your obligations are once it does.

The AI Act often doesn’t tell you. It sets out what it requires, and then defines several of those requirements by pointing at other law. The European Commission guidance that would explain how that works hasn’t been published. Law firm alerts take one instrument at a time. Your compliance function has most of a list already, assembled for reasons that had nothing to do with AI.

At some point you start to wonder whether there’s a document you were supposed to have found by now.

There isn't. What the AI Act assumes instead is that you already know which other regulations bind your company, and what each one does once AI is involved. It was drafted to sit on top of all of that and takes it as read. No one publishes that document, because it isn't the same document for any two companies. You build it yourself.

I call it the scope map.

What a Scope Map Is

A scope map is one document listing every regulation that binds your company, with a record of what each one does once AI is involved.

Not a summary of each instrument. One line per regulation, answering a single question: when we build or buy an AI system, does this rule add an obligation, discharge one the AI Act would otherwise impose, or change which authority comes asking?

Most entries do one of the three. The ones that do none of them stay on the map anyway, because “nothing here” is an answer, and the next person to ask won’t have to work it out again.

It has two layers, because the entries arrive from two different directions.

The fixed layer comes from what the company is: its sector, its legal entities, the countries it operates in. It binds every AI use you have, whether that’s a pricing model or a chatbot on the careers page. You build it once, and it changes rarely, because a company’s identity changes rarely.

The pull-in layer is one question, asked per use case: which additional law does this specific use drag in? Recruitment pulls in employment law. Consumer lending pulls in consumer credit rules. Anything customer-facing pulls in consumer protection, and sometimes accessibility law that’s been in force since June 2025.

Central for what’s common. A question for the rest.

Three Places the AI Act Points to Other Laws

Article 26(9): “Where applicable, deployers of high-risk AI systems shall use the information provided under Article 13 of this Regulation to comply with their obligation to carry out a data protection impact assessment under Article 35 of Regulation (EU) 2016/679 or Article 27 of Directive (EU) 2016/680.” Not may. Shall, wherever a data protection impact assessment is owed at all. An AI Act duty wired into a GDPR one.

Article 17(4) and Article 26(5): for financial institutions subject to internal governance requirements under Union financial services law, the quality management system obligation, minus three of its listed elements, and the deployer monitoring obligation will each be deemed fulfilled by complying with those sectoral rules. Two AI Act duties, answered in large part by a different regime entirely.

Article 26(7): before a high-risk system is used at the workplace, employers have to inform workers’ representatives and the affected workers, and that information “shall be provided, where applicable, in accordance with the rules and procedures laid down in Union and national law and practice on information of workers and their representatives.” The duty is European. The procedure is twenty-seven different answers.

Those three sit in Chapter III and apply from December 2, 2027. Three other things bind you already: the AI literacy duty in Article 4 and the prohibitions in Article 5, both since February 2, 2025, and the transparency duties in Article 50 since August 2, 2026.

The One That Gives the Game Away

Article 86(3): “This Article shall apply only to the extent that the right referred to in paragraph 1 is not otherwise provided for under Union law.”

Article 86 is the AI Act’s right to an explanation of a decision taken on the output of a high-risk AI system. It applies only where Union law hasn’t already provided one. To know whether your customer has an Article 86 right, you have to know what else they have.

Take a consumer lender. Three instruments reach the same lending decision, and each one has a different subject.

GDPR Article 22 is about a decision based solely on automated processing, and the explanation itself sits in Article 15(1)(h), which the Court of Justice settled in Dun & Bradstreet Austria in February 2025. The Consumer Credit Directive, which applies from November 20, 2026, is about a creditworthiness assessment that involves automated processing: no “solely,” no adverse-impact condition. Article 86 is about a decision taken by a deployer on the basis of AI output, and only one that produces legal effects or similarly significantly affects the person, in a way they consider to have an adverse impact on their health, safety or fundamental rights. A borrower approved on standard terms probably has no Article 86 claim at all.

Three rights, three subjects, one loan. Read any one of them on its own and you get the wrong answer.

Below in the article: how to build each layer, an example of a fixed layer for an EU credit institution, the pull-in question applied to three categories of use, and the record format, modeled on two registers your organization may already maintain.

It comes with a workbook you can download and start filling in, with the banking example already completed.

Read more

In August, a reader outside the EU asked me under one of my Notes whether the EU AI Act could become “another Brussels effect.”

I answered in two sentences. The AI Act already applies to companies outside the EU if they put systems on the EU market, so reach isn’t the interesting question. The interesting question is whether anyone maintains two versions. That’s where the Brussels effect actually gets decided, and it comes down to cost per obligation rather than principle.

It deserved a longer answer, because underneath it sits a practical question for any company outside the EU: should we just build everything to the EU standard, the way we did with GDPR?

It depends on which part of the AI Act you mean. Some of it will follow you home whether you like it or not. Some of it stays at the EU border. And some of it gets decided before your product ever reaches the border.

Subscribe now

What the Brussels Effect Is

Anu Bradford, a law professor at Columbia, gave the idea its name in 2012 and wrote the book on it in 2020. It comes in two versions.

The de facto version happens inside companies. A company applies EU rules everywhere because running one version of a product is cheaper than running two. No other government has to do anything. GDPR is the famous example: plenty of companies wrote one privacy program for the world rather than one for Europe and another for everyone else.

The de jure version happens in parliaments. Other countries write EU-style rules into their own law, often because their companies are already following them.

Both depend on the same condition, and it’s the one the literature calls non-divisibility: how expensive is it to split your product into an EU version and a rest-of-world version? For data systems in 2018, very. For software in 2026, it depends on what you’re splitting.

Bradford herself is less sure the old logic still holds. In an interview in March, she said: “In the past, companies often chose to comply globally with the toughest standard to keep things simple, but now the toughest standard might earn them punishment elsewhere. If fragmentation intensifies, some firms may run region-specific configurations to meet conflicting requirements.”

Region-specific configurations. Two versions, from the person who named the effect.

Other Countries Copied the Words

If the AI Act were spreading the way GDPR did, you’d expect other countries to adopt something close to it. Three have adopted something that sounds close.

South Korea’s AI Basic Act has applied since 22 January 2026. It has “high-impact” AI, labeling of generative AI output, and a local representative for foreign providers above certain thresholds. It has no list of prohibited practices, and the maximum fine is KRW 30 million, about $20,000. The government has promised at least a year without fines.

Vietnam’s AI law has applied since 1 March 2026, with high, medium and low risk tiers. Baker McKenzie’s summary is that it “contains many terms and references resembling those under the EU AI Act,” along with “many discrepancies and vague issues.” Kazakhstan’s law, in force since 18 January 2026, has risk levels, machine-readable labels on synthetic content, and the list of banned practices closest to the EU’s: manipulation, social scoring, emotion detection without consent. Its fines run to hundreds of dollars, low thousands for a repeat offense.

All three borrowed the shape. Only Vietnam borrowed a version of the machinery: high-risk systems there need a conformity assessment before they’re put into use. None of them borrowed fines calculated as a percentage of worldwide turnover.

Others didn’t follow at all. Japan passed an AI Promotion Act with no monetary penalties. The UK’s King’s Speech in May came and went without an AI bill. And Colorado, which had the most EU-like AI law in the US, postponed it and then, in May, replaced it with a much narrower law focused on notice and human review.

Two researchers, Sina Hoch and Daniel Mügge, concluded that because the EU’s rules are vague, harmonization across borders “remains shallow at best.” The vocabulary traveled. Most of the obligations didn’t.

Inside Companies, It Splits by Obligation

For your company, the de facto version is the one that matters, and it doesn’t come out the same for the whole AI Act. I see three outcomes.

What Travels

Some obligations change something you build once for the whole world. Those travel, because there’s no cheap way to keep them in Europe.

General-purpose AI models are the clearest case. A model is trained once. The rules for general-purpose models in Article 53 require a copyright policy that honors text-and-data-mining opt-outs, so the training data changes for every user of that model, in every country. They also require a public summary of the training content, and a published summary is public everywhere. Preparing EU paperwork about a global model isn’t the Brussels effect. Changing the model because of an EU rule is.

The Code of Practice for these models has 21 signatories, per the Commission’s list as updated on 31 July 2026, including Amazon, Anthropic, Google, IBM, Microsoft, Mistral AI and OpenAI. xAI signed one of its three chapters. Meta declined, saying the Code “introduces a number of legal uncertainties for model developers, as well as measures which go far beyond the scope of the AI Act.” It may. The Code is voluntary. Article 53 isn’t, and it applies to Meta either way.

One timing detail matters here. These obligations have applied since 2 August 2025. Models already on the market before that date have until 2 August 2027 under Article 111(3). Models released since then have had to comply from release, and that’s where many of today’s flagship models sit.

What Stays in the EU

Other obligations attach to systems that were local to begin with. Those stay at the border, because a second version costs almost nothing extra.

Credit scoring is the clean example. A US lender’s model for its American customers and the model it uses for EU customers are rarely the same model. They run on different data, under different credit laws, for different customers. When the high-risk rules in Annex III start applying to credit scoring in December 2027, nothing about them will force the US model to change. The same goes for risk assessment and pricing in life and health insurance, the other financial use on the list.

Hiring is less clean. A recruitment tool built for one country’s market stays there. A global HR platform running one model for customers worldwide may well end up applying the EU rules everywhere, simply because a second version of the platform would be the expensive option.

What Skips the EU

Bradford’s theory assumes companies can’t afford to walk away from the EU market. For a single product, sometimes they can. If complying costs more than the EU market is worth for that product, it doesn’t launch in the EU.

You can’t cheaply train an EU-only model. You can cheaply not ship one. Meta held back its multimodal model from the EU in 2024, over data protection questions. Apple is holding back Siri AI this year, over the Digital Markets Act. Neither is about the AI Act, but the mechanism is the same: the rule stays in Europe because the product never arrives.

A Note on Watermarks

Another likely global default is the machine-readable marking of AI-generated content under Article 50, which has applied since 2 August 2026. Systems that were already on the market have until 2 December 2026. A mark is added where content is generated, and marking only the outputs that end up in Europe is harder than marking all of them.

Brussels can’t take all the credit, though. China’s labeling rules for AI-generated content have been in force since September 2025, with visible labels and metadata. Korea and Kazakhstan require labels too. When both the EU and China want a mark, a global mark is the obvious engineering decision, whichever government asked first.

My reading of all this, which is close to what Marco Almada and Anca Radu warned about back in 2024: what travels is the engineering. Training choices, published summaries, watermarks. What mostly stays home is the part about people, the high-risk rules on credit, insurance and hiring decisions, which is where the AI Act’s fundamental rights protections sit.

Your First AI Act Contact Probably Won’t Be a Regulator

Every Member State had to designate market surveillance authorities by 2 August 2025. Per the Commission’s list as updated on 7 September 2026, nine have a designation that isn’t marked as pending. Twelve are still waiting for the national decision to be finally adopted, and six have no authority listed at all. Slovakia, where I live, is one of the six (a bill naming the digital ministry is in parliament). I’d tell you who to call, but the list doesn’t know either.

The AI Act applies everywhere in the EU. The machinery for enforcing it is still being assembled. So for many companies outside the EU, the AI Act won’t first arrive as a letter from an authority. It will arrive as a questionnaire, or a clause, from an EU customer. Which questions come depends on what that customer is.

If your EU customer uses your tool as supplied, it’s a deployer. Its questions come from its own obligations: AI literacy, GDPR, third-party risk rules if it’s a bank or insurer, and from 2 December 2027 the duties of a deployer of a high-risk system under Article 26. It needs things from you to meet them, and it will ask.

If your EU customer builds your model or component into a high-risk system it sells under its own name, it’s a provider, and Article 25(4) applies from December 2027. The two of you will have to agree in writing what information, capabilities and technical access you hand over. Since the Digital Omnibus, that explicitly includes AI models. And if what you supply is a general-purpose model, you don’t have to wait for 2027: Article 53 already requires you to give downstream providers documentation about it (on the same timeline as above).

Neither of these is a threat. It’s the AI Act arriving in a form you can prepare for, from someone who wants to keep buying from you. The questions I’d expect are the ones in my vendor questions piece, and a vendor who has the answers ready makes those conversations a lot shorter.

Four Assumptions I See Most Often

None of these comes from a survey. They’re the four I run into most, in comments and questions from readers outside the EU.

“It all starts in 2027.” Only the high-risk rules moved. The Digital Omnibus deferred them to 2 December 2027 (and August 2028 for AI built into regulated products like medical devices). The prohibitions and the AI literacy duty have applied since February 2025, the rules for general-purpose models since August 2025 (with the transition for older models noted above), and the transparency rules in Article 50 since August 2026. Some of the AI Act is already your problem.

“No EU entity, no problem.” This one is plainly wrong. If you offer your system to customers in the EU, Article 2(1)(a) catches you as a provider “irrespective of whether those providers are established or located within the Union or in a third country.” One EU customer you knowingly serve can be enough.

If you don’t offer it in the EU, Article 2(1)(c) can still catch you “where the output produced by the AI system is used in the Union.” Recital 22 points toward output “intended to be used in the Union,” but a recital guides interpretation, it doesn’t rewrite the article. Whether someone opening your output in Dublin makes it output used in the Union is not settled. I wouldn’t bet a product on either answer.

“The risk is a fine.” It is, eventually. Breaching the prohibitions can cost up to €35 million or 7% of worldwide turnover, and the transparency rules up to €15 million or 3%. But with a third of the authorities designated, the first cost for many companies is more ordinary: a deal that stalls because the answers to a customer’s questionnaire weren’t ready.

“We’ll comply globally, like we did with GDPR.” That was a reasonable default for data. For the AI Act it’s a decision you make per obligation. Global for anything baked into the model or the output. EU-only for systems that were local anyway. And for high-risk systems, one more date: providers outside the EU will need an authorized representative in the EU before making the system available there, from December 2027 (August 2028 for AI in regulated products), under Article 22. For general-purpose models, the equivalent rule in Article 54 already applies, with the same transition for older models.

Did the Omnibus End It?

The Digital Omnibus deferred the high-risk rules and softened the AI literacy duty. It’s easy to read that as Brussels losing its nerve, and Bradford thinks “the high-water mark of Europe’s regulatory leadership is behind us.”

The US pressure is real, but it has been aimed at EU digital rules generally rather than the AI Act specifically. When the US Trade Representative threatened retaliation in December 2025, it named European companies as possible targets rather than EU laws. One of them was Mistral AI, which had signed the Code of Practice.

And the Omnibus didn’t only delay. It left the prohibitions and the general-purpose model rules in place, and Article 50 largely in place. It added two new prohibitions (on AI-generated non-consensual intimate imagery and child sexual abuse material, from 2 December 2026). And it gave systems already on the market only four months’ grace for marking AI-generated content, less than the Commission had proposed. It mostly changed the dates. It didn’t change which obligations are cheaper to apply once than twice.

Subscribe now

What to Do With This

Sort your AI Act obligations by the three outcomes before anyone asks you to. Anything that changes the model or the output (training data choices, published summaries, marking) you’ll probably end up applying everywhere, so design it once. Anything tied to a system that serves EU customers only, keep separate and scope it to the EU. Anything that would need a product built only for Europe, decide early whether the EU market is worth it, because that decision gets harder once customers are waiting.

Find out what your EU customers are. For each one, know whether it uses your system or builds it into its own, because that tells you which questions are coming.

Check the dates that apply now rather than the one in the headlines. The prohibitions and the AI literacy duty apply. The general-purpose model rules apply. Article 50 applies. The high-risk rules don’t yet.

The Brussels effect for AI won’t be decided in Brussels. It’ll be decided one obligation at a time, by whoever in your company compares the cost of one version with the cost of two.

Like this article? The AI Governance Roadmap is something you can use in practice. It’s a company’s roadmap with steps and working documents. It includes the classification, the inventory spreadsheet, the role assignment, the vendor questions, the AI policy template. Everything a company needs to govern AI, at one place.

I woke up to a WhatsApp message at 5:04 am.

“Are you there? One more.”

I felt the knot in my stomach immediately. I jumped out of bed and replied right away. “I’m here. Who?”

It was a rainy morning in late October 2025, near the end of my sixth year working for Amazon’s headquarters. I was on a contracts team where most of the lawyers were from the US, a few were from India, and I was the only lawyer from the EU.

On Tuesday that week, an email went out to everyone at Amazon: 14,000 corporate positions would be eliminated. Then people started receiving emails or phone calls, one by one. They were disconnected immediately, their badges deactivated.

Those of us who stayed didn’t know who had left, or whether we were next.

It was by far the worst week of my corporate career.

And I felt guilty, too.

Two years earlier, I had started working on contract review automation project. It grew into an AI bot, then took on generative AI, and the tool kept getting better. It became one of Amazon’s first generative AI success stories and was featured in the Wall Street Journal. I received an award for it from a VP during a visit to Seattle.

But that October it ate me up from inside. Part of my job was to show how much time the tool saved. Everyone was talking about AI bringing layoffs, and I thought: you need to stay on top of it. If you learn to work with AI, your job won’t be eliminated.

However, the jobs of your colleagues can.

That’s what I didn’t see then.

When the layoffs hit, they sent me spiraling through so many emotions. Was it my fault? Could I have prevented it? Or was I too small a part of this, and it would have happened with or without me?

I guess I’ll never know.

I resigned two months later.

Today I work in a regulated industry in the EU which is a very different environment. Processes are different. Approvals are more measured.

Last week, two things happened at once and they made me think about my time at Amazon.

I took part in a round table discussion in the Slovak AI community, where we talked about AI adoption, AI transformation and what’s blocking it. We talked about layoffs too. I couldn’t help noticing how different the approach was. Several companies described slow processes and waiting for approvals from parent companies in other EU countries. Heavy regulation on top of the AI Act. And layoffs? Not anytime soon. The mood in the room was that AI can’t replace us yet.

When I got home, I opened LinkedIn and a Business Insider article popped up: Amazon is trying to rehire workers it laid off. Mostly for AI and cloud roles.

But Amazon wasn’t the only company cutting jobs in 2025. Meta, Microsoft and Google did too. Did US companies misjudge the speed of AI adoption?

In the EU, all of these decisions are still ahead of us.

Which made me wonder: is the EU behind on AI?

Subscribe now

Level at the Start

If the question is whether European companies have started using AI, the EU isn’t behind. In 2025 the European Investment Bank asked firms on both sides of the Atlantic the same question. 37% of EU firms were using generative AI. In the US, it’s 36%.

Eurostat counts differently and lands lower: 20% of EU companies with ten or more employees used some form of AI in 2025, up from 8.1% two years earlier. Among large companies it’s 55%. The spread inside the EU is wider than the one across the Atlantic, with Denmark at 42% and Romania at 5.2%. Slovakia, where I’m from, sits at 18%.

So the starting line is roughly level.

Behind After That

The same EIB survey asked how far AI had spread inside companies that were already using it. 81% of US firms had it in more than two business activities. In the EU, it’s 55%.

Workers show the same pattern. In a paper published by the St. Louis Fed, economists surveyed workers in the US and six European countries (the UK, Germany, France, Italy, Sweden and the Netherlands) with identical questions. 43% of American workers use AI for work, against 32% in the European countries. Americans spend 5.2% of their working hours with it. Europeans spend between 1.5% (France) and 2.8% (the UK).

Insurance shows what that looks like in one sector. When EIOPA surveyed 347 insurance undertakings, nearly two-thirds were using generative AI. And yet: “Most undertakings are nevertheless still at a proof-of-concept stage.” The supervisor calls it “a considerate, controlled roll-out.” Anyone who has worked in a large company has a less diplomatic word for it.

Then there's the money. According to the Stanford AI Index, private AI investment in the US reached $285.9 billion in 2025. Europe as a whole: $20.9 billion. The US invested almost 14 times as much, and the gap is growing. US investment rose 160% on the previous year, Europe's rose 7%.

It looks like European companies aren’t refusing AI. They start, run the pilot, and then it slows.

Mostly, It’s How Companies Are Run

The St. Louis Fed paper breaks the US–Europe difference in worker adoption into pieces.

About 55% of it is simply what the economies are made of: which industries, which jobs, what size of company, how old and how educated the workforce is. Small firms adopt less everywhere, and Europe has far fewer large tech companies. Comparing Amazon with a European bank or insurer compares two sectors as much as two continents, and the paper puts a number on how much of the difference comes from that kind of thing.

The rest comes down to one question: does your employer encourage you to use AI and give you the tools to do it? 42% of US workers get both. In France and Italy, 16 to 17%. Once the researchers added encouragement to their model, “almost all of the US-Europe adoption gap is accounted for.” The paper also found that “AI training does not predict higher adoption once we control for encouragement and tool provision.” Training on its own, without permission and a tool to use, doesn’t move the number.

The paper doesn't measure approval processes. But while a tool waits for approval, employees are being told "not yet", which is the opposite of encouragement.

What the AI Act Did

The AI Act entered into force on 1 August 2024. The first obligations that apply to companies using AI, AI literacy and the prohibited practices, started in February 2025. The AI Act mostly didn’t slow anyone down by what it required. It slowed them down by what it was about to require.

For banks and insurers, that was concrete. Creditworthiness assessment and credit scoring of individuals, and risk assessment and pricing for individuals in life and health insurance, are on the Annex III high-risk list, and those obligations were due on August 2, 2026. Many regulated companies spent 2025 preparing for a date that was written into law. Then the Digital Omnibus moved it to December 2, 2027. The delay entered into force on July 27, 2026, six days before the original deadline. Before that came months of not knowing whether the delay would happen at all, which slows a project down in its own way.

Legal uncertainty in general shows up in the data. Among EU firms that looked at AI and decided against it, 53.6% said they couldn’t tell what the legal consequences would be. That group is small: roughly 6% of all EU companies with ten or more employees. “Legal consequences” can also mean the GDPR, liability and copyright, not only the AI Act. The top reason, at 70.3%, was lack of expertise.

I’d like to stop there, but a September survey by Bitkom, Germany’s digital industry association, doesn’t let me. It covers German companies with 20 or more employees and asks a different question from Eurostat, so the numbers don’t compare directly. 57% of German firms now use AI, up from 20% two years ago. And 66% say the AI Act brings more disadvantages than advantages, up from 56% last year. Bitkom’s president said that the AI Act should build trust, but it creates widespread uncertainty.

Companies are adopting AI and resenting the AI Act more this year than last. Perception isn’t proof of cause, and the complaints grew in the same year that adoption jumped from 36% to 57%. But it would be dishonest of me to say the AI Act plays no part. It plays a part. But the evidence says it’s not the main one.

It’s also been blamed for things it had nothing to do with. The most visible “EU blocks AI” story this year was Apple holding back Siri AI in the EU, citing the Digital Markets Act. The Commission’s reply: “The decision not to roll out Siri AI in the EU is Apple’s and Apple’s only.” Whoever is right, the AI Act wasn’t in that fight.

The Brakes That Aren’t in the AI Act

In financial services, most of the approval chain existed before the AI Act. Third-party risk, outsourcing and data protection reviews run on every new tool, AI or not. An AI tool bought from a vendor is, before anything else, a new vendor.

Group structures add another layer, in any sector. A subsidiary of a group headquartered in another country often needs group sign-off on vendors and security on top of its own reviews. Each review is reasonable on its own. Run one after another, they add up.

Some brakes are national. In Germany, employers with a works council generally need its agreement before rolling out a company tool that could be used to monitor employees, and many workplace AI tools could be. A Hamburg labor court found no such right when staff used ChatGPT voluntarily through private accounts the employer couldn’t see (a first-instance decision, in interim proceedings). The same tool, provided and paid for by the company, is a different conversation. Most American rollouts have no equivalent step.

And some of it is simply how decisions get made. In his 2016 shareholder letter, Jeff Bezos split decisions into two kinds. Some are irreversible and deserve care. But “many decisions are reversible, two-way doors. Those decisions can use a light-weight process.” He added: “If you wait for 90%, in most cases, you’re probably being slow.” I have lived by those at Amazon.

Regulated companies tend to send every AI tool through the process built for irreversible decisions. However, an internal drafting assistant should not get the same review as a credit scoring model.

What to Do With This

If you sit in the approval chain, sort what’s waiting into two piles: the tools you could switch off tomorrow without harm, and the ones you couldn’t. They don’t need the same process, and you don’t want the first pile end up waiting behind the second.

Separate the AI Act question from the vendor question. For most internal productivity tools, the AI Act question is short. They aren’t Annex III use cases, so the high-risk rules won’t apply to them in 2027 either, unless you start using them for something on the list, like screening job applicants or evaluating employee performance.

The second one is the realistic trap: a meeting summarizer whose notes start feeding performance reviews has drifted onto the list, and a deployer who changes a tool’s purpose that way can become its provider. What applies today is AI literacy, the prohibitions (including the ban on emotion recognition at work) and, in specific cases, the transparency duties in Article 50. The vendor, security and data protection reviews are longer, and they would run anyway.

Don’t let December 2, 2027 govern tools it doesn’t apply to. The high-risk deadline is real for credit scoring and insurance pricing. For a meeting summarizer, it’s not.

If you sell AI into regulated European companies, the long sales cycle is mostly your buyer’s vendor-review machinery, not their AI Act anxiety. Arriving with the answers that machinery asks for (where the data goes, who your subprocessors are, how you handle incidents) will likely shorten it more than any AI Act compliance badge.

Subscribe now

Does Slower Mean Fewer Layoffs?

From March to July, AI was the most common reason US companies gave for cutting jobs. Challenger, Gray & Christmascounted more than 116,000 announced cuts attributed to AI in the first eight months of 2026. In August, AI dropped to fourth place, and hiring plans were up 37% on last year. As Andy Challenger put it in July: “AI-related cutting has been limited outside of the Tech sector.”

Many of those cuts may be premature. A Harvard Business Review survey of 1,006 executives found that AI-related layoffs are “almost completely in anticipation of AI’s impact,” not a response to what AI has actually delivered. The authors warn about companies “having to rehire in embarrassing retreats.”

So did US companies misjudge the speed of AI adoption?

Some of them, it seems, cut for the AI they expected rather than the AI they had.

Stanford researchers using payroll data found that employment of 22- to 25-year-olds in the most AI-exposed occupations now sits about 19% below the trend of workers the same age in less-exposed jobs. That’s driven by fewer young people being hired, not more people being fired.

Europe has no count comparable to Challenger’s, which isn’t the same as having no cuts. Lufthansa has announced 4,000 administrative job cuts by 2030 and pointed to AI. On average, though, the ECB finds that “companies that make significant use of AI are about 4% more likely to take on additional staff.” Only 15% of firms using AI cite cutting labor costs as a reason.

European labor law slows firing. EU rules on collective redundancies require consultation above certain thresholds, and national dismissal rules add more. None of it applies to hiring. Not hiring a graduate needs no consultation.

Slower adoption may mean fewer AI layoffs for now. A slower European company might avoid the fire-then-rehire mistake. Or it might make the same mistake later, in a different form: fewer graduates hired, and no one fired.

The last time Europe was slow with a technology, the cost wasn’t measured in jobs. The Draghi report found that, “excluding the main ICT sectors,” EU productivity “has been broadly at par with the US in the period 2000-2019.” The difference was the tech sector. It cost Europe productivity growth, and the companies: “only four of the world’s top 50 tech companies are European.”

Whether AI goes the same way, I don’t know. I do know that usually no one gets fired over an approval that took months. That’s what makes it easy to keep waiting.

Like this article? The AI Governance Roadmap is something you can use in practice. It’s a company’s roadmap with steps and working documents. It includes the classification, the inventory spreadsheet, the role assignment, the vendor questions, the AI policy template. Everything a company needs to govern AI, at one place.

Article 3 of the EU AI Act runs to seventy definitions. Sixty-eight numbered points, plus two the Digital Omnibus inserted in July.

“High-risk AI system” is not one of them.

Neither is “AI model”, “algorithm”, “AI tool”, or “user.”

The AI Act does define “floating-point operation”, “publicly accessible space”, and “sandbox plan”.

The words you argue about in a call are either missing from the list, or on the list and meaning something different than the meaning you brought to the call.

This is a glossary of both kinds. Each entry gives the definition where the AI Act has one, says where there’s no definition, and then says what turns on the difference. It’s grouped by how the words go wrong rather than alphabetically, because alphabetical order only helps when you already know which word you need.

Subscribe now

Words the AI Act Redefines

Provider

Article 3(3): a person or body

“that develops an AI system or a general-purpose AI model or that has an AI system or a general-purpose AI model developed and places it on the market or puts the AI system into service under its own name or trademark, whether for payment or free of charge.”

Not “the vendor”. There are two ways you can become a provider: you place an AI system on the market, or you put it into service. Putting into service covers your own use, so an internal build you never sell makes you its provider.

“Has an AI system developed” catches you if a supplier built it and your name went on it.

But there’s also a third route: Article 25(1)(a) turns a distributor, importer, deployer or third party into a provider if they “put their name or trademark on a high-risk AI system already placed on the market or put into service, without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated”.

That last clause lets two parties allocate between themselves. It doesn’t bind a regulator, and it sits on 25(1)(a) alone.

You aren’t a provider while you’re still building. Article 2(8) excludes “any research, testing or development activity regarding AI systems or AI models prior to their being placed on the market or put into service”, though testing in real-world conditions is carved back out of that exclusion.

Provider obligations for Annex III high-risk systems start December 2, 2027.

Deployer

Article 3(4): a person or body

“using an AI system under its authority except where the AI system is used in the course of a personal non-professional activity.”

The one whose authority it’s used under, not the one clicking. The person clicking is usually an employee, and the employer is the deployer.

The AI Act never defines under its authority.

Deployer obligations for high-risk systems start December 2, 2027. Deployer transparency duties under Article 50(3) and 50(4) already apply.

Operator

Article 3(8):

“a provider, product manufacturer, deployer, authorised representative, importer or distributor.”

Not a role. An umbrella for all six, used wherever the AI Act means any of them.

Read it as “deployer” and you’ll invert provisions. Article 111(2) applies the Regulation “to operators of high-risk AI systems” already in service, then names “the providers and deployers” specifically in its next sentence. The AI Act switches between the umbrella and the individual roles inside one paragraph.

Placing on the Market

Article 3(9):

“the first making available of an AI system or a general-purpose AI model on the Union market.”

The first supply. The AI Act hangs its dates on that single moment: legacy status, conformity assessment, CE marking, registration.

A distributor who sells the same system to a hundred customers hasn’t placed it on the market. They make it available. The provider or the importer did the placing.

Putting Into Service

Article 3(11):

“the supply of an AI system for first use directly to the deployer or for own use in the Union for its intended purpose.”

The same trigger as placing on the market, reached without a sale. Or for own use is the phrase that turns in-house builds into provider events.

It covers AI systems only. A general-purpose AI model can be placed on the market. It can’t be put into service.

Intended Purpose

Article 3(12):

“the use for which an AI system is intended by the provider, including the specific context and conditions of use, as specified in the information supplied by the provider in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation.”

What the provider says the system is for, not what it’s used for. The AI Act names where it will look, and marketing copy is on the list.

Annex III classification runs on intended purpose. A disclaimer in the terms of service doesn’t fix a product page promising the excluded use: the Commission’s draft guidelines on high-risk classification say so.

Reasonably Foreseeable Misuse

Article 3(13):

“the use of an AI system in a way that is not in accordance with its intended purpose, but which may result from reasonably foreseeable human behaviour or interaction with other systems, including other AI systems.”

The provider owns this too. Declaring a narrow intended purpose doesn’t shed the uses a reasonable person would predict.

Substantial Modification

Article 3(23): a change after placing on the market or putting into service “which is not foreseen or planned in the initial conformity assessment carried out by the provider” and which affects compliance with Chapter III Section 2, or modifies the intended purpose the system was assessed for.

Size is irrelevant here. A small unplanned change is substantial. A large planned one isn’t. The only benchmark is what the initial conformity assessment foresaw.

Make one and Article 25(1)(b) makes you the provider.

The benchmark doesn’t exist for systems already running. A system placed on the market before Chapter III applies never had an initial conformity assessment, so nothing was foreseen or planned in one. That’s the Article 111(2) question.

Legacy status has one hard limit. Article 111(2) opens “without prejudice to the application of Article 5.” An exempt system doing something banned is doing something banned.

Risk

Article 3(2):

“the combination of the probability of an occurrence of harm and the severity of that harm.”

Probability times severity. A two-variable term, not a traffic-light colour.

“High-risk” is not a risk rating, and classification under Article 6(1) and 6(2) never asks you to assess either variable. It asks whether the system is a safety component under Annex I or falls in an Annex III use case.

The Article 3(2) meaning returns at the 6(3) derogation, which asks the risk question directly: an Annex III system isn’t high-risk “where it does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons, including by not materially influencing the outcome of decision making.” It also governs Article 9, the risk management system.

Classification is categorical. The way out of classification is a risk assessment.

Performance

Article 3(18):

“the ability of an AI system to achieve its intended purpose.”

Accuracy and latency don’t enter into it. Performance is defined against intended purpose, so a model with 99% accuracy on the wrong objective has no performance in the AI Act’s sense.

Article 15 accuracy and robustness are judged against this, which means a narrow declared purpose lowers the bar. Article 15 applies from December 2, 2027 for Annex III systems, August 2, 2028 for Annex I. Widen it later and Article 25 catches you: 25(1)(c) if the widening makes a not-high-risk system high-risk, 25(1)(b) if it was high-risk already.

Safety Component

Article 3(14), amended in July:

“a component of a product or of an AI system which fulfils a safety function for that product or AI system, or the failure or malfunctioning of which endangers the health and safety of persons or property.”

The Omnibus added a tail:

“for the purposes of this definition, a component fulfils a safety function where its intended purpose is to prevent or mitigate risks to health and safety of persons or property.”

One of two gateways to Annex I high-risk, the other being a system that is itself a product covered by Annex I. The Omnibus narrowed this one twice over. There are three new paragraphs in Article 6:

• 6(1a): systems “solely used for non-safety related aspects of user assistance, performance optimisation, service efficiency, automation or convenience or quality control” don’t qualify.

• 6(1b): systems whose failure “would endanger health and safety” do.

• 6(1c): a product needing third-party conformity assessment “solely due to risks other than risks to health and safety,” radio spectrum and electromagnetic interference among them, doesn’t satisfy 6(1)(b).

Quality control is named. Annex I obligations start August 2, 2028.

The Role Chain Past Provider and Deployer

The Omnibus left all five definitions alone. It did amend what attaches to them: Articles 25 and 43 both changed.

Authorised Representative

Article 3(5): a person

“located or established in the Union who has received and accepted a written mandate from a provider of an AI system or a general-purpose AI model”

to carry out the provider’s obligations on its behalf.

A mandated agent who accepted the mandate in writing. Your EU subsidiary isn’t one, and neither is your local reseller.

Two separate obligations, both on third-country providers only:

• Article 22(1), for high-risk systems: “Prior to making their high-risk AI systems available on the Union market, providers established in third countries shall, by written mandate, appoint an authorised representative which is established in the Union.”

• Article 54(1), for general-purpose AI models.

Article 54 has applied since August 2, 2025. Article 22 applies from December 2, 2027 for Annex III systems, August 2, 2028 for Annex I.

Importer

Article 3(6): a person

“located or established in the Union that places on the market an AI system that bears the name or trademark of a natural or legal person established in a third country.”

Buying from a US vendor doesn’t make you one. You have to be EU-established and it has to be you doing the placing on the market. If the third-country provider places its own system on the Union market directly, there’s no importer in the chain.

The definition says “an AI system.” There’s no importer role for general-purpose AI models, where Article 3(9) covers both.

Importer obligations sit in Article 23 and start December 2, 2027.

Distributor

Article 3(7): anyone

“in the supply chain, other than the provider or the importer, that makes an AI system available on the Union market.”

A residual category, defined by exclusion. No contract required.

Same omission as the importer: AI systems only, no distributor role for models. Two roles were extended to models and two weren’t, which looks deliberate but who knows.

Distributor obligations sit in Article 24 and start December 2, 2027.

Product Manufacturer

Not defined in Article 3, despite being one of the six operators.

It appears in Article 2(1)(e), and in Article 25(3), which makes the product manufacturer the provider where a high-risk AI system is a safety component of a product covered by Section A of Annex I.

Section A is the operative word. Section B products (aviation, motor vehicles, rail, marine) get a thinner regime, and the Omnibus moved machinery from A to B. Moved, not released: Article 5, Article 50 and Chapter V still apply.

Downstream Provider

Article 3(68):

“a provider of an AI system, including a general-purpose AI system, which integrates an AI model, regardless of whether the AI model is provided by themselves and vertically integrated or provided by another entity based on contractual relations.”

A provider, of an AI system, positioned below a model. It’s heard as “the customer,” which it isn’t. It also covers vertical integration, so a company that builds its own model and its own system on top is a downstream provider of itself.

The consequence is the information you’re owed. Article 53(1)(b) requires model providers to give downstream providers what they need “to have a good understanding of the capabilities and limitations of the general-purpose AI model and to comply with their obligations pursuant to this Regulation.” Call yourself a deployer and you won’t know to ask. Article 53 has applied since August 2, 2025.

Terms That Get Used Interchangeably

AI System

Article 3(1):

“a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments.”

The core unit of the Regulation. Almost everything in Chapters II, III and IV attaches to this and not to a model.

AI Model

Not defined in the AI Act. The phrase is used and never explained: inside Article 3(63), inside Article 3(68), and in Article 2. The Omnibus added it to Article 25(4) in July, to the list of things a third party can supply into a high-risk system. A new obligation hung on an undefined word, two years after the AI Act passed.

The AI Act does explain the relationship, just not in a definition. Recital 97: “Although AI models are essential components of AI systems, they do not constitute AI systems on their own. AI models require the addition of further components, such as for example a user interface, to become AI systems.”

In ordinary technical use that means the model is the trained artefact, the weights and architecture that turn an input into an output, and the system is the model plus what makes it usable.

Only one kind of model is regulated as a model, and that’s the general-purpose kind. A narrow single-task model that isn’t part of any system sits outside both regimes.

General-Purpose AI Model

Article 3(63):

“an AI model, including where such an AI model is trained with a large amount of data using self-supervision at scale, that displays significant generality and is capable of competently performing a wide range of distinct tasks regardless of the way the model is placed on the market and that can be integrated into a variety of downstream systems or applications, except AI models that are used for research, development or prototyping activities before they are placed on the market.”

Two limbs get dropped when this is quoted: integration into a variety of downstream systems, and the research and prototyping carve-out. Both are in the definition.

The indicative threshold is 10^23 floating-point operations of training compute, in the Annex to Commission Decision C(2025) 5045 final of 18 July 2025. Guidance, not law.

Obligations for model providers, Articles 53 to 55, have applied since 2 August 2025. Models placed on the market before that date have until 2 August 2027.

“We built it ourselves and only we use it” is an exit with three conditions. Recital 97: where a provider “integrates an own model into its own AI system that is made available on the market or put into service, that model should be considered to be placed on the market.” The carve-out applies only where the model is used “for purely internal processes” that are “not essential for providing a product or a service to third parties” and where “the rights of natural persons are not affected.” A bank running an own model behind a customer-facing service fails the second condition. A model scoring employees fails the third.

General-Purpose AI System

Article 3(66):

“an AI system which is based on a general-purpose AI model and which has the capability to serve a variety of purposes, both for direct use as well as for integration in other AI systems.”

A system built on a general-purpose model. It can be high-risk under Article 6 like any other system, and the model underneath it stays on its own separate track of obligations.

Model duties started August 2, 2025. Annex III system duties start December 2, 2027. Annex I system duties start 2 August 2028.

High-Risk AI System

Not defined in Article 3. Article 6 decides it instead, by two routes.

Article 6(1), the product route: the system is “intended to be used as a safety component of a product,” or is itself a product, covered by the “Union harmonisation legislation” listed in Annex I, and that product must undergo third-party conformity assessment. Note the words “intended to be used as.” Classification runs on intended purpose here too.

Article 6(2), the use-case route: the system falls within Annex III. Eight areas: biometrics, critical infrastructure, education and vocational training, employment, access to essential private and public services, law enforcement, migration and border control, administration of justice and democratic processes.

Article 6(3) is the way out of the Annex III route, for systems that don’t “pose a significant risk of harm to the health, safety or fundamental rights of natural persons, including by not materially influencing the outcome of decision making.”

But the AI system also has to fit at least one of four listed conditions:

• “intended to perform a narrow procedural task,”

• “intended to improve the result of a previously completed human activity,”

• “intended to detect decision-making patterns or deviations from prior decision-making patterns” without replacing a human assessment, or

• “intended to perform a preparatory task to an assessment.” Every one of them turns on intended purpose again.

However: “Notwithstanding the first subparagraph, an AI system referred to in Annex III shall always be considered to be high-risk where the AI system performs profiling of natural persons.”

For most Annex III systems that touch individuals, profiling closes the door before the first exemption opens. Take the derogation anyway and Article 6(4) requires you to document the assessment.

Neither route asks how risky the system is in the ordinary sense. Provider and deployer obligations for Annex III systems start December 2, 2027, and for Annex I systems August 2, 2028.

Systemic Risk

Article 3(65):

“a risk that is specific to the high-impact capabilities of general-purpose AI models, having a significant impact on the Union market due to their reach, or due to actual or reasonably foreseeable negative effects on public health, safety, public security, fundamental rights, or the society as a whole.”

This attaches to general-purpose AI models and to nothing else. It isn’t a worse tier of high-risk, and an AI system can’t enter the category. A hiring tool is never a systemic-risk anything.

Article 51(2) sets the presumption: a model is presumed to have high-impact capabilities when training compute is “greater than 10^25” floating-point operations. That one is in the AI Act, not in guidance.

Two separate ladders. High risk runs through Article 6 and Chapter III, from December 2027. Systemic risk runs through Articles 51 and 55, since August 2025.

Classification and Role

Neither is defined.

Classification is a property of the system: prohibited under Article 5, high-risk under Article 6, transparency-triggering under Article 50, or none of those.

Role is a property of you: provider, deployer, importer, distributor, authorised representative, product manufacturer.

Your obligations are the product of the two. High-risk plus provider is Article 16. High-risk plus deployer is Article 26. Not-high-risk plus provider is still a documented assessment under Article 6(4) and a registration under Article 49(2).

Those last two arrive on different dates. Article 49(2) sits in Chapter III Section 5, which Article 113 doesn’t defer, so it has been in application since August 2, 2026. Article 6(4), which produces the assessment it registers, arrives sixteen months later.

“Is our AI high-risk?” is usually unanswerable as asked. It’s a role question in a classification question’s clothes.

Conformity Assessment, CE Marking, Notified Body

Three terms, three definitions, and they aren’t steps in one process.

Conformity assessment, Article 3(20): “the process of demonstrating whether the requirements set out in Chapter III, Section 2 relating to a high-risk AI system have been fulfilled.” The demonstrating, by whoever has to do it.

CE marking, Article 3(24): “a marking by which a provider indicates that an AI system is in conformity with the requirements set out in Chapter III, Section 2 and other applicable Union harmonisation legislation providing for its affixing.” A provider indicates. Not an assessor.

Notified body, Article 3(22): “a conformity assessment body notified in accordance with this Regulation and other relevant Union harmonisation legislation.” The second half is why one body can be notified for medical devices and for the AI Act at once. Required for very little on the Annex III side, as the closing section sets out.

Again it applies from December 2, 2027 for Annex III systems, August 2, 2028 for Annex I.

FRIA

Fundamental Rights Impact Assessment. The abbreviation is a practitioner invention. The AI Act writes the phrase out, in the heading of Article 27, in Article 27(2) and in Article 5(2), and never abbreviates or defines it. Article 27(1) simply requires certain deployers to perform “an assessment of the impact on fundamental rights that the use of such system may produce,” then lists six things it has to contain.

It’s a two-condition test and both conditions get dropped.

The system has to be one “referred to in Article 6(2),” which means Annex III. A FRIA never attaches to an Annex I high-risk system, however public the deployer. Annex III point 2, critical infrastructure, is exempt even then.

The deployer has to be a body governed by public law, a private entity providing public services, or a deployer of an Annex III point 5(b) or 5(c) system, which is credit scoring and life and health insurance. Fail either condition and you owe no FRIA.

You don’t do one per deployment. Article 27(2): the obligation “applies to the first use of the high-risk AI system,” and the deployer “may, in similar cases, rely on previously conducted fundamental rights impact assessments or existing impact assessments carried out by provider.” If the elements change or go stale, you update.

Applies from December 2, 2027.

DPIA

Data Protection Impact Assessment. It’s not an AI Act instrument. GDPR Article 35 requires one where processing is likely to result in a high risk to people’s rights and freedoms, and it assesses the processing of personal data.

The difference in one line: a DPIA asks what your processing does to personal data. A FRIA asks what the system’s use does to fundamental rights, which is broader and covers people whose data you never process.

They overlap, and the Omnibus changed how. The amended Article 27(4) is permissive: where a DPIA already meets one of the Article 27 obligations, the deployer “may” cross-reference the relevant sections or include relevant parts. The older text said the FRIA “shall complement” the DPIA. That sentence is gone, so an alert quoting it predates the Omnibus.

What a DPIA can’t reach is the elements it doesn’t cover, and two of the six aren’t GDPR territory: 27(1)(b), the period and frequency of intended use, and 27(1)(e), the human oversight measures.

Article 27(5) has the AI Office building “a template for a questionnaire, including through an automated tool,” to let deployers comply “in a simplified manner.” That has been in the AI Act since 2024.

The binding link runs the other way. Article 26(9): deployers of high-risk systems “shall use the information provided under Article 13 of this Regulation to comply with their obligation to carry out a data protection impact assessment.” FRIA to DPIA is optional. Article 13 information to DPIA is mandatory.

Quality Management System

Article 17(1): “Providers of high-risk AI systems shall put a quality management system in place that ensures compliance with this Regulation.” The paragraph then lists what it has to contain, starting with “a strategy for regulatory compliance.”

This is what the AI Act actually names, and it’s owed by providers of high-risk systems only. Not an AI policy. Not a governance framework.

It’s specific enough that another regime can be deemed to satisfy it. Article 17(4): providers that are financial institutions subject to internal governance requirements under Union financial services law are deemed to satisfy the QMS obligation by complying with those governance rules, except for risk management, post-market monitoring and serious-incident reporting. The deeming is conditional on the complying.

Applies December 2, 2027.

Training, Validation, Testing and Input Data

Four defined terms for what usually gets called one.

• Training data, Article 3(29): “data used for training an AI system through fitting its learnable parameters.”

• Validation data, Article 3(30): data for evaluating the trained system and tuning its non-learnable parameters, “in order, inter alia, to prevent underfitting or overfitting.”

• Testing data, Article 3(32): data for “an independent evaluation of the AI system in order to confirm the expected performance of that system before its placing on the market or putting into service.”

• Input data, Article 3(33): “data provided to or directly acquired by an AI system on the basis of which the system produces an output.”

The first three are the provider’s, under Article 10 data governance. Input data is the deployer’s, under Article 26(4), which scopes it: “to the extent the deployer exercises control over the input data,” the deployer ensures it’s “relevant and sufficiently representative in view of the intended purpose.”

Feed your own records into a bought-in system and that’s yours. If the system pulls its inputs from a third-party feed, arguably it isn’t. Both provisions apply December 2, 2027.

Other Words

Three of these do appear in the AI Act but are not defined.

Shadow AI

Not in the AI Act, or anywhere in EU law. Industry shorthand for employees using AI tools their organization never approved or inventoried.

The AI Act’s nearest equivalent is the deployer test: a system used “under its authority.” Corporate card, corporate work, and the employer is almost certainly the deployer. Personal account on a personal device producing work output is genuinely open.

Article 4, amended in July, has providers and deployers taking “measures to support the development of AI literacy” of staff and others operating systems on their behalf. The amendment also added: “This obligation does not require providers or deployers to guarantee any specific level of AI literacy of any individual.”

Article 50(3) and 50(4) deployer transparency duties have applied since August 2, 2026. An employee producing a deep fake on an unapproved tool is a live disclosure question now.

You can’t train staff on AI systems you don’t know exist, and the AI Act has no word for the systems you don’t know exist.

AI Tool

Not in the AI Act. Not defined, not a category, not a threshold.

In general use it means a piece of software with AI in it. The AI Act’s test is Article 3(1), which asks nothing about price, size or procurement. A twenty-euro browser extension that infers outputs influencing decisions is an AI system.

It usually arrives with a companion sentence: “so we’re just users.” There’s no user role.

Algorithm

In the AI Act once, and not as a category. Annex IV point 2(b) requires technical documentation to describe “the general logic of the AI system and of the algorithms.” Something you document, never something you classify.

Outside the AI Act it covers any defined computational procedure, from a sorting routine to a neural network. That breadth is why it’s useless as a legal test.

“It’s just an algorithm, not AI” isn’t an argument the Regulation recognizes, because it never asks the question. It asks the Article 3(1) question. The nearest thing to a real exclusion is in the Commission’s guidelines on the AI system definition, the Annex to Commission Decision C(2025) 924 final of 6 February 2025, which is non-binding and gives “linear or logistic regression methods” as an example of systems for improving mathematical optimization. Whether that gets your model out is contested.

User

Deleted from the AI Act. “User” was the term in the European Commission’s 2021 proposal. The final text replaced it with “deployer,” and no obligation attaches to a user anywhere.

The word survives only in compounds, like Annex IV’s “user-interface provided to the deployer” and Article 6(1a)’s “user assistance.”

Every vendor document that says “the user is responsible for X” allocates to a role that doesn’t exist. Between the two of you it may still work as a contract. It tells a regulator nothing about who the deployer is.

AI Governance Framework

Not a term of art in the AI Act. “Governance” appears as data governance in Article 10(2), as “arrangements for internal governance and complaint mechanisms” inside the FRIA contents, and as “internal governance, arrangements or processes” in the financial-institution provisions. Chapter VII is headed governance and covers the AI Office and national authorities, which is the regulator’s governance rather than yours.

Companies use it for the whole internal apparatus: policies, committees, inventories, sign-off gates.

The Article 17 QMS. The Article 9 risk management system. The Article 27 FRIA. And the Article 26(2) assignment of human oversight to people with “the necessary competence, training and authority,” which means a person you can name.

A framework can hold all four. It’s the container, and nothing in the AI Act requires the container.

However, article 26(1) requires “appropriate technical and organisational measures,” Article 26(2) requires the oversight staffing, and Article 4 already applies. But a policy is the ordinary way of discharging all three.

Subscribe now

Are You Compliant with the AI Act?

Article 43(2):

“For high-risk AI systems referred to in points 2 to 8 of Annex III, providers shall follow the conformity assessment procedure based on internal control as referred to in Annex VI, which does not provide for the involvement of a notified body.”

Points 2 to 8 is every high-risk use case except biometrics. Critical infrastructure. Education. Employment. Essential private and public services, which is where credit scoring and life and health insurance sit. Law enforcement. Migration. Justice.

You assess yourself. You affix your own marking. “Audit” appears once in the whole machinery, at Annex VII point 5.3, on the notified body route that points 2 to 8 can’t use.

Real certificates exist under Annex VII for Annex I products and Annex III point 1, and Article 42(2) recognizes a cybersecurity certificate once its scheme is published in the Official Journal. Neither is what a vendor means by AI Act certified for a hiring tool.

For that there’s no certificate and no one to issue it. Only you, signing your own declaration against requirements that don’t apply until December 2, 2027, in words the AI Act defined and your vendor didn’t.

Like this article? The AI Governance Roadmap is something you can use in practice. It’s a company’s roadmap with steps and working documents: the classification, inventory spreadsheet, role assignment, vendor questions and AI policy template. Everything a company needs to govern AI, in one place.

An Austrian mobile operator refused to sign a customer up for a phone contract. The contract would have cost her €10 a month. The operator’s reason was her credit standing, which an automated assessment run by Dun & Bradstreet Austria had found insufficient.

The customer asked how that assessment had been made. The answer she got didn’t satisfy her, and an Austrian court later found, in a final decision, that Dun & Bradstreet had breached the GDPR by failing to give her “meaningful information about the logic involved”. Enforcing that decision raised more questions, and those went to the Court of Justice of the EU. The case was registered in 2022. The judgment came on 27 February 2025.

A ten-euro phone contract, three years in Luxembourg.

That case was decided under data protection law. When I read the European Commission’s draft guidelines on high-risk classification, published in May, I could see that one of their examples of a high-risk credit system is a credit agency whose scores are shared with a third party deciding whether to grant “a loan/mortgage or access to housing, healthcare or telecommunication services”.

If you build, buy or run credit scoring systems with AI, the EU AI Act has a use case for it. Point 5(b) of Annex III. The obligations attached to it apply from 2 December 2027. What’s still open is which of your credit systems it actually reaches, and the draft guidelines answer some of those questions.

Subscribe now

What Point 5(b) Says

The text is one line:

“AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud;”

The Digital Omnibus didn’t touch it.

It covers two use cases, and a system only needs to be intended for one of them.

Evaluating creditworthiness means assessing a person’s ability and willingness to pay for a service or repay credit.

Establishing a credit score means building a representation of that creditworthiness, and the draft guidelines are clear that the form doesn’t matter: “a number, a ranking, or a label”. Renaming your score a “customer tier” doesn’t take it out.

Then, the guidelines add that a system intended to produce such a score for deciding access to financial resources or essential services is high-risk “regardless of other purpose the AI system may have”. The compliance assessment “should be limited to the intended high-risk purpose,” which is a small mercy for the multipurpose platforms.

Pricing gets its own line. A system that only prices credit isn’t covered, even if it uses creditworthiness data. A system that assesses creditworthiness and sets the price in one integrated process is.

There Are Three Gates to Look At

Before any of the 5(b) obligations reach a credit scoring system, three things have to be true. Whether it profiles people only matters after that.

First, it has to be an AI system. The Commission’s 2025 guidelines on the AI system definition list “linear or logistic regression methods” as an example of systems that improve mathematical optimization and can fall outside the definition. A large share of traditional credit scorecards are logistic regressions. Whether yours falls outside is a real question.

Second, its intended purpose has to be 5(b). The draft guidelines list what falls outside:

• customer classification for information duties, suitability or personalized marketing, “so long as the classification does not play a part in the assessment of the creditworthiness”

• segmentation and pricing simulations that are distinct from the creditworthiness system

• chatbots that help applicants fill in the form, and complaint-handling tools after the decision

• tools that monitor credit exposures after the loan is granted, for internal prudential purposes

• collateral valuation, where the system looks only at the asset

Every item comes with a condition. Once the marketing segmentation starts feeding the credit decision, it’s no longer marketing segmentation.

Third, the AI Act has to apply to it at all. A legacy model is still a 5(b) system, but Article 111(2) keeps its operators outside most of the AI Act. More on that below.

Essential Credit, and Credit That Isn’t Essential

Annex III point 5 of the EU AI Act is about access to “essential private services”. Point 5(b) doesn’t repeat the word, but the draft guidelines read it in anyway.

Their list of financial services that count as essential:

• a bank account,

• payment services (including an overdraft that supports a transaction),

• loans and credit, extending a credit line or card limit, and

• mortgages, plus

• publicly backed schemes like subsidized first-home loans or social microcredit.

Their list of services that don’t count:

• buying stocks and securities,

• margin trading,

• complex financial instruments,

• premium credit cards, and

• “special loans, such as leisure/travel loans”.

So a system that only scores applicants for travel loans may be outside 5(b). A system that scores applicants for travel loans and personal loans is inside. The draft is explicit that a system intended for both is high-risk, and it expects the provider to show that a system is “solely intended to be used for non-essential private services”.

But I would treat this exemption with caution: 5(b) itself has no “essential” qualifier. The practical consequence is a documentation question. If you want to rely on this, the intended purpose has to say so, the product has to match, and the model can’t drift into scoring the product line or anything like that.

Lastly, point 5(b) also covers natural persons. The draft guidelines say sole traders and the self-employed count as natural persons in their commercial activity. A system that scores companies from company data doesn’t. The guidelines go one step further. Where the owner of a legal entity is assessed to back a company loan, the owner falls outside 5(b) “as the primary beneficiary of the credit is the company, not the individual”.

Lend to a plumber trading in his own name, and you’re in. Lend to his limited company and take his personal guarantee, and on the draft guidelines’s reading you’re out. That sits awkwardly with the draft’s own condition in the same paragraph (company scoring is out “so long as the system is not intended to be used to evaluate the personal finances of natural persons”). The final text of the guidelines may differ though.

The Exit That Profiling Closes

Article 6(3) lets a provider argue that an Annex III system isn’t high-risk after all, if

• it only performs a narrow procedural task,

• improves a completed human activity,

• detects deviations from past decision patterns, or

• does preparatory work.

It’s the route providers in other Annex III areas will look at first. Providers of credit-scoring systems won’t get to use it, because of the sentence that follows:

“Notwithstanding the first subparagraph, an AI system referred to in Annex III shall always be considered to be high-risk where the AI system performs profiling of natural persons.”

Profiling has its GDPR meaning. The draft guidelines break it into three cumulative elements: automated processing, of personal data, with the objective of evaluating personal aspects. The GDPR’s own list of personal aspects includes a person’s “economic situation” and “reliability”. A credit score is about as close to the textbook example as it gets.

For a lender, then, the classification memo isn’t about derogations. It’s about scope:

1. is this an AI system,

2. is its purpose 5(b), and

3. was it already running before December 2027?

Yes, yes and no, and the conversation is over.

A narrow space remains for tools that process personal data without evaluating anyone. The draft guidelines note that a simple classification by characteristics like age doesn’t necessarily amount to profiling. A tool that reads income figures off a payslip for an underwriter might sit there. That line is untested, so document why the tool doesn’t assess anyone before relying on it.

Then, there’s the fraud exception. Fraud detection has to be “the main intended use of the AI system, preceding all other purposes”. If it is, the system stays outside 5(b) even when its output later feeds the credit decision. Anti-money laundering tools aren’t covered by the exception at all. They’re outside 5(b) only as long as they don’t assess creditworthiness, and the draft guidelines classify them as high-risk where they’re “functionally linked and simultaneously intended” for it.

One System or Two: Where the Capital Models Land

Recital 58 says AI systems “provided for by Union law… for prudential purposes to calculate credit institutions’ and insurance undertakings’ capital requirements should not be considered to be high-risk”. That reads like good news for banks’ internal ratings-based (IRB) models, the models that calculate how much capital they hold against their loan books.

The complication is the “use test”. Article 144(1)(b) of the Capital Requirements Regulation requires IRB ratings and estimates to “play an essential role in the risk management and decision-making process, and in the credit approval” functions of the bank. The prudential rules require the capital model to be used in lending decisions. Lending decisions about individuals are 5(b).

The draft guidelines take this on directly in a section on the CRR (section 3.5.5).

A system used solely to calculate risk-weighted exposure under the IRB approach, and not intended for credit scoring or creditworthiness, is outside 5(b). The use test alone doesn’t make it high-risk.

A system that does both is high-risk, and its main purpose doesn’t matter: “Provided one of the purposes of the system is the use case listed in point 5(b)… the AI system should be classified as high-risk”.

Where the bank runs two systems (a credit-scoring system that takes the IRB output as an input, or the other way round), only the credit-scoring system is high-risk.

Whether you have one system or two is “a case-by-case assessment,” based on the AI system definition, and the draft suggests describing hardware and software components, inputs, outputs and interfaces to show where one system ends.

For a bank, then, one of the most consequential classification documents is the architecture diagram. Two boxes and an arrow can put the capital model outside the high-risk regime, and one box can put it inside. Expect a market surveillance authority to check the diagram against the code.

The Exemption Clause

Article 111(2) says the AI Act applies to high-risk systems placed on the market or put into service before the Chapter III application date “only if, as from that date, those systems are subject to significant changes in their designs”. For credit systems under 5(b), that date is 2 December 2027.

A scoring system already placed on the market or put into service by that date is outside the AI Act (the prohibitions aside) until it changes significantly. The draft guidelines confirm this for financial institutions in plain terms: such systems “are grandfathered”.

Credit systems don’t stand still, though. They get monitored, recalibrated and redeveloped as a matter of routine. The question is when routine becomes significant.

The AI Act gives two anchors. Recital 177 says “significant change” should be understood as equivalent in substance to “substantial modification”. Article 3(23) defines that as a change “not foreseen or planned in the initial conformity assessment”. Legacy systems never had a conformity assessment, so nothing was foreseen or planned in one. Part of the definition points at a document that doesn’t exist. The rest still works: a change that alters the intended purpose counts, so moving a legacy system onto a new product line is a clean trigger.

For banks on the IRB approach, the draft guidelines offer a way out of that loop: “the definition of material change to the credit-scoring within the IRB Approach as set out in the relevant Union legislation will be relevant”. Banks already classify IRB model changes as material or not for their supervisors, under Delegated Regulation (EU) No 529/2014. The AI Act assessment would borrow that work.

Just a side note: in March 2026 the EBA sent the Commission revised standards that it says “significantly reduce the number of changes classified as material”. If the AI Act test follows the prudential one, fewer changes would count as significant, and more legacy systems would stay outside for longer. That’s my reading of where the two could meet, not something either text says.

For everyone else, the question stays open. A consumer lender that isn’t on the IRB approach, a buy-now-pay-later provider, a credit bureau: none of them has a prudential materiality framework to borrow. The final guidelines, expected by the end of 2026, may change the picture.

Who Owes What

If you build a scoring system and use it yourself, you’re the provider and the deployer. Both sets of obligations are yours.

Bought-in scores are less tidy. The draft guidelines’ bureau example says it is “not necessary that the deployer of the system is identical to the party using the credit score for its decision-making”. A deployer is whoever uses the system “under its authority”. A lender that integrates and configures a vendor’s model is using the system. A lender that receives a number from a bureau is arguably using an output, and the bureau may be both provider and deployer.

The AI Act doesn’t settle this. Article 86 gives a right to an explanation of a decision “taken by the deployer”. If the bureau is the deployer and the lender makes the decision, Article 86 may not reach that decision at all. Article 26(11) requires deployers that make decisions or assist in making decisions to inform the people affected, and a bureau assists but has no channel to the borrower. The open question is whether anyone owes the explanation at all.

The fundamental rights impact assessment has its own paragraph. Article 27(1) requires it from public bodies, from private entities providing public services, and from “deployers of high-risk AI systems referred to in points 5 (b) and (c) of Annex III.” Deployers of credit-scoring systems and of life and health insurance pricing systems are the only private businesses the article names by use case, which would include a bureau if it’s the deployer. After the Digital Omnibus on AI, a deployer “may” pull in the relevant parts of its GDPR impact assessment. That helps with the overlap.

Financial institutions do get relief, mostly about where things are filed:

• the quality management system is deemed covered by financial services,

• governance rules, except risk management, post-market monitoring,

• risk management isn’t deemed covered, but it can be made “part of, or combined with” the risk-management procedures banks already run under other Union law,

• technical documentation and logs sit inside the documentation banks already keep,

• deployer monitoring is deemed fulfilled through internal governance rules,

• for Annex III point 5 systems placed on the market or put into service by financial institutions, post-market monitoring can be integrated into existing systems and plans, “provided that it achieves an equivalent level of protection”.

However, there’s no comparable relief for data governance, human oversight, accuracy and robustness, the impact assessment, or informing the people affected. The EBA’s own mapping found “no significant contradictions” between the AI Act and banking law. It doesn’t mean the work is done, though some of it is. The CRR already requires banks to document when human judgment may override a rating and to analyze how overridden exposures perform. That’s a real head start on human oversight. On the other side, the CRR’s references to “biases” are about statistical estimation error. They aren’t about discrimination, so they won’t support AI Act.

What Stacks on Top

The GDPR already applies. In SCHUFA (C-634/21, 7 December 2023), the Court of Justice held that a credit score can itself be an automated decision under Article 22 of the GDPR where the bank or other party receiving it gives it a determining role in the decision. In Dun & Bradstreet, it set the standard for the explanation: the controller must describe “the procedure and principles actually applied” so the person can understand which of their data were used and how. “The mere communication of an algorithm” isn’t enough. It may be appropriate to tell the person how far a change in their data would have changed the result. Trade secrets go to the authority or court to be balanced. They don’t justify a refusal as such.

The second Consumer Credit Directive applies from 20 November 2026, a year before the AI Act’s high-risk rules. Its Article 18 does two things. The information behind a creditworthiness assessment can’t include special categories of personal data, and “social networks shall not be considered as an external source”. And where the assessment “involves the use of automated processing of personal data,” the consumer gets a right to human intervention, which includes a “clear and comprehensible explanation” of the assessment, the chance to give their own view, and a review of the assessment and the credit decision. “Involves” is a lower bar than the GDPR’s decisions “based solely on automated processing”. A human decision resting on an automated score still triggers it.

Against that background, the AI Act’s right to an explanation may do less in consumer credit. It applies “only to the extent that the right… is not otherwise provided for under Union law,” and the consumer credit right arguably is that right. It’s also limited to decisions that affect a person “in a way that they consider to have an adverse impact on their health, safety or fundamental rights”. A borrower approved on standard terms is unlikely to have a claim.

Lastly, mortgages are different. They sit outside the new consumer credit rules and under the Mortgage Credit Directive, which requires a lender who rejects an application to say, “where applicable, that the decision is based on automated processing of data”. That’s a notice, not an explanation. Where a person makes the mortgage decision with help from a score, the GDPR’s Article 22 may not apply either. That’s where, I think, the AI Act will do its real work.

Subscribe now

What to Do Before December 2027

1. List every system that touches a credit decision, including the ones your teams don’t call AI. Then test each against the AI system definition and write down the answer.

2. Draw the system boundaries. If a capital system and a scoring system share components, decide now whether they’re one system or two, and make sure the documented boundary matches how the system is actually built.

3. Write the intended purpose down, including which products each system scores. If you’re relying on the non-essential carve-out, check that the system scores only those products.

4. Mark every system that will already have been placed on the market or put into service by 2 December 2027, and agree internally what a “significant change” means for it. If you’re on the IRB approach, start from your material-change classification. If you aren’t, you’ll have to build the definition yourself.

5. For bought-in scores, set out in the contract who operates the system and who does what, and make sure that matches how the system is actually run. A contract can’t make anyone a deployer, but it can show who is.

6. Map your GDPR impact assessment against Article 27(1) and note what’s missing.

7. Test your explanations against the Dun & Bradstreet standard now. That standard already applies wherever the decision is automated in the GDPR sense, and after SCHUFA that can include bureau scores. The AI Act adds to it rather than replacing it.

A woman asked why she couldn’t have a €10 phone contract, and it took the Court of Justice to spell out what kind of answer she was owed. From December 2027, an AI system that produces that kind of verdict will have to be built so that the people using it can interpret what it produced.

Unless it was already running by then and never changes much. In that case, what she’s owed will still come from data protection law, however long the system keeps deciding.

Like this article? The AI Governance Roadmap is something you can use in practice. It’s a company’s roadmap with steps and working documents: the classification, inventory spreadsheet, role assignment, vendor questions and AI policy template. Everything a company needs to govern AI, in one place.

You are buying an AI system.

You asked the vendor whether it is compliant with the EU AI Act, and they said yes.

The security questionnaire came back clean. The data processing agreement is signed.

But somehow you still cannot answer the question whether the EU AI Act treats you as the provider of this system or the deployer of it.

At some point you start to wonder whether you are asking it wrong.

You are not. But there are five specific questions you can ask any AI vendor to find out where you stand.

Subscribe now

Why Ask Now

Article 113, as the Digital Omnibus amended it, defers Chapter III Sections 1, 2 and 3 to December 2, 2027 for the AI systems classified as high-risk under Annex III, and to August 2, 2028 for the ones caught through product legislation in Annex I. Those sections run from Article 6 to Article 27. They contain the classification rules, the requirements for high-risk systems, and the obligations of providers and deployers.

So the instructions for use, the written agreement, the documentation handover, your own duties as a deployer: none of them apply to anyone today.

But you should start asking sooner rather than later.

A vendor who cannot answer these questions in September 2026 is not breaching anything. They also have no obligation to improve, no deadline forcing them to build the documentation, and no reason to volunteer any of it. What they do have is a commercial motive to close, which will not be there again for next couple of years.

Sign a three-year agreement this month and it runs to September 2029. December 2027 arrives before the halfway point, at which time every answer below stops being a courtesy and starts being an obligation, on an AI system you have already bought, under a contract that has already been signed.

One part of the role question is already applicable. The transparency rules in Article 50 started on August 2, 2026, and they split by role: the duty to build in disclosure and machine-readable marking sits with the provider, the duty to tell people they are looking at a deepfake or an emotion recognition system sits with the deployer. So question one below has a live answer this year, even though most of what the answer decides is still fifteen months out.

The Commission is required to publish guidelines on the practical implementation of Articles 8 to 15 and Articles 25 and 26, which is where the value chain lives, and separately on what counts as a substantial modification. Neither carries a deadline.

Question No. 1: Who Is the Provider

Under the EU AI Act, are you the provider of this AI system, or are we?

You are the provider if you develop an AI system, or have one developed, and place it on the market under your own name or trademark. That second part is the white-label case: somebody else builds it, your logo goes on it, and the AI Act reads that as you. You are the deployer if you use a system under your own authority.

Two other roles displace the obvious answer. Where a high-risk system is a safety component of a product covered by the legislation in Section A of Annex I, the product manufacturer is the provider. And a supplier established outside the EU has to appoint an authorized representative here before making a high-risk system available on the Union market.

A good answer names one role and explains why. An evasive answer is “we’re fully compliant,” which answers a question you did not ask.

Then there is the part of Article 25(1) where three things turn a customer into a provider:

• putting your name or trademark on the AI system,

• making a substantial modification to a high-risk AI system, or

• changing the intended purpose so that a AI system which was not high-risk becomes high-risk.

The first of those, and only the first, is expressed “without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated.”

That the allocation works between the parties is clear from the text. Whether it would bind a market surveillance authority deciding who to pursue is not stated anywhere, and there is no case law. Write the clause. Do not build a position on it.

Get the answer in writing either way. If they are wrong, you want to know when they said it.

Question No. 2: What the System Is For

What is the intended purpose of this AI system, as you have declared it?

For the Annex III categories, high-risk classification runs through the declared intended purpose rather than through raw capability. The same AI system is in or out depending on what it is put in front of. That is not the whole picture, because a AI system caught through Annex I is classified by the product it sits inside, and because changing the purpose yourself has consequences of its own, below. For an Annex III AI system, though, the declared purpose is where classification starts.

Article 3(12) defines intended purpose as the use the provider intends, “as specified in the information supplied by the provider in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation.”

Sales materials are inside the definition. If the deck says the AI system screens applicants and the contract says it performs a narrow procedural task, both are in scope, and the vendor has a problem they may not know about.

A good answer is a sentence you could paste into your AI governance documentation. An evasive answer describes features.

From December 2027, the sentence you are asking for is one they will owe you. Article 13(3)(b) puts the intended purpose in the instructions for use. Today they owe you nothing, which is the difference between asking and negotiating.

And the catch: put the AI system to a use that makes it high-risk, and the AI Act can make you the provider, with every obligation that carries.

There is also a second half to that, added this summer. Article 25(2) makes the original provider cooperate with the new one, and now itemizes the handover: technical documentation sufficient to assess compliance, information on known limitations and failure modes, and targeted technical access including for testing and validation.

Then the sentence at the end of the paragraph. None of it applies where “the initial provider has clearly specified that its AI system is not to be changed into a high-risk AI system.”

One line in their documentation, and the duty switches off before it ever switches on. It will not stop you becoming the provider, because classification follows the facts and not the paperwork. It stops you getting the three things you would need once you are.

Question No. 3: What Happens If We Change It

If we fine-tune this, or connect it to our own data, does that change your answer about who the provider is?

Ask it in the same breath as the role question. Fine-tuning can move the role, but only on specific routes: a substantial modification to an AI system that is already high-risk, or a change of purpose that makes one high-risk.

For models rather than systems, the Commission’s guidance from July 2025 points at fine-tuning above roughly a third of the compute used to train the original. That figure is indicative and the guidance does not bind. The legal question is still whether the modification significantly changes the model’s generality, capabilities or risk profile, and arithmetic does not answer that.

Feeding it your own data usually does not do it. Retrieval is not training. It can still change what the system is for in practice, and it raises a separate set of questions under data protection law that the AI Act does not touch.

A good answer to this question engages with what you actually plan to do. An evasive answer is “that’s a customer configuration matter,” which means you own it and they would rather not say so.

Question No. 4: When They Change the Model

When you change the model behind this, how will we know, and what changes for us?

It is whoever makes a substantial modification who picks up the provider obligations, so a vendor-side swap usually stays theirs. What it breaks is yours: the assessment you did on the old model, and whatever you built on top of it. From December 2027, Article 26 requires deployers to operate a high-risk AI system in accordance with its instructions for use and to monitor it against them, which assumes the AI system in front of you is the system the instructions describe.

There will be a document that answers this. Article 13(3)(c) puts into the instructions for use “the changes to the high-risk AI system and its performance which have been pre-determined by the provider at the moment of the initial conformity assessment, if any.” Ask for the draft of it now.

There is an open question underneath that. Article 43(4) says pre-determined changes do not amount to a substantial modification, so no fresh conformity assessment is triggered. Its second subparagraph opens with a condition: “For high-risk AI systems that continue to learn after being placed on the market or put into service.”

Read strictly, the relief only reaches systems that keep learning in deployment. Read another way it changes nothing, because Article 3(23) already defines a substantial modification as a change “not foreseen or planned in the initial conformity assessment,” and a pre-determined change is foreseen by definition. On the second reading the subparagraph is confirming what the definition already said.

I do not think that is settled, and it is one of the things the Article 96 guidelines on substantial modification will have to answer. Ask the vendor anyway. Whichever reading wins, they should know which category their AI system is in.

A good answer includes notice, a changelog and a named person. An evasive answer is “we continuously improve the product,” which is basically a yes.

Question No. 5: Will You Put It in the Contract

Will you give us what we need to meet our own obligations, and will you put it in the contract?

Where a system is high-risk, Article 25(4) makes the provider and the third parties supplying into it set out in writing what information, capabilities and technical access get handed over. The Digital Omnibus widened it this summer: the list used to read “an AI system, tools, services, components, or processes,” and it now reads “an AI system, AI model, tools, services, components, or processes.” The model is listed now.

The same amendment did something else. Article 99 sets the penalty tiers, and the Omnibus added a new point to paragraph 4 covering Article 25(2) and Article 25(4). Fifteen million euro or three percent of worldwide annual turnover, whichever is higher.

Not today. Article 25 applies from December 2027. From then, not having the written agreement is the infringement.

There are two limits on the duty. It runs between the provider of the high-risk AI system and its suppliers, so if you are the deployer rather than the provider, your hook is different: the instructions for use the provider will owe you under Article 13, which covers accuracy metrics, known limitations, oversight measures, expected lifetime and how to read the logs. And Article 25(4) does not reach third parties making tools, services, processes or components publicly available under a free and open-source license, unless what they are supplying is a general-purpose model. Some of what is in your stack has no counterparty to sign anything.

Expect Article 25(5) to be quoted back at you, because it preserves intellectual property rights, confidential business information and trade secrets. Read what it is addressed to. It is expressed as without prejudice to paragraphs 2 and 3, which are the handover duties that bite when a role transfers. Paragraph 4 is not in its list, and paragraph 4 is an obligation to agree what will be shared rather than an order to disclose.

A good answer to this question is a clause. An evasive answer is a reassurance.

Either way, ask before signing. After signing it is a favor.

Subscribe now

The Five Questions, in One Place

1. Under the EU AI Act, are you the provider of this system, or are we?

2. What is the intended purpose of this system, as you have declared it?

3. If we fine-tune this, or connect it to our own data, does that change your answer about who the provider is?

4. When you change the model behind this, how will we know, and what changes for us?

5. Will you give us what we need to meet our own obligations, and will you put it in the contract?

   ---

What to Do with the Answers

Send them to the vendor’s legal or compliance contact rather than the account executive. An account executive’s answer is not an answer, and later it will be characterized as sales talk.

Date what comes back and keep it. Not because a wrong answer to you is an offense in itself. It matters because these answers are what you will be repeating when someone (potentially the regulator) eventually asks how you decided, and a dated file showing what you were told is the difference between a decision and a guess.

A refusal to answer is also a finding. It is the one you want on file before the argument rather than after.

If you want somewhere to start on the drafting of the contractual clauses, the Commission’s Public Buyers Community published model contractual clauses for AI procurement in March 2025, in a high-risk version and a lighter one, with commentary. They are not binding on anyone, and they are free.

The Other Fifteen Questions Worth Asking

These five questions settle your role and classification. They are the questions where a wrong answer costs you a reclassification, which is painful and fixable.

The ones I have not published here settle whether you can prove it, which is a different problem, because the moment to fix that one is before signing.

Four of them ask for documents the AI Act will entitle you to from December 2027 and which no vendor has to prepare today. Four are not AI Act questions at all, which is exactly why an AI Act review misses them. One is about the prohibitions, which are the only part of this you could be breaching already. And one is the only question in the set about ending the relationship, which is the part the AI Act says nothing about.

All twenty questions will be available in Scope, which opens this fall.

Like this article? The AI Governance Roadmap is something you can use in practice. It’s a company’s roadmap with steps and working documents: the classification, inventory spreadsheet, role assignment, vendor questions and AI policy template. Everything a company needs to govern AI, in one place.

You looked up the open source exemption, and it read like good news.

One sentence. Three exceptions. No conditions attached to any of it. So you wrote it down and went to check it against the thing your company actually runs, which is a set of weights someone downloaded and fine-tuned on your own data.

The law firm alerts quote that same sentence. So does the vendor documentation. So does the explainer your engineering lead sent you, the one with the green checkmarks.

At some point you start to wonder whether you have misread something.

You have not. You are reading an article that does not cover what you are looking at.

Subscribe now

The Sentence in Question

Article 2(12) of the AI Act says this:

“This Regulation does not apply to AI systems released under free and open-source licences, unless they are placed on the market or put into service as high-risk AI systems or as an AI system that falls under Article 5 or 50.”

That is the whole thing. It is genuinely useful. If you built a low-risk tool, released it openly, and it is not high-risk, not prohibited, and does not trigger transparency duties, you are outside the Regulation. Not lightly regulated. Outside.

Now read what it does not say.

It does not define a free and open-source license. It does not require you to publish weights, or architecture information, or anything else. It does not mention money. And it does not mention models.

That last one is the problem.

A Model Is Not a System

The AI Act keeps these apart on purpose. Article 3(1) defines an AI system. Article 3(63) defines a general-purpose AI model. Chapter V regulates general-purpose AI models on a separate track from everything else in the Regulation, with its own obligations and its own enforcement.

Article 2(12) says AI systems. So it does not reach the model.

The model exemptions live elsewhere. Article 53(2) provides:

“The obligations set out in paragraph 1, points (a) and (b), shall not apply to providers of AI models that are released under a free and open-source licence that allows for the access, usage, modification, and distribution of the model, and whose parameters, including the weights, the information on the model architecture, and the information on model usage, are made publicly available. This exception shall not apply to general-purpose AI models with systemic risks.”

Article 54(6) carries the same conditions across to the authorized representative duty.

See the difference. Article 2(12) asks one question: was it released under a free and open-source license? Article 53(2) asks three: does the license permit access, usage, modification and distribution, are the parameters public, and is the model free of systemic risk, which under Article 51 means the largest models, presumed once training compute passes 10^25 floating point operations.

Same phrase, two tests, and which one you are under depends entirely on what you have.

And there’s one more complication. Recital 103 opens by saying that free and open-source AI components cover “the software and data, including models and general-purpose AI models, tools, services or processes of an AI system.” And Recital 102 supplies, for general-purpose models, the same publicly-available-parameters condition that Article 2(12) leaves out. Neither changes the operative text, and recitals do not create obligations. But they tell you something about where this regime keeps its content.

The Money Condition Leaves in a Recital

The monetization limit is the most consequential condition on the open source exemption, and it appears in neither Article 2(12) nor Article 53(2). It is in Recital 103:

“AI components that are provided against a price or otherwise monetised... should not benefit from the exceptions provided to free and open-source AI components. The fact of making AI components available through open repositories should not, in itself, constitute a monetisation.”

Recitals guide interpretation. They do not impose obligations. So a provider who reads the articles gets a shorter answer than a provider who reads the articles plus the recitals, and nothing in the articles tells you to go looking.

The Commission filled some of this in. Its guidelines on the scope of obligations for providers of general-purpose AI models, the Annex to Commission Decision C(2025) 5045 final of 18 July 2025, are non-binding, and they are the clearest reading available.

Paragraph 83 lists what disqualifies a license. Limitations to non-commercial or research-only use. Prohibitions on distributing the model. Requirements to obtain separate commercial licenses for specific use cases. And this one:

“usage restrictions triggered by user scale thresholds (e.g. requiring additional licensing if monthly active users exceed a certain number)”

Now open the Llama 4 Community License Agreement of April 5, 2025, Section 2:

“If, on the Llama 4 version release date, the monthly active users of the products or services made available by or for Licensee, or Licensee’s affiliates, is greater than 700 million monthly active users in the preceding calendar month, you must request a license from Meta”

The guidelines describe that clause almost exactly, without naming it.

We can debate here but my understanding is that some of the most widely deployed open-weight models in Europe may sit outside the AI Act’s open source exemption while being described as inside it in many articles. The guidelines are not binding, the Commission has published no determination on any named model, and this has not been litigated. Read the clause and the paragraph and judge for yourself. But if your compliance position rests on a model being open source, the license text is the document to read.

What Survives a Perfect Open Release

Say the model clears every condition. Truly open license, weights and architecture published, no systemic risk, no charge for anything.

The copyright policy under Article 53(1)(c) still applies. So does the public summary of training content under 53(1)(d). Recital 104 confirms both were deliberately left outside the exemption. Cooperation with the Commission and national authorities still applies. If the model crosses into systemic risk, Article 55 applies in full and the exemption disappears entirely.

Then there is everything downstream. Article 50 transparency, if the system talks to people or generates synthetic content. Prohibited practices. High-risk classification.

The exemption is documentation relief for model providers and a scope exclusion for genuinely low-risk systems. It is not a status your project acquires and keeps.

However, building on an exempt open model does not make your system exempt.

Another Exception?

Article 25(4) requires a written agreement between the provider of a high-risk AI system and the third party supplying components into it, specifying the information and technical access the provider needs to comply. Its second subparagraph exempts open source suppliers:

“This paragraph shall not apply to third parties making accessible to the public tools, services, processes, or components, other than general-purpose AI models, under a free and open-source licence.”

Other than general-purpose AI models.

The Digital Omnibus on AI replaced the first subparagraph of Article 25(4). The list of what a third party can supply now reads “an AI system, AI model, tools, services, components, or processes.” AI model is new.

The second subparagraph was not touched.

So the written agreement duty grew to reach model suppliers, and the open source relief still excludes exactly the thing model suppliers supply. The single place the AI Act offers open source contributors contractual relief in the high-risk value chain is the place it withholds it from them, and the amendment made the mismatch wider rather than narrower.

Three Exits with Three Different Clocks

There is probably one date in your file for this. There are three dates though.

Article 2(12) names the three ways out of the exemption in a single line of text, which is why they get planned for as one deadline.

They do not arrive together.

1. Article 5, prohibited practices. In force since February 2, 2025, and the Omnibus added two new points that apply from December 2, 2026. Article 99(3) puts breaches here in the top tier: up to €35 million or 7% of total worldwide annual turnover, whichever is higher.

2. Article 50, transparency. In force since August 2, 2026. The machine-readable marking duty in Article 50(2) carries a four-month transitional period for systems that were already on the market, and that period is running right now. It closes December 2, 2026. Up to €15 million or 3%.

3. High-risk classification. 2 December 2027 for standalone systems in the Annex III use cases: employment, credit, education and the rest. August 2, 2028 for AI embedded in products already covered by EU product safety law. Up to €15 million or 3%.

Two of the three are already live. The third is fifteen months out, and it moved to get there. Before the Omnibus, standalone high-risk obligations would have applied from August 2, 2026 and embedded high-risk from August 2, 2027.

Which leaves the exit most open source coverage is organized around as the one that cannot bite yet, and the two that can as the ones drawing the least attention.

The Omnibus also inserted new paragraphs 1a, 1b and 1c into Article 6, recutting what counts as a safety component. 1a takes out systems that only assist users or optimize performance. 1b puts back in systems whose failure would endanger health or safety. 1c takes out products that need third-party assessment only for risks other than safety. Article 6(3), the classification off-ramp, was not amended.

The Prohibition That Was Not Costed for Open Weights

The Omnibus added two prohibited practices to Article 5, applying December 2, 2026. Point (ba) covers AI systems that generate or manipulate realistic images, video, audio or similar material of an identifiable person’s intimate parts, or of an identifiable person in sexually explicit activity, without that person’s explicit consent. Point (bb) covers systems generating or manipulating child sexual abuse material within Directive 2011/93/EU, except where a “without right” defense applies under national law.

Realistic narrows point (ba): it reaches convincing output, not obvious fabrication. Article 5(1b) narrows it again. Editing that neither increases the exposure of intimate parts nor changes the nature of the depicted activity is not manipulation for these purposes. On a provision carrying a 7% ceiling, that is the line between a prohibited system and a lawful one.

The rest of the limits sit in a new Article 5(1a). For placing on the market, the prohibition bites where that generation is the intended purpose, or where the system’s design, training, architecture, capabilities or user-facing functionalities make it

“a reasonably foreseeable and reproducible outcome, without requiring significant technical modification, and the system does not have reasonable and adequate technical safety measures and other safeguards to reliably prevent that generation or manipulation, taking into account reasonably foreseeable misuse, and to correct observed or reported misuse”

The standard is reasonableness, not perfection, and open-weight providers can argue prevention: refusal training, classifiers, usage policies, published safeguards.

Correction is a different question. The provision asks for safeguards to correct observed or reported misuse, and there is no mechanism that reaches a checkpoint after it has been downloaded, mirrored and fine-tuned. You cannot patch it. You cannot recall it. You frequently cannot observe it. The obligation assumes a channel back to the artifact, and open weights is the distribution model defined by not having one.

The same distinction cuts the other way.

Article 5 is written throughout in terms of “an AI system.” Article 5(1a) turns on “the system’s design, training, architecture, capabilities or user-facing functionalities.” The reasoning that keeps a model outside Article 2(12) keeps a bare weights release outside Article 5. Being outside an exemption costs you obligations, and being outside a prohibition costs the public a protection. The prohibited practices guidelines do not resolve it. As far as I can find, nothing does.

Your own exposure is clearer than the drafters’ intent. Article 5(1a)(b) prohibits use where “the deployer uses the system for the purpose of generating or manipulating such material.” Download open weights, fine-tune away the refusal behavior, generate the output, and you are inside the prohibition with no exemption available at any point, because Article 5 is one of the three named exits from Article 2(12). On that limb, and only that limb, accidental output is outside: the use prohibition turns on purpose. The placing-on-the-market limb is built to catch unintended output where it is foreseeable, reproducible and inadequately guarded.

The Argument Running the Other Way

Everything above says the exemption is narrower than it looks. There is a serious published argument that it is too wide, and it deserves the floor.

Simona Ramos and Fabio Pianese, writing in AI and Ethics this year, go after the definition itself. The AI Act never requires training data disclosure. Publish the weights, publish a descriptive summary of what went into them, and you qualify. They call the result open-washing: partial disclosure earning a regulatory exemption that exists to reward transparency, leaving downstream users carrying risks with no identifiable party accountable for them.

I would say that both readings hold at once. The exemption is too narrow for the person who assumes it covers their fine-tuned model, and too wide for the person who assumes it guarantees them a model they can actually inspect.

Subscribe now

What to Do

1. Work out whether you have a system or a general-purpose model. If you deployed something users interact with, you have a system and Article 2(12) is your provision. If you published weights of a general-purpose model, Articles 53(2) and 54(6) are yours. If you did both, you have both, assessed separately. And if you openly released a narrow, single-purpose model, note that Chapter V does not reach you and neither does Article 2(12), which speaks to systems.

2. Read the license, not the announcement. Check it against guidelines paragraph 83: non-commercial limits, distribution bans, user-scale thresholds, separate commercial licenses for particular uses. Any one of them and the model is arguably not open source for AI Act purposes, whatever it is called.

3. Check for monetization before you rely on the exemption. Paid support bundled with access, dual licensing, hosted access behind payment, ad-served access, data collection beyond model security. Recital 103, and guidelines paragraphs 86 to 89.

4. Stop treating upstream openness as your answer. Write down your own role for each system. The exemption belongs to whoever made the release.

5. If you supply a model into someone’s high-risk system, expect the written agreement. The Article 25(4) carve-out does not cover general-purpose models, and after the Omnibus the duty names AI models explicitly.

6. If you deployed a generative system before August 2, 2026, check your Article 50(2) marking. The transitional period ends December 2, 2026.

7. If you fine-tune image, video or audio generation models, put December 2, 2026 in the calendar. Not the 2027 date. That one.

   ---

What Is Left Unresolved

An authorized representative exists so that EU authorities have someone inside the Union to serve, question, and hold responsible when the provider is somewhere else.

Article 54(6) removes that requirement for providers of free and open-source general-purpose AI models without systemic risk. Reasonable enough, in 2024, for a regime built around documentation.

From December 2, 2026, Article 5(1a) makes lawfulness turn partly on whether misuse gets corrected after release. It does that for the class of providers least able to correct anything, many of them outside the Union, and by virtue of 54(6), with no one inside it to ask.

The obligation needs a channel back to the artifact. The exemption removed the channel back to the provider.

Two holes in the same instrument, pointing in opposite directions. One lets a provider look open without being open. The other lets a provider be open without being reachable.

Like this article? The AI Governance Roadmap is something you can use in practice. It’s a company’s roadmap with steps and working documents: the classification, inventory spreadsheet, role assignment, vendor questions and AI policy template. Everything a company needs to govern AI, in one place.

You have read Article 15 of the EU AI Act more times than you would like to admit.

It says your high-risk system needs an appropriate level of accuracy. It does not say what appropriate means. So you go looking, because eventually someone has to write a number into a document and it is going to be you.

The Commission guidance does not answer it. The law firm alerts do not answer it. The vendor says their product is compliant, which is not an answer to anything.

At some point you start to wonder whether you are missing something obvious.

You are not. The thing you are looking for has not been written yet.

The AI Act was designed to leave that gap. The regulation states the duty, a harmonized standard states how to meet it, and conforming to the standard earns you a presumption that you have satisfied the requirement it covers. That is a good design.

As of today the European Commission has not cited a single harmonized standard for the AI Act in the Official Journal. Citation is the step that gives a standard its legal effect, and it has not happened once.

In July the first European standard did arrive. EN 18286, on quality management systems, described by CEN-CENELEC on their own site as “the first harmonized European standard for the AI Act regulatory purposes.” Every part of that is accurate. It still confers nothing.

Your date is December 2, 2027. It no longer waits for any of this.

Subscribe now

What the Presumption Is, Exactly

Article 40(1) says that a high-risk AI system which conforms to harmonized standards, or parts of them, the references to which have been published in the Official Journal, is presumed to be in conformity with the requirements set out in Section 2 of that Chapter, to the extent those standards cover those requirements.

There are three conditions though.

The first is publication of the reference in the Official Journal. Not drafting. Not approval by CEN-CENELEC. Not publication of the standard itself. The Commission assesses the standard against the request it made and then cites the reference in the OJ, and that is a separate act which happens afterward. EN 18286 has cleared every CEN-CENELEC stage. It has not cleared that one, and there is a Commission assessment and national transposition still to happen in between.

The second is coverage. A harmonized standard carries an Annex ZA, the table mapping the standard onto the specific legal provisions it supports. The presumption reaches exactly as far as that table and stops. A cited risk management standard answers Article 9. Your data governance obligations under Article 10 will regard it with polite indifference.

The third is the word presumed. It shifts the burden of proof. It does not end the argument. A market surveillance authority can still look at your system, decide it does not meet the requirement, and act on that, even if you followed the standard exactly. The AI Act has a whole procedure for it.

The standard itself is not permanent either. A Member State or the European Parliament can formally object to a harmonized standard, and the Commission can then narrow what it covers or pull the reference back out of the Official Journal.

None of that is a flaw. It is how CE marking has always worked. It is just a good deal less than “safe harbor” suggests to a board.

What Is Often Skipped in a Commentary

The AI Act splits its high-risk AI system duties into two kinds.

One set is about the system: it has to manage risk, use decent data, keep records, be transparent, allow human oversight, and be accurate, robust and secure. The other set is about you, the company placing it on the market or putting it into service: run a quality management system, keep the documentation, fix things when they go wrong.

Article 40 offers the presumption for the first set. Only the first set.

EN 18286 is a standard for the second set. It covers the quality management system.

So the first standard to reach publication is a standard for a duty the presumption does not obviously reach. Whether citing it in the Official Journal produces one anyway is a question the text does not answer, and I have not found anything authoritative that does. Common specifications would not solve it either, because Article 41 is written to the same scope.

Most commentary assumes the presumption attaches on citation and moves on. It may. The European Commission did ask for a quality management deliverable when it issued the standardization request, which says something about intent. But intent is not operative text, and this gets settled when the Commission decides whether, and how, to cite.

Where Everything Else Sits

As of August 23, 2026 one standard is finished, four drafts out for public comment, the rest is still being written.

The four out for comment cover risk management, cybersecurity, logging, and human oversight. (prEN 18228, 18282, and 18229 parts 1 and 3, if you want to go and look.) Still being written: transparency, accuracy, robustness, data quality, bias, and the conformity assessment framework itself.

Do not attach much weight to the count. It moves. The trustworthiness standard that was one document is now a five-part series, and there are ISO-derived standards on the same work program alongside the purpose-written ones. The Commission describes its request as covering ten key areas rather than a number of documents, which is the more useful way to hold it.

The number that matters is the other one. As of today the Commission has published no reference to a harmonized standard under the AI Act in the Official Journal.

The Commission issued its standardization request in May 2023, with 30 April 2025 as the deadline for CEN and CENELEC to deliver. That date passed with nothing delivered under the request. An amending request followed in June 2025, extending the timeline and adding quarterly progress reporting.

Then, in October 2025, CEN and CENELEC changed their own rules, in what they called exceptional and temporary measures.

A European standard goes through an enquiry stage, where the national standards bodies vote and comments come in, and then a second formal vote before publication. Under the October measures, a draft that passes enquiry can go straight to publication, and technical changes after that point are no longer allowed.

The consultation is still real, so this is not consensus abandoned. It is consensus on a shorter rope. But a standards body suspending its own approval vote is not a routine schedule adjustment, and it is the clearest signal available about how the timeline is actually going.

And note what “available by the end of 2026” is a target for. The document existing. Not the Commission citing it, which is a separate step and comes after.

The Condition That Was Proposed, and Removed

When the Commission proposed the Digital Omnibus on AI, it did not propose a simple postponement of the high-risk AI systems. According to the Council’s own account of the provisional agreement, the Commission had proposed adjusting the timeline by up to sixteen months, so that the rules would start to apply “once the Commission confirms the needed standards and tools are available.”

A conditional trigger. The obligations would begin when the means of complying with them existed.

Parliament and Council did not keep it. The agreed text replaced the trigger with fixed dates.

Those dates are now law. Regulation (EU) 2026/1744 of 8 July 2026, published in the Official Journal on 24 July and in force three days later.

It sets two. 2 December 2027 for high-risk systems that stand on their own, the ones on the Act’s list in Annex III. 2 August 2028 for high-risk AI built into products that already carry their own EU safety rules, medical devices among them.

The delay survived. The condition attached to it did not.

And the Regulation says why, in its own recitals. Recital 40 records that for the high-risk obligations in Chapter III, “the delayed availability of standards, common specifications, and alternative guidance and the delayed establishment of national competent authorities lead to challenges that jeopardize the effective entry into application of those obligations.”

That is the EU stating, inside a binding instrument, that the standards are not ready. In the same instrument that removes the condition which would have waited for them.

There is a real argument for the choice. An open-ended trigger hands the Commission the power to postpone a regulation indefinitely by declining to confirm readiness, and gives businesses no date to plan against. Fixed dates are certainty, and certainty is what compliance teams have been asking for since 2024.

But it produces a specific result. The Commission’s version tied the start to whether the tools existed. The adopted version just picked a day.

The Fallback That Has Not Been Used

The AI Act does have a backup plan.

If the standards do not arrive, Article 41 lets the European Commission write the specifications itself. They are called common specifications, and they work the same way: follow them and you get the same presumption a harmonized standard would give you. A provider who would rather not use them has to show its own solutions are at least as good, which is real work, and that is the point.

The conditions for using it are not hypothetical. The Commission has to have asked for standards, the standards have to have missed their deadline, and nothing can be published in the Official Journal or expected there soon.

A request was issued. The deadline was missed. Nothing is cited.

As far as I have been able to establish, no common specifications have been adopted for the high-risk requirements. If that is right, the mechanism written into the AI Act for this exact situation is sitting unused while the situation it was written for continues.

It would not fix the quality management gap either. Common specifications are offered for the same set of duties as the presumption itself, the ones about the system rather than the ones about the company.

And the AI Act says the Commission may adopt them. Not shall. That one word is why there is no obligation on anyone to fix this, and no date by which it has to be fixed.

The One Box That Is Not Empty in the Same Way

Two other routes exist, and neither runs through the standards process. They are the only places where the answer to “can I get a presumption today” is not simply no.

Article 42 gives them both. If your system was trained and tested on data that reflects the specific setting it will actually be used in, it is presumed to meet that part of the data governance requirement. And if it holds a cybersecurity certificate issued under the EU’s cybersecurity certification framework, it is presumed to meet the cybersecurity requirement, as far as that certificate reaches.

The second one comes with a familiar condition. It only works where the references have been published in the Official Journal.

Same gate. A different queue.

What ISO 42001 and NIST Do Not Do

In the absence of something to build against, teams reach for what exists.

ISO/IEC 42001 is an AI management system standard. It is certifiable, genuinely useful, and an organization that holds it is doing real governance work. It carries no presumption of conformity under the AI Act.

It is not that an ISO standard cannot become a harmonized European standard. ISO standards are adopted as European standards routinely, and the committee writing the AI Act standards is doing exactly that with two of them. The reason is that they chose to write EN 18286 rather than adopt ISO/IEC 42001 for the quality management standard, and 42001 is not on their work program as a candidate for it.

The substance differs too. EN 18286 is built around obligations that come out of the AI Act rather than out of management system practice, including a strategy for regulatory compliance, the technical specifications and standards to be applied, and procedures for reporting serious incidents under Article 73. Those map onto Article 17(1). An ISO 42001 programme gives you a conceptual head start. It does not give you the evidence.

The NIST AI Risk Management Framework is a voluntary United States framework with no legal effect in the European Union. If your organization built its AI governance on NIST because that is where the guidance was in 2023, that work is not wasted, but it does not travel to Brussels on its own.

Both are evidence of a serious organization. Neither is evidence of conformity.

Subscribe now

What to Actually Do

Five things, and none of them require you to predict whether CEN-CENELEC makes its target.

1. Read the drafts, and note which version you read. Four harmonized standards are out for public comment right now: risk management, cybersecurity, logging, and human oversight. A draft gives you no legal protection. It is still the best picture available of what the finished requirement will look like, and having built toward it is worth more than having waited. Write down which draft and which date, so that if the final version changes you can show your decision was current when you made it.

2. Start the quality management work now. EN 18286 is the one standard that is finished. Set aside the question of whether it will ever produce a presumption: the AI Act already requires you to record which standards and specifications you apply, so a published European standard is a useful thing to be able to point at. It is also the clearest published description of what a quality management system for high-risk AI is meant to contain.

3. Write down your own reasoning, and date it. The requirements apply on their own terms whether or not a standard ever arrives to explain them. So every time you decide what "appropriate" means for your AI system, write down what you decided, why, and when.

4. Do not buy presumption. If someone tells you their product delivers presumption of conformity, ask which standard, and in which issue of the Official Journal the reference was published. For harmonized standards there is no correct answer today. For the cybersecurity certification route there might be, which makes it the better question.

5. Watch the Official Journal, not the announcements. When a standard is published by CEN and CENELEC it generates press coverage. When the European Commission cites it, generally it does not. The second is the one that changes your legal position, so put a recurring check in the calendar rather than waiting to hear about it.

   ---

The Bargain

Underneath the procedure, the AI Act’s design for high-risk AI systems is a trade, and a sensible one.

The regulation states the requirement in general terms, because a regulation specifying test methodologies would be obsolete before it applied. The harmonized standard then states how to demonstrate it, written by people who understand the technology and updated as the technology moves. Meet the standard and you are presumed to comply. The regulator gets requirements that survive contact with the field. You get a route to certainty that does not depend on your own legal interpretation being correct.

That is the bargain. It is the only reason a phrase like “an appropriate level of accuracy” is a workable legal obligation rather than an invitation to litigate.

One half of it has been delivered. The requirements have been on the statute book since 2024, and they apply to your systems on 2 December 2027 regardless of what has been cited by then.

The other half was originally due in April 2025.

EN 18286 was approved on 12 July 2026. The Digital Omnibus was adopted on 8 July, four days earlier, and it amended Article 17 along the way. So the first AI Act standard to reach publication maps onto a version of the law that had changed the week before. Whatever the Commission is assessing when it decides on citation, it is not assessing a fixed target.

You are being measured against instructions that have not been issued, for a requirement that has not finished moving. That is not an oversight in the drafting. It is the timetable, as adopted.

Like this article? The AI Governance Roadmap is something you can use in practice. It’s a company’s roadmap with steps and working documents: the classification, inventory spreadsheet, role assignment, vendor questions and AI policy template. Everything a company needs to govern AI, in one place.

You have one AI system. A vendor built it, your company runs it, it processes personal data, and if you work in financial services a prudential regulator supervises the whole operation.

Three rulebooks land on that system at once. The EU AI Act regulates it as an AI system. The GDPR regulates the personal data running through it. DORA, the EU’s financial resilience regulation, regulates the vendor relationship behind it.

Each of them has something to say about risk. Each of them wants an assessment. Each of them names the parties involved, and none of them uses the same names.

At some point you go looking for the provision that says which one governs when they answer the same question differently.

It is not there. For these overlaps the EU never wrote one.

That absence is deliberate, and understanding why it is deliberate may change what you build. The months that disappear into AI governance projects mostly disappear here, into a search for a tiebreaker that does not exist.

Subscribe now

There Is No Hierarchy, and Lex Specialis Will Not Help

Two EU instruments of equal rank do not resolve against each other by default.

Where obligations genuinely collide and no express rule applies, the Court of Justice does not pick a winner. It reconciles.

In C-73/17 France v Parliament the Court held that two provisions of the same legal value must be read “in a manner that reconciles those obligations and strikes a fair balance between them.”

Two caveats before you count on that. It concerned primary law, where “same legal value” has a specific meaning. And no judgment has applied the method to two equal-rank regulations. Try applying it either way.

The instinct at this stage is to reach for lex specialis derogat legi generali, the specific displaces the general. It is a real principle and genuinely part of EU legal reasoning. It is also an interpretive tool rather than a hierarchy rule, and it only engages where two provisions govern the same subject matter.

I believe that the AI Act and the GDPR do not. One regulates the placing on the market and the use of AI systems. The other regulates the processing of personal data. They land on the same system without meeting on the same question.

Article 10 of the EU AI Act on data governance, and the new Article 4a, do regulate the processing of personal data. Article 2(7) carves out its own exceptions to GDPR neutrality, which concedes some overlap. I would say that the overlap sits at the edges, and lex specialis needs more than edges. But many might disagree with me.

Which leaves the default: absent an express rule, both instruments apply in full.

Neither is discounted because the other exists. So a single system in a single financial entity might be, at the same time, a high-risk AI system with a provider and a deployer, a processing operation with a controller and a processor, and an ICT service supplied by an ICT third-party service provider to a financial entity.

Three regimes. Three sets of names for the same two parties. Three definitions of risk.

You do not choose between them. You carry all of them.

The EU Knows How to Write a Precedence Rule

Article 4 of NIS2, the EU’s cybersecurity directive, does exactly what the AI Act declines to do. Where sector-specific Union law imposes cybersecurity risk-management measures or incident notification requirements at least equivalent in effect to NIS2’s own, the NIS2 provisions do not apply to those entities.

Do not apply, including the whole supervision and enforcement chapter.

Article 4(2) then supplies the equivalence test. And Recital 28 names the winner outright:

Regulation (EU) 2022/2554 of the European Parliament and of the Council should be considered to be a sector-specific Union legal act in relation to this Directive with regard to financial entities.

DORA displaces NIS2 for financial entities. Written down, by name, in the recitals.

The Commission then published guidelines on how to apply the equivalence test, setting out what the sectoral measures have to cover to qualify.

So the mechanism exists. A template, a test, and official guidance on operating the test. (NIS2 is a directive rather than a regulation, which complicates the comparison slightly but it changes nothing about the point.)

None of it was applied between the AI Act and the GDPR, or between the AI Act and DORA.

What the AI Act Wrote

It wrote interaction clauses.

Article 2(7) says Union law on the protection of personal data applies to personal data processed in connection with the rights and obligations in the AI Act, and that the Regulation does not affect the GDPR. That looks like a precedence clause. It is not quite it. It is the AI Act confirming that the GDPR continues to apply alongside it, in full, and declining to say what happens when the two point in different directions.

Article 9(10) says providers already subject to internal risk-management requirements under other Union law may fold the AI Act’s risk management into those procedures.

Article 8(2) gives providers a choice of integrating testing, reporting and documentation with product-safety law to avoid duplication. However, Article 8(2) opens with a duty, not a choice: providers shall be responsible for ensuring the product is fully compliant with both regimes. Only the integration is optional.

Article 17(4) deems, conditionally. For providers that are financial institutions subject to internal governance requirements under Union financial services law, the quality management obligation is deemed fulfilled by complying with those internal governance rules. Complying, not merely being subject to them. And three points are excepted: the risk management system, post-market monitoring, and serious incident reporting. The AI Act lets existing governance carry the paperwork and keeps the three obligations that detect harm.

And Article 26(9) says shall. Deployers of high-risk AI systems shall use the information the provider supplies under Article 13 to comply with their data protection impact assessment obligation under Article 35 GDPR.

That is the only provision in the AI Act that makes an AI Act piece a required input to a GDPR process. The vendor’s instructions for use are now compulsory reading for company’s DPIA.

Last Month Wrote Precedence Three Times

On 24 July the Digital Omnibus on AI was published in the Official Journal (it was in force three days later). Aside from the deadline deferrals that got all the coverage, it wrote precedence into the AI Act three times, by three different techniques.

The first is an equivalence route. New Article 2(13): where product-safety legislation listed in Section A of Annex I already provides an equivalent or higher level of protection, the application of Articles 9 to 15 and 17 to 25 may be limited. The Commission is to adopt delegated acts by 2 August 2027 specifying which systems, which requirements, and how far. Though nothing is limited yet. This is an empowerment with a deadline, not a live carve-out.

The second is a migration. The Omnibus moved the Machinery Regulation from Section A of Annex I to Section B. Section B triggers Article 2(2), which disapplies the entire high-risk chapter for those systems. Recital 42 calls it a move to a sectoral approach. However, the Recital also provides that the Commission is to adopt delegated acts amending the Machinery Regulation’s own annex to reflect the AI Act’s high-risk requirements, plus Articles 17, 19, 72 and 73, applying by 2 August 2028. Manufacturers can rely on AI Act harmonized standards in the interim. The obligations are not being removed. They are being rehoused.

The third is a hole aimed at the GDPR. New Article 4a lets providers and deployers process special categories of personal data where strictly necessary to detect and correct bias. And post-Omnibus, Article 2(7) now opens “Without prejudice to Articles 4a and 59 of this Regulation.” The clause that announces GDPR neutrality now names its own exceptions to it, in its first line.

So the position after last month is this:

• Machinery: rehoused, with the requirements to follow it across by 2028.

• Other Section A product legislation, medical devices and toys and lifts among them: an equivalence route, pending 2027.

• Personal data: one prohibition, for one purpose. Financial services: nothing, and DORA is not in Annex I at all.

The EU is willing to rank its own instruments. It has at least three techniques for doing it. It used all three last month.

Same Word, Different Meaning

Which brings me back to the beginning and the example of one AI system that falls under three regimes.

Risk

If you assessing such AI system, start with risk, because three regimes use it to mean three different things.

The AI Act defines risk in Article 3(2) as the combination of the probability of harm occurring and the severity of that harm. Harm to whom is answered elsewhere in the Act: health, safety and fundamental rights. Of persons.

The GDPR uses the word risk throughout and never defines it in its definitions article. The operative phrase is risk to the rights and freedoms of natural persons, given content by the recitals, by Articles 24, 32 and 35, and by two decades of supervisory guidance.

DORA does not define risk at all. It defines ICT risk: a circumstance in relation to the use of network and information systems which, if it materializes, may compromise the security of those systems, of technology-dependent tools and processes, of operations and processes, or of the provision of services.

Three objects of harm. The AI Act protects the person from the system. The GDPR protects the person’s rights in their data. DORA protects the firm’s operations from disruption.

A system can be low-risk under one and high-risk under another with no contradiction at all, because they are not measuring the same thing. Which is why your DORA risk register is not an AI Act risk management system, and why handing one to a market surveillance authority in place of the other will not go well.

Roles

The roles diverge the same way, and worse, because the two sets are not even the same kind of category. AI Act roles turn on market position: who placed the system on the market under their own name, who uses it under their authority. GDPR roles turn on decisional control: who determines the purposes and means of processing, who processes on their behalf.

The working assumption is that provider maps to processor and deployer maps to controller. It holds often enough to be dangerous. An AI vendor that decides what to do with customer data to improve its own model is a controller for that processing while remaining a provider under the AI Act.

Role determination has to be done twice, on two different tests, and the two answers do not have to agree.

Where the GDPR Stops, the AI Act Starts?

The sharpest divergence is about explanations.

Article 22 GDPR applies to a decision based solely on automated processing. The received wisdom followed: insert a human who exercises real judgement and Article 22 falls away. It is in most privacy training decks written between 2018 and 2023, and it has not aged well.

The Court of Justice narrowed it in C-634/21 SCHUFA Holding. Where a credit reference agency produces a probability value and a third party draws strongly on that value in deciding whether to enter into a contract, establishing the value is itself a decision within Article 22(1). The human at the other end signing off does not necessarily rescue you.

Meanwhile the AI Act arrives from the opposite direction. Article 86 gives a right to explanation for

a decision which is taken by the deployer on the basis of the output from a high-risk AI system listed in Annex III, with the exception of systems listed under point 2 thereof, and which produces legal effects or similarly significantly affects that person in a way that they consider to have an adverse impact on their health, safety or fundamental rights

Taken by the deployer, on the basis of the output. The human is assumed, not excluded. The AI Act’s right is written for the exact decision the GDPR was thought to release.

The fix that used to remove the obligation is now what both rules are watching.

And then the AI Act does something strange with its own right. It applies only where EU law does not already give you one.

The GDPR does give you one. If a decision about you was made by the machine, you can ask the company for meaningful information about the logic behind it. For years the standard answer was that the logic is a trade secret. In 2025 the Court of Justice closed that off: a trade secret is not a refusal. The company hands the material to the supervisory authority or the court, and they decide how much the person sees.

So the AI Act’s right exists to cover what the GDPR misses, and what the GDPR misses keeps shrinking.

The GDPR right attaches to decisions the machine made. The AI Act right attaches to decisions a person made using the machine. Those are different sets. After the credit scoring judgment they overlap more than they used to, and neither the Commission nor a court has said where one ends and the other begins.

A right defined by the absence of another right, with the boundary still being drawn.

What to Do

As always, I want to give you something that you can implement. Five moves:

1. Stop asking which regulation governs. Ask what each one is measuring. The first question has no answer. The second always does, and it resolves the practical case. Harm to the person: AI Act. Harm to the person’s rights in their data: GDPR. Harm to the firm’s operations: DORA.

2. Classify separately, then map. Never classify once and translate. Run role determination twice, on each regime’s own test. Run risk classification separately for each. Build the mapping table as an output, one row per system, one column per regime.

3. When both rules point the same way, meet the tighter one and write down why. Two regulations rarely ask for opposite things. More often one asks for more than the other, and the stricter version is the one you have to hit. An incident is the clearest case. If you are a financial firm, DORA wants the first report within four hours of classifying it, or 24 hours of noticing it, whichever comes first. The AI Act allows fifteen days. Four hours is your deadline, and the fifteen-day rule is satisfied on the way past. The AI Act lets you reuse the same paperwork for both. It does not let you use the looser standard.

4. When two rules pull against each other, decide, and write down the reasoning. Sometimes you just have to choose. Bias testing is the live example. The AI Act now lets you use sensitive personal data, health and ethnicity and the rest, to check whether your system discriminates. It also tells you to delete that data once the bias is fixed. Every instinct in a testing team says keep it, so you can prove the fix held. Both positions are defensible, the choice needs to be on paper with a reason attached.

5. Keep a list of the words that do not match. One line each: the word, the regulation, what it means there, what follows from it. Risk takes three lines. So does provider. So does incident. It is the least impressive document you will produce this year, and it is the one that stops the same argument restarting every quarter, because the answer is written down with a source next to it.

And one note on timing. The AI Act’s high-risk obligations are deferred to 2 December 2027 for standalone Annex III systems and 2 August 2028 for those embedded in regulated products. Most of the collisions above are not operative today. The divergences are already law. The obligations they create mostly are not.

Subscribe now

Closing Argument

Cumulative application sounds like an inconvenience. It has a sharper edge,and it shows up in the order things happen.

One system fails. Two regulators can fine you for it: your data protection authority under the GDPR, and whoever supervises the AI Act where you are.

The Court of Justice has been asked whether that is allowed. Its answer is yes, with conditions. The Court said two fines can be lawful, but only where three things are true:

1. the company could have seen the double exposure coming,

2. the two authorities work in step, and

3. the second fine takes the first into account so the total stays proportionate.

It said the same thing a second time on the same day, in a different case.

A specialist regulator followed by a general one. Which is roughly the shape of a data protection authority and an AI regulator looking at the same system.

Now look at what the AI Act tells its own regulator to weigh when setting a fine. One item on that list is whether you have already been fined by another authority, under other EU or national law, for the same conduct.

That is the third condition, written into the statute. Your GDPR fine is something the AI Act instructs the regulator to take into account.

The GDPR does not return the favour. Its own list of factors has no equivalent item. The closest is a catch-all at the end: any other aggravating or mitigating factor in the circumstances. Open-ended, discretionary, and not the same thing as a rule.

So the coordination exists, and it runs one way.

Which means the order matters. Fined under the GDPR first, and the AI Act regulator has to account for it. Fined under the AI Act first, and your data protection authority may account for it, under a catch-all, if it chooses.

The AI Act was written to account for the GDPR. The GDPR was written eight years before there was anything to account for.

Like this article? The AI Governance Roadmap is something you can use in practice. It’s a company’s roadmap with steps and working documents: the classification, inventory spreadsheet, role assignment, vendor questions and AI policy template. Everything a company needs to govern AI, in one place.

You finish the regulation map. Which laws apply to your company, which of your systems they touch, where every source is. It takes weeks, and almost none of that time goes on reading legislation. It goes on chasing answers around the company: which legal entity does what, whether a tool touches retail customers, who owns which system.

Then it’s done, and it does the thing it was built to do. The scope stops being arguable. “Does this even apply to us” has an answer now, with citations, and the conversation can finally move.

It also produces a list of gaps.

I thought the hard part was over at that point. What actually happened was that people stopped disputing the gaps and started avoiding eye contact instead.

Nobody argued. That’s the part worth sitting with. The list worked exactly as intended, and made the problems undeniable. What it could not do was put a name against any of them.

If you have run this exercise you already know how it ends. The gaps get logged. The document gets circulated. Someone says we should probably look at that. Six months later it is still true.

There is a reason that happens, and it isn’t organizational cowardice. It’s in the regulation.

Subscribe now

The EU AI Act Asks for a Responsibility Map Exactly Once

Article 17 sets out the quality management system a provider of a high-risk AI system has to put in place. Thirteen items: compliance strategy, design control, testing, data management, risk management, post-market monitoring, incident reporting, record-keeping, resource management. Then, at the bottom of the list:

(m) an accountability framework setting out the responsibilities of the management and other staff with regard to all the aspects listed in this paragraph.

That is the only place in the EU AI Act that asks an organization to write down, in one document, who is responsible for what. One sub-point, thirteenth of thirteen, in the article about quality management.

But there are three limits.

It applies to providers. Article 17 sits in Chapter III and binds providers of high-risk AI systems. If you deploy AI rather than build it, you have no equivalent obligation. If you build AI that isn’t high-risk, same thing.

It can be satisfied by something you already have. Article 17(3) lets any provider already subject to quality management obligations under sectoral EU law fold these aspects into the existing system. That reaches further than it sounds: medical device manufacturers, machinery and automotive suppliers, anyone already running a certified quality management system for a regulated product. Build the accountability framework into the system you were already audited on, and you have complied.

Article 17(4) goes further still for financial institutions. Comply with your internal governance requirements under EU financial services law and the quality management obligation is deemed fulfilled, with three exceptions: risk management, post-market monitoring, incident reporting. Point (m) is not among the exceptions.

Article 17(4) does add a sentence though:

To that end, any harmonised standards referred to in Article 40 shall be taken into account.

The deeming comes with a duty to take harmonised standards into account. No harmonised standard under Article 40 has been cited in the Official Journal yet. A duty to take into account something that doesn’t exist is a duty in form only, and it stays that way until CEN-CENELEC delivers and the Commission cites the result.

And it isn’t in force. The Digital Omnibus on AI deferred the bulk of Chapter III. Article 17 applies from December 2, 2027 for stand-alone Annex III systems and August 2, 2028 for AI embedded in regulated products.

Writing in August 2026, that is just under sixteen months. For providers. For high-risk systems only. And satisfiable by pointing at a governance framework you built for something else.

Then the Regulation Steps Back, In Writing

Article 26 covers what deployers of high-risk systems have to do, and it contains the closest thing the EU AI Act has to a named-person requirement:

Deployers shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support.

Natural persons. Authority. Not a function, not a committee. That’s real, and it asks for more than a one-line summary of Article 26 suggests.

But read what it covers: human oversight of a specific high-risk system while it’s running. It says nothing about who owns the compliance program, who owns a documented gap, or who gets to decide that a gap is acceptable for now.

The obligations in paragraphs 1 and 2 are without prejudice to other obligations under EU or national law, and then, in paragraph 3, to:

..the deployer’s freedom to organise its own resources and activities for the purpose of implementing the human oversight measures indicated by the provider.

The regulation is declining, on the record, to tell you how to organize yourself.

This is a drafting decision, not an omission. Article 96 gives the European Commission open-ended power to issue guidelines, but nothing on its published guidance program addresses who inside your company should own AI compliance. If you have been holding the assignment question open until guidance arrives, it probably won’t.

Deployers get their own version of the deeming move. Article 26(5) requires deployers to monitor the operation of a high-risk system, then adds that for deployers who are financial institutions subject to internal governance requirements under EU financial services law, that monitoring obligation is deemed fulfilled by complying with those rules.

If you built the AI system, Article 17 is yours. If you bought it, Article 26(5) is. Either way the move is identical, and so is the consequence. A structure you built for a different regulation is treated as sufficient, and whether it was designed with AI risk in mind never gets asked.

Other Regulations Name Someone

The GDPR names the data protection officer. Articles 37 and 38: mandatory designation in defined cases, reporting directly to the highest management level.

DORA names the management body. Articles 5 and 6: ultimate responsibility for ICT risk, a duty to define, approve and oversee the framework, and an annual review of it.

NIS2 names management bodies. Article 20: they approve and oversee the risk-management measures, undergo training, and can be held liable under national implementing law.

The Medical Devices Regulation names a person responsible for regulatory compliance. Article 15 requires at least one named individual inside the manufacturer, with defined qualifications and minimum years of experience.

Solvency II names key function holders. Article 42 on fit and proper, then Articles 44, 46, 47 and 48: named holders of risk management, compliance, internal audit and actuarial functions.

The EU AI Act names the company.

Every one of those regimes decided that an obligation without a name attached to it doesn’t get met. The EU AI Act reached the opposite conclusion, or more precisely, declined to reach one.

The practical consequence is to pick any regulated system in your company and you will find a named accountable person for its data, its security, or its operational resilience, and no named owner for the fact that it runs on AI.

Supervisors have started noticing this, and one of them has already acted. EIOPA published an Opinion on AI governance and risk management in August 2025 that creates no new rules and instead reads the EU AI Act alongside the sectoral rules it supervises, including DORA and the GDPR. It says the board remains responsible for the use of AI in the business, calls for clear definition of roles and responsibilities, and notes that firms may appoint AI officers to advise the other functions. The scope is the interesting part: the Opinion covers AI systems that are neither prohibited nor high-risk, expressly to avoid overlapping with the EU AI Act.

Which means a European supervisor wrote guidance on who owns AI, specifically for the systems the EU AI Act doesn’t reach.

That is probably the pattern to watch out for. The bodies that will fill this hole are not going to be the European Commission. They are the supervisors who already regulate you, who already hold a view on who should be accountable for what, and who are used to saying so.

The One Place the EU AI Act Does Allocate Ownership

There is a counter-example though.

The General-Purpose AI Code of Practice, drawn up under Article 56 and endorsed in August 2025, has a Safety and Security chapter that does what the rest of the EU AI Act doesn’t. Signatories commit to define responsibilities for managing systemic risk across all levels of the organization, allocate resources to it, and follow specific guidance on distributing those responsibilities, including assigning supervisory duties to the management board and pushing the obligations down defined reporting lines.

That is an EU instrument naming who owns AI risk, and it is EU AI Act machinery.

It is also voluntary, provider-side, and very narrow. The Code is not binding law, signatories can adopt some chapters and not others, and the Safety and Security chapter reaches only providers of general-purpose AI models with systemic risk: a handful of frontier labs, not the roughly 190 organizations that have signed the Code overall.

It buys no presumption of conformity, only the AI Office weighing your commitments when it sets a fine under Article 101.

What a Documented Ownership Gap Does To Your Legal Position

Article 99(7) lists what a national authority weighs when deciding whether to fine you and how much. Ten factors, (a) through (j). I find two of them important:

(g) the degree of responsibility of the operator taking into account the technical and organisational measures implemented by it

(i) the intentional or negligent character of the infringement

Point (g) puts your organizational measures directly into the fine calculation. Assigning an owner is an organizational measure. So is not assigning one, and the absence shows up on the face of your own governance documents.

Point (i) is sharper. A gap you never found is negligence. A gap you identified, wrote down, circulated to the people who could have fixed it, and left unassigned for eighteen months is a different animal. You have produced a written record of knowledge and a written record of inaction, and they are in the same document.

The list that ended the scope argument is also the list that proves you knew.

None of which is an argument for keeping worse records. Deliberately not looking is its own exposure, and a supervisor who finds no regulation map at all will draw the obvious conclusion about your organizational measures under point (g). The argument is narrower: documenting a gap starts a clock that assignment is supposed to stop.

Timing matters here. Until December 2027 there is no high-risk obligation to breach, so an unassigned high-risk gap is not yet fineable under the EU AI Act. What is live today: Article 5 on prohibited practices, Article 50 on transparency, the general-purpose AI obligations in Chapter V, and your GDPR exposure running alongside all of it. A documented gap in any of those is fine-relevant now. A documented high-risk gap is a record being built for a regime that arrives in sixteen months.

What Assignment Actually Takes

The reason the ownership gaps stay unassigned is that the assignment step has no deadline attached to it. Everything else on the roadmap has a date. This has nothing, because the one provision that would force it is sixteen months out and doesn’t reach deployers at all. Organizations focus on the work that has a date on it.

So it has to be made non-optional by someone with the standing to do that, and there are only three things they need to hand over.

A name. Not a function, not a committee, not “Legal and IT jointly.” Article 26(2) already tells you the standard for human oversight: natural persons with competence, training and authority. Apply the same test one level up. If your governance document says a department owns something, nobody owns it.

A budget. An owner who has to negotiate for resources every time the ownership gap needs work is a person with a title and a problem.

The authority to stop the system. This is the one that gets skipped. ISO/IEC 42001 is explicit about it in its treatment of AI roles and responsibilities: the role needs documented authority to act, not a designation. If your named owner cannot pull a system out of production without escalating to three other people, you have assigned blame rather than ownership.

ISO/IEC 42001 and the NIST AI Risk Management Framework both put role assignment at the foundation, which tells you the practitioners who drafted them hit this same wall. Neither is a harmonised standard under Article 40, so certifying to one discharges no EU AI Act obligation. What it gives you is a defensible answer to Article 99(7)(g) when someone asks what organizational measures you implemented. That’s not nothing, and it’s also not compliance.

None of this works without an honest inventory underneath it, which is the step before this one.

AI Governance Ownership Across Functions

The IAPP and Credo AI asked over 670 governance professionals across 45 countries which function holds primary responsibility for AI governance. Privacy came first at 22 percent. Legal and compliance also came first, at 22 percent. Then IT at 17, data governance at 10, ethics and compliance at 6, security at 5. The fieldwork ran in spring 2024, so read it as how the profession arranged itself as the regulation arrived.

No function holds a majority. Those six account for 82 percent, which leaves roughly one in five organizations answering something else entirely.

Distributed is the word the reports use. In practice, distributed is what an ownership gap becomes when it has no name against it.

Subscribe now

Set the frontier labs aside and every EU AI Act obligation in force today applies to the company as an abstraction. Article 4 on AI literacy, which the Omnibus rewrote in July to soften the standard from ensuring a level of literacy to supporting its development. Article 5 on prohibited practices. Article 50 on transparency, live since August 2. All of them binding on “providers and deployers,” which is to say on nobody in particular.

The first provision that requires a written answer to who is responsible arrives in December 2027, for providers, for high-risk systems, and can be satisfied by pointing at a structure you built for a different regulation.

Which leaves the ownership gap where it started. On the page, undeniable, and still no one’s.

Like this article? The AI Governance Roadmap is something you can use in practice. It’s a company’s roadmap with steps and working documents: the classification, inventory spreadsheet, role assignment, vendor questions and AI policy template. Everything a company needs to govern AI, in one place.

An associate spends two weeks on an article. Research, structure, argument, several drafts. A partner reads it, changes a heading, and the firm publishes it under his name.

This is not a scandal. It is how law firms, the Big Four, consultancies, politics and most of business have worked for as long as any of us have been in it. The named author supplied the judgment about whether the thing was right, and the accountability for it being wrong. The associate supplied the keystrokes.

And in ordinary commercial publishing, nobody has ever demanded a disclosure. No client alert has carried a line reading “100% written by our paralegal.” Formal rules do exist at the edges, where the stakes are personal: several US bars require a lawyer to disclose ghostwriting for a self-represented litigant, and academic authorship standards require contributors to be named. But for the alerts, the briefings and the thought leadership that make up most professional writing, nobody asked, because nobody thought the keystrokes were what they were buying.

Then the assistant stopped being a person, and suddenly the keystrokes are the only thing anyone wants to measure.

Two instruments now claim to deliver transparency about written work. One is law and has applied since August 2. The other is a button on this platform, live since July 21. They point at the same anxiety, they measure completely different objects, and if you write a newsletter it is worth knowing which one should actually matter you.

Subscribe now

The Law: In the Version That Concerns Writers

I went through Article 50 in full last week, including what human review, editorial control and editorial responsibility mean in the European Commission’s reading. The provision that concerns anyone publishing text is the second subparagraph of Article 50(4). The first subparagraph is about deepfakes. The second one is about you.

Start with whether it reaches you at all, because a lot of people reading this are not in Europe. The AI Act binds deployers established or located in the Union, and deployers in third countries where the output of the system is used in the Union. A newsletter written in Ohio with subscribers in Dublin is not obviously outside that. Whether “output used in the Union” condition is met by EU readers opening an email is untested, and we don’t know yet how this will play out.

Then four questions, in the order the provision actually asks them.

The first one I skipped last week.

Article 50(4) applies to deployers of an AI system that generates or manipulates text. If nothing generated or manipulated your text, nothing that follows applies. So where does editing assistance stop and generation start? The AIAct does not say so.

Article 50(2), which governs marking by providers rather than disclosure by deployers, carves out systems performing an assistive function for standard editing, or not substantially altering the input data or its meaning. That carve-out sits textually in 50(2) and does not appear in 50(4). So the argument that polishing is not generating is available, and it is not airtight.

Second, are you a deployer? You are, if you use an AI system under your own authority in a professional capacity. The Commission draws the line at economic activity: a natural person who gains economic benefit on a regular basis, or is otherwise engaged in business, trade, occupational or freelance activity, is a deployer. Purely personal, non-professional use sits outside the EU AI Act entirely.

A newsletter for six friends is out. Paid subscriptions put you in. So does a free newsletter that feeds a consulting practice, or that you treat as professional work. That somebody else pays your salary is irrelevant to your own publication, which is your own professional activity. Inside your day job the analysis differs, because employees acting under a company’s instructions are not separate deployers.

Third, is it a matter of public interest? The European Commission’s list is illustrative rather than closed, and it runs through politics and democratic processes, public administration and services, the administration of justice and law enforcement, fundamental rights, public security, public health, the environment, consumer safety, and economic, financial, scientific and cultural developments relevant to public debate. Write about any of those seriously and you are inside it. There is no case law. There is guidance, which sets out a three-part test of published, informative to the public, and on a matter of public interest, and which does not tell you where the boundary runs.

Fourth, did a person examine the substance, and is a person answerable for it. That is the exemption, and it needs both parts at the same time.

However, the Commission’s guidelines are interpretive and not binding. Market surveillance authorities can be expected to follow them. The Court of Justice is the only body that decides what the AI Act means, and it has not been asked yet.

If you get this wrong the ceiling is €15 million or 3% of worldwide turnover, enforced by national market surveillance authorities. For a solo newsletter the realistic exposure is somewhere near nothing. The line still matters, because it is the only defensible thing you can say.

And the fourth question is the same question the partner was answering.

It has never required a disclosure.

The Platform: Live Since July 21

On July 21 Substack switched on AI detection built with Pangram. Any reader can open a post, tap three dots, choose Scan for AI text, and get an estimate of how much of it was human-written and how much was AI-assisted.

It works only on posts and Notes published on or after July 21. It runs in the Substack Reader on web and in the iOS app, with Android still to come, and it covers Notes in the feed plus individual comments and replies. Reported minimum lengths differ between outlets, and neither Substack’s help page nor the announcement gives a firm number, so treat any figure you have seen as unconfirmed.

Writers get two controls. A statement under Settings called “How I make this,” which surfaces to anyone who scans your work. And the option to disable detection on a given post, after which readers see “AI detection unavailable,” which is its own kind of answer.

The European Commission wrote a rule about editorial responsibility. Substack shipped a classifier that reads sentence patterns.

Both were called transparency.

What Happened When I Scanned My Own Work

My article on MS Copilot Agent, published on July 22, came back as fully AI-assisted text. The reading was 100%. That piece was researched by me, argued by me, experienced by me in my day job, checked line by line against the Commission’s guidelines, and rewritten repeatedly (one part of it I rewrote eight time) because the ambiguity at its centre would not land clearly enough.

I then scanned the AI Act Tracker. Same desk, same process, different week. 11% AI. 89% human.

The tempting conclusion is that the detector is broken.

I do not think that, and I would rather not build an argument on a claim that is convenient. Pangram publishes a false positive rate on the order of one in ten thousand. More usefully, an independent evaluation by Jabarian and Imas, written up by Chicago Booth Review, tested it against three competitors and found it the only detector holding what they call policy-grade accuracy across models, though performance degrades on very short passages.

So I guess it was doing its job both times, and between those two pieces the amount of AI assistance in the prose genuinely differed. Note the words the tool actually uses. It reports AI-assisted rather than machine-written, and it calls the figure an estimate rather than a verdict. Both of those are more careful than a round 100% makes them sound.

In my opinion that is the actual problem.

Both pieces went through the same editorial process. Both were verified against primary sources by a lawyer. Both carry my name, my judgment, and my liability if they are wrong. Under Article 50(4) they are indistinguishable, and I believe that both sit inside the exemption.

One scored 11%. The other scored 100%.

The number moved. My accountability did not.

The detector is not malfunctioning. It is answering a question the law does not ask. Article 50(4) wants to know whether a person examined the substance and whether a person is answerable for it. A classifier cannot see either, because neither is in the text.

What is in the text is rhythm, cadence and word choice.

Polish.

The least substantive layer of any piece of writing. Not the argument, not the structure, not whether the article number is right or the deadline is real.

Which is why the verdict and the obligation come apart in both directions. You can be compliant and flagged. You can also be non-compliant and clean, because a writer who pastes raw output, runs it through a rewording tool and publishes without reading it properly may well scan as human.

That writer is the one Article 50(4) was written for.

The Hole In the Tool

Substack’s own documentation says the scan is unavailable for video or audio posts, for posts viewed on standalone Substack sites including custom domains, and for emails.

Three exclusions, and the last two are the ones that reach you. This newsletter lives at ailawdecoded.com. Most of you are reading this in your inbox, because that is what a newsletter is.

In both of those places the label does not exist. No scan on the website, no scan in the email. The verdict is visible only to a reader who opens the piece inside the Substack Reader or the iOS app.

A transparency tool that cannot reach the publisher’s own website, and cannot reach the email that delivers the writing to the people who subscribed to it, has a fairly substantial gap where its transparency should be.

There is a third instrument, for completeness. The Commission’s Code of Practice on Transparency of AI-generated Content, finalized in June, covers the labelling duties in Article 50(4) and gives signatories an approved route to demonstrating compliance. It is built for platforms and generative AI companies rather than individual writers, and signing it is not a realistic move for a person with a newsletter. Worth knowing it exists before somebody tells you that you should have signed it.

So, the law measures editorial responsibility and cannot see how the text was made.

The detector measures how the text was made and cannot see who is responsible for it. And it only looks in one of the three places people read.

Subscribe now

What Editorial Control Looks Like From the Inside

The practical question for a writer is not whether you use AI. It is whether you could describe your process to a reader, or a regulator, and have it clear the exemption.

Mine, in the detail the standard actually asks for:

Topics come from practice. From the work itself, and from questions readers leave in the comments. Nothing gets written because it would be easy to generate.

Every piece starts from a brief I write: the article numbers in play, the argument, the opening, the point the piece has to drive at. Then research, and verification of every claim against the regulation, the official guidance, and other lawyers’ readings of it. Where something cannot be confirmed, the draft says so, and that sentence survives into publication.

Then editing, which takes most of the time. Like I mentioned, a piece can go through eight rewrites. Not for typos. For the angle, for which points survived, for the closing. Seven versions may not be clear enough about an ambiguity that matters, so they don’t get to be published.

That is human review of the substance. Somebody with relevant knowledge decided what was true, what was arguable, and what was not going out, and my name is on the result, which means I hold the legal responsibility for every claim in it.

A classifier cannot see any of that. It sees the eighth version’s sentences and reports on their texture.

If you publish, there are three things worth doing:

1. Work out whether you are a deployer. That mostly means asking whether the newsletter is professional activity or a hobby, and answering honestly.

2. Decide whether your process would survive the description above. “AI drafts it, I skim it, it ships” does not, and that is the case the label exists for.

3. Write the process down. Substack now gives you somewhere to put it, under Settings, called “How I make this.” It is the voluntary version of a disclosure the law may or may not require of you.

Detection is on for this piece. Turning off the scanner on an article about AI disclosure would be indefensible, so whatever it returns is what it returns.

The associate was never the disclosure. The partner’s name was the disclosure, because the name carried the judgment and the liability. That has not changed. Only the assistant has.

I won’t apologize for using AI for my prose. You shouldn’t either.

Like this article? The AI Governance Roadmap is something you can use in practice. It’s a company’s roadmap with steps and working documents: the classification, inventory spreadsheet, role assignment, vendor questions and AI policy template. Everything a company needs to govern AI, in one place.

I don’t know if it is just me, but I feel like it’s becoming increasingly hard to keep track of all the guidelines, Q&As and codes the EU publishes for the AI Act. Especially in combination with the timeline. What is applicable when, which guideline is in force and which one is still in public consultation. And what should a small company actually do, and when?

OK, I have to be honest. From the conversations I have, I know it’s not just me. That’s why I decided it’s high time I publish this AI Act Tracker.

I will update the Tracker whenever something moves. The date below tells you when I last checked and updated the Tracker.

Just one disclaimer (because I’m a lawyer, you know): This is not a legislative history. The Future of Life Institute maintains one of those, plus an implementation timeline of what is still ahead. This is a different thing: a running record of what has already changed, and what changed for you and me as a result.

Last checked: August 2, 2026.

Subscribe now

Still in draft

Two documents on this page are not final. Do not build a position on either without saying so.

Serious incident reporting, Article 73. Draft and template published September 26, 2025. No final version, no announced date. Originally expected August 2, 2025.

High-risk classification, Article 6(5). Draft published May 19, 2026, consultation closed July 23, 2026, final expected before the end of the year.

Subscribe now

Dates ahead

After August 2, 2026, these are the following obligations that we can expect:

December 2, 2026. New Article 5 prohibitions take effect: AI systems that generate or manipulate child sexual abuse material, and systems that generate or manipulate non-consensual intimate imagery. Added by the omnibus.

December 2, 2026. Article 50(2) watermarking, for systems placed on the market before August 2, 2026. Anything launched from August 2 marks from day one, so this date only helps systems that already existed.

End of 2026. Final guidance on high-risk classification under Article 6(5) expected. It was statutorily due on February 2, 2026.

August 2, 2027. GPAI models placed on the market before August 2, 2025 must comply. Article 111(3).

December 2, 2027. Annex III standalone high-risk obligations apply. Moved from August 2, 2026.

August 2, 2028. Annex I embedded high-risk obligations apply. Moved from August 2, 2027. Machinery Regulation products were excluded from the high-risk regime altogether and handed to delegated acts, so they are not on this clock at all.

August 2, 2030. Legacy high-risk systems operated by public authorities.

For the fuller forward view, including procedural milestones, the Future of Life Institute’s implementation timeline is more detailed than anything worth duplicating here.

Something changed and it is not here? Email me: silvia@ailawdecoded.com

Like this article? The AI Governance Roadmap is something you can use in practice. It’s a company’s roadmap with steps and working documents: the classification, inventory spreadsheet, role assignment, vendor questions and AI policy template. Everything a company needs to govern AI, in one place.

When the Omnibus on AI deal landed in May, it read as relief. High-risk obligations for Annex III systems: pushed to December 2027. AI embedded in the regulated products listed in Annex I: August 2028. If the AI Act sits in your portfolio, next to everything else that does, you probably made the reasonable mental note. Revisit next year.

The note is wrong by one chapter.

Article 50, the transparency rules, did not move. It applies from August 2, 2026. This Sunday. And on July 20, less than two weeks before the deadline, the European Commission published its final guidelines on how to comply. Thirteen days of runway. Brussels’ idea of a running start.

The timing is inconvenient. But I would say that the substance matters more. Article 50 reaches more companies than the high-risk chapter ever will. The high-risk rules catch CV-screening tools and credit scoring. Article 50 catches the chatbot on your website, the AI-generated visuals in your marketing, and the product descriptions your content team stopped writing by hand more than a year ago.

Subscribe now

What Article 50 Is

The AI Act sorts systems by risk: prohibited, high-risk, transparency-risk, minimal. Article 50 is the third box. It also stacks on the second, because Article 50(6) says the transparency duties do not affect the Chapter III requirements for high-risk systems. So there is no “we’re not high-risk, so we’re fine,” and no “we’re already doing the high-risk work, so this is covered.” Article 50 applies to any AI system used in four specific situations, whatever else is true about it.

The four situations:

1. An AI system interacts directly with people (chatbots, voice assistants, AI agents)

2. An AI system generates synthetic content (text, images, audio, video)

3. An AI system runs emotion recognition or biometric categorisation on people

4. AI-generated content gets published: deepfakes, or text informing the public on matters of public interest

Breach the transparency rules and the ceiling is €15 million or 3% of worldwide annual turnover, whichever is higher (Article 99(4)(g)). For SMEs and start-ups the calculation flips to whichever is lower, and the European Commission’s guidance now extends that proportionality to small mid-cap companies as well. Not the €35 million tier reserved for prohibited practices. Still not a rounding error.

Two of the four obligations belong to providers, the companies that build the systems. Two belong to deployers, the companies that use them. You may be both. A company that builds a customer-facing bot on top of a foundation model and also publishes AI-generated content holds obligations on both sides.

One carve-out runs through all four: systems authorised by law to detect, prevent, investigate or prosecute criminal offences are excepted, with conditions. If you are not in law enforcement, it will not help you.

The Provider Duties (Systems That Talk or Generate)

If you provide an AI system that interacts with people, Article 50(1) requires it to be designed so that people know they are talking to AI. From the start of the first interaction. Clear, distinguishable, accessible.

There is an exception where this is obvious. The guidelines then spend considerable effort narrowing what counts as obvious:

the test is a reasonably well-informed, observant and circumspect person, judged against your actual audience,

And the Commission says to read the exception restrictively. A widget labelled “Assistant” is not disclosure. And the obligation protects natural persons, not just consumers: the Commission reads it to cover consumers, professionals and other users alike, which is why the internal HR bot your employees use counts too.

One detail for anyone building agents. The guidelines confirm AI agents fall under Article 50(1), and where a provider cannot reliably predict whether the agent will end up interacting with a human, it should be designed to disclose its AI nature in all situations where such interaction is reasonably foreseeable. The agent has to introduce itself. Few of the agent demos circulating are designed for this.

If you provide a system that generates synthetic content, Article 50(2) requires the outputs to be marked in a machine-readable format and detectable as AI-generated. This is the watermarking obligation: metadata, watermarks, provenance signals. Article 50(2) asks for solutions that are effective, interoperable, robust and reliable, so far as technically feasible. The Code of Practice published in June prescribes no single technique, and the reason is not hard to see: no marking method available today satisfies all four criteria on its own. Expect to layer them.

The exemptions are worth reading before you panic-procure a watermarking vendor. Standard editing assistance is out: spell-check, grammar, quality improvements, anything that does not substantially alter the data or its meaning. So are short sequences of numbers or letters, source code, and outputs that never reach a human. Content that stays inside closed industrial pipelines is out too, with a condition: the exemption falls away for the final output. The AI-generated asset that actually ships is not covered. The guidelines also include a narrow exemption for certain business-to-business and industrial contexts. Open-source systems, for the record, are not exempt.

The Deployer Duties: Where You Might Come In

Most readers of this newsletter are not building foundation models. You are using AI systems under your own authority, professionally. That probably makes you a deployer, and two obligations are yours.

If you deploy emotion recognition or biometric categorization, Article 50(3) requires you to inform the people exposed to it. Sentiment analysis in the call centre, demographic categorisation in retail analytics. Real-time or after the fact, both count. But screen against Article 5 first: inferring emotions in the workplace or in education institutions is prohibited outright, save for narrow medical and safety purposes. Where the ban applies, it is not a disclosure question at all.

If you use AI to create deepfakes, Article 50(4) requires you to disclose that the content is artificially generated or manipulated. Visibly. At first exposure. And this is where the definitions deserve your attention, because the word “deepfake” suggests malice, and the definition does not require any.

A deepfake under Article 3(60) is

AI-generated or manipulated image, audio or video that resembles existing persons, objects, places, entities or events, and would falsely appear authentic.

Three criteria: resemblance, something that exists or plausibly could, and the capacity to mislead about authenticity. Dragons are out. Talking animals are out. Standard film production, color correction, noise reduction: out.

An authentic photo of an empty apartment, furnished by AI for the listing: in. That example is not mine. It appears in the Commission’s own labelling guidance, as a case for the “partially AI-modified” label. Product visuals, staged scenes, AI photography of real places. Your marketing department has deepfake obligations. It has probably not been told.

The second half of Article 50(4) covers text.

Publish AI-generated text with the purpose of informing the public on matters of public interest, and you must disclose it. The public-interest list is long. Politics and democratic processes, public administration and services, justice and law enforcement, fundamental rights, public security, public health, environmental protection, consumer safety, plus economic, financial, scientific and cultural developments that may be relevant to public debate. A fair amount of corporate publishing brushes against that.

Most corporate text will escape through the exemption: no label needed where the text underwent human review or editorial control, and a person holds editorial responsibility for it. Read the definitions before you rely on them.

Human review means deliberate examination of the substance by someone with relevant knowledge and professional judgement.

Editorial control means the authority to approve, alter or reject the content on substantive grounds, fact-checking included.

And editorial responsibility, per the European Commission, means someone holds the ultimate legal responsibility for the publication. A spell-check pass is none of the three. If your workflow is “AI drafts it, someone skims it, it ships,” you have a choice: make the review real and documented, with a name attached, or add the label.

The Watermark Is Not the Label

Your AI vendor markets its compliance. The model watermarks its outputs, embeds provenance metadata, signs the Code of Practice. You might conclude that content generated with a compliant tool is compliant content.

The two obligations are two layers, and only one of them is the vendor’s.

The machine-readable mark under Article 50(2) is the provider’s job: invisible, embedded, readable by detection tools. Y

our disclosure duty under Article 50(4) is a separate, visible layer: a label a person can see or hear without any tool at all.

The Commission’s Q&A says it plainly: deployers cannot simply rely on the machine-readable marking embedded by the provider to fulfill their disclosure obligation.

The provider marks. You label. A compliant tool does not make your published deepfake compliant. It just means the invisible half was done by someone else.

How to Label, Practically

The EU published a set of official icons in June. Three of them:

• a basic “AI” icon,

• one for fully AI-generated content,

• one for partially AI-modified content.

They are free to download (SVG and PNG), free to use, no attribution required.

The placement rules, from the Code of Practice: perceivable at first exposure, not hidden behind overlays, embedded directly into the content (creative works get more flexibility), and still visible when the content is reshared or downloaded.

The Commission user-tested the icons and found they perform better with a text label attached, “modified” or similar. The icon that needs a caption to work.

Two things to hold apart: the icons are optional, the labelling is not. The Commission says so itself, so downloading the icon set does not close the file. Using these icons does not establish legal compliance by itself. It is the same trap as the watermark, one layer up.

You can use your own disclosure format if it is clear, distinguishable and accessible. What I think will not survive that test: a small line in the website footer, a faint watermark on an image, a label that flashes for a frame, anything buried in the terms and conditions.

For artistic, creative, satirical or fictional work, the obligation softens: disclose the manipulation exists, in a way that does not hamper the display or enjoyment of the work. A credits-style disclosure rather than a stamp across the screen.

Subscribe now

The Dates

August 2, 2026: everything above applies. Chatbot disclosure, emotion-recognition notice, deepfake and text labelling, and the marking obligation for systems placed on the market from that date.

There is no exception under Article 50. The transitional regime in Article 111, the one that lets certain legacy high-risk systems stay outside the AI Act unless they are significantly changed, has no equivalent here. A chatbot you launched in 2023 is in scope on Sunday. So is the generative tool your team has been using since last spring. One exception, and it is narrow.

December 2, 2026: Providers of generative systems already on the market before August 2 get four extra months, for the machine-readable marking obligation only. Nothing else is deferred, and no deployer obligation is deferred at all.

The four months come from the Omnibus on AI, published in the Official Journal on July 24 and in force three days later. Five days before the deadline it modifies. Confirm the publication date yourself before you rely on it, because it landed the same week this article went out.

Content generated before August 2 does not need retroactive labels. The Commission encourages them anyway.

What to Do This Week

If you are wondering what to do now, there are five moves needed:

1. Inventory the four situations. One page: where do we have systems talking to people, systems generating content, emotion recognition, published AI content? You cannot label what you have not listed.

2. Fix the chatbot disclosure. The cheapest obligation on the list: a clear line at the start of the first interaction. Include the internal bots.

3. Audit published content against the deepfake definition. Not “do we make deepfakes” but “do our visuals depict real or plausible people, places or products in a way that looks authentic.” Start with marketing, where most of the exposure sits.

4. Decide your text position. For anything AI-written that informs the public: real, documented human review with named responsibility, or a label. Pick one per content stream and write it down.

5. Ask your vendors two questions. Do your systems mark outputs in machine-readable format, and can we detect it? Their answer covers their layer. Then set up yours.

What Sits Underneath

Enforcement mostly belongs to national market surveillance authorities, and they are behind. The designation deadline was August 2025. As of June, nine member states had designated both their market surveillance and notifying authorities. National penalty laws are similarly unfinished. The enforcers are not missing so much as untested and unevenly resourced, since most member states are handing AI competence to regulators that already exist and already have full desks.

Two reasons not to treat that as breathing room.

The AI Office is not behind. It is competent for AI systems built on general-purpose AI models where the same entity provides both, and for systems integrated into the very large platforms designated under the Digital Services Act. The Omnibus on AI widened its remit further. If your chatbot sits on a foundation model from the company that also built the model, your enforcer is in Brussels, fully staffed.

And Article 50 breaches are the most visible violations in the entire AI Act. A missing chatbot disclosure, an unlabelled AI visual: public, permanent, screenshot-able by any competitor, journalist or future regulator with a scrolling habit. The Unfair Commercial Practices Directive (2005/29/EC) already reaches deceptive content today, enforced by consumer authorities that very much exist.

The transparency rules arrive Sunday. Some of the enforcers are still being appointed.

Your audience is already here.

Like this article? The AI Governance Roadmap is something you can use in practice. It’s a company’s roadmap with steps and working documents: the classification, inventory spreadsheet, role assignment, vendor questions and AI policy template. Everything a company needs to govern AI, in one place.

An employee builds an MS Copilot agent for their own work. It drafts proposals in the company template, pulls pricing from the right SharePoint folder, and saves them an hour a day. After three weeks, they share it with the team. A month later, it’s in an all-staff email with a link.

Somewhere in that sequence, the company acquired obligations under the EU AI Act. The intuitive answer for where: at the sharing. Private use was the employee’s own business. Distribution made it the company’s.

That answer reads the regulation backwards.

The obligations attached in week one, before anyone else knew the agent existed. Sharing changed something, just not that. The gap between those two answers decides whether a company governs employee-built AI or merely finds out about it.

Subscribe now

The Personal Use Exemption Covers Your Holiday, Not Your Job

The AI Act defines a deployer in Article 3(4):

a natural or legal person, public authority, agency or other body using an AI system under its authority except where the AI system is used in the course of a personal non-professional activity

“Personal non-professional activity” is quite narrow actually. Article 2(10) adds the word “purely”: the AI Act does not apply to deployers who are natural persons using AI in the course of a purely personal non-professional activity. Asking Copilot where to go in September: covered. Building an agent that drafts your weekly reports: professional, however few people know about it. The exemption follows the activity, not the account.

And the deployer of that professional use is the company, not the employee: the agent runs in the company’s tenant, on a company license, for company work, which is use “under its authority” on any serious reading, and Article 3(4) asks nothing about whether the company knew. (No regulator has ruled on an employee-built agent yet. This is interpretation, the mainstream one, and mine.) So the company was a deployer of that agent for three weeks without knowing it existed.

If a compliance training taught you that the company only becomes a deployer at sharing, the rule has a real source. For tools a company never provided and merely tolerates (an employee’s private ChatGPT account in a browser), there is a serious argument that the employer lacks authority over the use. Lawyers split on that case.

An agent built inside the company’s own Copilot is not that case. The company licensed the platform, enabled the feature, and controls the tenant. Article 4 makes the same assumption: before and after the omnibus softened it, the AI literacy provision is addressed to providers and deployers for the people using AI systems on their behalf. Staff using AI for work is the deployer’s use. A legal person has no other way to use anything.

What Sharing Changed

Legally, almost nothing. Practically, two things moved.

Scale. One person relying on an agent is an anecdote. A company relying on it is a dependency, with the error surface to match. If the pricing sheet it reads is stale, that’s now every proposal it touches.

Deniability. Before the email, the company’s gap was factual: no inventory, no awareness. After the email, the use is announced, organization-wide, in writing. Whatever duties exist are now duties the company visibly isn’t performing.

Which leaves the question with actual money on it. The company deploys a Copilot agent, fine. When does it become the deployer of that particular agent, and what extra obligations arrive when it does? Take a harmless one: an agent that walks employees through submitting business-trip reports, shared with the whole company.

There are two layers here. If the agent counts as nothing more than a configuration of Copilot, there is no separate deployer question: the company was deploying Copilot all along, and the agent is one way of using it. If the agent counts as its own AI system (an open question, below), the deployer analysis repeats: first use for work under company authority, so the company was the agent’s deployer while its creator was still its only user. Under neither reading is sharing the moment deployer status begins.

What sharing plausibly triggers is a different concept. The AI Act defines putting into service as supplying an AI system for first use “directly to the deployer or for own use.” An agent distributed org-wide starts to look like a system the company put into service for its own use. And whoever develops an AI system and puts it into service is its provider, the role with the heavy obligations. Follow that logic to its end and the company is the provider of this particular agent: it developed the system (through its employee) and rolled it out for its own use.

Two conditions stand between that sentence and settled law: whether the agent is an AI system in its own right at all, and whether an internal rollout happens “under its own name or trademark,” as the provider definition in Article 3(3) requires. Both are unresolved, and for the trip-report agent, comfortably little turns on them. Under the AI Act, obligations scale with risk class, not with the number of systems on your list, and provider of a minimal-risk system is a nearly empty role.

A benign agent adds almost nothing to what the Copilot rollout already required: literacy, transparency where output leaves an informed audience, prohibited-practice hygiene. What it adds is one unavoidable task: someone has to look at its purpose and classify it. Everything heavier waits on that.

One thing the email did not do: internal sharing is not “placing on the market”. Making available on the market means supply in the course of commercial activity. Colleagues are not a market. The comfort is narrower than it looks, though. Market supply is not the only route to the heavy provider obligations: for a high-risk agent, putting into service for the company’s own use is enough. What stays internal stays light only while the purpose does.

Microsoft Ships the Gate Open

The product mechanics deserve a closer look, because two default settings decide more than most written AI policies do.

A new Copilot agent is private. Microsoft’s documentation gives its creator three options: keep it private, share it with specific people or groups, or share it with anyone in the organization via link. Whether employees can use that third option is an admin setting. Its default value: all users may share org-wide.

Unless your admin changed a setting, every licensed employee can distribute an AI agent to your entire company. No approval step. That all-staff email needed no one’s permission.

Microsoft’s documentation also states that changes to the sharing controls apply only to new sharing actions: existing shared agents remain accessible. Tighten your policy next quarter and every agent shared before the change stays in circulation.

There is also an approval gate. Agents submitted to the organizational catalog go through admin review before they appear in the company’s agent store. The gate exists. The sharing link walks around it.

Two more details for whoever owns offboarding. Only an agent’s creator can delete it, though admins can reassign ownership if they know the agent exists. And nothing in the sharing flow retires an agent when its creator leaves: it keeps answering questions from a knowledge base nobody is updating.

None of this is a criticism of Microsoft, and roughly the same story applies to custom GPTs, Gemini Gems, and every other build-your-own-assistant feature: the vendor optimizes for adoption, the defaults follow. But an AI Act compliance program that audits policies and never audits tenant settings is auditing the wrong document.

Purpose Is Where It Turns

Everything so far is manageable. The modest obligations that travel with any minimal-risk agent: AI literacy under Article 4, applicable since February 2, 2025, though the omnibus softened it from ensuring literacy to supporting its development. And transparency under Article 50 from August 2, 2026, which turns on people knowing they’re dealing with AI. Inside the company, that’s obvious. It stops being obvious when the agent’s output reaches customers. Weeks away, not next year.

The structural risk is different, and it has a specific address: Article 25(1)(c).

A deployer becomes the provider of a high-risk AI system if it modifies the intended purpose of an AI system, including a general-purpose one, such that the system becomes high-risk. And when that happens, Article 25 is explicit about the consequence: the original provider stops being the provider of that system. Microsoft exits. You inherit the full Article 16 stack: risk management, technical documentation, conformity assessment, registration, the works.

One more twist. The departing provider normally owes the new one cooperation and documentation under Article 25(2), except where it clearly specified that its system is not to be turned into a high-risk one. Microsoft’s use terms restrict high-risk uses. Check your agreement before assuming the handover comes with help.

Copilot’s intended purpose is general productivity. An agent is, functionally, a purpose machine: you give it instructions, knowledge, and a job. Which means the distance between “deployer of Copilot” and “provider of a high-risk AI system” is one agent built with the wrong job description.

The recruiting team builds an agent that pre-screens CVs against role requirements. That’s employment, Annex III, point 4: high-risk. Article 25(1)(c) has no seniority threshold, no requirement that anyone approved anything.

The high-risk obligations themselves now apply from December 2, 2027, after the omnibus moved the dates. That’s runway. Use it.

Two things are not waiting for 2027.

First, the prohibitions, in force since February 2025 and carrying the top fine tier: €35 million or 7% of global turnover. The relevant one for this story is Article 5(1)(f), emotion inference in the workplace. An agent that reads sentiment in the team’s messages so a manager knows “how everyone’s doing”? An enthusiastic employee can build a prohibited practice in an afternoon, with knowledge sources and a friendly name.

Second, a detail from Article 26(7) that reframes the whole sharing question: before using a high-risk AI system at the workplace, employers must inform the affected workers and their representatives. For high-risk agents, an announcement to staff isn’t the moment the trouble starts. It’s a legal requirement.

Is an Agent Even a Separate AI System?

No one can tell you yet. The Commission’s guidelines on the AI system definition predate the no-code agent wave and don’t address it. The May 2026 draft guidelines on high-risk classification come closest, but they answer a neighboring question: multi-component and agentic setups are classified as one system when their linked parts jointly serve a high-risk purpose. Direction confirmed, purpose decides, slicing doesn't help. Who answers for a single no-code agent remains open.

There are two defensible readings.

One: a declarative agent is a saved configuration of Microsoft’s system, instructions plus knowledge plus permissions, and the AI system remains Copilot, with Microsoft as its provider.

Two: an agent with its own name, its own purpose, its own knowledge, its own tool permissions, its own user base, and an entry in a store is an AI system built on a general-purpose model, and someone other than Microsoft is answering for it. A saved prompt sits at one end. An org-wide Copilot Studio agent with autonomous triggers sits at the other. The vocabulary (”agent,” “skill,” “Gem”) is marketing. The AI Act’s question is functional.

Two reasons not to lose sleep over the metaphysics. For a benign internal agent, both readings land in nearly the same place: thin obligations either way. And in the scenario where the readings would diverge, the high-risk one, Article 25(1)(c) settles the question by making you the provider regardless.

One more fear worth retiring: building agents does not make your company a provider of a general-purpose AI model. Under the Commission’s GPAI guidelines, that role attaches to modifications that significantly change the model, with an indicative threshold of training compute above roughly a third of what trained the original. Instructions and knowledge files are not training compute. Your agents are prompting, not pre-training.

Subscribe now

What to Actually Do About It

The duties in the AI Act share one hidden precondition: you can’t train people on agents, disclose agents, purpose-check agents, or classify agents you don’t know exist. The inventory comes first.

For the people building agents, six rules that fit on one page:

1. There is no personal AI at work. Work account plus work task equals the company’s deployment, even if no one knows. The exemption you’re thinking of covers your holiday planning.

2. Building is fine. Repurposing is the event. The moment an agent starts touching decisions about people (hiring, performance, promotion, credit, claims, access to anything), stop and ask before you share.

3. The short forbidden list is absolute. No agents that infer colleagues’ emotions, score people, or nudge them manipulatively. Not with approval, not as a pilot, not as a joke.

4. Four questions before you hit Share. What does it do? Whose data does it read? Who will rely on it? Could its output touch a decision about a person?

5. Label what leaves the team. People outside your context need to know they’re reading AI output.

6. Your agents outlive your tenure. When you change roles or leave, hand them over or kill them.

For whoever owns “the AI thing” at your company, six checks:

1. Open the admin center today and look at the agent sharing setting. If nobody changed it, it’s set to everyone.

2. Route org-wide distribution through the catalog. The approval gate is already built. Make the link route the exception.

3. Build the register. One row per agent: name, owner, purpose, knowledge sources, audience. This is the unglamorous document that makes every other obligation performable.

4. Add agents to the leaver checklist. Reassign or retire them when their creator walks out.

5. Put agent-building into your AI literacy training. Article 4 has applied since February 2025 (now an effort obligation after the omnibus, but applicable), and the person most in need of it is your most enthusiastic builder.

6. Name the escalation trigger in plain words. “An agent that helps decide about people goes to [name] before sharing.” One sentence, on the intranet, beats a policy nobody opens.

The Question the AI Act Asks

The all-staff email didn’t create the company’s obligations. It ended the period in which no one could see them.

And an email is the polite version. Most agents move through links, team channels, and word of mouth: no announcement, no list, no owner once the creator changes jobs. The population grows every quarter, mostly useful, occasionally one job description away from Annex III.

The register you haven’t built yet is a list of things you already answer for.

The AI Act doesn’t ask whether you knew.

Like this article? The AI Governance Roadmap is something you can use in practice. It’s a company’s roadmap with steps and working documents: the classification, inventory spreadsheet, role assignment, vendor questions and AI policy template. Everything a company needs to govern AI, in one place.

In February 2017, the European Parliament voted on considering whether robots should become “electronic persons”. ChatGPT was nearly six years away. The most advanced consumer AI in Europe could recommend a playlist. And the Parliament was already asking the question that would follow EU lawmakers for the next nine years:

When the machine gets it wrong, who pays?

The electronic personhood idea died, mercifully. The question survived.

Hold onto it. It’s the thread that makes sense of everything the EU has done on AI since, including the last eighteen months, which otherwise look like the EU changing its mind.

Because if you’re trying to track EU AI regulation in 2026, it does look like that. The EU AI Act got amended before most of it applied. A liability directive appeared, sat in Parliament for three years, and vanished. In June, the Commission proposed something called the Cloud and AI Development Act, which regulates data centres and sounds like it wandered in from a different policy file. Each development makes sense on its own. Together, they read as noise.

They’re not noise. They’re one story in three acts: the EU built a complete legal system for AI, dismantled part of it before it applied, and is now spending public money to make sure there’s a European AI industry left to regulate. If compliance is your job, the arc matters more than any single law. It tells you which rules will be enforced, which got softened, and where the next obligations might come from.

Subscribe now

Act I: Regulate (2017–2024)

That 2017 resolution asked the Commission for liability rules covering robots and AI. The EU’s opening move on AI law was liability. Market access rules came four years later.

What followed was Brussels at its usual pace. An AI strategy in 2018. Ethics guidelines from an expert group in 2019: voluntary, high-minded, and largely ignored by the market. Then the February 2020 White Paper, which committed to a risk-based approach and introduced the framing that still runs the show: an “ecosystem of excellence” and an “ecosystem of trust”. Ursula von der Leyen had promised AI legislation within her first hundred days. What arrived around day one hundred was a white paper announcing the intention to legislate. In Brussels terms, that is punctual.

The actual proposal landed on April 21, 2021. The logic behind it: Member States were starting to write their own AI laws, and one regime is cheaper than 27. Trust was treated as an adoption strategy (people won’t use AI they don’t trust, so trust rules double as industrial policy). And after the GDPR, there was open ambition to set the global standard again.

One architecture choice from that proposal explains more than anything else in it. The AI Act was built as product safety law: risk classes, conformity assessments, CE marking. AI regulated like lifts and medical devices, because that was the machine the EU already had. It is a market access instrument, not a fundamental rights instrument. A good share of what frustrates people about the AI Act traces back to that choice.

And the system was designed with two halves. In September 2022, the Commission proposed the AI Liability Directive together with a rewritten Product Liability Directive. The AI Act tells you how to put AI on the market. The liability pair answered what happens when it hurts someone anyway. Rules and consequences. On paper, a complete system.

Then the negotiations met reality. Six days before the Council agreed its negotiating position in December 2022, ChatGPT launched. The text barely contemplated general-purpose AI, so Parliament wrote an entire GPAI chapter mid-flight in 2023. In November 2023, France, Germany and Italy nearly collapsed the final talks by demanding that foundation models be governed by “mandatory self-regulation”, a position that happened to match the interests of Mistral and Aleph Alpha. The deal that saved the file took a 36-hour negotiating marathon in December 2023.

The pattern is worth registering: the fight between protection and competitiveness didn’t start after the AI Act passed. It was inside the building the whole time.

EU AI Act (Regulation (EU) 2024/1689) entered into force on August 1, 2024. Act one complete. The EU had its rulebook. The liability half was still sitting in committee.

Act II: Retreat (2024–2026)

In September 2024, Mario Draghi’s competitiveness report handed Brussels a new vocabulary: regulatory burden, simplification. The mood shifted from “the world will copy our rules” to “our rules are why we don’t have an AI industry.” Whether that diagnosis is correct is a separate article. Its effects arrived fast.

Laws usually die loudly. A failed vote, a walkout, a press conference. The AI Liability Directive died in an annex: one line in the Commission’s 2025 work programme, published February 11, 2025, marking it for withdrawal due to “no foreseeable agreement.” Parliament’s legal affairs committee was actively working on the file at the time, with votes scheduled. Twelve industry associations had formally called for the withdrawal weeks earlier. It is rare for Brussels to move so quickly on stakeholder feedback. The formal withdrawal appeared in the Official Journal on October 6, 2025. The ePrivacy Regulation died in the same annex, after eight years of negotiation.

It’s worth being precise about what was lost, because the directive had a modest reputation and an even more modest text. It created no new liability regime. It gave people harmed by high-risk AI two procedural tools: court-ordered disclosure of evidence (Article 3) and a rebuttable presumption of causality (Article 4). Without them, a rejected job applicant who suspects the algorithm has to reverse-engineer a neural network to prove their case. Parliament had asked for strict liability in 2020. The Commission offered presumptions. Even presumptions turned out to be too much.

The stated reasoning, per Commissioner Virkkunen: the directive would have led Member States to "apply the rules in different ways". The result of withdrawing it: AI liability now runs through 27 national tort regimes, each applying its own rules. The fragmentation offered as the risk is the outcome that was chosen.

So where does liability actually live now? In the surviving half of the 2022 pair. The new Product Liability Directive treats software and AI systems as products, SaaS included, and applies to products placed on the market from December 9, 2026. It even inherited the dead directive’s tools: disclosure duties and presumptions for complex cases. But it compensates product-defect damage: death, personal injury, property, destroyed data. An AI system that wrongfully denies you a loan, filters out your job application, or scores you into a worse insurance bracket produces none of those. The harms that motivated the liability directive in the first place now depend on which of the 27 countries you’re standing in when the algorithm gets it wrong.

The retreat also reached the AI Act itself. The Digital Omnibus moved the high-risk obligations to December 2, 2027 (Annex III) and August 2, 2028 (AI embedded in regulated products), fixed dates this time. Parliament adopted it on June 16, the Council signed off on June 29. I covered the full reshuffled timeline in May. What stayed on schedule is more important than what moved: the prohibitions have applied since February 2025, transparency obligations arrive on August 2, 2026 — with one carve-out: systems already on the market get until December 2, 2026 for the Article 50(2) watermarking duty — and the Commission's enforcement powers over general-purpose AI switch on the same day. Weeks away, not next year.

One more date, because the timing is almost too neat. The following week after the omnibus deal was struck in May, the EU ratified the Council of Europe Framework Convention on AI, the first binding international treaty on AI and human rights. Delaying its own rules at home, signing commitments abroad, in the same week.

Both are the EU’s real position. Act two, in a single image.

Act III: Build (2025–2026)

While the rules were being trimmed, the money arrived.

February 2025, AI Action Summit in Paris: the Commission announced InvestAI, a plan to mobilize €200 billion for AI, including €20 billion for “gigafactories” to train frontier-scale models.

April 2025: the AI Continent Action Plan, built on five pillars. Compute, data, skills, adoption, and simplification. The thing act two was made of is now an official pillar of AI industrial policy.

Then June 3, 2026: the Tech Sovereignty Package, headlined by the Cloud and AI Development Act. CADA is a proposal, weeks old, and the negotiations will reshape it. But the design is telling. It creates a "cloud sovereignty framework" for providers serving the public sector, built on four "Union assurance levels." The baseline requires infrastructure, assets and customer data to stay in the EU. The strictest tier requires a provider free of any third-country control, no derogations, holding a high-assurance EU cybersecurity certificate, and able to demonstrate control over every software component in the stack, down to who maintains and evolves it.

The Commission's own numbers explain the urgency: European providers' share of their home cloud market fell from roughly 29% in 2017 to 15% by 2022 (from the proposal's explanatory memorandum), and the EU spends €264 billion a year on US proprietary IT products and services (from the Open Source Strategy published in the same package).

CADA gets filed under industrial policy, and that’s how it reads, until you look at the mechanics. Assurance levels. Certification schemes. Software bills of materials. Source code audits. Corporate separation requirements. That is a conformity assessment regime: compliance law in a hard hat. The EU didn’t stop regulating AI in act three. It changed what it regulates for. Acts one and two regulated to protect individuals. Act three regulates to secure the stack.

If you sell cloud or AI services to an EU public body, or your product runs on a hyperscaler that does, the sovereignty framework is now a question in your future procurement bids. Which parts of the proposal survive the negotiations is genuinely open. The direction is not.

The Rest of the Map

The three acts are the spine. The body of EU AI law is wider, and a map that pretends otherwise would be lying to you. The short version:

• GDPR — Article 22 on automated decisions is still arguably the most litigated AI provision in Europe. And the omnibus process is now reopening the GDPR itself, including a proposed legal basis for AI training. Contested, not adopted.

• Copyright — the 2019 CDSM Directive‘s text-and-data-mining exception (Articles 3 and 4) is the legal foundation of every AI training data fight in the EU. The AI Act cross-references its opt-out directly.

• DSA — recommender transparency and systemic risk duties for the largest platforms. AI rules that never mention the AI Act.

• Data Act — applies since September 2025. Who gets access to device data: the supply side of AI.

• Cyber Resilience Act — security requirements for connected products, AI-enabled ones included. Main obligations land December 2027.

• Platform Work Directive — the first EU law on algorithmic management. Transposition due December 2026. If you build or use HR tech, this one is aimed at you.

• European Health Data Space — health data for AI training and development, phasing in from 2027.

• Digital Fairness Act — expected as a proposal in late 2026: dark patterns, addictive design, unfair personalization. The next AI-adjacent law is coming from consumer protection, not tech policy.

• Harmonised standards — not law, but where “compliant” is currently being defined for high-risk AI. The omnibus delay was officially justified by these not being ready.

• Sector rules — DORA for financial entities, MDR for medical devices, vehicle type-approval. Your vertical has its own chapter.

Horizontal EU law only. National AI laws are a separate map, for a separate article.

Subscribe now

Where This Leaves You

The arc translates into priorities better than any single law does.

Enforcement energy is real for what’s already live: prohibitions, GPAI obligations, transparency from August 2. It’s reduced for high-risk conformity, where you gained time until December 2027. And it’s rising in two new places: liability and procurement.

The liability point deserves numbers.

December 9, 2026: the new product liability regime starts applying to AI products, with disclosure duties and presumptions that make claims easier to bring.

December 2, 2027: the high-risk safety rules those products would naturally be judged against. The exposure arrives 358 days before the rulebook.

For roughly a year, a court assessing whether your AI product is “defective” has no applicable harmonised standard to measure it against, and you have no AI Act compliance to point to, because there is nothing yet to comply with. Contracts, indemnities, documentation and insurance carry that year. If your liability planning is waiting for 2027 because the AI Act is, it’s waiting too long.

Act three is still being written. The gigafactories are funded, CADA is heading into negotiations, and the next obligations are arriving through procurement criteria and consumer law rather than another grand AI statute.

Which leaves the question from 2017. The Parliament asked who pays when the machine gets it wrong, back when the machines could barely do anything worth suing over. Nine years later, the EU has some 150 pages on how to build AI responsibly, a product liability law that covers half the problem, and 27 national courts assembling the rest.

When the machine gets it wrong, who pays?

Three acts later, it’s the one question the EU formally withdrew.

Like this article? The AI Governance Roadmap is something you can use in practice. It’s a company’s roadmap with steps and working documents: the classification, inventory spreadsheet, role assignment, vendor questions and AI policy template. Everything a company needs to govern AI, in one place.

The register is finished.

Three weeks after the workshop with the blocked calendars and the mandatory attendance, the spreadsheet is complete. Fourteen AI systems, each with a role in column D, each with documented reasoning, each with a reassessment trigger. You presented it to the general counsel. She nodded. In your world, that’s a standing ovation.

Then comes the quarterly all-hands. The product team is doing a demo. They’ve built something called Atlas: an internal assistant that answers customer-history questions for the support staff. It runs on a vendor’s model, fine-tuned on two years of support tickets. It has an internal brand name. It has a logo. Someone made a logo.

Atlas is not in the register.

That afternoon, you do something you should have done earlier. You search the expense system for AI subscriptions. Seventeen results. Team cards, individual expense claims, one recurring charge labeled only “productivity tool”. Four of them match the register. The other thirteen are new to you.

The register isn’t wrong. Everything on it is classified correctly. The problem is what’s missing from it. And what’s missing from it follows a pattern.

Subscribe now

The Assumption Underneath the Decision Tree

The EU AI Act never tells you to build an AI inventory. No article requires one. What the AI Act does instead is attach every obligation to a specific system and to your role with respect to it.

Provider and deployer are defined system by system in Article 3. The role-transformation triggers in Article 25 fire per system. Deployer obligations under Article 26 attach to each high-risk system you operate. The fundamental rights impact assessment in Article 27 is per system. Even the AI literacy obligation in Article 4 assumes you know which systems your staff are operating.

The regulation assumes enumeration without ever mandating it. Every obligation is conditional on knowing a system exists and knowing what you are in relation to it. The inventory is the unstated premise of the whole compliance architecture, which is why build the inventory is step one of the practical process of role assignment.

Step one is also the step that so often fails.

Some Systems Get In, and Some Don’t

A register is built from what can be seen. What can be seen is what passed through procurement: a contract exists, legal reviewed it, the vendor wrote an intended purpose into the documentation. These are also the systems most likely to sit in a clean deployer posture, because a contract and a documented intended purpose are what keep you a deployer. The vendor assessed the use case. You operate inside the lines the vendor drew. Column D says deployer, and column D is right.

The systems that escape are a different population. The subscription on a team card. The API key a developer set up in an afternoon. The tool a business unit reconfigured after go-live, without anyone from legal knowing. These systems have no documented intended purpose, no contractual guardrails, and no review scheduled for later. Which is the exact environment where the Article 25 triggers live:

• repurposing a system beyond what the vendor assessed (25(1)(c)),

• modifying it in ways no conformity assessment foresaw (25(1)(b)),

• putting your own name on it because it looked better that way (25(1)(a)).

The properties that keep a system out of your register are the properties that push it toward provider territory.

So the undercount isn’t even. The register misses the expensive category first. A procured chatbot used exactly as licensed can go missing too, but the tool that was fine-tuned on proprietary data, branded internally, and pointed at a use case its vendor never heard of? That one skipped procurement almost by definition.

Atlas was never getting into column D. Systems like Atlas never are.

Two Ways a Register Fails

The invisible system is the first failure mode. Shadow AI: the system isn’t in the register, you don’t know it exists, so you never classify it. A gap, at least, is honest about itself.

The second failure mode sits inside the register. The tool was procured properly. Legal reviewed the contract. The entry says deployed SaaS, vendor X, deployer. Then a business unit fine-tuned it on internal data, or pointed it at a use case the vendor never assessed, or put an internal brand on the interface. The entry was correct on the day it was written. It isn’t anymore.

A missing entry is a gap. A stale entry is false confidence, and false confidence costs more, because a signed-off register is the last place anyone looks for a problem. The classification happened. The box is ticked. The general counsel nodded.

Both modes map onto the decision tree on role-assignment. The first breaks step one: the classification never runs. The second breaks the “document and revisit” step: the classification ran once, and the system kept moving.

The regulation doesn’t distinguish between the two. Article 25 fires at the moment of the act. Rebranding is a marketing decision. Substantial modification can be a configuration choice. Repurposing is often plain usage drift. None of it requires a contract, a procurement event, or an approval. The legal event happens when the team does the thing, not when legal finds out.

Shadow AI Data Breach

Shadow AI became a security story before it became a compliance story, so the numbers come from the security world.

IBM’s 2025 Cost of a Data Breach report found that 20% of studied organizations experienced a breach linked to shadow AI: unsanctioned tools operating outside IT oversight. Those breaches cost an average of $670,000 more than the baseline. And 63% of the breached organizations had no governance policy for managing AI or detecting unauthorized use.

Reading it as a lawyer, the same numbers say something else. One in five organizations has already had unsanctioned AI surface in the most expensive way possible. The population of unregistered systems is large enough to show up in breach statistics. Every system in it has an AI Act role that has never been assigned.

The security industry measures shadow AI in exposed records and incident costs. The measurement still missing: how many of those invisible systems have crossed an Article 25 threshold. I haven’t found a published figure, and I doubt one exists yet.

I guess that the share is disproportionate.

The Questionnaire Coming Back Clean

My next question is how can an organization solve such situation. The instinctive fix is a survey. Email the business units, ask them to list their AI tools, compile the answers.

But what if the survey comes back clean, and it’s wrong anyway?

Self-reporting requires the respondent to know that what they did was legally significant. The team that fine-tuned a vendor model on support tickets did not experience that as a substantial modification within the meaning of Article 25(1)(b). They experienced it as making the tool better. The marketing team that put the company’s name on the interface wasn’t rebranding an AI system. They were fixing an ugly login page.

Article 25 triggers don’t feel like legal events to the people performing them. Ask people to self-report legal events, and you get a list of everything except the things you need.

The detection has to run on activity, not on memory:

Expense data. Recurring charges to AI vendors, individual subscription claims, the “productivity tool” line items. Finance has this already. Legal has never asked for it.

SSO and network logs. Which AI services people actually authenticate into. IT can pull the list in a day. It will be longer than your register.

API traffic. A live API key to a model provider is the tell for build activity, and build activity is where provider status gets created. If a team holds an OpenAI or Anthropic key, that team is at layer two of the GPAI stack, whether it knows it or not.

Procurement follow-up, not procurement records. The register captured what was bought. It didn’t capture what happened after. For every entry marked deployer, the question is not “did we license this” but “what has been done to it since”. Fine-tuning, configuration beyond vendor parameters, internal branding, new use cases. Each one is a potential Article 25 event that happened after the paperwork closed.

Then treat the register as a living document with named reassessment triggers: every modification, every retraining, every new use case, every contract renewal. I have already said this. What I didn’t say: the trigger list only works for systems already in the register. Everything else needs the detection layer, running continuously, because a system that skipped procurement will skip your triggers too.

One timing note. The Digital Omnibus pushed high-risk obligations for standalone Annex III systems to 2 December 2027. That reads like breathing room. For the visible register, it is. An Article 25 trigger doesn’t wait for 2027. The role shift happens when the act happens. The obligations land later.

The classification error exists now, sitting in systems you haven’t found yet.

Subscribe now

The All-Hands Applause

The product team finishes the Atlas demo to applause. It’s a good tool. That was never the question.

You’re running the decision tree in your head. Fine-tuned on proprietary data: possible substantial modification. Internal name and logo: possible 25(1)(a). A purpose the vendor never assessed: possible 25(1)(c). Three potential triggers, one system, zero entries in the register. And thirteen subscriptions in the expense report you haven’t looked at yet.

The register you presented was accurate. Every system on it, correctly classified. It just wasn’t an inventory of your company’s AI. It was an inventory of your company’s procured AI. Those are different documents, and what separates them is not a random slice of what’s out there.

It’s the systems that never crossed legal’s desk, put to uses their vendors never assessed, carrying obligations that have never been assigned.

The decision tree still works. It will classify anything you feed it.

Feeding it is the part that has to be solved.

Like this article? The AI Governance Roadmap is something you can use in practice. It’s a company’s roadmap with steps and working documents: the classification, inventory spreadsheet, role assignment, vendor questions and AI policy template. Everything a company needs to govern AI, in one place.

I was at a conference two weeks ago, listening to a presentation on the EU AI Act and its connection to GDPR, when the speaker put Article 111(2) on the screen.

I had read it before. If you’ve read the AI Act cover to cover (condolences), so have you. It lives in Chapter XIII Final Provisions, the part of a regulation where the highlighter runs dry. Entry into force. Amendments to other regulations. Transitional arrangements. Article 111(2) reads like exactly what it appears to be: a transition rule for AI systems that were already on the market before the new obligations apply.

Then he walked the room through what it does.

I sat there realizing I had filed one of the most consequential provisions in the EU AI Act under administrative. Judging by the quality of the silence around me, I wasn’t the only one.

Article 111(2) doesn’t give older AI systems more time to comply.

It decides which AI systems never have to.

Subscribe now

What the Provision Says

The text, from the Official Journal version:

“...this Regulation shall apply to operators of high-risk AI systems... that have been placed on the market or put into service before 2 August 2026, only if, as from that date, those systems are subject to significant changes in their designs. In any case, the providers and deployers of high-risk AI systems intended to be used by public authorities shall take the necessary steps to comply with the requirements and obligations of this Regulation by 2 August 2030.”

Transitional provisions normally come in two parts. Old systems get relief, and then a date arrives when the relief ends. Article 111(2) has the first part. For private-sector systems, the second part doesn’t exist.

A high-risk AI system placed on the EU market before the deadline, and never significantly redesigned afterwards, is exempt. There is no date at which that changes. The risk management system, the data governance requirements, the technical documentation, the human oversight design, the accuracy and robustness standards: none of it applies. Not late. Never.

Though, I must mention two exceptions. The Article 5 prohibitions apply to everything, old or new (a pre-deadline social scoring system is still illegal). And systems intended for use by public authorities must comply by August 2, 2030, modified or not.

The Dates Just Moved and the Difference Grew

The original cut-off was August 2, 2026. The Digital Omnibus on AI, provisionally agreed on May 7, 2026, moves the high-risk AI obligations to December 2, 2027 for stand-alone Annex III systems (hiring tools, credit scoring, education, life and health insurance pricing), and to August 2, 2028 for AI embedded in regulated products. The Article 111(2) cut-off moves with them.

Laura Caroli, who led the Parliament’s technical negotiations on the AI Act, put it plainly: a high-risk hiring system placed on the market before December 2, 2027 “may remain outside the AI Act indefinitely, unless it is substantially altered after that date”.

At the time of writing this article, the Digital Omnibus on AI isn't in the Official Journal yet. The European Parliament approved the final text on June 16, 2026; the Council's formal adoption and publication follow, before August 2. Everything here reflects the text Parliament approved in June. I'll flag anything that changes in the official version once it's published.

The Digital Omnibus on AI does one more thing to this provision, and it got a fraction of the attention the delay got. The Commission’s proposal clarifies that the exemption attaches to the type of system, not to each individual unit. If at least one unit of a high-risk AI system was lawfully placed on the EU market before the deadline, identical units can continue to be placed on the market afterwards, with no conformity assessment, as long as the design stays unchanged. (This clarification originated in the November 2025 proposal, and it survived: the adopted text keeps the grace period attached to the type of system, not each individual unit.)

The pool of exempt AI systems doesn’t just persist after December 2027.

It keeps growing.

What This Means if You’re the One Buying

If your company is procuring AI systems in the next 18 months, the system you sign for may never be subject to the AI Act’s requirements. Not because of a loophole your vendor found. Because of the EU AI Act’s own architecture.

Which changes what the compliance conversation in procurement is even about. “We’ll be AI Act ready” on the sales slide is not a compliance status. The question is no longer whether the vendor is compliant. The question is whether their system will ever be legally required to be.

And you cannot check the answer yourself. There is no public registry of when an AI system was “placed on the market”. The EU database for high-risk systems covers systems that register and comply, which exempt legacy systems, by definition, don’t. A vendor’s claim about their system’s legacy status is unverifiable from the outside. That moves it from due-diligence question to contractual warranty (more on that below).

What Your Vendor Is Thinking

Every month between now and December 2027 is a strategic shipping window. Place a high-risk AI system on the EU market before the deadline and you’ve acquired an indefinite exemption. Keep the design frozen and you keep it. Under the type-based clarification, you can keep selling new copies of it too.

This is not a fringe reading. MEP Sergey Lagodinsky calls the provision “a loophole” and “a weak spot” in the law. Bram Vranken of Corporate Europe Observatory warns that companies “might abuse this timeline and quickly push risky AI systems onto the market” before the deadline, saving the compliance costs entirely. The people who built and watched over this regulation are saying, on the record, that the rational vendor strategy is to race to market and then stand very still.

None of this requires bad faith. It requires a vendor who reads the regulation and responds to incentives.

On “Significant Change”

The exemption holds only while the system avoids “significant changes in its design”. So the entire question of whether a legacy system ever enters the EU AI Act collapses into one undefined phrase.

What we know: Recital 177 says significant change should be understood as equivalent to “substantial modification” under Article 3(23). That definition covers a change not foreseen or planned in the provider’s initial conformity assessment which either affects compliance with the high-risk requirements or changes the system’s intended purpose.

Notice the problem. The test’s reference point is the initial conformity assessment. Legacy systems never had one. That’s what makes them legacy systems. The yardstick the regulation points to doesn’t exist for exactly the systems this provision governs. I think that in practice the reference point will have to be the provider’s own design documentation, which the provider writes, controls, and can draft as broadly as their lawyers dare.

The open questions are the ones your vendor will answer in their own favor. Is retraining on new data a design change? A new model version behind the same interface? Swapping the underlying foundation model while the product name stays the same? No guidance exists yet. Until it does, expect every vendor changelog to be written by someone who has read Article 111(2) very carefully.

The Trap on Your Side of the Contract

The exemption protects the system as the vendor shipped it. It does not protect what you do to it afterwards.

If you substantially modify a high-risk AI system yourself, or change its intended purpose, Article 25(1) can make you the provider. Not provider-ish. The provider: conformity assessment, technical documentation, CE marking, registration, all of it, for an AI system you didn’t build, possibly without the documentation you’d need to do any of it.

Buying an exempt legacy system and customizing it heavily is how a company wakes up one morning as an AI provider.

Six Questions Before You Sign

The practical part. These belong in your procurement process for any AI system that is or could be high-risk, starting now.

1. “When was this system first placed on the EU market?”

The single most consequential question in the deal, and the sales team likely won’t know why you’re asking. Don’t accept the answer on a call. Make it a contractual warranty, with the date stated. If the vendor won’t warrant the date, that tells you something too.

2. “Which types of updates do you classify as design changes?”

Their update policy decides whether the exemption survives contact with their own roadmap. Get their classification approach in writing, with an obligation to notify you before any update they consider significant, and before any update you might.

3. “If an update brings the system into scope, who carries the compliance?”

Allocate it in the contract: who performs the conformity assessment, who pays, what happens to the system in production while that takes months. Contract silence defaults to a dispute, and the dispute happens while you’re running an uncertified high-risk system live.

4. “Will you hand over the technical documentation if the roles shift?”

If you ever become the provider under Article 25, you need the technical file to have any chance of complying. The EU AI Act foresees cooperation from the original provider, but you don’t want to be litigating the AI Act when you could be enforcing a clause. Documentation escrow or a hard contractual handover duty.

5. Does your AI inventory record legacy status?

Internal question. Every high-risk system in your inventory should carry three fields: its placing-on-market date, its Article 111(2) status, and a modification log. If your inventory doesn’t have those columns, this article is your reason to add them.

6. Are you, or do you sell to, a public authority?

Then the indefinite exemption isn’t yours. August 2, 2030 applies regardless of modifications. Different planning, different timeline, same provision.

Subscribe now

The EU AI Act was written to make high-risk AI systems demonstrably safe: documented, overseen, accountable. For systems shipped before December 2027, it will do something else entirely. It will make them permanent.

From that date, the EU market carries two kinds of high-risk AI, identical on the demo call, separated only by a date. One is governed. One never will be but it will keep selling.

The date won’t be on the box. It will be in your contract, if you ask.

Like this article? The AI Governance Roadmap is something you can use in practice. It’s a company’s roadmap with steps and working documents: the classification, inventory spreadsheet, role assignment, vendor questions and AI policy template. Everything a company needs to govern AI, in one place.

RAG and fine-tuning look like two ways to build the same tool. Under the EU AI Act, one of them hands you a second regulatory role the other never would.

And the choice almost always gets made before anyone decides to consult Legal.

You usually find it three weeks after the tool ships, scrolling back through the project board for something else entirely.

It’s a card from the planning sprint. The title is some internal codename people outside the team would not recognize. The description is one line, written by an engineer who has long since moved on to the next thing:

Approach: fine-tune the base model on our contract corpus.

You read it once and it means nothing. A technical note about how the contract-review tool got built, the kind of sentence you’ve trained yourself to skim, because ninety percent of what crosses the engineering channel isn’t yours to worry about.

You read it a second time and you stop, because you’ve spent the last month building the company’s EU AI Act position for this exact tool. You decided it was a deployer situation, then talked yourself into provider, then wrote three pages explaining why. And you did all of that without knowing this one line existed.

The word is fine-tune. Not the word you’d been assuming, which was something closer to plugged the model in.

And it occurs to you, sitting there with a cold coffee and a project board you opened for an unrelated reason, that you may have been answering the wrong question for a month.

Subscribe now

The Question You Were Being Asked

The instinct, when someone hands you a tool built on a model like GPT or Claude, is to ask what kind of system it is. Is it high-risk? Is it a chatbot under Article 50? Where does it sit in Annex III? Reasonable questions, all of them. And there’s time for all of them later.

There’s a prior question, and it’s the one the engineer’s card answered for you without asking. Not what is this tool, but how was it built on the model underneath it. Because under the EU AI Act, that single design choice decides whether your company holds one regulatory role or two.

The framing usually goes wrong from the start. People ask whether a “RAG system” is something different from “an AI system,” as though those were two products you could choose between. They aren’t the same kind of thing.

“AI system for contract review” describes what the tool does.

“RAG system” (retrieval-augmented generation) describes how it’s wired together.

Your contract tool is almost certainly a RAG system underneath. One word is about function. The other is about plumbing.

And the plumbing words barely appear in the regulation.

“RAG” is nowhere in the AI Act.

Neither is “prompting” or “tool use”.

“Fine-tuning” surfaces once, in a recital, but never as a defined operative term with obligations hung on it.

These are engineering terms, and the EU AI Act doesn’t regulate engineering patterns. It regulates two things, and names them precisely: the AI system (Article 3(1)) and the general-purpose AI model (Article 3(63)). The line that decides your obligations runs between those two definitions. It does not run between RAG and not-RAG, which is the comparison that feels natural and leads nowhere.

Start with the Model, Continue with the System

Start with the model, because that’s the foundational part.

A general-purpose AI model is the engine. GPT, Claude, Llama, Gemini. It displays, in the regulation’s words, “significant generality” and can “competently perform a wide range of distinct tasks” (Article 3(63)). On its own, it is not an AI system, and on its own it puts no AI-system obligations on you at all.

Recital 97 says this in a sentence worth keeping somewhere you can find it:

AI models “do not constitute AI systems on their own”, and they “require the addition of further components, such as for example a user interface, to become AI systems”.

The model is the engine. It is not the car. You cannot drive it until someone builds the rest of the vehicle around it.

So the moment your team builds the contract tool, the interface, the inputs, the defined purpose of reading agreements and flagging clauses, they have built an AI system. And your company is its provider under Article 3(3): you developed it, or had it developed, and put it into service under your own name. That last part catches people, so it’s worth saying plainly.

“Putting into service” includes building something purely for your own use, inside your own walls, never sold to anyone. Provider does not mean seller. If your firm built this tool to run over its own contracts and never licenses it to a soul, your firm is still the provider.

Hold onto that, because it is the part the engineer’s card did not change. Whether the team wrapped the model or fine-tuned it, your company is the provider of the AI system. That was true before you found the card and it’s true after.

The card changed something else.

The Real Deal: Did Anyone Touch the Weights?

What the card changed is whether your company also reached into the model and altered it.

This is the fork, and it’s cleaner than almost any other line the AI Act draws.

On one side, you wrap the model. On the other, you modify it.

Wrapping leaves the model exactly as the provider shipped it. RAG is the clearest example: you connect the model to your clause library and a decade of your old contracts, and at the moment someone asks a question, the system retrieves the relevant material and hands it to the model as context. The model answers from your documents instead of from its training data. But its weights, the actual numbers that make the model what it is, never change. The same is true of prompting, of giving the model tools it can call, of wrapping it in guardrails that check its output. All of that sits around the model. None of it gets inside.

Fine-tuning gets inside. You take the model and keep training it, on your own data, until the weights shift and it starts reasoning in your patterns. That is a different act in kind, not in degree. And past a certain point, the regulation stops treating the result as “the provider’s model, configured by you” and starts treating it as a new model, with your company as its provider.

The dividing question, the one to carry into every build conversation, is not “are we doing RAG”.

It’s whether anyone is touching the model’s weights.

The Number That Decides It Isn’t in the EU AI Act

The threshold that separates “you modified the provider’s model” from “you built a new model” does not appear in the AI Act. It lives in the European Commission’s Guidelines for providers of general-purpose AI models, published 18 July 2025. Guidelines, not regulation. Non-binding guidance interpreting the text. A lawyer who reads the whole EU AI Act cover to cover and stops there will never find this number, which is a strange thing to be able to say about the single line that decides whether you’ve taken on an entire chapter of obligations.

The legal trigger is a significant change in the model’s generality, capabilities, or systemic risk. That phrase is hard to measure, so the guidance offers a number you can actually work with:

if the compute used to fine-tune the model exceeds one-third of the compute used to train the original, treat the result as a significant change, the modified version as a new model, and the entity that fine-tuned it as a provider that may become responsible for it.

An indicative proxy, not a bright line in the text. Where you don’t know the original training compute, which is most of the time, the guidance gives a fallback:

one-third of 10²³ floating-point operations, the same threshold that brings a model into scope as a general-purpose model in the first place.

Now the reassuring part, before anyone panics. Almost no downstream fine-tuning comes anywhere near one-third of the compute that trained a frontier model. Training GPT-class models costs sums the majority of companies will never spend on anything, let alone on adjusting one. So the realistic outcome for the vast majority of teams fine-tuning a commercial or open model is that they do not become model providers. The threshold matters less as a trap people are constantly springing, and more as proof of where the real boundary sits: at the model, not at the technique. Fine-tuning is simply the most common way to walk up to that boundary.

And if you do cross it, Recital 109 softens the landing in a way that rarely survives into the law-firm summaries. Your obligations as the modifier are limited to the modification. You complement the existing technical documentation with information about what you changed. Your training-data summary and your copyright policy cover only the data and compute you added. You do not inherit the documentation burden for the entire original model, which you couldn’t produce anyway, because you didn’t train it.

That’s my reading of how 109 operates, and it’s the reading the guidance supports, though I’d want to see how the AI Office applies it before treating it as settled.

Roles Stack. They Don’t Swap.

One thing I’d want a product team to understand even if they understood nothing else.

The fine-tune decision did not move your company out of one box and into another. It added a box.

Wrap the model, and you hold one role: provider of an AI system. Fine-tune past the threshold, and you hold two: provider of that same AI system, and, on top of it, provider of a general-purpose AI model. Not instead of. As well as. You were always the system provider the moment you built the tool, and nothing about modifying the model relieves you of that. It just stacks a second regulatory identity on top of the first.

And the second identity is its own job, with its own chapter. Chapter V brings obligations that have nothing to do with the contract tool sitting on top and everything to do with the model itself: technical documentation drawn up to the standard of Annex XI, a duty to give downstream builders the information they need to comply with their own obligations (Article 53(1)(b)), a policy for complying with EU copyright law including the text-and-data-mining opt-out, and a publicly available summary of what the model was trained on, using the template the AI Office provides.

Push the modified model past 10²⁵ floating-point operations, into systemic-risk territory under Article 51, and the Article 55 obligations follow: model evaluations, adversarial testing, serious-incident reporting, cybersecurity measures. Downstream fine-tuners will essentially never hit that ceiling. But the first set of obligations lands the day you become a model provider, and it lands in addition to everything you already carried as the provider of the system.

One regulatory role, or two. Decided by a line on a sprint card, by people who were choosing, as far as they knew, between two equally good ways to make the tool work better.

Where This Gets Murky

The wrap-versus-modify line is clean.

The threshold sitting on it is not, and honesty about that is the difference between guidance you can trust and guidance that gets you in trouble.

The one-third figure is indicative. It’s a compute ratio offered in non-binding guidance, and the fallback (one-third of 10²³ FLOP, when you don’t know the base model’s training compute) was never meant to be a precise instrument.

A team fine-tuning close to the line, or building on a model whose training compute the provider has never disclosed, is working with an approximation. The direction is reliable: wrapping is safe, heavy modification is not. The exact boundary is soft, and the guidance may be revised. If you’re near it, that’s a “document your reasoning and watch for updates” situation, not a “we did the math, we’re fine” situation.

Two more things that get conflated and shouldn’t.

RAG keeps you out of model-provider territory, but it does not keep you out of trouble generally. Point a retrieval system at personal data, privileged material, or confidential client contracts, and you’ve created a GDPR and confidentiality problem that has nothing to do with the EU AI Act and everything to do with whether you should be shipping the thing at all.

“We only did RAG, not fine-tuning” answers the question about your role under the EU AI Act. It does not answer the question about data protection, and the second question is often the one that bites first.

And fine-tuning below the threshold, while it doesn’t make you a model provider, still changes the system you provide. If that behavioral shift affects accuracy or bias in a deployment that is high-risk, it’s squarely relevant to your obligations as the system provider, under the data-governance and accuracy requirements in Articles 10 and 15.

The threshold answers one question. It doesn’t answer all of them.

One Caveat About the Contract Tool Itself

So the example doesn’t mislead anyone: plain commercial contract review, a tool a company runs over its own agreements, is not high-risk under the EU AI Act. It isn’t listed in Annex III. The provider obligations that attach to it are light: transparency where Article 50 applies, AI literacy under Article 4, not a great deal beyond that.

That picture changes the moment the tool starts feeding decisions the AI Act cares about. Use it to screen job candidates and it falls into employment. Use it on behalf of a court to interpret and apply the law and it falls into the administration of justice (The trigger there is use by or for a judicial authority. The same tool run purely inside your own business isn’t caught). Use it to inform creditworthiness or insurance pricing and it falls into access to essential services.

All three are Annex III, all three are high-risk, and all three pull the full Chapter III provider regime down on top of everything else. And if the tool profiles individuals, the off-ramp in Article 6(3), the one that lets you argue an Annex III system isn’t really high-risk, closes on you.

The risk question and the role question are separate, and both worth running. But the build point holds at every risk level: wrapping keeps you a system provider, and fine-tuning past the line makes you a model provider too.

High-risk or not, that’s still true.

Subscribe now

The Question to Ask Before Anyone Writes Code

It isn’t “is this high-risk”.

That one comes later, and someone will eventually ask it, probably loudly, probably close to a deadline.

The question that gets skipped is the one the sprint card answered while you weren’t looking:

Are we touching the model, or wrapping it?

That single answer routes everything downstream of it. Wrap, and your compliance work tracks the system you built, and only that. Modify past the threshold, and you’ve acquired a second regulatory identity that needs its own documentation, on a clock that starts the day you ship, not the day you notice.

The question costs nothing to ask in a design review. It costs a great deal to answer in an audit, when the honest answer turns out to be “we touched it”, and the follow-up is “and who wrote that down”.

Put it in the AI inventory you should already be keeping. For every system built on someone else’s model, record one more field next to the role and the risk level: wrapped, or modified. Then set the trigger that matters, because this is the field most likely to change without anyone telling you.

The day someone decides to retrain, you reassess. Not the day you find the card. The card is still there, one line, an engineer’s shorthand for a decision that felt purely technical to everyone who touched it.

Approach: fine-tune the base model on our contract corpus.

You’d written three pages on what your company was under the EU AI Act. You’re now fairly sure it was a different number of pages than the company actually needed. And the thing that decided that wasn’t a lawyer, or a regulator, or a clause buried on page four hundred of the AI Act.

It was a sprint card. And no one thought of sending it to you.

Like this article? The AI Governance Roadmap is something you can use in practice. It’s a company’s roadmap with steps and working documents: the classification, inventory spreadsheet, role assignment, vendor questions and AI policy template. Everything a company needs to govern AI, in one place.