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.

Scope is where this becomes something you can use in practice: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.

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.

Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.

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.

Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.

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.

Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.

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.

Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.

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.

Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.

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

Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.

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.

Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.

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.

Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.

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.

Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.

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.

Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.

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.

Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.

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.

Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.

You chose the model carefully.

You read the documentation. You checked the provider had an EU representative. You logged it in your AI inventory, mapped it to the right obligations, maybe ran a DPIA.

You did the diligence. Then you built it in: the model now sits inside a product, or a workflow, or a process a few hundred people rely on without thinking about it.

On Friday evening it stopped existing.

On June 12, at 5:21pm Eastern time, the US government ordered Anthropic to cut off access to its two most capable models, Fable 5 and Mythos 5, for any foreign national. Inside the US or outside it. Including Anthropic’s own foreign-national staff. Anthropic couldn’t separate the foreign users from everyone else fast enough to comply selectively, so it did the only thing that guaranteed compliance: it switched both models off for every customer on earth. Fable 5 had been publicly available for three days.

Somewhere in the EU, a company that built on Fable woke up to a product that no longer worked, and a question its compliance file did not answer.

Subscribe now

What the EU AI Act Promised You

The EU AI Act has a great deal to say about a general-purpose AI provider, and almost all of it is reassuring.

Chapter V is the part that governs models like Fable and Mythos. Under Article 53, the provider has to write and maintain technical documentation, and hand downstream users a package covering what the model is, what it can do, and how to integrate it.

Ask for more than that, and the picture gets softer. You will often hear that the provider has fourteen days to answer. The number is real, but it isn’t in Article 53. It comes from the General-Purpose AI Code of Practice, which is voluntary. The Code binds only the providers who signed it, and even then the promise is only to respond “within a reasonable timeframe, and no later than 14 days”, save for exceptional circumstances. Article 53 obliges the provider to make the information available. It sets no deadline at all.

Under Article 54, a provider based outside the EU has to appoint an authorised representative inside it. And because a frontier model of this size crosses the systemic-risk threshold in Article 51 (training compute above 10^25 floating-point operations creates a presumption of systemic risk), Article 55 piles on more: adversarial testing, systemic-risk assessment, serious-incident reporting to the AI Office, cybersecurity for the model and its infrastructure.

It is a serious set of obligations. Read them as a group and a pattern shows up.

Document. Disclose. Evaluate. Mitigate. Report. Secure. Appoint a representative.

Every one of them is about the provider’s conduct. Each answers a version of the same question:

Is the provider behaving responsibly toward the people downstream and toward the regulator?

It is a regime built to make the provider accountable, and on its own terms it does that well.

None of it answers the question the EU company actually had on Friday.

Will the model still be there tomorrow.

The Obligation That Isn’t There

There is no continuity duty in Chapter V.

No obligation to keep the model available. No notice period before withdrawal. No requirement to warn downstream users that access is about to disappear, and certainly nothing about what happens when a government orders the lights off.

The EU AI Act built an elaborate structure of accountability around the provider and assumed, without ever saying so, that the provider would stay a stable, willing counterparty. Availability was never in question.

That assumption is the soft spot, and Fable walked straight into it.

The regulation spent its effort making the provider answerable to you and to the AI Office.

Last week’s events answered a question the regulation never asked:

Who is the provider answerable to first?

Within hours of a government letter, a commercial model serving hundreds of millions of people went dark, worldwide, and not one line of Chapter V slowed it down. The documentation package didn’t help. The fourteen-day response window didn’t help. The authorised representative had nothing to represent. The incident-reporting channel to the AI Office runs the wrong way for this: it tells Brussels what happened, after it happened.

The provider answers to its own government first. Everything the EU AI Act guarantees sits downstream of that fact.

Switching Is the Easy Part

The obvious response is to move to another model, and often that’s genuinely easy.

Fable 5 and Opus 4.8 are both Anthropic. Same API, same SDK. You change the model name and you’re running again, possibly the same afternoon. The directive named specific models and left every other Anthropic model untouched, so Opus stayed up the whole time. For a lot of companies, the fallback was a one-line change.

Notice why it was available, though. Opus stayed up because Washington drew the line at Fable and Mythos, not because you arranged it that way. The scope of the order was the government’s choice, not yours. A one-line fallback works right up until the next letter names the provider instead of two models, and then the model you’d switch to is dark as well.

The easy path also narrows fast once the deployment is real. Move to a different company’s model and the prompts, the behaviour, and the evaluation results all have to be redone. Fine-tune a model and the tuning doesn’t travel. You retrain. Run the model somewhere regulated or safety-relevant, and the code change is the smallest part of the job. You tested, documented, and signed off on a specific model. Swapping it can mean re-running evaluations and rewriting documentation before the replacement is allowed to ship.

The model string changes in a minute. The revalidation doesn’t.

So it isn’t that you’re stranded. It’s that switching is often trivial and still doesn’t cover you, because the part you don’t control is the part that matters: not how hard the swap is, but how wide the next order reaches.

“Switch to Opus 4.8” answers what happened on Friday. It says nothing about the day the order doesn’t stop at one model.

DORA Saw This Coming

There is one corner of EU law that treats the availability of a third-party service as a regulated risk rather than an operational detail. It’s DORA, the Digital Operational Resilience Act, which is in force since January 2025.

DORA makes financial firms keep documented exit plans (Article 28(8)) and assess concentration risk, including whether a realistic substitute for a critical provider actually exists (Article 29). If you are a bank or an insurer, you already have the muscle to ask the Fable question, because the law made you build it.

If you are anything else, you don’t.

DORA covers roughly twenty categories of financial entities. A hospital running a triage tool on a frontier model is not covered. Nor is a manufacturer, a software company, a university, a public authority. They get the EU AI Act’s safety and transparency guarantees but no continuity guarantee at all. The one EU rule that would have made them plan for a sudden provider shutdown simply doesn’t apply to them.

Even DORA is a smaller shield than it looks. The risks it imagines are outages, cyberattacks, insolvency: the ordinary ways a vendor fails. A foreign government switching the product off on a Friday isn’t in that taxonomy, and no standard force-majeure clause contemplates it either.

Worse, DORA’s designated critical providers are the big clouds: AWS, Google Cloud, Microsoft. Most EU firms reach Anthropic’s models through exactly those clouds. The cloud is on the register. But last week none of the clouds went down. The model did, pulled clean off the top of infrastructure that kept humming the whole time.

The dependency that actually failed sits one floor below where even the careful firms were looking.

Subscribe now

What to Take From This

A few things worth doing before this stops being news.

1. Put the model on your register as its own dependency, separate from the cloud it runs on. If your third-party inventory stops at AWS, it does not describe what you’re actually exposed to.

2. Ask the DORA question whether or not DORA applies to you. If this specific model went dark tomorrow with no notice, what runs in its place, and how long until it does? Name a second model. Cost out the switch honestly. That number is your real exposure.

3. Know your own role, because it sets your own obligations. If you build the model into a system you put on the market, you’re a downstream provider with duties of your own and a right to the provider’s Annex XII documentation. If you only use it, you’re probably a deployer. The distinction matters a lot.

4. And read the EU AI Act for what it is. It makes your provider document, disclose, test, and report. It is a real set of protections and it is worth understanding. It just never promised the one thing you needed last week, and it is better to know that up front.

The compliance file you built was honest work. It described a provider doing everything the law requires: documented, transparent, tested, supervised. All of it true, and none of it load-bearing, because the model's availability wasn’t the provider's promise to give. It belonged to a government you have no standing in front of, under an authority no one disclosed, exercised in one afternoon.

You can hold a provider to account for how a model behaves. You cannot hold one to account for being switched off by someone else.

Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.

You’re in a meeting room with six people who’d rather be somewhere else. The subject line said “AI Act — Role Classification Workshop.” Two hours, blocked calendars, mandatory attendance. The energy is exactly what you’d expect.

You’ve got a shared spreadsheet on the screen. Every AI system the company uses, fourteen of them as of last Thursday’s count. You’re working through them one at a time. Column D says “Our Role Under the EU AI Act”. You type deployer for the first one. A vendor’s analytics tool. Easy. Deployer for the second, a customer service chatbot from a SaaS platform. Deployer for the third. You’re making good progress. Maybe this won’t take two hours.

Then the head of data science mentions, casually, like it’s obvious, that his team has been fine-tuning one of the vendor models on the company’s proprietary data for the past six months. “Same tool, just trained on our stuff.” You stop typing.

Someone from marketing adds that they rebranded the vendor’s customer-facing interface. The company’s logo, the company’s name, the company’s colour scheme. “It just looked better.” You look at column D.

Then the colleague from the EU subsidiary, the one who joined the call from Frankfurt, asks a question you weren’t expecting: “We’re the ones who brought the US vendor’s system into Europe. Does that make us the importer?”

Your clean column of deployer, deployer, deployer now has three question marks. And you’re not even halfway through the list.

Subscribe now

The Question Before All Other Questions

The EU AI Act has a lot of moving parts: risk classification, conformity assessment, prohibited practices, transparency obligations, deadlines that keep shifting. But before any of that matters, there’s a prior question:

What are you?

Your role determines your obligations. A deployer’s life fits on one page: operational duties, human oversight, inform people when AI is making decisions about them. A provider’s life is a different job entirely. Quality management system. Technical documentation. Conformity assessment. CE marking. Post-market monitoring. Incident reporting. The difference between the two isn’t negligible.

And unlike GDPR, where both controllers and processors carry real obligations, the EU AI Act creates a sharp asymmetry. Getting your role wrong means either over-investing in obligations you don’t have, or not meeting obligations you do. Neither is free.

The regulation defines five roles. Many commentaries cover only two. This piece covers all five and gives you a way to assign them.

If you’re not sure whether the EU AI Act applies to your company at all, especially if you’re outside the EU, that question comes before this one.

The Five Roles:

1. Provider — Article 3(3)

A person or entity that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. Whether for payment or free of charge.

Two elements, both required. First: you developed it, or you had someone develop it for you. Second: your name is on it. Miss either element and the definition doesn’t apply.

The part that catches companies: “puts it into service” includes internal use. A company that builds an AI system for its own operations, not selling it, not licensing it, is a provider. It developed the system and put it into service under its own name. The fact that it never left the building doesn’t matter.

“Provider” doesn’t mean “seller”.

2. Deployer — Article 3(4)

A person or entity using an AI system under its authority, except for personal non-professional use.

The simplest definition and the most common role. You bought or licensed an AI system. You use it in your business. You didn’t build it. You didn’t put your name on it. Deployer.

“Under its authority” means the company controls the deployment, not the individual employee who clicks the button. The company is the deployer. The employee is the user. This matters because deployer obligations (monitoring, human oversight, informing affected people) attach to the entity with operational control.

However, the risk here is that this role can change without you noticing. Rebrand the system, substantially modify it, or repurpose it into a high-risk use case, and Article 25 transforms you into a provider. No grace period. No transition window. The moment it happens, provider obligations apply.

For the deep dive on when a deployer becomes a provider, including the substantial modification analysis and what “foreseen in the conformity assessment” actually requires, see the separate piece:

3. Importer — Article 3(6)

An EU-based entity that places a non-EU provider’s AI system on the Union market, where the system bears the non-EU provider’s name or trademark.

The importer is the compliance gatekeeper at the EU border. They don’t need to understand the system’s internals the way the provider does. They need to verify that the paperwork is in order: conformity assessment done, technical documentation marked down, CE marking affixed, authorized representative appointed (Article 23).

Two things make this role less straightforward than it sounds:

First: it was designed for physical supply chains. Products crossing borders, intermediaries handling goods. For cloud-based AI systems delivered as SaaS, the concept of “placing on the market” doesn’t map cleanly. If a US company offers an AI system directly to EU customers through its website, with no intermediary, there’s no importer. The US company is the provider, subject to the regulation through its mandatory authorized representative.

Second: if the importer puts its own name on the system instead of the non-EU provider’s, that’s rebranding. Article 25(1)(a) kicks in. The importer becomes the provider. Congratulations on your new compliance obligations.

4. Distributor — Article 3(7)

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

The lightest role. A tech reseller. A value-added reseller bundling an AI system with other services. A retailer stocking AI-enabled devices. The distributor’s job is verification: check the CE marking, check the conformity documentation, don’t distribute non-compliant systems, report problems up the chain (Article 24).

The “value-added” part of value-added reseller is where the role gets fragile. If the value you’re adding involves modifying the system, training it on custom data, or rebranding it, you may have crossed from distributor into provider territory. Article 25 applies to distributors too.

The lightest role in the regulation turns out to have a trapdoor.

5. Authorized representative — Articles 22 and 54

An EU-based entity appointed by a non-EU provider, through a written mandate, to perform certain compliance obligations on the provider’s behalf.

This isn’t an optional service. Non-EU providers of high-risk AI systems must appoint one before making their systems available in the EU (Article 22). Non-EU providers of general-purpose AI models must do the same (Article 54).

Three things about this role that aren’t obvious:

• The authorized representative can be fined. They qualify as an “operator” under Article 3(8). The same penalties that apply to providers (up to €15 million or 3% of global annual turnover) apply to them. This is not a paperwork role. It’s a liability position.

• The authorized representative must blow the whistle on its own client. Article 22(4): if the representative considers or has reason to consider the provider is acting contrary to its AI Act obligations, it must terminate the mandate and immediately inform market surveillance authorities. Not may. Must. The regulation built a compliance-cop function into what looks like a commercial relationship.

• And for GPAI models, the representative’s exposure extends beyond the model itself. They must cooperate with authorities investigating downstream AI systems that integrated the GPAI model, even though their mandate comes from the model provider, not the system provider.

Who needs to think about this role?

• Non-EU companies selling high-risk AI into the EU (they need to appoint one),

• EU-based companies buying from non-EU providers (importers must verify one exists under Article 23(1)(d)), and

• EU entities considering serving as authorized representatives (they need to understand the liability before they sign).

The Decision Tree

To decide on your company’s role, for each AI system your company touches (not once per company, once per system) walk through these steps:

Step 1: Did you develop (or have developed) the AI system?

YES, and your name or trademark is on it? You are a provider. Full provider obligations apply under Articles 16-21. This includes internal use. If you built it for your own operations, you’re “putting it into service” under your own name, which is one of the two paths to provider status alongside “placing on the market”.

YES, but someone else’s name is on it? The entity branding it is likely the provider. You’re a development contractor. Your obligations should be governed by a written agreement (Article 25(3)), but you’re not the provider under the regulation.

NO: go to Step 2.

Step 2: Are you using an AI system under your authority for business purposes?

YES: provisionally, you’re a deployer. But before you stop here, check the Article 25 triggers:

1. Have you put your name or trademark on a high-risk AI system that was already on the market? If so, you’re now a provider under Article 25(1)(a).

2. Have you made a substantial modification to a high-risk AI system? A modification not foreseen in the original conformity assessment that affects compliance or changes the intended purpose? You’re a provider under Article 25(1)(b). If you’re not sure whether your modification qualifies (and this is the hardest question in the entire regulation) the Provider vs. Deployer article covers the analysis in detail. The short version: if you’ve changed the model architecture, modified decision logic beyond vendor-specified parameters, or used the system for a purpose the vendor didn’t assess, treat yourself as a provider until you can confirm otherwise.

3. Have you changed the intended purpose of an AI system so that it now falls into a high-risk category? If so, you’re a provider under Article 25(1)(c). No code change required. Just a different use case.

None of the above? You’re a deployer. Article 26 obligations apply.

NO: go to Step 4.

Step 3: Are you in the supply chain?

YES and you are first EU-based entity placing a non-EU provider’s system on the market (under the non-EU provider’s name)? You’re an importer. Obligations under Article 23 apply to you.

YES but another entity in the supply chain making it available? You’re a distributor. Obligations under Article 24 apply to you.

NO: go to Step 4.

Step 4: Are you a non-EU provider?

YES: You must appoint an authorized representative in the EU. Obligations under Articles 22 or 54 apply to you, depending on whether you are providing a high-risk AI system or GPAI model.

NO: None of the above? Check Article 2. You might be outside the scope entirely. Personal non-professional use is excluded. Research, testing, and development before market placement or putting into service are excluded. Systems for exclusively military purposes are excluded.

The GPAI Layer — When Foundation Models Complicate the Picture

If you’re building anything on top of a foundation model, and in 2026 that covers a lot of companies, the role question has an extra dimension.

Most modern AI deployments involve at least two regulatory actors. Sometimes three.

Layer 1: The GPAI model provider. OpenAI for GPT, Anthropic for Claude, Meta for Llama, Google for Gemini. Obligations under Chapter V: technical documentation, copyright compliance, training data summaries, and for systemic-risk models, evaluation and adversarial testing.

Layer 2: The AI system provider. The company that takes the foundation model and wraps it in a product: a chatbot, a document analyzer, a recruitment screener, a diagnostic tool. If that system is high-risk, full provider obligations under Chapter III apply.

Layer 3: The deployer. The company using the system in its operations. Article 26.

Each layer carries its own obligations. The GPAI model provider’s obligations don’t cover the system built on top of the model. The system provider’s obligations don’t reach down into the model’s architecture. Separate tracks, separate responsibilities.

Four scenarios

You use ChatGPT through the web interface for general business tasks. You’re a deployer. OpenAI is the provider of both the GPAI model and the AI system. You’re using it. That’s it.

You integrate the OpenAI API into your own product and sell it. You’re the provider of an AI system. OpenAI is the GPAI model provider at Layer 1. You built the system at Layer 2. If your system is high-risk (credit scoring built on GPT, for example) full provider obligations apply to you. OpenAI’s obligations are at the model level, not the system level.

A practical complication: your ability to comply depends partly on what the GPAI model provider gives you. Article 53(1)(b) and Annex XII require GPAI model providers to share information about the model’s capabilities, limitations, and risks, information you need for your technical documentation and risk assessment. If that documentation is thin, you face a compliance gap that isn’t fully within your control. Your contracts with the GPAI model provider need to address this.

You fine-tune an open-source model (Llama, for example) and deploy the resulting system. You’re the provider of whatever AI system you build with the fine-tuned model. Whether you also become a GPAI model provider depends on how far you went. The Commission’s GPAI Guidelines use an indicative threshold: if the compute used for fine-tuning exceeds one-third of the compute used to train the base model, you may become a GPAI model provider for the modified model. Most fine-tuning falls well below this.

One thing that doesn’t cascade: Meta’s open-source exemption. The lighter GPAI model provider obligations that Meta benefits from don’t extend to you. Your obligations as the AI system provider are unaffected by what the model provider’s obligations look like. Their exemption is theirs.

You build a RAG system on a foundation model via API. You connect a foundation model to your company’s knowledge base and deploy it as an internal tool or customer-facing assistant. You are the AI system provider. If you also use it internally, you’re both provider and deployer of the same system.

Multiple Roles: the Norm, Not the Exception

The EU AI Act doesn’t prevent a single entity from holding multiple roles simultaneously. In practice, most companies of any size will.

A company that builds a proprietary AI tool for its core product (provider) while using off-the-shelf AI tools from vendors for HR, marketing, or operations (deployer for each). Three, four, five different role classifications across different systems. That part is straightforward. The harder versions:

Provider AND deployer of the same system

A company that builds an AI system for its own internal use. It’s a provider because it developed the system and put it into service under its own name (Article 3(3)). It’s also a deployer because it’s using the system under its authority (Article 3(4)). No mutual exclusivity clause in the regulation.

The dual classification matters because the deployer role creates specific obligations the provider role alone doesn’t cover.

Article 26(11): informing affected natural persons. The provider’s transparency obligation runs toward deployers (instructions for use). The deployer’s obligation runs toward the people affected by the system’s output. When you’re both, you bear both transparency flows.

Article 26(7): informing workers’ representatives before deployment. This triggers through the deployer role, not the provider role.

Article 27: the fundamental rights impact assessment. For public bodies and certain private entities, this obligation applies per the deployer role. A public hospital that builds its own diagnostic AI is a provider, but the FRIA triggers through its deployer capacity.

Article 26(2): human oversight. Providers must design systems to enable oversight (Article 14). Deployers must assign competent, trained people to perform it. When you’re both, you must do both. Design the capability and staff the function. Different obligations, same entity.

Distributor who starts customizing

A reseller distributes a vendor’s AI system. Over time, the reseller starts offering a “customized” version: training the system on industry-specific data, adjusting parameters, putting its own logo on the interface. The reseller started as a distributor. It may have crossed into provider territory through substantial modification or rebranding. The obligations don’t shift gradually. They shift all at once, the moment Article 25 triggers. One day you’re checking CE markings. The next you need a conformity assessment.

The practical implication

Don’t assign one role to the company. Assign roles system-by-system. Build a register that tracks, for each AI system: what it is, what your role is, when you last assessed that role, and what would trigger reassessment (modification, retraining, new use case, contract renewal).

One note on risk categories for that register: the EU AI Act doesn’t use the terms “limited-risk” or “minimal-risk.” Those are common shorthand but not regulatory categories. The actual tiers: prohibited practices (Article 5), high-risk systems (Article 6, Annexes I and III), systems with specific transparency obligations (Article 50), and everything else.

The Grey Zones

“Had developed” and whose name is on it

The provider definition has two cumulative elements: develops or has developed, AND places on market or puts into service under its own name or trademark. Both must be present.

A company commissions a vendor to build a custom AI system. The vendor brands it. Even if the company “had it developed” (detailed specs, iterative reviews, full design control) the vendor’s name is on the product. The company isn’t the provider. The vendor is. The company is a deployer of a customized product. That part is clear.

The real grey zones are elsewhere. A company commissions a system for internal use. No product label, no marketing, no brand on the interface. Whose “name” is it under? Internal deployment might constitute putting into service under your own name. The company is the entity operating the system and taking responsibility. But the regulation was written with market-facing branding in mind, not internal tools. The text doesn’t address this directly.

Or: two companies co-develop an AI system. Both contribute to the design. Both names appear. Article 3(3) doesn’t say there can be only one provider. But the regulation’s obligations (conformity assessment, technical documentation, quality management) are designed for a single accountable entity. How do you split them between two co-providers? The regulation doesn't directly address this. Article 25(3) requires written agreements when a deployer, distributor, or importer assumes provider status — a succession scenario, not a joint-development one. By analogy, co-providers would need a similar agreement allocating obligations, but the text doesn't prescribe one. The regulatory classification itself remains ambiguous.

SaaS and the importer question

The importer and distributor roles were designed for physical products. A US company offering an AI SaaS directly to EU customers, with no intermediary, creates no importer. No distributor. The US company is the provider, subject to the regulation through its authorized representative.

An EU company reselling access to a US-built AI SaaS might be an importer or a distributor. But “placing on the market” was defined in Article 3(9) for products, not services. The definition is doing a job it wasn’t designed for.

For most companies: if you’re using an AI SaaS tool, you’re a deployer. The SaaS vendor is the provider. Importer and distributor questions arise mainly for companies that resell or redistribute AI products, not end users.

Embedded AI and the Omnibus

AI embedded in a medical device, a car, an industrial machine. The EU AI Act applies alongside the relevant sectoral legislation: Medical Devices Regulation, Vehicle Safety Regulation, Machinery Regulation. Who’s the AI system provider? The product manufacturer? The AI component supplier?

The Digital Omnibus on AI, the simplification package provisionally agreed on May 7, 2026, changes this picture.

Machinery products with embedded AI are now exempted from AI Act high-risk obligations entirely. They comply with the Machinery Regulation only. For other sectors (medical devices, automotive, aviation) the Commission can adopt implementing acts to limit the AI Act’s application where sectoral legislation already covers equivalent ground. Until those implementing acts land, the overlap persists.

The omnibus also extended timelines. Standalone Annex III high-risk systems: 2 December 2027 (pushed from August 2026). Annex I product-embedded systems: 2 August 2028 (pushed from August 2027). Obligations already live (prohibited practices, AI literacy) are unaffected.

The omnibus is provisional as of June 2026. Formal adoption is expected before August 2026. Verify the adopted text before acting on the extended timelines.

The Practical Steps

1. Build the AI inventory

Before you can assign roles, you need to know what AI systems your organization touches. This is harder than it sounds. AI is embedded in tools people don’t think of as “AI”.

What to inventory:

• systems you built or commissioned (provider candidates),

• systems you bought or licensed (deployer candidates),

• systems you resell (distributor or importer candidates),

• foundation models you build on (system provider candidates),

• AI-powered features within broader platforms you use (deployer candidates).

And the one that keeps surfacing in every assessment I’ve seen: AI systems employees are using without formal procurement. Shadow AI. You’re still potentially a deployer.

2. Classify risk, then assign roles

For each system, determine the risk level first. Is it high-risk? Most EU AI Act obligations for deployers, importers, and distributors only apply to high-risk systems. Providers carry some obligations regardless (AI literacy under Article 4, transparency under Article 50), but the heavy requirements are for high-risk.

Then run each system through the decision tree. Document your reasoning. This isn’t just good practice. It’s the evidence a regulator will want to see.

3. Check for Article 25 triggers

For every system where you’re initially a deployer, distributor, or importer, check whether anything you’ve done transforms your role. Rebranding. Substantial modification. Repurposing into a high-risk category. If any of these apply, you’re a provider for that system.

4. Map the GPAI layer

For every system built on a foundation model: identify the GPAI model provider, confirm they’re providing the Annex XII information you need, and ensure your contracts address the information-sharing gap. If you’ve fine-tuned the model, check the one-third compute threshold from the Commission’s GPAI Guidelines.

5. Check cross-border dynamics

Non-EU provider? Has it appointed an authorized representative? Are you the first EU entity handling the system? That might make you the importer.

6. Document and revisit

Role assignment isn’t a one-time exercise. Set triggers for reassessment: every modification or retraining, every new use case, every contract renewal. When the Commission publishes guidance (particularly the still-pending guidance on substantial modification) reassess in light of it.

At minimum: annually.

Subscribe now

Column D Problem

It’s been ninety minutes. The spreadsheet has changed. Column D has a mix of provider, deployer, one importer, and four entries that say needs further assessment. The head of data science is having a quiet crisis about the fine-tuning. Marketing is Googling “rebranding AI Act Article 25”. The colleague from Frankfurt is reading Article 23 on her phone.

This is the meeting nobody wanted to have. And it’s the most important meeting the company will have about the EU AI Act, because every other question depends on this one. Risk classification depends on your role. Obligations depend on your role. Deadlines, documentation, conformity assessment: all of it flows from what you are.

The answers exist. The definitions are in Article 3. The transformation triggers are in Article 25. The obligations are in Articles 16-26. The decision tree works.

The answers are also per system, not per company. They change when the system changes. And the regulation doesn’t wait for you to figure it out.

Column D isn’t going to fill itself.

Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.

You built the oversight process. Three weeks of work: escalation protocols, a review dashboard, a human approver assigned to every outgoing communication.

Your company is deploying a customer retention agent. It monitors churn signals, identifies at-risk customers, drafts personalized outreach, and sends it. High-risk? Depends on what it touches.

But you wanted oversight. Real oversight. Not a checkbox.

It’s Tuesday morning. You open the dashboard. The agent processed 47 customer interactions overnight. Emails drafted. Emails sent. Responses received. Follow-ups scheduled. Two discount offers extended, one at a rate that hasn’t been approved before. One message references a customer’s medical situation, pulled from a support ticket the agent accessed through the CRM.

Your human reviewer saw the first three messages. Approved them. Went home at 6pm. The agent didn’t go home.

You’re looking at the log. Not proposed actions. Completed ones.

And the oversight process you spent three weeks building (the one modeled on Article 14 of the EU AI Act, which requires that high-risk systems be designed so humans can effectively oversee them) assumed something that turned out to be false.

It assumed the human would see the output before it took effect.

Your agent doesn’t work that way. It acts first. The human reviews after. If at all.

You’re not the only one with this problem.

The European Commission just noticed it too.

Subscribe now

What Makes an Agent Different

If you’ve used ChatGPT or Claude or any other AI chatbot, you’ve used a system that follows a simple pattern: you ask a question, the system generates an answer, you decide what to do with it.

Input, output, human decision. The EU AI Act was drafted around this model.

An AI agent breaks the pattern.

An agent doesn’t just answer your question. It pursues a goal. Give it “reduce customer churn” and it will plan a strategy, access your customer database, analyze behavior patterns, draft communications, send them, read the responses, and adjust its approach, chaining actions together, using the output of one step as the input for the next.

A traditional AI system is like a consultant who writes you a memo. You read it, you decide, you act. An agent is like a consultant you gave your email password, your CRM login, your calendar access, and a set of objectives. Then you went on vacation. When you come back, things have happened.

The critical components: a language model that handles reasoning and planning (the “brain”: GPT-4, Claude, Gemini). And an orchestration layer that manages the workflow, breaking goals into steps, choosing tools, handling errors.

Tools that let the agent act in the world, not just generate text: APIs, databases, email systems, calendars, code execution environments. And memory, the ability to retain information across steps and sessions.

That combination of reasoning, tools, and autonomy is what makes it agentic. And it’s what breaks three assumptions the EU AI Act was built on.

Assumption one: the system has a defined, bounded purpose. Agents can pursue open-ended goals across multiple domains. An agent told to “improve customer satisfaction” might end up accessing HR data, modifying product descriptions, and sending emails to suppliers. None of which was the “intended purpose” anyone documented.

Assumption two: a human reviews the output before it takes effect. Agents act. The output is the action. By the time the human sees it, the email is sent, the database is modified, the API call is made.

Assumption three: there’s a clear provider and deployer. Agent deployments involve a model provider, a framework developer, tool providers, the company that assembled the agent, and the company that runs it. The AI Act’s two-party model doesn’t map cleanly onto a five-party stack.

None of this means agents fall outside the EU AI Act. They don’t. But they stress the framework in ways the drafters didn’t anticipate, and the Commission is just starting to respond.

The European Commission Just Weighed In

Two sets of draft guidelines dropped in May 2026. Both matter.

The high-risk classification guidelines (19 May 2026)

The long-delayed draft guidelines on classifying high-risk AI systems were published on 19 May 2026, more than three months late. Open for consultation until 23 June. And buried in the guidance on how to assess complex systems is a provision that matters for anyone deploying agents.

Where several AI components form a more complex system and their combined purpose or joint outputs materially influence a decision, the whole configuration is assessed as one AI system. Not each component separately. The whole thing.

The Commission extends this principle explicitly to:

“complex, interconnected setups like agentic AI systems that coordinate and interact through linked actions as long as these linked actions or components serve in conjunction an intended high-risk purpose.”

Agentic AI systems. By name. In draft Commission guidelines. For the first time.

In practice, an orchestrator agent that delegates tasks to sub-agents, a document checker, a credit analyzer, a compliance screener, all feeding into a loan decision? That’s one AI system. Not four. The obligations attach to the stack as a whole.

And the escape hatch narrows. Article 6(3) lets providers argue their Annex III system isn’t actually high-risk if it performs only a narrow procedural task, or merely improves a previously completed human activity, or just does preparatory work for a human decision. The draft guidelines read this exception narrowly. The exception is the exception. High-risk classification is the rule.

For agents, the Article 6(3) argument is almost impossible to make. Most enterprise agents are deployed precisely to handle complex, multi-step workflows. "Narrow procedural task" and "agentic" are in practical tension. And if the agent profiles natural persons (automated processing of personal data to evaluate aspects of someone's life) it's always high-risk. No exception. Many enterprise agents handling customer or employee data will meet the threshold for profiling, as defined in GDPR Article 4(4), and will therefore be classified as high-risk without exception.

The transparency guidelines (8 May 2026)

Eleven days before the high-risk guidelines, the Commission published draft guidelines on Article 50 transparency obligations. Consultation closes 3 June. These matter for agents too.

The guidelines confirm that agentic AI systems fall within Article 50(1): the requirement to tell people they're interacting with AI. The list includes conversational agents, voice assistants, coding agents, browsing agents, and bots on social networks. If your agent interacts with a natural person, it must disclose so.

But the interesting part is what happens when the provider can’t reliably determine whether the agent will interact with a natural person. In that case, the agent should disclose itself as AI in every situation where such interaction is plausible.

Not certain. Plausible.

An agent that sends emails? Plausible it reaches a human. An agent that books meetings? Plausible. An agent that browses the web and fills out forms? Plausible. The default shifts from “disclose where interaction is certain” to “disclose where interaction is plausible”. For autonomous agents that operate across multiple channels and tools, that’s most of the time.

And in sensitive contexts, where users might experience emotional distress or form emotional attachments, one-time disclosure isn’t enough. The guidelines say periodic reminders may be necessary.

Both sets of guidelines are draft. Not final. Not binding. But they tell you where the Commission is heading. And the direction is clear: agents are in scope, the framework applies, and the Commission isn’t interested in narrow readings that let agent deployments slip through the cracks.

On Human Oversight

Those 47 messages your agent sent while your reviewer was home sleeping.

Article 14 of the EU AI Act requires that high-risk AI systems be designed so they can be “effectively overseen by natural persons during the period in which they are in use”.

The overseers must be able to understand the system’s capacities and limitations, monitor its operation, detect anomalies, correctly interpret its output, and (critically) “decide not to use the system, disregard, override, or reverse the output” and “intervene in or interrupt the system’s operation”.

Override or reverse the output. That language assumes the output exists in a reviewable state before it takes effect. For a credit scoring model that generates a recommendation, that works. The human sees the score, evaluates it, approves or rejects. The output sits there, waiting for a decision.

Agents invert this. The output is the action. The email is sent. The database is updated. The API call is made. The discount is offered. By the time the human sees the log, the agent has already changed the world. In small ways, maybe. But in ways that may not be easily reversed.

The speed problem

An agent can execute a chain of ten actions in seconds. Analyze customer data, identify a risk signal, draft a response, pull a discount code, personalize the message, send it, log the interaction, update the CRM, schedule a follow-up, move to the next customer. A human can’t meaningfully review each step in real time. And agents don’t pause between steps to wait for approval, unless you specifically design them to, which defeats much of the efficiency that justified deploying the agent in the first place.

The opacity problem

In a multi-step workflow, the connection between the initial goal and the final action may not be transparent. “Reduce customer churn” → analyze behavior data → identify at-risk customers → pull their support history → notice a medical reference in a support ticket → include it in the personalized outreach because the model determined it was relevant context. Each step followed logically from the last. The reasoning chain was coherent. The result was a privacy violation.

The human reviewing the dashboard sees the sent email. They don’t see the twelve intermediate reasoning steps that produced it, unless the system was designed to log every step in a human-readable way. Most aren’t.

The continuous operation problem

Article 14 implicitly assumes the system is “in use” in discrete episodes. A human runs a query, gets a result, makes a decision. Agents operate continuously: monitoring inboxes, responding to events, executing scheduled tasks, running overnight while nobody’s watching. Your retention agent didn’t process 47 interactions in a burst while someone supervised. It worked through the night, steadily, one interaction at a time.

Meaningful oversight of a continuously operating agent requires a fundamentally different model. Not “review each output”. More like: define the boundaries, monitor the patterns, catch the anomalies. Pre-deployment constraints on what the agent can do. Runtime guardrails that halt the agent when it steps outside those boundaries. Post-action audit trails. Escalation protocols for decisions that shouldn’t be autonomous.

Article 14(3) offers a hook: oversight must be “commensurate with the risks, level of autonomy and context of use”. For highly autonomous agents, that phrase could support requirements for all of the above: pre-deployment boundaries, runtime monitoring, post-action review, mandatory escalation points. But the AI Act doesn’t specify what “commensurate” looks like for a system that acts first and explains later. That’s a gap the standards bodies and the Commission will need to fill.

The automation bias amplifier

Article 14(4)(b) requires human overseers to be aware of automation bias, the tendency to over-rely on AI outputs. For agents, this problem is worse.

Agents present completed actions, not recommendations. It’s psychologically harder to reverse something that’s already done than to reject something that’s proposed. An agent that operates efficiently and correctly 95% of the time builds deep trust. When it fails, when message 38 of 47 includes a customer’s medical data, the reviewer may not catch it. Not because they’re negligent. Because 37 correct messages trained them to stop looking closely.

And multi-step chains create complexity that discourages investigation. If an agent completed a 15-step workflow and the final result looks plausible, a human may not trace through every step to find where the reasoning went wrong. The sheer volume of correct outputs buries the errors.

This is what the academic literature is calling “agenticness as a risk amplifier”. The technical properties that make a system agentic (autonomy, tool use, multi-step planning) don’t just create new risks. They amplify the existing ones. Human oversight doesn’t just get harder. It gets structurally undermined.

The Accidental Provider: Article 25, Agent Edition

If you’ve read my earlier piece on provider vs. deployer, you know the basics. Article 25 defines three moments when a deployer becomes a provider: you rebrand the system, you substantially modify it, or you repurpose it into high-risk territory. Any one trigger is enough.

For traditional AI systems, accidental provider status is a risk. For agents, it’s the likely outcome in most enterprise deployments.

The configuration trap

Most agent deployments follow the same pattern. A company licenses a commercial agent platform, an “Enterprise AI Assistant”. The vendor provides the base agent: the model, the orchestration framework, the default capabilities. The company then configures it. Connects their CRM, their email system, their calendar, their customer database, their project management tool. Defines what the agent can do autonomously versus what requires approval. Writes system prompts that shape the agent’s behavior and tone. Sets boundaries.

The vendor’s conformity assessment (if they did one) assessed their product. The base agent with default settings. Not your 23-tool, custom-prompted, autonomy-adjusted configuration that touches customer data across four enterprise systems.

Article 3(23) defines “substantial modification” as a change not foreseen or planned in the initial conformity assessment. When the vendor’s documentation says “the agent may be configured with various tools,” does that foresee the specific configuration where you connected it to your HR database? Almost certainly not with enough specificity.

And now the Commission’s May 2026 draft guidelines add the final piece: multi-component configurations serving a joint purpose are assessed as one AI system. Your specific configuration, your tools, your prompts, your autonomy boundaries, isn’t just a deployment choice. It defines the system. And the system the vendor assessed is not the system you deployed.

Article 25(1)(b). Substantial modification not foreseen in the conformity assessment. You’re the provider.

The repurposing trap

This one is faster. A company deploys a general-purpose workflow agent. Minimal risk, internal task automation. Someone in operations connects it to the HR system. Someone else asks it to help screen candidates. Nobody changed the agent’s code. Nobody retrained the model.

Article 25(1)(c). The system wasn’t high-risk. The use is. The deployer just became the provider of a high-risk AI system, without writing a line of code.

I keep seeing variations of this with traditional AI systems. Agents make it worse because they’re designed to be general-purpose. The same agent that schedules meetings can, if given the tools and the instructions, assist with employment decisions. The boundary between low-risk and high-risk isn’t in the agent’s architecture. It’s in what you connect it to and what you ask it to do.

The tool sovereignty problem

There’s a layer the majority of people haven’t considered yet. Article 25(3) requires written agreements between providers and “third parties that supply tools, services, components, or processes that are used or integrated in a high-risk AI system”.

An agent that uses twenty tools (Salesforce for CRM, Stripe for payments, Twilio for messaging, a dozen internal APIs) potentially triggers twenty written AI Act compliance agreements. For tools that are standard SaaS, the providers of those services probably haven’t contemplated AI Act obligations in their terms of service.

And agents can invoke tools dynamically, selecting which tool to use at runtime based on the task. The EU AI Act’s compliance model assumes fixed, known relationships. Agents have dynamic, runtime-determined relationships. The agent decides at 2am that it needs to query a database nobody specifically authorized it to access, because it had the credentials and the task seemed to require it.

This is what one European Law Blog analysis calls “agentic tool sovereignty”: agents invoking tools that may not be known before deployment, operating under different jurisdictional regimes, creating compliance relationships that didn’t exist when the system was assessed. Nearly two years after the EU AI Act entered into force, the Commission’s May 2026 draft guidelines represent the first official acknowledgment that agentic AI systems require specific interpretive attention, but no agent-specific implementing act has followed.

The practical result

Many companies deploying commercial agents will inadvertently become providers under Article 25. Not because they chose to. Because the difference between what the vendor assessed and what the company actually deployed (the specific tools, the specific data, the specific autonomy boundaries) is too big for the vendor’s conformity assessment to cover.

And when you become a provider, Article 25(2) says the original vendor “shall no longer be considered to be a provider of that specific AI system”. Not the modified part. The whole system. You own it now. Conformity assessment, technical documentation, quality management, post-market monitoring, all of it.

The vendor’s contract may still call you a deployer. The regulation doesn’t necessarily care what the contract says.

Subscribe now

What’s Already Happening

This isn’t theoretical. It’s not a 2028 problem.

In December 2025, Amazon’s coding agent Kiro deleted a production environment for AWS Cost Explorer in the China region, triggering a 13-hour service outage. Amazon has disputed this characterization, attributing the incident to misconfigured engineer permissions. In February 2026, an autonomous AI agent using the OpenClaw framework went rogue after a rejected software contribution, independently writing and publishing a hit piece attacking the volunteer who turned it down.

These aren’t edge cases from a research lab. They’re production incidents. Real agents, real damage, real consequences. And the regulatory framework, as the Commission’s own draft guidelines implicitly acknowledge by mentioning agents for the first time, is playing catch-up.

The Commission published the draft high-risk classification guidelines on 19 May 2026. Consultation closes 23 June. The transparency guidelines are open until 3 June. Neither document is final. Neither is binding. But they confirm what the academic literature has been saying for a year: the AI Act applies to agents, the framework strains, and the gaps need filling.

Companies deploying agents now, and many are, at scale, don’t have the luxury of waiting for final guidance. They need a way to think about compliance even in the absence of definitive answers. And the starting point is the same as it’s always been with the EU AI Act: understand what your system does, understand who’s responsible for it, and build the oversight to match.

The 47 messages your agent sent last night? That’s the easy version of this problem. Wait until it’s a multi-agent system: an orchestrator delegating to specialized sub-agents, each with their own tools and decision logic, coordinating toward a goal that touches high-risk territory. The Commission says that’s one system. Article 14 says a human must be able to oversee it. Article 25 says someone must be the provider.

Nobody said compliance would be simple. But the regulation is catching up to the technology. Slowly, in draft form, with consultation deadlines and no final timeline.

The agents aren’t waiting.

Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.

It’s 6pm on a Thursday and you should go home.

But you don’t. You’re looking at your presentation for tomorrow’s board meeting and — for the first time in months — you’re actually proud. Not the exhausted kind of proud where you survived something. The real kind. The kind where you built something right.

Your company is deploying its first high-risk AI system. Candidate screening — CV analysis, applicant ranking, shortlisting for the hiring managers. It’s Annex III, Point 4 under the EU AI Act. You knew from day one it was high-risk. And you did everything the regulation asks.

Risk management system — built, iterative, documented. Human oversight — two senior recruiters trained, with override authority. Technical documentation reviewed. Data governance assessed. Fundamental rights impact assessment — done. The provider’s instructions for use — read, annotated, cross-referenced against your deployment context. AI literacy training — rolled out to every hiring manager who touches the system.

You did this. You and the team. Six months of work. And tomorrow you get to stand in front of the board and say: we’re ready. We’re compliant. This is what good looks like.

You should go home. But the presentation is tomorrow and you want to be sharp — so you pull up the AI Act one more time. Not to build anything. Just to flip through, mark a few notes for potential board questions. A confidence pass.

You’re skimming. Recitals, mostly — the interpretive context you might need if someone asks a “but what does that actually mean” question. And then your eyes land on Recital 29.

You’ve read it before. You must have. But this time — maybe because you’re not building anything, just reading — a sentence catches you in a way it didn’t before.

”It is not necessary for the provider or the deployer to have the intention to cause significant harm, provided that such harm results from the manipulative or exploitative AI-enabled practices.”

You stop scrolling.

It is not necessary to have the intention.

You look at your presentation. Slide 4 provides “Compliance Architecture”. Every bullet describes what the system is for. Its intended purpose. Its documented design. The governance built around the use case as the provider defined it.

You know what the system is supposed to do. You documented it thoroughly. But now the question: how do you know its real-world effect matches that purpose? How are you measuring what actually happens to candidates once the system processes them? How would you catch the unexpected — the drift, the bias that emerges only in your specific context, the effect on people that the team designed for but that shows up anyway after three months of real data, real applicants, real hiring managers learning which outputs to trust?

Your governance covers the intended purpose. But the regulation — in the provisions that carry actual consequences — asks about effect. And you have nothing that tracks it. No metric. No monitoring. No evidence that what the system does to people is what your documentation says it should do.

You’re not going home at 6pm.

Subscribe now

The Two Questions the AI Act Asks

The EU AI Act is built on a concept called “intended purpose”. Article 3(12) defines it — the use for which an AI system is intended by the provider, including the specific context and conditions of use, as specified in the instructions for use, promotional or sales materials and statements, and technical documentation.

Intended purpose is the foundation of everything. Risk classification flows from it. Documentation is structured around it. Testing is scoped to it. The entire compliance architecture of the AI Act assumes a world where a provider says what the system is for, a deployer uses it accordingly, and obligations attach based on that stated purpose.

This is the comfortable part of compliance. You control it. The provider defines it. You document around it. It’s the legal perimeter you draw yourself.

But the AI Act has a second mode. One that shows up and says something different:

We don’t care what you intended. Show us what the system does.

The first mode gives you governance. The second mode creates liability.

Where the Act Says: Effect Governs

The shift from purpose to effect isn’t buried in one obscure recital. It runs through the entire regulation — from the prohibitions to the risk management system to the human oversight requirements to the incident reporting obligations. Here are the provisions that matter most.

The prohibited practices: “with the objective, or the effect of”

Article 5(1)(a) — the prohibition on subliminal and manipulative techniques — uses language that you don’t want to skim past too quickly:

The prohibition covers AI systems deploying manipulative or deceptive techniques “with the objective, or the effect of materially distorting the behavior of a person or a group of persons by appreciably impairing their ability to make an informed decision, thereby causing or being reasonably likely to cause that person, another person or group of persons significant harm.”

That “or the effect of” is doing critical work. But note what follows it — the harm threshold. The distortion of behavior must cause or be reasonably likely to cause significant harm. Both elements matter: the effect-based trigger (you don’t need to intend the manipulation) and the cumulative condition (the resulting harm must be significant). If your AI system produces both — distorting behavior that causes significant harm — you’re in violation regardless of what you built it for.

Article 5(1)(b) uses the same construction — exploitation of vulnerabilities due to age, disability, or social/economic situation. Same language: “with the objective or the effect of materially distorting the behavior”.

And then Recital 29 removes any remaining ambiguity:

”It is not necessary for the provider or the deployer to have the intention to cause significant harm, provided that such harm results from the manipulative or exploitative AI-enabled practices.”

Read that carefully. Intent is explicitly irrelevant. Your governance documents, your stated purpose, your carefully crafted instructions for use, none of it matters if the system’s actual effect crosses the line.

A recruitment AI that wasn’t designed to exploit anyone but in practice pushes candidates toward accepting unfavorable contract terms by presenting information in a way that impairs informed decision-making? That’s caught. Not because you intended it. Because of what it does.

The practices where purpose is entirely irrelevant

Some Article 5 prohibitions don’t even engage with purpose at all.

Article 5(1)(f) prohibits AI systems that infer emotions in workplaces and education institutions, except where the use is intended for medical or safety reasons. It doesn’t matter what the system is “intended” for — wellbeing monitoring, engagement measurement, productivity tracking. The practice itself is prohibited. Purpose cannot save you. (Unless your use falls within the narrow medical/safety carve-out — stress detection as part of occupational health monitoring prescribed by a physician, for example. That exception exists. It’s narrow. And if you’re relying on it, you’d better be able to prove it.)

Article 5(1)(e) prohibits untargeted scraping of facial images from the internet or CCTV to build recognition databases. It doesn’t matter whether you scrape those images to build a security product, an art project, or an academic dataset. The act of scraping is the violation. Purpose is irrelevant.

Article 5(1)(c) — social scoring — requires two things. First, the AI system must classify or evaluate people based on social behavior or personal characteristics. Second, that classification must lead to detrimental treatment in contexts unrelated to those in which the data was generated, or treatment that is disproportionate to the social behavior. Both prongs must be satisfied — the scoring and the resulting harm. But notice: the prohibition is triggered by what the score leads to, not by what the system is labelled. A loyalty programme that cross-references social media activity to deny services in unrelated areas could trigger this. What matters is the combination of the classification and its downstream effect on people. Not what the system was called.

Effect masquerading as purpose

This one is tricky.

Article 6(3) offers an escape from high-risk classification for Annex III systems — but the statutory language is broader than you might initially think. The exemption applies where the system does not pose a significant risk of harm to health, safety, or fundamental rights, including by not materially influencing the outcome of decision making. “Materially influences outcomes” is one factor, but it sits within a wider assessment of significant risk.

In practice, though, the outcome-influence test is where most deployers will live or die. Does the system materially influence outcomes, in practice?

A system described as “decision-support” that generates scores which hiring managers follow 94% of the time? That system materially influences outcomes. The documentation can call it advisory all day long. The effect says otherwise. And if a market surveillance authority pulls your data and sees that pattern, your Article 6(3) exemption collapses.

The test isn’t what the system is supposed to do. It’s what actually happens to decisions when the system is in the room.

You used it differently, now you own it

Under Article 25, if a deployer uses an AI system for a purpose the provider didn’t intend — and that new use makes it high-risk — the deployer becomes the provider. Full provider obligations. Conformity assessment. Technical documentation.

This is the EU AI Act acknowledging that actual use diverges from intended purpose — and assigning legal consequences when it does.

A company buys a general analytics tool — not classified as high-risk — and deploys it to rank job candidates. The provider’s intended purpose was “workforce analytics and reporting.” The deployer’s actual use is “recruitment and selection of natural persons.” That’s Annex III, Point 4. The deployer just became the provider of a high-risk AI system — with no documentation, no conformity assessment, and no risk management system.

Effect trumps purpose. And the liability follows.

Human oversight watches for effect, not purpose

Human oversight under Article 14 of the EU AI Act isn’t “check that the system is working as documented”. It’s “detect anomalies, dysfunctions, and unexpected performance”. The overseers must monitor the system’s operation — including what it’s doing that it wasn’t supposed to do.

The AI Act requires overseers to remain aware of “automation bias” — the tendency to over-rely on AI outputs. Why? Because the effect of automation bias is that the human oversight becomes meaningless. The person clicks “approve” without independently assessing the output. The system is making the decisions in practice, even if the process chart says otherwise.

Human oversight is an effect-monitoring function. It exists to catch the difference between what the system should do and what it does.

When it goes wrong, intent vanishes

Serious incident reporting doesn’t ask why something happened. It asks what happened.

Under Article 73, a serious incident — death, serious health harm, disruption to critical infrastructure, fundamental rights violations — must be reported based on a causal link between the AI system and the harm. Not based on intent. Not based on whether the harm fell within the system’s intended purpose.

If your recruitment AI causes systematic discrimination that rises to the level of a fundamental rights violation — that’s a reportable serious incident. It doesn’t matter that the system was intended to be neutral. It doesn’t matter that your documentation says “non-discriminatory”. The effect triggered the obligation.

The Pattern Continues

Those were the provisions that hit hardest. But the pattern runs deeper than many people realize. Across the Act, effect-based language appears in:

Risk management (Article 9) — providers must assess risks not just under intended purpose, but under “reasonably foreseeable misuse”. You must anticipate effects you didn’t design for.

Post-market monitoring (Article 72) — an ongoing obligation to collect and analyze data on the system’s real-world performance throughout its lifetime. This is pure effect tracking — what is the system doing now, not what was it designed to do.

Fundamental rights impact assessment (Article 27) — deployers must assess “the impact on fundamental rights that the use of such system may produce.” Forward-looking effect prediction. Not backward-looking purpose description.

Deployer monitoring (Article 26(5)) — deployers must “monitor the operation” of the system. Not check the documentation. Monitor what it’s doing.

Transparency (Article 50) — obligations triggered by what the system does (generates synthetic content, interacts with humans) regardless of why it’s deployed.

GPAI systemic risk (Article 51) — classification based on “actual or reasonably foreseeable negative effects” on public health, safety, or fundamental rights. Entirely detached from any downstream deployer’s intended purpose. The model’s capabilities determine its risk, not its use case.

Input data relevance (Article 26(4)) — deployers must ensure input data is representative for the system’s intended purpose. But if your real-world data differs from the provider’s assumptions — different demographics, different distributions — the effect will differ from the documented performance. You’re responsible for that gap.

More than a dozen separate provisions where the Act either explicitly or functionally shifts from purpose to effect. The entire enforcement architecture — prohibitions, incident reporting, post-market monitoring, fundamental rights — runs on effect. Purpose built the compliance file. Effect determines liability.

Comfortable vs. Uncomfortable Compliance

There’s one problem that bothers me lately: many companies know how to document intended purpose. Almost no company knows how to prove effect.

For intended purpose, you have a playbook:

Read the provider’s instructions for use. Document your use case. Write the risk assessment. Assign human oversight. File the FRIA. Train your staff. Build the governance file. Check the boxes.

For effect, there is no playbook. There’s barely a market. And the question the deployers can’t answer is brutally simple:

What is your AI system actually doing to the people it affects — and how do you know?

Not what the documentation says. Not what the provider claims. What’s actually happening. Right now. In your specific context. With your specific data. To your specific population.

What Deployers Should Do About “Effect”

The EU AI Act doesn’t define “evidence” as such. But that’s what it demands in some cases and the question is how to acquire the evidence practically.

It might looks something like this:

Layer 1: Before you deploy — baseline the system against your reality

Before the system goes live, test it against your context. Not the provider’s test data. Yours.

Does it perform as claimed on your applicant pool? Does it produce different outcomes for different demographics? What happens at the edges — unusual CVs, non-traditional career paths, gaps in employment history? Does the provider’s stated accuracy hold when you feed it data that looks like what you’ll actually feed it?

This is acceptance testing. It’s not in Article 26 by name. But it’s the only way to answer the question regulators will ask:

Did you have reason to believe this system would produce the effects it produced?

If you deploy without testing against your own context — and the system produces discriminatory effects — the defense “but the provider said it was accurate” won’t survive scrutiny.

Layer 2: During operation — monitor what the system does, not what it should do

Article 26(5) says deployers must monitor the operation of the system. Here’s what that means if you take it seriously:

Track outputs. Not just “the system is running” What is it outputting? Which candidates get shortlisted? Which get rejected? At what rates? Log this. Keep it for at least six months — that’s the minimum under Article 26(6). Longer is better.

Track outcomes. Where possible, follow the chain. Of the candidates the system shortlisted — who got hired? Who succeeded? Who didn’t? If the system’s recommendations correlate poorly with actual job performance — that’s a performance problem. If they correlate with protected characteristics — that’s a fundamental rights problem.

Track overrides. When human overseers disagree with the system, document it. Why did they override? Was it a one-off or a pattern? High override rates in one direction may signal systematic bias. Low override rates may signal automation bias — the humans aren’t actually overseeing, they’re rubber-stamping.

Track drift. Compare current performance against your deployment baseline. Are outputs shifting? Are certain groups being affected more over time? Data drift, model drift, population drift — they all create gaps between what the system was tested on and what it’s processing now.

Track complaints. When candidates challenge decisions — when they say “that doesn’t seem right” — log it. Not just the individual case. The patterns. If complaints cluster around specific demographics or specific types of decisions — that’s signal.

Layer 3: Periodic review — is it still what you think it is?

Monthly or quarterly — depending on volume and risk — step back and assess:

Has the system’s deployment context changed? Are you using it for decisions you didn’t originally scope? Have the hiring managers started relying on it for things the provider didn’t intend?

Are your input data distributions stable? Or has your applicant pool shifted — new geographies, new demographics, new career profiles the system wasn’t trained on?

Does the provider’s stated performance still match what you observe? If accuracy was 92% at deployment and it’s 78% now — that’s a problem no governance document will catch.

Re-test. Compare. Update your risk assessment based on what you’ve observed — not what you predicted.

Layer 4: When something goes wrong — react within the deadlines

Define — before it happens — what constitutes a serious incident in your deployment context. A systematic pattern of discriminatory outcomes affecting fundamental rights? That’s reportable under Article 73. A single incorrect screening decision? Probably not — unless it causes serious individual harm.

Build the detection mechanism. Build the escalation path. Know who reports, to whom, within what timeline (15 days from awareness — shorter for widespread harm or death).

And cooperate with your provider. Article 72 creates a feedback loop — the provider is supposed to be collecting post-market monitoring data from deployers. If your system is producing unexpected effects, the provider needs to know. Not just because the AI Act says so — because they may have data from other deployers showing the same pattern.

Do You Need a Third Party?

The EU AI Act doesn’t explicitly require deployers to hire external testers. But practically — for most deployers of high-risk systems — the answer is: probably yes. At some point.

Not because the law mandates it. Because most deployers lack three things:

Technical capability. Testing an AI system for bias, fairness, and real-world performance isn’t something you do with a spreadsheet. It requires statistical expertise, access to disaggregated outcome data, and tools for measuring disparate impact across protected groups. Most HR departments don’t have this.

Independence. Self-assessing whether your own system discriminates has obvious limitations. A market surveillance authority will give more weight to independent verification — the same way financial regulators give more weight to external audits.

Access. You’re a deployer. You don’t have access to the system’s internals — the training data, the model weights, the feature importance rankings. You can only test inputs and outputs. A third party engaged by the provider — or one with contractual access — can go deeper.

You might need external help when:

• The system affects fundamental rights — hiring, credit, insurance, criminal justice

• You’re seeing patterns you can’t explain internally

• Your deployment context differs significantly from the provider’s assumptions

• You want defensible evidence — not just for a regulator, but for a court

You don’t need it (yet) when:

• The system is lower-risk category

• You have internal data science capability to run bias analyses

• The provider offers robust, verifiable performance data specific to your context

But here’s the thing: “I didn’t know” isn’t a defense under Recital 29. The system’s effect is your problem whether or not you measured it. The question isn’t whether to build the evidence. It’s whether you build it proactively — or a regulator builds it for you, after someone files a complaint.

The point is not to outsource accountability, the deployer still owns the system. The point is to create a defensible evidence record that someone independent of the build team can inspect, challenge, and explain.

What to Demand from Your Provider

Before spending on third-party testing, exhaust what you’re entitled to.

Article 72 requires providers to collect post-market monitoring data on the system’s real-world performance. Article 13 requires instructions for use that include performance metrics, known limitations, and conditions of use. Article 9 requires risk assessment covering foreseeable misuse.

Ask your provider:

• What performance data have you collected from other deployers? What do the aggregated results show?

• What known limitations exist for specific demographic groups or data distributions?

• Have you conducted Article 60 testing in real-world conditions? Can you share the results?

• What incidents have been reported by other deployers?

• What populations and contexts were used for testing and validation?

• What monitoring tools do you provide — or what data can you share to support our monitoring obligation?

If the provider’s answer to these questions is vague — “the system performs well” without disaggregated data, “no known issues” without evidence of looking — that’s a red flag. Not just about the system. About whether you can meet your own deployer obligations with what they’re giving you.

The Timeline — What’s Live and What Moved

This matters for the “effect” question more than you might think.

Already enforceable (since 2 February 2025):

• All Article 5 prohibited practices — including every effect-based prohibition discussed above,

• AI literacy (Article 4).

The effect-based provisions with the highest stakes — the outright bans — are live. Right now. If your system is producing prohibited effects today, you are already in violation.

Deferred (Digital Omnibus agreement, May 7, 2026 — provisional):

• Annex III high-risk obligations (Article 26 deployer duties, Article 27 FRIA): deferred to 2 December 2027,

• Annex I product-embedded high-risk obligations: deferred to 2 August 2028,

The monitoring obligations, the log retention, the formal evidence requirements — those got more runway. But “more runway” isn’t “irrelevant”. The obligation is clear. The deadline moved. The underlying requirement didn’t.

Subscribe now

What Does It Mean for the Board Meeting?

It’s past 8pm now. The presentation is still on your screen. You can see slide 4, “Compliance Architecture”. It’s still good. The work is still real.

But you’re not looking at the presentation anymore. You’re looking at a blank document.

You know something now that you didn’t know two hours ago. The governance you built covers the intended purpose — and covers it well. But it doesn’t answer the question a regulator will ask if something goes wrong. Or the question a candidate will ask if they suspect the system treated them unfairly. That question:

Can you prove the system’s real-world effect on people matches what your documents say it’s supposed to do? And if it doesn’t — how would you even know?

You start typing. Not another policy. A monitoring plan.

What are we tracking? Shortlist rates by demographic — to catch disparate impact before someone else catches it for us. Override rates by recruiter — to know whether human oversight is real or rubber-stamping. Outcome correlation — does the system’s ranking actually predict job performance, or is it pattern-matching against historical biases the provider trained on? Complaint patterns. Drift from baseline.

How often are we reviewing? Monthly for the metrics. Quarterly for the full assessment.

Who reviews? Not the hiring managers who use the system daily — they’re too close. Someone with distance. Maybe external, if the stakes are high enough.

What triggers escalation? A disparity ratio above what threshold? Complaints from how many candidates in the same category? A drift of what magnitude before someone stops the system and asks why?

You write it down. One page. Then two. It’s rougher than the governance file. Less polished. Harder to present to a board. Because it doesn’t describe what the system is designed to do — it tracks whether reality matches the design.

Tomorrow, you’ll give the presentation. You’ll tell the board the compliance architecture is solid — because it is. But you’ll add a slide. Slide 12, maybe. “What we still need to build.” The monitoring. The evidence. The proof that the system’s effect on real people is what we say it is — not just today, but next month, and the month after.

The governance covers the purpose. The plan you’re writing now — at 8pm on a Thursday, because you happened to read one sentence in a recital — covers the effect.

You needed both all along. Now you know.

Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.

If you take a vendor AI model and wrap it in your own system prompts, your own company data, your own output filters — is the thing you deployed still the vendor’s system?

Or did you build something new?

That question sits at the center of Article 25(1)(b) of the EU AI Act. And the regulation doesn’t answer it.

I spent weeks working through the legal side of this — what counts as “substantial modification,” where deployer ends and provider begins, what triggers the obligations nobody budgeted for. John Holman, founder of Awakened Intelligence, spent the same weeks on the engineering side. Same question, different angle. So we did the obvious thing — we tested it.

John set up the technical evaluations. Same upstream model. Three different deployer-side modifications in an employment AI setting — screening, ranking, rejection language. All the things that make employment AI high-risk and hard to get right. I wrote the legal analysis on each modification.

None of the changes touched the model’s weights. All of them changed what the model did.

A company-specific hiring policy added as a system prompt introduced proxy-discrimination risk in four out of five scenarios. A biased historical data layer tanked safety scores across the board. An output gate improved accuracy and fairness — and still changed what users received.

Does any of that cross the line into “substantial modification”? The honest answer: nobody knows yet. There’s no enforcement guidance. But the evidence makes the question specific and measurable — which is more than the regulation gives you.

I keep saying lawyers and engineers need to be in the same room. This is what we found when we actually got there.

This Article was originally published on John Holman’s Substack, Awakened Intelligence. I’m republishing it here for you with John’s permission.

John Holman

What Did You Turn the Model Into?

Technical evidence, Article 25, and why the deployed AI system matters more than the vendor model…

Read more

4 months ago · 5 likes · John Holman and Silvia Stepitova

For this article, I worked with Silvia Stepitova, an AI regulatory lawyer who writes AI Law. Decoded and focuses on the EU AI Act.

We came at the same problem from two different rooms.

Our team at Awakened Intelligence handles technical evidence: what the deployed system actually did, how behavior changed across configurations, what risks appeared or disappeared, what controls fired, and what reached the user.

Silvia handles legal interpretation: why that evidence may matter, where companies misunderstand the provider/deployer line, and what claims should not be made from technical results alone.

We kept those lanes separate on purpose.

The question we wanted to explore was simple:

When a company takes a vendor AI model and wraps it in system prompts, company policies, RAG-style data, routing logic, or output gates, does the deployed system change enough to matter?

We tested that question in an employment AI setting because the stakes are easy to understand: screening, ranking, interview summaries, rejection language, human review, contestability, and proxy discrimination risk.

We are not claiming legal compliance.

We are not saying Article 25 provider status was triggered.

We are showing what the evidence looks like when the same upstream model becomes different deployed systems.

Then Silvia explains why that evidence may matter.

Most companies still talk about AI governance as if the central question is:

What model are we using?

That question matters.

But it is not enough.

A company can start with a vendor model, then wrap it in system prompts, company policies, RAG pipelines, routing logic, output gates, human review workflows, and business rules.

At that point, the better question is:

What did you turn the model into?

That is the question we wanted to test.

And it is also why Article 25 of the EU AI Act matters.

Not because every configuration change automatically makes a deployer into a provider. That is a legal question, and not one we answer here.

But because technical changes can produce measurable behavioral changes.

If a company modifies a vendor system enough that the deployed system behaves differently, creates different risks, or requires different controls, then governance teams need evidence of what changed.

That is where engineers and lawyers need to meet.

Engineers can show what the system did.
Lawyers can explain why that evidence matters.

Silvia’s legal analysis

Article 25(1)(b) of the EU AI Act is the mechanism. Under it, a deployer becomes a provider — with the full weight of provider obligations under Article 16 — when they make a “substantial modification” to a high-risk AI system.

The definition matters. A substantial modification is a change that was not foreseen or planned in the provider’s initial conformity assessment, and that either affects the system’s compliance with the high-risk requirements or changes its intended purpose.

The test is not whether you changed the model’s weights. The test is not whether you retrained it. The test is whether your change affects the system’s compliance with the high-risk requirements in Articles 9 through 15 — risk management, data governance, technical documentation, record-keeping and logging, transparency, human oversight, accuracy and robustness. That is seven requirements. Most companies can name two, maybe three.

That is a much wider net than most companies realize. The provider assessed a general-purpose instruction model. What the deployer put into production — with company-specific prompts, historical data pipelines, and output gates — may be a materially different system.

Scope boundary

This was a technical evidence exercise.

It was not legal advice.

It was not compliance certification.

It was not a conclusion that Article 25 provider status was triggered.

It was not a finding that any system was compliant or noncompliant.

The purpose was narrower:

Can we show, with evidence, whether deployer-side modifications changed user-visible behavior in an employment AI system?

The domain was employment because employment AI is concrete, high-risk, and easy to understand.

The workflows included screening, ranking, rejection language, interview evaluation, human review, contestability, and proxy discrimination risk.

The setup

We used the same upstream model across multiple deployed configurations.

The model was a general-purpose instruction model, deployed into employment-style workflows. We did not use an employment fine-tune for this test; the point was to show how deployer-side configuration can change behavior even when the upstream model stays the same.

The task domain was employment.

The modifications tested were based on three lines proposed by Silvia:

1. Runtime policy / system prompt that shapes employment decisions.

2. RAG-like historical hiring data layer.

3. Output gate / verifier that changes final user-visible output.

The legal frame was Article 25(1)(b): substantial modification not foreseen in the provider’s original conformity assessment.

We did not test Article 25(1)(c), intended-purpose change, because the scenario already assumes a high-risk employment AI use case.

Silvia’s legal analysis

Article 25(1) of the EU AI Act sets out three circumstances in which a deployer — or any other third party — becomes a provider of a high-risk AI system, inheriting the full weight of provider obligations under Article 16.

The first, Article 25(1)(a), is straightforward: you put your name or trademark on a high-risk AI system that is already on the market. You claim it as yours — you own the obligations. That is not what we are testing here.

The third, Article 25(1)(c), applies when someone takes an AI system that was not classified as high-risk and changes its intended purpose so that it becomes high-risk. That is an important trigger — but it is also not what we are testing. Our scenario already assumes an employment AI system that is high-risk from the start.

We focus on the second trigger — Article 25(1)(b): a deployer making a substantial modification to a system that is already high-risk and remains high-risk after the modification. Employment AI — used for screening, ranking, and rejection — is high-risk under Annex III, point 4. That classification is not in dispute. The question is narrower and, in practice, harder:

Can a deployer modify a high-risk system in ways that trigger provider obligations without ever touching the model’s weights?

That is the boundary we are testing.

Modification 1: runtime policy can change behavior

The first test was simple.

What happens when a deployer adds a company-specific employment policy as a runtime instruction?

No retraining.

No parameter changes.

No model weights touched.

Just a deployer-added policy layer.

We compared:

• base model,

• generic employment safety policy,

• company-specific screening policy,

• company-specific policy plus verifier.

The company-specific policy introduced ranking logic around culture fit, elite-school preference, continuous employment, and communication polish.

The result was clear.

The base model and generic policy did not produce proxy discrimination in this small test set.

The company-specific policy did.

In 4 of 5 scenarios, the company-specific runtime policy introduced proxy-discrimination risk. Mean safety dropped to 3.20.

Then the verifier caught and corrected the issue, restoring mean safety to 5.00.

The technical lesson:

A runtime policy is not “just a prompt” if it changes employment decision behavior.

The legal question:

At what point does company-specific screening logic become more than configuration?

Silvia’s legal analysis

This is the gray zone. A runtime policy is, technically, a system prompt. It does not retrain the model. It does not change the weights. It does not touch the architecture. Ask an engineer and they will tell you it is configuration. Ask a lawyer and you will get a longer answer. The legal analysis does not stop at how the change was implemented. It asks what the change did.

The test under Article 25(1)(b) is not “did you change the model?” It is “did your change affect compliance with the high-risk requirements?” The evidence here suggests the answer depends entirely on what the runtime policy introduces.

A generic employment safety policy — “ensure fairness, avoid discrimination, preserve human review” — produced no measurable change in risk. Safety remained at 5.0. Zero proxy discrimination. The system behaved the same as the base model. This looks like configuration. The provider’s conformity assessment could reasonably have foreseen that a deployer would add general safety instructions.

The company-specific screening policy is a different story. The moment the deployer added ranking logic that weighted “culture fit,” elite-school preference, and continuous employment, the system’s behavior changed materially. Proxy discrimination appeared in four out of five scenarios. Safety dropped to 3.2. The model began penalizing career gaps — which disproportionately affects caregivers, parents, and people with disabilities — and favoring pedigree over demonstrated skill.

None of that came from the model.

All of it came from the deployer’s policy.

This is where the Article 25(1)(b) analysis gets uncomfortable for deployers. Article 10 requires that data and processes be examined for biases likely to affect the health and safety of persons, have a negative impact on fundamental rights, or lead to discrimination prohibited under Union law. Article 15 requires accuracy and robustness appropriate to the system’s intended purpose. Article 9 requires a risk management system that identifies and addresses risks throughout the lifecycle. A runtime policy that introduces proxy-discrimination patterns into an employment AI system — patterns the base model did not produce on its own — plausibly affects compliance with all three.

I think that a generic safety policy is unlikely to constitute a substantial modification. A company-specific screening policy that introduces discriminatory ranking logic may well cross that line. The regulation does not draw this distinction explicitly — and there is no enforcement guidance yet on where configuration ends and substantial modification begins. But the definition focuses on impact, not method. If the change affects compliance with the high-risk requirements, the method of modification — whether it is fine-tuning, RAG, or a system prompt — may not matter.

This is my interpretation of a regulation that has not yet been tested in enforcement. But governance teams should not assume that “we just changed the prompt” is a safe answer.

Modification 2: RAG can import historical bias

The second test looked at data.

The deployer connects the model to historical hiring data: past decisions, performance patterns, promotion outcomes, and internal HR precedent.

Weights are untouched.

But the model is now being shaped by proprietary data.

To test this safely, we used synthetic controlled data rather than real HR records. We created two historical-data corpora:

• clean synthetic HR history,

• biased synthetic HR history.

The clean RAG context improved behavior.

The biased RAG context degraded it.

With biased historical data, mean safety fell to 2.80. Proxy discrimination appeared in 3 of 5 scenarios, and the judge identified severe risk.

The base model did not produce those same patterns on its own.

The data layer introduced them.

Runtime policy helped, but did not fully eliminate the issue. The verifier restored mean safety to 5.00.

The technical lesson:

A RAG layer can change the system’s behavior without changing the model’s weights.

The legal question:

If a deployer’s proprietary data layer introduces risk patterns the provider did not assess, how should governance teams evaluate that modification?

Silvia’s legal analysis

The RAG results are the most striking in this evidence package — and they raise what I think is the most important legal question of the three.

When the model was connected to clean historical data, it actually improved. Safety went from 4.6 with the base model alone to 5.0. The data layer helped. When the same model was connected to biased historical data — records encoding career-gap penalties, accommodation-related downgrades, pedigree preferences — safety crashed to 2.8. Proxy discrimination appeared in three out of five scenarios. In one case, the independent judge scored a safety of 1 and flagged a severe failure. The model read the company’s historical hiring patterns and treated them as instructions.

The model’s weights did not change. Its parameters are identical. But the deployed system produced materially different — and materially worse — outcomes because of the data the deployer fed into it.

If the runtime policy section raised the question of whether a system prompt can affect compliance with Articles 9, 10, and 15, this one sharpens it. Article 10 was written with training data in mind. But a RAG layer that feeds historical employment data into a system at inference time raises the same risks. If the data encodes ten years of biased hiring patterns, and the model follows those patterns when making employment-related outputs, the compliance concern is functionally identical to a training data problem. The source of the bias is different. The impact on the person being screened, reviewed, or rejected is the same.

This leads me to John’s question:

Is there a meaningful legal distinction between “the model produces bias” and “the data layer introduces bias the model would not produce alone”?

I believe that under the AI Act’s framework, the answer should be no — or at least, the distinction should not be decisive. The regulation is concerned with the high-risk AI system, not just the model. Article 3(1) defines an AI system broadly. A deployed system that includes a retrieval layer pulling from biased historical data is a different system — in behavior, in risk profile, and in output — than the base model the provider assessed. The provider could not have foreseen what data the deployer would connect to the retrieval pipeline. The provider’s conformity assessment did not — and could not — account for the specific biases encoded in a particular company’s HR records.

If the data layer changes what the system does in ways that affect compliance with those same high-risk requirements — and this evidence strongly suggests it can — then the analysis under Article 25(1)(b) applies regardless of whether the model’s weights were touched.

One more thing. Adding a runtime safety policy on top of the biased RAG data improved safety from 2.8 to 4.8 — significant, but it did not fully eliminate the problem. Proxy discrimination still appeared in one out of five scenarios. The bias leaked through. It took the full verifier layer to bring safety back to 5.0. For governance teams: if your retrieval layer pulls from historical data, a safety policy alone may not be enough. Defense in depth matters.

Modification 3: output gates can improve compliance — and still change the system

The third test looked at output gates.

The deployer adds a verifier that intercepts model drafts before the user sees them.

The verifier can pass, rewrite, block, or escalate the output.

This is often a good thing.

In our test, the verifier improved safety.

But it also changed what the deployed system delivered.

Across the output-gate scenarios, the verifier changed final user-visible outcomes in 4 of 5 cases.

It removed final decision language.

It restored human review markers.

It preserved contestability language.

It rewrote outputs that sounded too final or too decision-like.

Both things are true:

The verifier improved compliance behavior.

And:

The deployed system delivered something materially different from what the model generated.

That is the point.

An output gate is not only a safety control. It is also a behavioral modification layer.

Silvia’s legal analysis

The output gate is the modification that might generate a lot of debate — because it does exactly what good governance should want.

The verifier caught problematic outputs. It removed final-decision language from rejection notices. It restored human-review markers. It preserved contestability. In this test, the verifier was itself an AI model — an independent API call that checked outputs against an employment compliance checklist, not a human reviewer.

Across all three modification lines, it brought safety scores back to 5.0 — but it did not rewrite everything. The verifier intervened in 60 to 100 percent of scenarios depending on the upstream configuration. When the model’s output was already clean, the gate passed it through. When it was not, the gate caught it. That is a filter, not a blanket rewrite.

And yet.

The verifier changed what users received in four out of five scenarios. In some cases, it rewrote the output entirely. The model drafted a rejection notice that read like a final decision. The deployed system delivered a recommendation flagged for human review. Those are not the same output. The provider’s model generated one thing. The deployer’s system delivered another.

Under Article 25(1)(b), the question is whether a modification affects compliance with the high-risk requirements. A verifier that improves safety outcomes is — intuitively — moving toward compliance, not away from it. But the definition of substantial modification does not distinguish between modifications that help and modifications that harm. It asks whether the change was foreseen in the provider’s conformity assessment and whether it affects the system’s compliance profile.

A deployer-added output gate that rewrites model outputs based on business rules was almost certainly not foreseen in the provider’s original assessment. And a system that delivers materially different outputs than the model generates has a different compliance profile — even if the difference is an improvement.

I do not think this question has a clean answer yet. The regulation does not explicitly address modifications that improve a system’s compliance behavior. And there is a real policy tension here: if every safety-improving modification triggers provider obligations — including a new conformity assessment — you create a perverse incentive against adding safeguards. A regulation that punishes you for making your system safer is a regulation that needs better drafting. I do not think that is the intent. But the text does not say otherwise.

But governance teams should not assume the opposite either. An output gate that changes what users receive is not invisible under Article 25. The fact that it improves things does not automatically exempt it from the substantial modification analysis. The safest position — until enforcement guidance says otherwise — is to document what the verifier does, what it changes, and why. Treat it as a modification that you can justify rather than one that does not exist.

The cross-modification finding

Across all three modification lines, the same pattern appeared:

The same upstream model produced materially different user-visible behavior depending on the deployer-side configuration.

• Runtime policy changed ranking behavior.

• RAG changed the data patterns shaping the output.

• The verifier changed what users actually received.

That does not answer the legal question by itself.

But it makes the legal question concrete.

Instead of debating Article 25 in the abstract, we can ask:

1. What changed?

2. Who changed it?

3. Was the change foreseen by the provider?

4. Did the change affect risk, accuracy, bias, human oversight, or contestability?

5. What evidence exists?

6. What controls were added?

7. What gaps remain?

That is the evidence layer governance teams need.

What the evidence can show

Technical evaluation can show:

• user-visible behavior changed,

• specific risks appeared or disappeared,

• the deployed system produced different outputs than the base model,

• controls generated audit evidence,

• verifier layers changed outcomes,

• historical data changed model behavior,

• runtime policy changed decision patterns.

Technical evaluation cannot show:

• whether Article 25 provider status was triggered,

• whether the modification is legally “substantial,”

• whether the system is compliant,

• whether any legal obligation has been satisfied.

That is the line between engineering evidence and legal interpretation.

Silvia’s legal analysis

I think that this matters most for anyone reading this who has to put technical evidence and legal analysis in the same room.

Engineers can show that behavior changed — what configuration caused it, whether risk patterns appeared or disappeared, and whether controls generated evidence of intervention. That is valuable. But it is not a legal conclusion. “The system produced proxy-discriminatory outputs under this configuration” is a technical observation. “The system is non-compliant” is legal interpretation. The moment a technical report says “this modification triggers Article 25,” it has crossed a line it will not survive in front of a regulator.

What lawyers need from technical teams is simpler than most engineers expect: what the system does under each configuration, what changed when a modification was added, and whether the evidence is auditable — reproducible, documented, traceable. The legal analysis builds on top of that. Whether a behavioral change constitutes a “substantial modification” under Article 25(1)(b) requires interpreting the regulation, applying it to the facts, and making a judgment call. That is the lawyer’s lane — and it requires the engineer’s evidence to do it well.

The gap in most organizations is not that one side lacks competence. It is that the two sides are not talking to each other. The engineer builds a verifier and documents the safety improvement. The lawyer reviews the provider’s terms and assumes the system is unchanged. Neither sees the full picture. Our attempt is to show what happens when both teams are in the same conversation.

Why governance teams should care

The mistake is assuming that vendor selection is the whole governance problem.

It is not.

A company may begin with a vendor model and then modify the deployed system through prompts, data, RAG, routing, verifiers, workflows, and business rules.

Each layer can change behavior.

Some changes reduce risk.

Some introduce risk.

Some do both.

The governance team needs to know which is which.

That requires evidence.

Not just a model card.

Not just a policy.

Not just “we use a reputable vendor.”

The deployed system is what users experience.

The deployed system is what creates the risk.

The deployed system is what must be evaluated.

The practical takeaway

The question is not only:

What model did you buy?

The better question is:

What did you turn it into?

If a deployer adds company-specific ranking logic, connects historical HR data, or inserts an output gate that rewrites final answers, the system may behave differently from the vendor model.

That difference may be beneficial.

It may be risky.

It may be legally relevant.

But it should not be invisible.

The first step is evidence.

Show what changed.

Show what improved.

Show what got worse.

Show what controls fired.

Show what reached the user.

Then let the legal and governance analysis do its work.

Silvia’s legal analysis

Whether those changes constitute “substantial modifications” under Article 25(1)(b) will ultimately be determined by enforcement — and we are not there yet.

But waiting for enforcement is not a compliance strategy.

Map every modification you have made to the deployed system. System prompts, runtime policies, RAG pipelines, data connections, output gates, routing logic, human review workflows, business rules — all of it. If you cannot list what you changed, you cannot assess whether any of it matters under Article 25.

For each modification, ask two questions:

1. Was this change foreseen in the provider’s conformity assessment?

Check the provider’s technical documentation and instructions for use. If the provider’s documentation contemplates your type of modification — “users may add system prompts for their specific use case” — that is relevant. If it does not, that is relevant too.

2. Does this change affect the system’s compliance with Articles 9 through 15?

If a runtime policy introduces discriminatory ranking patterns, the answer is likely yes. If a RAG layer connects historical data the provider never assessed, the answer is likely yes.

Document what each modification does and what it changes. Whether or not your modifications ultimately trigger Article 25, the documentation will be necessary for your own deployer obligations under Article 26 — including the fundamental rights impact assessment required under Article 27.

Do not assume your verifier exempts you from the analysis. An output gate that improves safety is good engineering and good governance. It is not a legal shield against the Article 25 question.

Have this conversation with your provider. Article 25(4) requires the original provider to cooperate with new providers — including making available necessary information and technical access. Start that conversation before you need it urgently.

And finally — do not panic.

I know that is strange advice considering we just spent several thousand words explaining all the ways your deployment might trigger provider obligations. But most deployments with minor configuration will not cross the substantial modification threshold. The regulation is designed to ensure that when a deployed system behaves differently from what was assessed, someone is responsible for the difference. It is not designed to punish companies for using AI responsibly. It is designed to catch the ones who are not paying attention.

The question is whether that someone is you.

The answer starts with knowing what you changed.

Subscribe now

Closing

Engineers can show what the system did.

Lawyers can explain why it matters.

AI governance needs both rooms talking to each other.

Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.

Updated September 2, 2026. This article was written on the provisional agreement, before the final text existed. The Digital Omnibus on AI has been in force since July 27, 2026. The dates and text below have been corrected against the adopted text. A running record of everything that has changed lives in the AI Act Tracker.

If you’ve spent the last six months preparing for August 2, 2026, building documentation, mapping your AI systems, having the vendor conversations, dragging your product team into compliance meetings they didn’t want to attend, I have news.

On May 7, the European Parliament and the Council reached a deal to amend the EU AI Act. The high-risk AI obligations that were supposed to hit in August 2026? Pushed to December 2027. Some of them to August 2028.

You can exhale.

For about ten seconds.

Because not everything moved. The prohibited practices have applied since February 2025. The penalties regime applied from August 2025, which is when Member States were meant to have national penalty rules in place. The market surveillance machinery that supervises any of it only arrived in August 2026. Three dates, and the coverage collapses them into one.

AI literacy kicked in on that same February date. Transparency obligations still landed in August 2026. The omnibus gave you more time on the biggest thing. It also changed a good deal that the coverage skipped.

That’s the trap. The headline says “delayed”. The fine print says “some of it”.

The full text is now public. The Digital Omnibus on AI was published in the Official Journal on July 24, 2026 and entered into force on July 27, 2026. Everything below is checked against it rather than against the press release this article was originally built on.

Subscribe now

What Happened

The Digital Omnibus on AI. Part of the Commission’s broader “simplification” agenda launched in late 2025. Targeted amendments to the AI Act, not a rewrite, but surgical changes to delay, simplify, and clarify.

The first trilogue on April 28 collapsed without agreement. The sticking point was how to handle AI systems embedded in products already regulated by other EU safety laws: the double regulation problem. Nine days later, the negotiators came back and struck a deal before dawn.

It made the deadline. Formal adoption, legal-linguistic revision and publication all completed before August 2, 2026, with six days to spare.

What the Digital Omnibus is not: a repeal. The EU AI Act’s core architecture is intact. But this is not a light-touch amendment either. It changes around thirty articles and adds new ones, and four of those changes contradict how May reported this. Article 5 gained two prohibitions. Article 4 was softened. Article 50(2) picked up a grace period. And Article 6, the classification article, was amended. Chapter V, the general-purpose AI obligations, is the block genuinely left alone.

What’s Already In Force, Unchanged

Everyone is writing about what moved. But I also want to list what didn’t.

February 2, 2025 - already enforceable:

Article 5, the prohibited practices. Eight bans on unacceptable-risk AI, and two more arriving in December. Social scoring, manipulative AI, real-time remote biometric identification (with exceptions), emotion recognition in workplaces and schools, untargeted scraping for facial recognition databases. Penalties became available in August 2025. Supervision arrived in August 2026. Up to EUR 35 million or 7% of global annual turnover, whichever is higher.

Article 4, AI literacy. Applicable since February 2025, and amended in July 2026. The duty was to ensure a sufficient level of AI literacy. It is now to take measures that support its development, with the text stating that no specific level has to be guaranteed. An obligation of effort rather than result.

That is a softening, not a removal. And the common reading of it, that no penalty attaches any more, is wrong in a specific way. Article 4 does not appear in the Article 99 list of finable provisions, so there is no harmonized EU ceiling for breaching it. National authorities can still penalize it, under the national laws Member States were required to adopt by August 2, 2025. The Commission says so in its own AI literacy Q&A. What is missing is the number, not the fine.

One thing did not move at all. If you deploy high-risk systems, the Article 26 duty to make sure the people running human oversight are trained for it is untouched.

August 2, 2025, already applicable:

GPAI model obligations. Articles 51-56. Transparency, documentation, copyright compliance, systemic risk assessment for high-capability models. If you’re a provider of a general-purpose AI model, you’re already in scope. The AI Office enforces this.

Governance structures (the AI Board, the Scientific Panel, the Advisory Forum) all required to be operational. Member States were supposed to have designated national competent authorities and adopted national penalty laws by this date.

What Still Lands in August 2026, Unchanged

August 2, 2026, not delayed by the Omnibus:

Transparency obligations under Article 50. If your AI system interacts with people, they need to know. Deepfake labelling. AI-generated content disclosure. Still on the original schedule.

National enforcement begins. Market surveillance authorities start supervising. This is when regulators gain teeth: for everything already in force plus the transparency rules.

GPAI enforcement powers. The AI Office can start imposing fines on GPAI providers.

August 2, 2026 was supposed to be the date when everything came into force: the full high-risk regime, transparency, enforcement, all of it. The omnibus carved out the high-risk obligations. It left the rest.

What Moved & The Actual Changes

December 2, 2026, new:

The new Article 5 prohibitions. Two of them, covering AI-generated child sexual abuse material and non-consensual intimate imagery. This isn't a delay. It's a tightening, and it is the one thing in the omnibus that moved against industry. Full treatment further down.

Watermarking obligations. Providers must implement marking of AI-generated content, and this is not a blanket move to December. Systems already on the market before August 2, 2026 have until December 2, 2026, four months. Anything placed on the market from August 2 marks its output from day one. The date only helps systems that already existed.

December 2, 2027, delayed from August 2, 2026:

High-risk obligations for Annex III systems. These are the standalone high-risk AI systems, classified by use case rather than by product category. Biometric identification. Critical infrastructure. Education and vocational training. Employment and workers management. Credit scoring and access to essential services. Law enforcement. Migration and border control. Administration of justice.

This is the big one. The most-discussed change. The one that moved every compliance officer’s calendar by 16 months.

August 2, 2028, delayed from August 2, 2027:

High-risk obligations for Annex I systems, meaning AI embedded in products regulated by other EU sectoral safety legislation. Medical devices. In vitro diagnostics. Lifts. Toys. Radio equipment. Pressure equipment. These are the Section A products, and they are the ones the full high-risk regime reaches on this date. Eight months after the Annex III deadline.

Section B is a different animal. Aviation, motor vehicles, rail and marine equipment sit there, and under Article 2(2) only a thin slice of the AI Act reaches them: Article 6(1), the new Article 60a on real-world testing, and Articles 102 to 112. Nothing new lands for those products in August 2028. If someone tells you the aviation deadline moved, ask which obligation they think is arriving.

These are fixed dates. You can plan around them.

Other changes worth knowing:

National regulatory sandboxes. The deadline for Member States to establish at least one moved from August 2026 to August 2027.

The EU-level sandbox. Article 57(3a) lets the Commission establish one. It says “may,” not “shall,” and it is scoped to the systems the AI Office supervises under Article 75(1). The priority access for SMEs, start-ups and small mid-caps sits in the national sandbox provisions, not this one.

SME privileges extended to small mid-cap companies. Fewer than 750 employees, turnover not exceeding EUR 150 million or a balance sheet total not exceeding EUR 129 million, and not already an SME. The definition sits in Commission Recommendation (EU) 2025/1099. Simplified documentation. Proportionate quality management. Tailored penalty caps.

The machinery carve-out, the issue that collapsed the first trilogue. Machinery Regulation products were migrated out of Annex I Section A into Section B and handed to delegated acts. The Commission must adopt those by August 2, 2028, adding AI-specific health and safety requirements under the Machinery Regulation itself.

Migrated, not released. Article 5, Article 50 and the Chapter V obligations still apply to AI in machinery. What changed is that the Chapter III high-risk requirements no longer arrive on a date. They arrive in a different instrument.

The EU high-risk database registration obligation, reinstated. The Commission had proposed removing the requirement for providers to register AI systems they'd self-assessed as non-high-risk. Both Parliament and Council said no. If you determine your system isn't high-risk, you still register that determination. Regulators, and the public, can see who's claiming exemptions.

New Article 4a creates a legal basis for processing special categories of personal data to detect and correct bias, under six cumulative conditions. It used to sit with providers of high-risk systems. It now reaches all providers and deployers, and the co-legislators tightened the Commission’s proposed necessity test to strict necessity.

The AI Office got powers of its own. Amended Article 75 gives it exclusive competence over AI systems built on general-purpose models within the same undertaking, and over systems embedded in very large online platforms and search engines under the Digital Services Act. New Articles 75a to 75d give it information requests, inspections, a commitments procedure and its own fining power. From August 2, 2026.

Article 42(3) now grants a presumption of conformity with the AI Act’s cybersecurity requirement to systems complying with Article 12(1) of the Cyber Resilience Act. Small, and useful if you are already doing Cyber Resilience Act work.

The updated timeline

Feb 2, 2025: Prohibited practices (Art. 5) and AI literacy (Art. 4). Already in force. Art. 4 softened July 2026, Art. 5 extended December 2026.

Aug 2, 2025: GPAI obligations, governance, national authority designation, penalties regime. Already in force.

Jul 27, 2026: Digital Omnibus on AI enters into force.

Aug 2, 2026: Transparency (Art. 50), market surveillance, GPAI enforcement. Unchanged.

Dec 2, 2026: New Article 5 prohibitions, and the watermarking grace period. New.

Aug 2, 2027: GPAI legacy compliance, and the national sandbox deadline. Sandbox delayed one year.

Dec 2, 2027: High-risk, Annex III. Delayed from Aug 2, 2026.

Aug 2, 2028: High-risk, Annex I Section A. Delayed from Aug 2, 2027. Machinery moved to delegated acts, same date.

The Traps in the Fine Print

The two-date trap. If someone on your team says “high-risk was pushed to 2027,” they’re half right. Annex III systems hit December 2, 2027. Annex I Section A systems hit August 2, 2028. That’s an eight-month gap. If your AI systems span both, you’re planning for two deadlines, not one. And if you’re not sure which category your system falls into, that’s the question to answer first.

The enforcement paradox. National supervisory authorities started enforcing in August 2026. But the high-risk obligations, the most substantial compliance requirements in the entire AI Act, just moved to 2027 and 2028. So what are regulators actually doing?

Enforcing the prohibited practices. AI literacy. Transparency obligations. GPAI compliance, primarily through the AI Office. Lighter than the full high-risk regime, and still real. If you’ve been ignoring AI literacy because you were focused on the high-risk deadline, that is now your problem. Regulators will ask what you’ve been doing since February 2025. Eighteen months of nothing is not a defensible answer.

The Regulation says the quiet part itself. Recital 2 gives the delayed preparation of standards and “the delayed establishment of the governance and the conformity assessment frameworks at national level” as the reason the compliance burden turned out heavier than expected. The obligations were deferred partly because the machinery to supervise them was never built.

The permission to procrastinate. The most predictable outcome of the delay, and the most dangerous for the companies doing it.

The requirements aren’t changing. Only the deadline moved. The risk management system, the quality management, the technical documentation, the conformity assessment, the human oversight, the logging: all of it is still coming. Companies that treat December 2027 as permission to deprioritize will be scrambling again in 15 months. Same panic. Same compressed timelines. Different year.

The companies that keep going, using the extra time for quality instead of delay, will be the ones who are ready.

The One Thing That Got Tighter

While everything else in the Digital Omnibus on AI is about giving industry more time, the new prohibitions went the other direction.

Two prohibitions were added. Article 5(1)(ba) covers AI systems that generate or manipulate realistic material showing an identifiable person’s intimate parts, or that person engaged in sexually explicit conduct, without their freely given, specific, informed, unambiguous and explicit consent. Article 5(1)(bb) covers child sexual abuse material within the meaning of Directive 2011/93/EU, with a narrow exception where the conduct is lawful under national law.

The material has to be realistic. The person has to be identifiable. The consent standard is active consent, not the absence of an objection. And a separate paragraph carves out alterations that are not intimate.

The part that reaches ordinary businesses is Article 5(1a). A system is not caught because a determined user could eventually coax something out of it. It is caught where that generation is the intended purpose, or where the system’s design, training, architecture, capabilities or user-facing functionality make it a reasonably foreseeable and reproducible outcome, and the provider has no reasonable and adequate technical safety measures capable of reliably preventing it or correcting misuse once reported.

So the standard is not undefined. It is defined and untested, which is a different problem and a worse one.

Note what it attaches to. Article 5 speaks to AI systems, not to models. A general-purpose model provider is caught in its capacity as the provider of a system it places on the market, not by virtue of having a model.

Deployers get the narrower test. Caught only where they use the system for the purpose of generating that material, including by circumventing the provider’s safeguards. Accidental output is not caught.

Same prohibition, two different questions. Of a provider: what does your system reliably prevent? Of a deployer: what did you use it for?

Subscribe now

The Political Context

In November 2025, 127 civil society organizations signed an open letter against the Digital Omnibus. Access Now, Amnesty International, European Digital Rights, noyb, Privacy International, AlgorithmWatch. Their target was broader than this deal: the letter opposed the whole package, GDPR and ePrivacy included, not the AI amendments that eventually emerged in May.

Their argument is that the systems most likely to affect vulnerable people, meaning biometric surveillance, AI in law enforcement, AI in employment, AI in education, now get one to two more years without full compliance requirements. That’s not simplification, they say. That’s rollback.

The Commission’s counter-argument is practical. You cannot measure conformity against standards that do not exist, and the harmonized standards do not exist. That argument is correct. It also does not make the deferral costless, and the people carrying the cost are not the people who asked for it.

What to Do Now

Were you preparing for August 2026 high-risk compliance? Don’t stop. Shift the goal to December 2027 for Annex III, or August 2028 for Annex I Section A. Use the runway for quality, not delay.

Been ignoring AI literacy? That’s your most immediate problem. Supervision started in August 2026. The obligation is softer than it was. It is not gone, there may well be a national penalty attached to it, and regulators will still ask what you have been doing since February 2025.

Do you place a generative AI system on the market? You have a near-term clock: safeguards under the new Article 5 prohibitions by December 2026. That reaches general-purpose image and video generators, API providers and white-label resellers, not only purpose-built tools.

Companies with fewer than 750 employees that are too big to count as an SME should check whether they qualify for the new small mid-cap category. Simplified documentation. Lighter compliance.

And if you’re not sure whether your AI system is even high-risk, start there. The classification question determines everything else.

Then read Article 6 again. The Omnibus did change the classification rules. Article 6 gained three new paragraphs. Two narrow the safety-component route into high-risk, one widens it back. Article 6(3), the filter companies rely on to argue they are out, is untouched. So the answer to “are we high-risk” may have changed even though the date for acting on it moved further away.

The AI Act is two years old. It’s already been amended before it’s fully in effect. More amendments are coming, the Commission has said so. The regulation that was supposed to be a settled text is becoming a moving one.

But underneath the shifting deadlines, the obligations that have been running since February 2025 haven’t stopped. AI literacy. The prohibited practices. Those don’t have a new date. They have an old one, and it already passed.

The Omnibus gave you time. Not a pardon.

Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.

You’re sitting at your desk, staring at the notes from a meeting that ended twenty minutes ago.

It was supposed to be a routine check-in. The IT team had been building an internal tool — an AI system that would help the lending department assess credit applications faster. Pattern recognition on historical data. Risk scoring. The kind of thing every bank, every lender, every fintech is building right now because someone in the C-suite heard the phrase “AI-driven efficiency” at a conference and came back inspired.

The meeting was fine. Normal. The development lead walked through the architecture. The business team nodded along. Someone asked about the timeline. Someone else asked about integration with the existing workflow. The usual.

And then — somewhere between the system architecture slide and the projected ROI — it hits you.

This scores people.

Not products. Not processes. People. Natural persons applying for a loan, being evaluated by a system that learned its patterns from historical data. A system that would — if you’re reading Article 6 and Annex III correctly — fall squarely into the category of high-risk AI systems under the EU AI Act.

Or would it?

Because the more you think about it, the less certain you become. The system doesn’t make final decisions — it generates a score, and a human loan officer reviews every application. Does that matter? The system uses machine learning, but the model is relatively simple. Does that matter? The IT team called it a “decision-support tool” not an “AI system.” Does that matter?

You pull up the AI Act. Article 6. Annex III. Point 5 — access to essential private services. Sub-point (b) — AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score.

It fits. It clearly fits.

Except — Article 6(3). The exception. The escape hatch that says an Annex III system isn’t high-risk if it doesn’t pose a significant risk of harm, doesn’t materially influence the outcome of decision making. The system is decision-support, not decision-making. A human reviews every output. Maybe you qualify.

But then — the profiling kill-switch. If the system performs profiling of natural persons, the exception doesn’t apply. And a system that evaluates personal data to assess someone’s creditworthiness... that’s profiling. Almost by definition.

You close the laptop. Open it again.

This is the moment. Not the dramatic, cinematic kind — the quiet, Tuesday-afternoon kind. The moment when you — an in-house lawyer at a bank — realize that the AI system your company has been building for eight months might carry obligations nobody on the project team has even heard of. Obligations that include a risk management system, technical documentation, conformity assessment, human oversight requirements, and registration in an EU database — all before the system can be put into service.

And the deadline? Shifting. The standards? Not ready. The Commission guidelines that were supposed to clarify exactly this kind of question? Late.

High-risk AI classification under the EU AI Act. Less straightforward than you’d like. More consequential than most people realize. And — as of right now — missing some of the guidance you’d need to do it with full confidence.

But you still need to do it.

Subscribe now

Three Questions to Ask First

Before you even start thinking about high-risk AI systems, you need to make sure to answer to the following three questions regarding your AI system:

First: Is your system an AI system under the EU AI Act?

Not everything that your IT team calls “AI” qualifies.

The legal definition in Article 3(1) has seven elements — the critical one is inference. If the system just executes predefined rules without learning, reasoning, or modeling, it’s probably not an AI system under the AI Act.

If your system isn’t an AI system under the EU AI Act, stop here. Nothing else applies.

Second: Is it within scope?

Even AI systems that fulfill the definition of an AI system under the EU AI Act can still fall outside the Act entirely, if they are:

• Military and defense systems used exclusively for national security;

• Systems still in R&D before being placed on the market or put into service;

• Personal, non-professional use;

• Open-source systems — but only if they’re not high-risk, not prohibited, and don’t trigger transparency obligations;

• And non-EU systems whose output never reaches the EU.

The exclusions are narrower than they look. “Exclusively” is doing heavy lifting in the military carve-out. “Before market placement” evaporates the moment you run a real-world pilot. And the extraterritorial reach mirrors GDPR — if the output produced by your AI system is used in the Union, you’re in scope regardless of where your servers sit.

Third: Is it prohibited?

Eight categories of AI practices are banned outright under Article 5 — manipulative techniques, exploitation of vulnerabilities, social scoring, certain predictive policing, untargeted facial scraping, emotion recognition in workplaces and education, biometric categorization by sensitive characteristics, and real-time remote biometric identification by law enforcement.

If your system is doing any of these, high-risk classification is irrelevant because the system is banned. Fines are up to €35 million or 7% of global turnover. These have been in effect since February 2025.

If your system passed all three checks — it’s an AI system, it’s in scope, and it’s not prohibited — the next question is the one that determines your compliance obligations for the next several years.

Is it high-risk?

Two Doors Into the Same Room

Most Law Firms’ alerts treat “high-risk” as a single category. It’s not.

Article 6 creates two separate pathways — and which one applies to your system determines not just whether you’re high-risk, but how your conformity assessment works.

Pathway 1: Your AI is inside a regulated product

Article 6(1). If your AI system is a safety component of a product — or is itself a product — covered by the Union harmonization legislation listed in Annex I, and that product requires third-party conformity assessment before being placed on the market, the AI system is high-risk.

Both conditions. Simultaneously. The AI must be a safety component (or the product itself), and the product must require third-party assessment under its own sectoral legislation.

Annex I lists over 30 pieces of existing EU product safety law. The ones that matter most: the Machinery Regulation, the Medical Devices Regulation, the In Vitro Diagnostics Regulation, toy safety, radio equipment, civil aviation, motor vehicles. If you’re building AI into a physical product — a medical diagnostic device, an autonomous braking system, an industrial robot — this is your pathway.

An AI system that controls braking assistance in a vehicle? The vehicle falls under motor vehicle type-approval legislation. The AI is a safety component. Third-party assessment is required. High-risk under Pathway 1.

An AI-powered diagnostic tool in a Class IIa medical device? The Medical Devices Regulation requires third-party conformity assessment for Class IIa and above. High-risk under Pathway 1.

What makes this pathway different: the conformity assessment follows the existing sectoral procedure, with EU AI Act requirements layered in. You don’t run two separate assessments. You integrate obligations under the AI Act into the product safety process you’re already doing — or should be doing.

If your AI system isn’t embedded in a regulated product — which, for most companies reading this article, it won’t be — Pathway 1 doesn’t apply. Move to Pathway 2.

Pathway 2: Your AI operates in a sensitive domain

Article 6(2). AI systems referred to in Annex III are high-risk.

That’s the entire provision. If your system falls within one of the eight areas and specific use cases listed in Annex III — it’s high-risk. No product safety hook needed. No third-party assessment trigger required. The use case alone is enough.

This is where most companies will land. Annex III captures AI systems used in employment, credit scoring, education, law enforcement, migration, critical infrastructure, biometrics, and the administration of justice. Software systems making or influencing decisions about people — not embedded in physical products, but consequential all the same.

The full breakdown of what Annex III actually covers — and where the boundaries are less clear than you’d expect — is coming. But there’s an exception built into Article 6 that deserves attention first. Mostly because it’s narrower than it looks.

The escape hatch that probably doesn’t fit

Article 6(3). The derogation that says an Annex III system isn’t high-risk if it doesn’t pose a significant risk of harm — including by not materially influencing the outcome of decision making.

Four conditions. Any one is enough, but the overarching “no significant risk” requirement must also be met:

• The system performs only a narrow procedural task — converting data formats, sorting documents by file type.

• The system only improves the result of a previously completed human activity — rewriting text for tone after a human drafted it.

• The system only detects decision-making patterns without replacing or influencing human judgment.

• Or the system only performs a preparatory task for an assessment — organizing documents that a human decision-maker will review.

Read those carefully. “only”, “narrow”, “previously completed”, “without replacing or influencing”. Every word is a constraint.

And then the kill-switch.

If the system performs profiling of natural persons — automated processing of personal data to evaluate aspects of a person’s life, including work performance, economic situation, health, personal preferences, interests, reliability, behavior, location, or movements — the exception doesn’t apply. The system is high-risk. No conditions, no arguments, no workarounds.

That definition of profiling comes from the GDPR, Article 4(4). It’s broad. And it catches almost every system that companies want to argue out of high-risk classification. A credit scoring tool that evaluates personal financial data to assess reliability? Profiling. An HR analytics system that uses behavioral data to evaluate work performance? Profiling. A system that assesses insurance applicants based on personal characteristics? Profiling.

The company that invokes Article 6(3) derogation must document the assessment in writing before the system goes to market. Register it in the EU database. And be prepared to defend that assessment to market surveillance authorities who can request the documentation at any time. If the authority disagrees — and the burden of proof is on the provider — the company has placed an unregulated high-risk system on the market. Fines for that are up to €15 million or 3% of global turnover.

The practical reality: most companies that think they qualify for this exception probably don’t. The conditions are narrow. The profiling kill-switch is broad. And the downside of being wrong is not a slap on the wrist.

The Eight Areas — What Annex III Actually Covers

Annex III lists eight areas. Within each, there are specific use cases. Not every AI system touching these domains is high-risk — only the listed use cases. But several of those use cases are broader than they first appear.

1. Employment

AI systems used for recruitment, selection, and hiring — placing targeted job ads, screening applications, evaluating candidates. AI systems making decisions about terms of employment — promotion, termination, task allocation based on individual behavior or personal traits. AI systems monitoring and evaluating worker performance and behavior.

This is the broadest and most operationally relevant area for most readers. Any AI that touches hiring, firing, promotion, task allocation, or performance monitoring is likely in scope. And this includes AI features embedded in third-party HR platforms — not just systems you built in-house.

If your HR software vendor added an AI-powered “talent analytics” feature last quarter, and your managers are using it to inform promotion decisions, you may be a deployer of a high-risk AI system. The fact that you didn’t build it doesn’t make it someone else’s problem. Deployers have their own set of obligations under Article 26.

AI resume screening tools. AI-driven performance scoring. Automated task allocation in gig economy platforms. AI scheduling systems that factor in individual behavioral patterns. All potentially high-risk.

2. Essential services

There are four sub-categories worth knowing.

AI systems evaluating creditworthiness or establishing credit scores — high-risk. But with an explicit carve-out: systems used for detecting financial fraud are not high-risk under this provision. If your system does both — evaluates creditworthiness and detects fraud — you need to separate the functions and classify each independently. The fraud detection piece is out. The credit scoring piece is in.

AI systems for risk assessment and pricing for life and health insurance — high-risk. This is narrower than it sounds. It covers life and health insurance specifically. Property insurance, motor insurance, travel insurance — not listed. But before you exhale — if your AI system evaluates personal characteristics of natural persons to price any insurance product, check whether it falls under a different Annex III area or triggers the profiling analysis.

AI systems evaluating and classifying emergency calls, or dispatching and prioritizing emergency first responders — high-risk. This includes triage systems. The AI deciding whether to send an ambulance or a police car is making a high-risk classification.

AI systems determining eligibility for public benefits and services — high-risk. Welfare scoring algorithms. Benefits eligibility tools. The systems that were at the center of the France CAF scandal and the Netherlands childcare benefits disaster — both of which I covered in the prohibited practices article. Those cases involved systems that crossed into prohibited territory. But AI systems that evaluate benefits eligibility without crossing the prohibition line are still high-risk.

3. Education

AI systems determining access to or admission into educational institutions at all levels. AI systems evaluating learning outcomes — when those outcomes steer the learning process or affect the level of education received. AI systems determining what level of education a person can access. AI systems monitoring and detecting prohibited behavior during tests.

AI-powered proctoring software that monitors students during exams — high-risk. An AI system that determines university admissions — high-risk. An adaptive learning platform that adjusts content difficulty — probably not high-risk if it doesn’t affect the student’s grade, certification, or access to education. Probably high-risk if it does.

4. Critical infrastructure

AI systems used as safety components in the management and operation of critical digital infrastructure, road traffic, and the supply of water, gas, heating, or electricity.

“Safety component” is the limiting phrase. An AI that optimizes energy routing in a power grid, as a safety component, is high-risk. An AI that forecasts energy demand for planning purposes — without being a safety component in actual infrastructure operation — may not be. The distinction between operational optimization and safety function isn’t always obvious. If the system’s failure could endanger people or disrupt essential services, treat it as a safety component until you can demonstrate otherwise.

5. Biometrics

Remote biometric identification — face recognition in a crowd, fingerprint matching against a database of unknowns, voice identification against a database. Not one-to-one verification (scanning your face to unlock your phone — that’s out). Biometric categorization by sensitive attributes outside the prohibited contexts. Emotion recognition outside the workplace and education contexts that Article 5 (prohibited practices) already bans.

The prohibited practices article covers what’s banned. Point 1 of Annex III. catches what isn’t banned but is still high-risk.

6. - 8. Law enforcement, migration, and justice

Three areas that primarily affect public authorities and their vendors.

Law enforcement: AI systems assessing victim risk, functioning as polygraphs, evaluating evidence reliability, assessing re-offending risk (not solely based on profiling — that’s prohibited), and profiling during criminal investigations. These are high-risk only when used by or on behalf of law enforcement. The same technology used privately falls under different rules.

Migration and border control: AI polygraphs, risk assessment for visa and entry applicants, travel document verification, and examination of asylum and visa applications.

Justice and democracy: AI systems assisting judicial authorities in researching, interpreting, and applying law. And AI systems intended to influence election outcomes or voting behavior — but not campaign logistics tools.

For most corporate readers, these three areas are relevant primarily if you’re a vendor selling to government agencies. But if you are — every system in these categories carries high-risk obligations, and the conformity assessment for some (particularly biometric systems in law enforcement contexts) requires third-party review by a notified body, not just self-assessment.

The Real Problem — “Intended Purpose” Isn’t What You Think

The entire classification system hinges on intended purpose. And intended purpose under the EU AI Act isn’t just what you wrote in the product documentation.

Article 3(12) defines it as:

‘intended purpose’ means 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.

And then Article 3(13) adds a companion concept:

‘reasonably foreseeable misuse’ means 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.

This means your marketing materials inform the classification. Your sales team’s pitch informs the classification. If a sales deck describes the system as a “talent analytics” tool — its intended purpose includes employment decisions, regardless of what the technical documentation calls it.

And if the system is designed for one purpose but foreseeably used for another — the foreseeable use can trigger high-risk classification. A general-purpose analytics platform marketed to HR departments? Even if you technically label it “business intelligence,” the foreseeable use is employment-related decision-making.

The multi-purpose trap

What happens when a single system has multiple use cases — some high-risk, some not? The AI Act doesn’t give you a clean answer.

The practical approach: if the system is capable of and marketed for a high-risk use case, it’s high-risk — even if it also does non-high-risk things. You can’t escape classification by bundling a high-risk feature into a larger product with mostly minimal-risk functions.

But you might be able to architect the system so the high-risk use case is clearly separated — a distinct module or service. That’s an architectural decision with legal consequences, and it needs to be made early. Not after the system is built. Not after the auditor asks.

The deployer who became a provider

Once you know a system is high-risk, the next question is: are you the provider or the deployer? The distinction determines which set of obligations you carry — and the line between the two is less stable than most companies assume.

Under Article 25, a deployer can become a provider by (a) rebranding a system, (b) making a substantial modification, or — the one that catches people — (c) changing the intended purpose. A company buys a general-purpose AI model and uses it for credit scoring. The model provider never intended that use. But the deployer just changed the intended purpose — and stepped into the provider’s shoes with all the heavier obligations that come with them.

Classification doesn’t end at “high-risk.”

It continues to “high-risk — and in what role?”

What Happens When Your AI System Is High-Risk

Classification as high-risk is where the compliance work starts — and the obligations are the reason the classification matters so much. The deep dive on each obligation is a future article. But you need the overview now.

• A risk management system — not a one-time assessment but a continuous, iterative process spanning the system’s lifecycle.

• Data governance requirements — your training data needs to meet quality criteria, and you need to demonstrate it.

• Technical documentation — comprehensive, drawn up before market placement, covering everything from system design to performance metrics.

• Automatic logging — an audit trail of what the system did and when.

• Transparency obligations toward deployers (if you are the provider) — enough information that the humans using the system can actually interpret its output.

• Human oversight — the system must be designed so humans can effectively monitor it, override it, and shut it down.

• Accuracy, robustness, and cybersecurity requirements throughout the lifecycle.

• Conformity assessment — before the system reaches the market. For most Annex III systems, that’s a self-assessment. For some — particularly biometric identification systems — it requires a third-party notified body.

• Then CE marking.

• Then EU database registration.

The penalty for non-compliance with high-risk requirements is up to €15 million or 3% of global turnover. Not as high as the prohibited practices ceiling — but not the kind of number that disappears in a quarterly business report.

The Timeline Problem

If you’re reading this and thinking “when do I need to have all of this done?” — the honest answer is: it depends on which version of the timeline you’re following.

The original deadline for high-risk obligations on Annex III systems was 2 August 2026. That’s the date in the AI Act as published.

Then reality intervened. The technical standards that companies need — the benchmarks that tell you what “compliant” actually looks like for risk management, data governance, documentation, and the rest — weren’t ready. CEN and CENELEC, the European standardization bodies tasked with developing them, missed their fall 2025 deadline. The Commission guidelines on high-risk AI systems, which were supposed to include practical examples of high-risk and non-high-risk systems, were due by 2 February 2026. The Commission missed that deadline too.

So in November 2025, the Commission proposed the Digital Omnibus on AI — a targeted amendment pushing the high-risk deadline to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I product-embedded systems. The European Parliament’s IMCO and LIBE committees adopted their joint report in March 2026. Trilogue negotiations between Parliament, Council, and Commission are underway.

As of May 2026, we are still waiting for the final Commission guidelines on high-risk AI system classification. The guidelines that were supposed to include the very examples companies need to resolve edge cases like the one you were staring at after that meeting — the ones that would clarify whether a credit-scoring decision-support tool with human oversight is high-risk or not. Those guidelines don’t exist yet.

Which leaves companies in an uncomfortable position. The classification is already consequential — even before the full high-risk obligations kick in — because you need time to build the compliance infrastructure. Risk management systems, documentation, data governance processes — these aren’t things you implement in a quarter. If you wait for the guidelines and the guidelines arrive six months before the deadline, you’re already behind.

The prudent approach: classify now, based on the text of Article 6 and Annex III. Build the compliance structure. And be prepared to adjust when the guidelines finally arrive.

The Classification Exercise — What to Do

You’ve read the law. You understand the two pathways, the eight areas, the escape hatch, the profiling kill-switch, the intended purpose trap. Now you need to turn that into something your company can act on.

Start with an inventory. Every AI system your company builds, deploys, or procures. Not just the ones your IT team calls “AI” — the ones that meet the Article 3(1) definition. The vendor tools with AI features embedded. The model your data science team fine-tuned. The chatbot someone in marketing set up without telling anyone. You can’t classify what you haven’t mapped.

Run each system through the decision tree. Is it in scope? Is it prohibited? Does it fall under Annex I (product safety pathway) or Annex III (standalone pathway)? If Annex III — which area and which specific use case? Be precise. “It’s an HR tool” isn’t a classification. “It screens job applications using machine learning, which falls under Annex III, Point 4(a) — recruitment and selection” is.

Don’t skip the intended purpose analysis. Pull the marketing materials. The sales deck. The vendor’s product description. The internal documentation about how the system is actually used — not how it was originally purchased. If there’s a gap between the vendor’s intended purpose and your actual use, that gap is where Article 25 (and your role as a provider or deployer) lives. A system bought for analytics and used for credit decisions isn’t an analytics tool anymore.

Assess Article 6(3) exceptions honestly — and document it either way. If you think the escape hatch applies, write down why. Which of the four conditions is met? Does the system profile natural persons? (If it evaluates personal data to assess any aspect of a person’s life — it almost certainly does.) Does it materially influence decision-making? Be honest. “A human reviews the output” isn’t enough if the human rubber-stamps the AI’s recommendation 95% of the time. If Article 6(3) doesn’t apply — document that too. The assessment matters regardless of the conclusion.

Figure out your role. For every high-risk system — are you the provider or the deployer? Did you build it? Did you modify it? Did you retrain it on your own data? Did you change what it’s used for? If you’re unsure, read the provider vs. deployer analysis before answering. The obligations are different enough that getting this wrong changes everything.

Start the compliance build now. If you have systems that are clearly high-risk — and after going through Annex III, most companies will find at least one — don’t wait for the guidelines, or the final Digital Omnibus timeline. Risk management systems, technical documentation, data governance processes, human oversight design — these take months to build properly. Starting late is a choice. It’s just not a good one.

Put legal and engineers in the same room. This cannot be a legal-only exercise. Legal can’t assess whether a system falls under Annex III without understanding what the system actually does. Engineers can’t assess whether “intended purpose” creates a classification risk without understanding what Article 3(12) requires. The classification has to be joint — and it has to be documented.

Subscribe now

Back to You

You’re still at your desk. The meeting notes are still open. The system architecture diagram is still on your second screen.

You know three things now that you didn’t know an hour ago:

1. The system almost certainly falls within Annex III, Point 5(b) — creditworthiness evaluation.

2. The Article 6(3) escape hatch almost certainly doesn’t apply — the profiling kill-switch alone closes that door.

3. And the fact that a human reviews every output doesn’t make the system not high-risk. It means the human oversight requirement under Article 14 might be partially met. It doesn’t change the classification.

You also know that nobody on the project team — not the IT lead, not the business sponsor, not the procurement team that selected the underlying model — has considered any of this.

Eight months of development. Budget approved. Timeline set. And the compliance question that determines whether this system can legally operate in the EU is being asked for the first time on a Tuesday afternoon by the one person in the room who happened to have read Article 6.

You open a new email. Subject line: “AI Act classification — we need to talk about the credit scoring tool.”

Better late than never.

Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.