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.

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.

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.

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.

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.

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.

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

a month 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.

Closing

Engineers can show what the system did.

Lawyers can explain why it matters.

AI governance needs both rooms talking to each other.

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, at 4:30 in the morning, 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 — and national authorities have had the power to enforce them since August 2025. AI literacy obligations kicked in on the same February date, with enforcement beginning August 2026. Transparency obligations still land in August 2026. The omnibus gave you more time on one thing. The rest didn't move.

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

A note on sources: The full text of the provisional agreement isn’t public yet. Everything in this article — and in every law firm alert and media analysis published since May 7 — is based on the Council’s press release, the European Parliament’s legislative documentation, and secondary analysis. I’ve cross-checked across multiple sources and flagged where things are uncertain. But until the full text drops, treat the details with the care you’d give any legal analysis built on a press release rather than a regulation. I’ll update this piece when the text is published.

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 after 12 hours of talks. 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.

The omnibus still needs formal adoption by both the Parliament and Council, legal-linguistic revision, and publication in the Official Journal. The co-legislators intend to finish all of that before August 2, 2026 — the date the original high-risk deadline would otherwise kick in. Tight timeline. Strong political will. Nobody wants to be the reason it slips.

What the omnibus is not: a repeal. The EU AI Act’s core architecture is intact. The prohibited practices aren’t touched. The GPAI rules aren’t touched. The transparency obligations aren’t touched. What moved is the high-risk timeline and the enforcement architecture around it.

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. Social scoring, manipulative AI, real-time remote biometric identification (with exceptions), emotion recognition in workplaces and schools, untargeted scraping for facial recognition databases. Applicable since February 2025. National enforcement powers followed in August 2025. Penalties: up to EUR 35 million or 7% of global annual turnover, whichever is higher.

Article 4 — AI literacy. The obligation to ensure your staff understands the AI systems they’re working with. Also in force since February 2025. Enforcement begins August 2026 — three months from now. If you’ve been treating this as a future problem, it isn’t one.

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, Scientific Panel, 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, etc. The omnibus carved out the high-risk obligations. It left everything else.

What Moved & The Actual Changes

December 2, 2026 — new:

Two things land here, and one of them is new.

The nudification and CSAM ban. A new addition to Article 5’s list of prohibited practices. AI systems used to generate child sexual abuse material or non-consensual intimate imagery are prohibited — including systems placed on the market without reasonable safety measures to prevent that use. Penalty tier is the highest one. EUR 35 million or 7% of global turnover. This isn’t a delay. It’s a tightening. While everything else in the omnibus is about giving industry more time, this one moved in the opposite direction.

Watermarking obligations. Providers must implement marking of AI-generated content. The grace period for systems already on the market was reduced from six months to three.

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, not 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 made every compliance officer’s calendar just shift by 16 months.

August 2, 2028 — delayed from August 2, 2026:

High-risk obligations for Annex I systems — AI embedded in products regulated by other EU sectoral safety legislation. Medical devices. In vitro diagnostics. Aviation. Motor vehicles. Railway systems. Marine equipment. Machinery. Toys. Radio equipment. This is eight months after the Annex III deadline.

These are fixed dates. You can plan around them.

Other changes worth knowing:

National regulatory sandboxes — deadline for Member States to establish at least one pushed from August 2026 to August 2027. A new EU-level sandbox operated by the AI Office, with priority access for SMEs, startups, and small mid-caps.

SME privileges extended to small mid-cap companies (up to 750 employees, with turnover and balance sheet ceilings — exact thresholds to be confirmed from the final text). Simplified documentation. Proportionate quality management. Tailored penalty caps.

The machinery carve-out — the issue that collapsed the first trilogue. AI systems in machinery products no longer face double compliance (AI Act + Machinery Regulation). They comply with the Machinery Regulation only. But this carve-out is limited to machinery. Medical devices, lifts, radio equipment — still dual compliance.

The EU high-risk database registration obligation — reinstated. The Commission had proposed to remove 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.

The updated timeline

Feb 2, 2025 — Prohibited practices (Art. 5) + AI literacy (Art. 4) — already in force

Aug 2, 2025 — GPAI obligations + governance + national authority designation — already in force

Aug 2, 2026 — Transparency (Art. 50) + enforcement begins + GPAI enforcement — unchanged

Dec 2, 2026 — Nudification/CSAM ban + watermarking — NEW

Aug 2, 2027 — GPAI legacy compliance + national sandbox deadline — sandbox delayed 1 year

Dec 2, 2027 — High-risk: Annex III (biometrics, employment, education, law enforcement…) — DELAYED

Aug 2, 2028 — High-risk: Annex I (AI in regulated products — medical devices, machinery…) — DELAYED

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 (classified by use case) hit December 2, 2027. Annex I systems (AI embedded in regulated products) hit August 2, 2028. That’s an eight-month gap. If your AI systems span both categories, 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 start enforcing in August 2026. But the high-risk obligations — the most substantial compliance requirements in the entire Act — just moved to 2027 and 2028. So what are regulators actually doing from August 2026?

Enforcing the prohibited practices. AI literacy. Transparency obligations. GPAI compliance (primarily the AI Office). That’s lighter than the full high-risk regime — but it’s real. If you’ve been ignoring AI literacy because you were focused on the high-risk deadline, August 2026 is still your problem. Regulators will ask what you’ve been doing since February 2025. Fifteen months of nothing is not a defensible answer.

The permission to procrastinate. This is 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 deprioritise will be scrambling again in 18 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 actually ready.

The One Thing That Got Tighter

While everything else in the omnibus is about giving industry more time, the nudification ban went the other direction. A new prohibited practice. Added to Article 5. Effective December 2, 2026.

It covers AI systems designed to generate CSAM, AI systems that create non-consensual intimate imagery of identifiable persons, and — critically — AI systems placed on the market without effective safety measures to prevent that use. That third prong matters. It means GPAI model providers need content safeguards robust enough to qualify. What “effective safety measures” means in practice isn’t defined yet. But the penalty tier is the maximum one.

Worth remembering — the next time someone tells you the omnibus is just about deregulation.

The Political Context

More than 127 civil society organisations — including Amnesty International, European Digital Rights, the European Disability Forum, and the European Network Against Racism — opposed the omnibus.

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

The Commission’s counter-argument is practical: harmonized standards aren’t ready, and companies can’t comply with rules when the measurement tools don’t exist. Both positions are legitimate. Both are worth knowing.

What to Do Now

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

Been ignoring AI literacy? That’s your most immediate problem. Enforcement starts August 2026. Three months from today.

GPAI model providers have a near-term clock — nudification safeguards by December 2026. AI Office enforcement powers from August.

Mid-size companies under 750 employees should check whether they qualify for the new small mid-cap category. Simplified documentation. Lighter compliance. Worth knowing before you build the full-scale programme.

And if you’re not sure whether your AI system is even high-risk — start there. The classification question determines everything else. The omnibus didn’t change the classification rules. Just the deadline for complying with what follows.

The AI Act is 21 months 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.

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.

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.

Someone at your company bought an AI tool.

Maybe it was the marketing team — a content assistant, a campaign optimizer, something with “AI-powered” in the tagline that justified a budget nobody would have approved two years ago. Maybe it was HR — a screening tool that promises to save 40 hours per hiring cycle. Maybe your developers just started using Copilot and nobody told compliance.

And then someone — you, probably, because these things always land on the same desk — asked the question that changes the meeting: “Do the people using this actually understand what it does?”

Not the features. Not the sales pitch. Do they understand what the system is doing with its inputs? Do they know when the output might be wrong? Do they know what the company’s legal obligations are now that they’re using it?

Silence.

Since 2 February 2025, that silence has been a legal problem.

Subscribe now

The Shortest Obligation with the Longest Reach

The entire AI literacy obligation of the EU AI Act lives in one sentence of Article 4:

Providers and deployers of AI systems shall take measures to ensure, to their best extent, a sufficient level of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf, taking into account their technical knowledge, experience, education and training and the context the AI systems are to be used in, and considering the persons or groups of persons on whom the AI systems are to be used.

One sentence. No subparagraphs. No delegated acts. No annexes. If you printed the entire AI Act’s high-risk AI requirements and then printed Article 4, one of them would be a binder and the other would be a Post-it note.

That one-sentence treatment has made everyone underestimate it.

Three things make Article 4 different from almost every other obligation in the AI Act:

It already applies. Not in August 2026 with the high-risk requirements. Not in 2027 with the extended deadline. February 2025. If you’re reading this in April 2026, you’ve been subject to this obligation for 14 months. Surprise.

It applies regardless of risk level. Article 4 doesn’t care whether your AI system is high-risk, limited-risk, or minimal-risk. Every AI system in the Act’s scope triggers this obligation. Your chatbot. Your translation tool. Your AI coding assistant. The thing the intern installed last Tuesday. All of them. The only systems that escape are those outside the Act’s scope entirely — military use, purely personal use, R&D before market deployment.

And it reaches everyone your AI touches. Not just employees. Contractors. Consultants. Outsourced teams. Anyone “dealing with the operation and use of AI systems on your behalf.”

What the Commission Said — and What It Left to You

In 2025, the European Commission published a Q&A on AI Literacy — the most concrete guidance available on what Article 4 means in practice. It didn’t get the attention of the prohibited practices guidelines or the AI system definition guidelines. It should have.

The Q&A sets a tone. Flexible, not prescriptive. No mandatory certifications. No required training hours. No pass/fail tests. The AI Office says it “does not intent to impose strict requirements” regarding what counts as a “sufficient level” of AI literacy.

If you just exhaled with relief — hold that breath a moment longer.

Because the Q&A also says that the choice not to train staff will be “closely scrutinised, and likely viewed negatively, by regulators, customers and other stakeholders.” You can argue about what kind of training. You can argue about how much. You cannot argue that training is unnecessary.

The minimum floor the Commission outlines:

Ensure a general understanding of AI within the organization.
What is AI? How does it work? What AI systems do we use? What are the risks?

Consider the role of the organization.
Provider or deployer? The obligations differ. A company building AI systems needs a different literacy profile than one using off-the-shelf tools.

Identify and communicate risks specific to the AI systems in use.
Staff need to know what can go wrong — and what to do when it does.

Tailor the program to the people and the context.
A data scientist and a claims handler don’t need the same training. Article 4 says so explicitly — “taking into account their technical knowledge, experience, education and training.”

One more thing the Q&A clarifies.

There is no obligation to measure your employees’ AI knowledge. No mandatory testing. No certification requirements. You don’t have to quiz your head of sales on the definition of a neural network. But documentation of what training was provided matters — because when supervisory authorities start enforcement in August 2026, AI literacy programs (or the absence of them) will be among the first things they examine.

Three Tiers — Not One Box to Check

“Train your staff on AI.” That’s what most compliance summaries tell you. As if you could buy a single e-learning course, push it to the entire organization, and file the receipt.

The regulation is more specific than that — and, for once, more reasonable.

Article 4 builds in a proportionality test through its qualifying language: “taking into account their technical knowledge, experience, education and training and the context the AI systems are to be used in.” That’s not a uniform standard. That’s a signal — different people need different things.

Recital 20 makes it explicit. The “notions” required for AI literacy “may vary with regard to the relevant context” and can include understanding technical elements during development, measures during use, how to interpret AI output, and — for people subjected to AI decisions — how those decisions will impact them.

Germany’s Bundesnetzagentur — the designated national market surveillance authority — published guidance in June 2025 recommending a three-stage approach. The Commission’s Q&A acknowledges that “having different levels of training or learning approaches can be appropriate.”

Put these together and the shape is clear. Three tiers.

Tier 1 — General AI awareness. Everyone.

This is the floor. Every person in the organization — from the CEO to the receptionist to the warehouse worker — needs a baseline:

What AI is and, at a conceptual level, how it works. Which AI systems the organization uses. That the organization has legal obligations around AI. What to do if they encounter something unexpected — who to escalate to. The basic opportunities and risks.

This isn’t a 40-hour course. It could be an annual e-learning module. An internal policy document everyone reads and signs off on. A town hall where at least some people are paying attention. The format matters less than the fact that it exists and that you can prove it happened.

Tier 2 — Role-specific competence. People who work with AI systems.

Anyone who operates, manages, or makes decisions based on AI output needs more.

Understanding how the specific AI systems they work with function — not at code level, but practically. What the system does. What data it uses. What its limitations are. When it might be wrong. The risks specific to those systems. The ability to interpret AI outputs correctly — including knowing when to distrust the output. And what to do when something doesn’t look right.

The HR coordinator using an AI screening tool needs to know what the system evaluates, what it misses, and when human judgment should override it. The loan officer reviewing an AI credit recommendation needs to understand the model’s inputs and limitations — not because they’re a data scientist, but because they’re making decisions that affect people’s mortgages.

Tier 3 — Specialised competence. Human oversight.

Article 14(5) of the AI Act requires that natural persons assigned to human oversight of high-risk AI systems have the “competence, training and authority” to effectively perform that role. Not “awareness.” Not “familiarity.” Competence. They must be able to properly understand the system’s capabilities and limitations. Monitor its operation and detect anomalies. Be aware of automation bias — the tendency to over-rely on AI output. Correctly interpret the system’s output. And have the authority to override or disregard it when necessary.

Article 4 is the foundation. Article 14 is the superstructure. You cannot comply with human oversight requirements if your oversight personnel lack AI literacy.

This matters because the real enforcement risk for AI literacy isn’t a standalone Article 4 fine. It’s what happens when a high-risk AI system causes harm and the investigation reveals that the person assigned to human oversight didn’t understand the system well enough to oversee it. At that point, Article 4 non-compliance becomes evidence of Article 14 non-compliance — and the penalty exposure jumps from a training gap to a systemic governance failure.

Who falls into Tier 3: the senior underwriter serving as human-in-the-loop for AI-assisted insurance decisions. The radiologist overseeing AI diagnostic imaging. The safety engineer monitoring AI in critical infrastructure. The compliance officer responsible for an AI system that makes decisions affecting people’s rights.

These people need deep, system-specific knowledge. Known failure modes. Confidence levels. Conditions under which the system should be stopped. Documentation and incident reporting requirements. This isn’t an e-learning module. This is dedicated, ongoing, system-specific training — and the ability to prove it.

What This Looks Like in Practice

First Scenario - The insurer

An insurance company uses AI for claims processing — a fraud detection model that flags suspicious claims and a machine learning system that assists underwriters with risk assessment.

Tier 1 is straightforward. Everyone in the company — from reception to the CEO — gets an annual briefing on the company’s AI use, its obligations, and basic AI literacy. An e-learning module. Internal communications about the AI policy.

Tier 2 is the one that will take work. The claims team needs to understand that “flagged” means a probability score — not a verdict. They need to know the system’s false positive rate. They need to know what to do when they disagree with the system’s output. The underwriters using AI-assisted risk assessment need to understand the model’s inputs, its limitations, and the circumstances under which they should override the recommendation. This isn’t optional training. This is the minimum for people making decisions based on AI output every day.

Tier 3 applies to the senior underwriter serving as human-in-the-loop. They need Article 14-level competence: understanding automation bias, knowing the system’s failure modes, having the authority and knowledge to override it, and understanding what triggers an incident report.

And there’s a dimension most insurers won’t think about on their own. The affected persons — policyholders whose claims are processed by AI. Article 4 doesn’t create a direct obligation to train your customers. But internal AI literacy needs to be sufficient that staff can explain AI-assisted decisions to policyholders who challenge them. That connects to transparency obligations under Article 50 — and to the practical reality that someone will ask “why was my claim denied?” and the answer can’t be “the algorithm said so.”

Second Scenario - The 30-person e-commerce company

A small company. Shopify’s AI-powered product recommendations. ChatGPT for customer service drafts. An AI accounting tool. They didn’t build any of this. Pure deployers.

What they think: We just use tools. AI literacy isn’t our problem.

What the law says: they’re deployers. Article 4 applies.

What “to their best extent” looks like for a company this size: an internal AI use policy — one document listing which AI tools are in use and the basic rules for using them. A team briefing. Making sure the marketing manager using ChatGPT knows about hallucination risks. Making sure the customer service team understands the limits of AI-generated responses before sending them to customers.

This company doesn’t need a three-tier training program with a dedicated AI literacy officer and a quarterly assessment cycle. But it needs something documented and demonstrable. A written policy. A record that the conversation happened. Evidence that people know what they’re using and what can go wrong.

The bar is lower. It is not zero.

Third Scenario - The startup building an AI product

Five people. All technical. Building an AI-powered legal research tool for law firms.

Their AI literacy gap is the opposite of what you’d expect. They understand transformers and embeddings. They can explain attention mechanisms over coffee. Their technical AI knowledge is deep.

Their regulatory AI literacy might be zero. They can build an AI system. They cannot tell you what Article 6 says about it.

As a provider, they need to understand what obligations attach to their product. That the AI Act requires specific documentation. That the system will need instructions for use. That their customers — law firms deploying the tool — will have their own obligations under the Act, and the startup’s product needs to support those obligations.

“To their best extent” here means documented internal policies on AI Act compliance. Evidence that the team has studied the relevant obligations. Someone assigned to regulatory responsibility — even if it’s the co-founder spending Saturdays reading guidance documents. Training doesn’t need to be a formal program. But the knowledge needs to exist. And it needs to be demonstrable.

The Third Group in the Definition — Affected Persons

The definition of AI literacy in Article 3(56) covers three groups: providers, deployers, and affected persons. The people on the receiving end of AI decisions.

Article 4 itself only imposes the obligation on providers and deployers regarding their staff. But Recital 20 goes further — affected persons need “the knowledge necessary to understand how decisions taken with the assistance of AI will have an impact on them.”

Wait — does that mean I have to train my customers?

No. Not directly. But it creates an expectation. And it connects to transparency obligations elsewhere in the Act — particularly Article 50, which requires deployers to inform people when they’re interacting with certain AI systems.

The practical implication: your internal AI literacy program needs to be good enough that your staff can explain AI-assisted decisions to the people affected by them. The patient who asks how AI influenced their diagnosis. The job applicant who wants to know why they were screened out. The policyholder disputing a claim decision.

If your staff can’t explain it — because they don’t understand it themselves — you have both an AI literacy problem and a transparency problem. They compound.

Penalties and the Aggravating Factor

The penalty tier for Article 4 violations falls under Article 99 — likely up to €15 million or 3% of total worldwide annual turnover, whichever is higher. I say “likely” because the exact tier applicable to Article 4 is not perfectly clear from the penalty structure.

However, nobody is getting fined €15 million because their training program was weak. That’s not how this plays out.

The scenario regulators are actually preparing for is different.

A high-risk AI system causes harm. An investigation follows. The regulator discovers that the deployer’s staff didn’t understand the system’s limitations. Didn’t know how to interpret its outputs. Didn’t recognise the risk signals. The regulator asks: what AI literacy measures did you have in place?

If the answer is “none” or “a generic webinar from 2025 that nobody remembers” — that absence of literacy becomes evidence of broader non-compliance. It amplifies the penalty for the primary violation.

Article 4 doesn’t bite on its own. It bites when something else goes wrong — and it proves the failure was systemic.

Enforcement Timeline — the Gap You Should not Misread

2 February 2025 — Article 4 started to apply.

2 August 2026 (if not postponed) — national market surveillance authorities begin supervising and enforcing.

That 18-month gap between obligation and enforcement is not a grace period in the “you can ignore this until August” sense. It’s runway. The Commission gave organizations time to build programs before inspections begin.

Germany has already designated the Bundesnetzagentur as its supervisory authority. It published guidance. It set up an AI Service Desk. Other Member States are at different stages — which means enforcement intensity will vary across the EU, at least initially.

But the question a supervisory authority will ask in August 2026 is not “do you have a program now?” It’s “what have you been doing since February 2025?” Fourteen months of doing nothing is not a defensible answer.

What to Do — Practically

You have at least until August 2026 before enforcement starts. But that’s not a lot of time if you’re starting from nothing. However, Article 4 doesn’t ask for perfection. It asks for measures taken “to your best extent.” Demonstrable, proportionate, real.

Start with an inventory. Which AI systems does your organization use? Who uses them? In what context? You can’t build a literacy program around tools you haven’t mapped. This is also the exercise that feeds risk classification under Article 6 — so it’s not wasted work.

Identify your tiers. Not everyone needs the same training. Sort your people into the three categories — general awareness (everyone), role-specific competence (people working with AI daily), and specialised oversight (human-in-the-loop roles under Article 14). The Commission’s Q&A supports this approach explicitly.

Build the floor first. General AI awareness for the entire organization. What AI is. Which systems you use. What the risks are. What to do if something looks wrong. This can be an e-learning module, an internal policy document, a briefing — whatever fits your size. The format is flexible. The fact that it happened needs to be documented.

Then go deeper for the people who need it. Role-specific training for anyone operating AI systems or making decisions based on AI output. What the system does. What it can’t do. When to distrust it. What to do when something doesn’t look right. For high-risk AI with human oversight requirements, this becomes Article 14-level competence — and that standard is higher than a training session.

Write it down. The AI Act doesn’t prescribe documentation formats for Article 4. But when a supervisory authority asks what you’ve done, “we had some conversations” is not an answer. A written AI literacy policy. Training records — who was trained, when, on what. An internal AI use policy listing your tools and the rules for using them. Evidence that the program evolves as your AI use changes.

Check what your providers give you. If you’re a deployer, your AI literacy depends partly on the information your providers disclose — instructions for use, capabilities, limitations. If the documentation is thin, your ability to train your staff on that system is compromised. That’s a conversation worth having with your vendors before the regulator has it with you.

The Foundation That Makes Everything Else Work

There’s a reason Article 4 applies before almost everything else in the AI Act.

Risk classification requires someone who understands what the AI system does well enough to assess which Annex III category might apply. Conformity assessment requires people who can prepare and review technical documentation. Human oversight — Article 14 — explicitly requires competence and training. Transparency obligations require understanding what the AI actually does before you can tell anyone else about it. Post-market monitoring requires identifying issues. Incident reporting requires recognising when a serious incident has occurred.

Every single one of those obligations assumes that the people doing the work understand what they’re working with. Article 4 is that assumption, written into law.

AI Literacy will never headline a conference panel. It won’t generate breathless LinkedIn posts or €50K consulting proposals. It sits there — one sentence, one article — doing the structural work of making everything else in the regulation possible.

A company that gets AI literacy right will find the rest of the AI Act manageable. A company that skips it will find every other obligation harder, every assessment shallower, every oversight function weaker.

The regulation gives you flexibility on the how. Not on the whether.

Fourteen months are already gone. The people using AI in your organization — right now, today, across every department and every risk level — either understand what they’re working with, or they don’t.

That’s the question. Not whether you need a program. Whether the one you have is enough.

I was reviewing a contract last month.

A mid-sized bank licensing an AI-powered credit scoring system from a fintech vendor.

Standard setup. The vendor builds it, the bank uses it. Clean.

Then I got to the section on customization.

The bank’s data science team had been training the model on the bank’s own lending data. Five years of loan applications, defaults, repayments.

They’d also adjusted some of the decision thresholds. And someone — probably an ambitious junior data scientist — had integrated an additional ML component that post-processes the vendor’s output before it reaches the credit committee.

The contract called the bank a “deployer”.

I sat there thinking — are you, though?

Subscribe now

If you’ve worked through GDPR, the exercise will feel familiar. Controller or processor? You had to figure out your role before you could figure out your responsibilities. The answer determined which obligations applied, how much documentation you needed, and what happened when something went wrong.

The AI Act follows the same logic. Different terms — provider and deployer instead of controller and processor — but the same structural question: what is your role in relation to this AI system, and what follows from it?

The consequences, though, are not the same. Under GDPR, both controllers and processors carry real obligations. Under the AI Act, the gap between provider and deployer is enormous. A deployer’s obligations fit on one page — use the system properly, keep humans in the loop, tell people when AI is making decisions about them. A provider is responsible for the system itself — its design, its documentation, its conformity assessment, its safety. That’s not a difference in degree. That’s a different job.

And your role can change. You can start as a deployer and end up as a provider — not because you decided to be one, but because of what you did with the AI system.

The Definitions

The AI Act defines both roles in Article 3.

A provider is 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. Two things matter: developing (or commissioning the development), and putting your name on it.

A deployer is a person or entity using an AI system under its authority. That’s it. You use the AI system. You didn’t build it. You’re not selling it. You’re operating it.

On paper, the line is clean. One builds, one uses.

In practice, companies buy AI systems and then customize them, train them on proprietary data, integrate them into larger pipelines, repurpose them for new use cases. The neat definition breaks down the moment real business happens to it.

Three Triggers That Make You a Provider

Article 25. “Responsibilities along the AI value chain.” Sounds like the title of a slide deck nobody wants to sit through. What it actually does: define the three moments when a deployer becomes a provider.

Three triggers. Any one is enough.

You put your name on it. You buy a high-risk AI system from a vendor. You rebrand it. Call it yours. Put your trademark on the interface. From the outside world, it looks like your product. Under the AI Act, it now is your product — even if you didn’t change a line of code.

You substantially modify it. You change a high-risk AI system in a way that wasn’t foreseen in the original conformity assessment — and that change affects compliance or intended purpose. You just became the provider.

You repurpose it into high-risk. You take an AI system that wasn’t classified as high-risk and use it for something that is. You didn’t touch the AI system itself. You just used it differently.

That third trigger is the one that is easy to miss. You don’t have to modify the AI system. You just have to use it wrong.

One Bank, Five Ways to Get It Wrong

Credit scoring.

One of the clearest high-risk use cases under the AI Act — Annex III, point 5(b), AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score. No ambiguity about the risk classification.

The only question is about the role. And it turns out there are at least five versions of that question — all sitting inside the same bank.

The simple version

The bank licenses a credit scoring AI system from a fintech vendor. Plugs it in. Follows the instructions. Doesn’t touch the internals.

Deployer. Article 26 obligations — operational stuff. Use the system according to instructions, assign competent people for human oversight, make sure the input data is relevant, inform applicants that AI is involved in the credit decision, cooperate with authorities if they come asking.

What the bank does not have to do: conformity assessment, CE marking, technical documentation, quality management system, registration as provider, post-market monitoring system. None of it.

That’s a comfortable position. Most banks want to stay there.

Few do.

The obvious version

The bank builds its own credit scoring model from scratch. Data science team trains it on the bank’s lending data, validates it, deploys it. The bank’s name is the only name on it.

Provider. Not because of Article 25 — this isn’t a transformation question. The bank developed an AI system and put it into service. That’s the definition, full stop.

Full provider obligations. Quality management system (QMS). Technical documentation per Annex IV. Conformity assessment before putting the system into service. EU declaration of conformity. CE marking. Registration. Automatic logging. Post-market monitoring. Serious incident reporting.

The list goes on. I’ll come back to the full comparison. But the gap between this and the deployer list isn’t incremental — it’s structural.

The version that keeps me up at night

The bank licenses a credit scoring system. The system is designed to be trained on the deployer’s data — that’s the product.

“Bring your own data” the vendor’s sales deck probably said.

The bank feeds in five years of lending history. The model learns the bank’s patterns. Parameters change. The model now behaves differently than the vanilla version.

Still a deployer?

Everything turns on one phrase in Article 3(23) — the definition of “substantial modification”: not foreseen or planned in the initial conformity assessment.

If the vendor’s conformity assessment explicitly accounted for retraining on deployer data — specified what kind of data, assessed how retraining affects performance, set guardrails — then the bank is likely still a deployer. Recital 128 backs this up: changes that were “pre-determined by the provider and assessed at the moment of the conformity assessment” are not substantial modifications. The vendor planned for this. The AI system was designed to be trained this way.

If the vendor didn’t account for it — if the sales team said “you can train it on your data” but the conformity assessment never assessed the impact of that retraining — the bank just made a substantial modification. Not foreseen. Affects accuracy, fairness, robustness. The bank is a provider.

The practical problem is that most vendor contracts and conformity assessments aren’t drafted with this level of specificity. Not yet.

Many vendors offer customization without formally assessing it in the conformity assessment. Which means many banks doing what feels like routine customization may already be providers without knowing it.

If that sounds like the early days of GDPR — when half the companies processing personal data didn’t know they were controllers — the parallel is intentional. Same logic. Same trap. Different regulation.

The version where it’s not even close

The bank doesn’t just train the model on new data. It modifies the architecture. Adds features. Changes the weighting logic. Adjusts decision thresholds beyond what the vendor’s instructions permit. Integrates an additional ML component that post-processes the output.

This was the bank in the contract I was reviewing. And no — there’s no grey zone here. Architecture changes, additional components, modified decision logic — none of this was foreseen in the vendor’s conformity assessment.

The bank is a provider. Probably has been since the first architecture change. It just didn’t notice.

The contract still said “deployer.”

The version you didn’t see coming

The bank licenses a general-purpose chatbot. Customer service tool. Not high-risk.

Then someone in the product team has an idea: use it to screen loan applicants, ask financial questions, feed the responses into the credit pipeline.

No code changed. No model retrained. Just a decision about how to use it.

The vendor’s intended purpose was customer service. The bank’s use — creditworthiness assessment — falls under Annex III. The system is now high-risk, and the bank is its provider under Article 25(1)(c).

A tool bought for one purpose, quietly repurposed for another. Nobody flagged it because nobody changed the system. But Article 25 doesn’t require you to change the system. It just requires you to change what you use it for.

Provider of What, Exactly?

When the bank crosses the line, a question follows that almost nobody answers clearly: does it become the provider of the entire system, or just the part it modified?

Article 25(2) says “the provider that initially placed the AI system on the market or put it into service shall no longer be considered to be a provider of that specific AI system.”

“That specific AI system.” Not “the modified portion of that AI system.” Not “the component the deployer changed.” The whole system. The original provider drops out entirely. The bank steps in.

My reading — and I want to be clear this is interpretation, because the Commission hasn’t addressed it explicitly — is that the bank becomes provider of the AI system as a whole. Full conformity assessment of the entire system. Full technical documentation. Full quality management coverage.

You can’t do a conformity assessment of half a system. When the bank changes the model’s architecture, the entire system’s compliance profile shifts — inputs, processing, outputs, everything.

One exception worth noting — for general-purpose AI models (not systems), the GPAI guidelines suggest the modifier’s obligations concern “the portion of the model that has actually been modified.” But that’s a different regulatory chapter, different rules. Don’t mix them up.

Now, Article 25(2) anticipated that this would be hard. The original vendor must cooperate with the new provider — hand over information, provide technical access, assist with conformity assessment. The bank needs to assess a system it didn’t fully build. The vendor has to make that possible.

Except — and this is where the regulation argues with itself — Article 25(5) says all of this cooperation is “without prejudice to intellectual property rights, confidential business information and trade secrets.” The bank needs access to comply. The vendor may resist on IP grounds.

The regulation creates the obligation in one paragraph and its own exception three paragraphs later. I’ll let you sit with that.

What Actually Changes When You Become a Provider

The list comparison tells the story faster than I can.

A deployer under Article 26: follow the provider’s instructions, assign competent humans for oversight, ensure input data is representative, inform people when AI affects their decisions, cooperate with authorities. Operational. Manageable.

A provider under Articles 16-21: quality management system covering design to post-market. Technical documentation per Annex IV — before the system goes live. Conformity assessment. EU declaration of conformity. CE marking. Registration in the EU database. Automatic logging capability built into the system. Post-market monitoring system. Serious incident reporting. Corrective actions when something goes wrong.

For a bank that was comfortably a deployer and becomes a provider because it fine-tuned a model too aggressively — the compliance burden doesn’t just increase. It transforms. The bank needs documentation it doesn’t have. A conformity assessment it wasn’t planning for. A quality management system covering AI-specific requirements it probably hasn’t built.

One sliver of relief. Article 17(3) allows financial institutions subject to EU financial services law to satisfy the quality management requirements through their existing internal governance. Banks already have governance structures under EU banking regulation. They don’t need to build a separate AI-specific QMS from scratch — they can adapt what exists. (One caveat: points (g), (h), and (i) of Article 17(1) — covering post-market monitoring, incident reporting, and communication with authorities — are excluded from this deemed-compliance provision. Those you still need to build.)

But “we already have governance” isn’t the same as “our governance covers AI Act QMS requirements.” Anyone who’s worked in banking compliance knows how far apart those two sentences can be.

And there’s no grace period. None. Article 25 triggers are immediate. The moment the bank makes a substantial modification, it’s a provider. Not “you have six months to figure it out.”

The bank should have completed the conformity assessment before putting the modified system into service. In practice, most banks won’t realize they’ve crossed the line until after they’ve deployed the modified system.

The fines reflect the stakes. Non-compliance with high-risk AI system obligations: up to €15 million or 3% of global annual turnover, whichever is higher.

The Questions I Can’t Answer Yet

A few things the regulation leaves open — and that the Commission’s still-pending guidance on substantial modification needs to address.

How specific does “foreseen” need to be? A generic “this system may be customized” in the vendor’s documentation — is that enough? How detailed does the foreseeability assessment need to be? Who bears the burden of proving it — the vendor claiming they foresaw everything, or the regulator saying they didn’t foresee this specific change?

What counts as “affects compliance”? Almost any modification to an ML model can theoretically affect accuracy, fairness, or robustness — all Chapter III requirements. If any performance change counts, then any customization is a substantial modification. If only material degradation counts, the regulation doesn’t say so.

Cumulative drift. Recital 128 says pre-determined continuous learning isn’t a substantial modification. Fine. But a system learning on the bank’s data will, over time, diverge from the version the vendor assessed. Each individual step is pre-determined. The cumulative result might not be. At what point does a series of small, foreseen changes become a material departure from the assessed system? Nobody knows.

Cooperation vs. IP. When the bank needs the vendor’s proprietary model architecture to perform a conformity assessment, but the vendor claims trade secret protection — what happens? The regulation doesn’t resolve this. And I suspect it will take actual litigation to draw the line.

The Exercise

Same logic as GDPR. Different stakes.

Map every AI system you use. For each one — are you the provider or the deployer? Have you modified it? How? Was that modification foreseen in the vendor’s conformity assessment? Can you prove it?

Check your vendor contracts. Do they address AI Act compliance? Do they specify what customization falls within the conformity assessment? Do they include the cooperation obligations Article 25(2) requires?

And if you’ve already modified a vendor’s system — already trained it on your data, already adjusted its parameters, already integrated it into a larger pipeline — you’re not looking at a future compliance question.

You’re looking at one that already triggered.

August 2, 2026. That’s the deadline for high-risk AI system obligations — at least, that’s the date in the AI Act as published. The Commission’s Digital Omnibus proposal, currently in trilogue, would push it to December 2027. But even if the deadline shifts, Article 25 doesn’t shift with it. The question of whether you’re a provider or a deployer isn’t waiting for a legislative amendment.

That question is already live.

There’s a moment — and if you work in compliance or risk, you’ve either had it or it’s coming — when someone in a meeting turns to you and says: “So, the AI Act. What do we need to do?”

And you sit there thinking — I barely finished the DORA implementation…

The regulation is 400+ pages. The guidance documents keep stacking up.

Every law firm in Europe has published an “alert” that somehow manages to create more questions than it answers.

And you — the person who already handles GDPR, maybe DORA, maybe NIS2, maybe all three on a good day — just got handed another regulation to figure out.

Because apparently regulatory compliance is like a hotel room minibar: there’s always room for one more.

The instinct is to start reading from Article 1 and work your way through. Don’t.

Start with Article 5. Start with the prohibited practices.

Not because they’re the most complex — they’re not. But because they carry the highest fines in the entire regulation: up to €35 million or 7% of total worldwide annual turnover, whichever is higher. And because they were the first provisions to take effect — 2 February 2025. While the rest of the AI Act rolls out in stages, the prohibitions are already live.

If any of your AI systems are doing something on this list, it doesn’t matter how far along you are with risk classification or documentation or conformity assessment. You have a problem that outranks all of those.

That’s the logic. Start with the biggest exposure. Work down from there.

Subscribe now

What the Commission Said — and What It Didn’t

The European Commission published Guidelines on Prohibited AI Practices on 4 February 2025. Over 100 pages. Non-binding, which means the Court of Justice of the EU has the final word on interpretation. But these guidelines are the Commission’s view of what each prohibition means, and they will shape how enforcement authorities approach these cases.

They clarify definitions, provide examples, and take positions on ambiguous questions. They’re useful. They’re also — in a way that’s becoming familiar with the AI Act — incomplete in exactly the places where you most need clarity.

But before we go through the eight practices, one thing. The single most important position in those 100+ pages. The one that changes how you should think about every AI system in your organization.

The Standard “We Didn’t Mean to” Is Not a Defense

Article 5 uses a specific formulation across multiple prohibitions: “with the objective or the effect of.”

That little word — “or” — is doing more work than most people realize.

Intent is not required. If an AI system has the actual effect of materially distorting someone’s behavior — even if nobody designed it to do that, even if the deployer didn’t know it was happening, even if the system sailed through every internal review — the prohibition applies.

The guidelines say it directly: the prohibition applies “even if the material distortion of a person’s behaviour occurs without the intent of the provider or deployer.”

The EU borrowed this approach from the Unfair Commercial Practices Directive. An effects-based standard. A deliberately low bar — designed to protect people regardless of what the company thought it was building.

You can build an AI system with the best intentions. Run bias audits. Hire a responsible AI team. Document everything. And if that system — in practice, in the real world, with real users — has the effect of manipulating behavior or exploiting vulnerable users, you’re in violation of Article 5.

“We didn’t mean to” is not a defence. “We had a governance framework” is not a defence. “Our vendor assured us it was compliant” is not a defence.

The effect is enough.

The Eight Prohibited Practices

1. Subliminal, manipulative, and deceptive AI techniques

Article 5(1)(a). An AI system that deploys subliminal techniques beyond a person’s consciousness, or purposefully manipulative or deceptive techniques, with the objective or effect of materially distorting behavior — appreciably impairing their ability to make an informed decision, causing them to take a decision they would not have otherwise taken, in a manner that causes or is reasonably likely to cause significant harm.

These are the key words: “Subliminal techniques” — imperceptible influences. Visual content flashed during video too fast for the conscious mind to catch. Audio signals below the threshold of awareness. “Material distortion” — borrowed from consumer protection law — means a substantial impact on behavior. Not mere influence. Manipulation.

The grey zone is enormous. Personalized advertising based on user preferences? The guidelines say that’s not inherently prohibited. But an AI system that dynamically hides cancellation buttons, generates artificial urgency, or adjusts scroll behavior in ways the user can’t perceive? Closer. Much closer. An adaptive checkout flow that increases pressure when it detects hesitation? That’s the territory where “personalization” starts looking like “manipulation” — and the only thing separating them is whether the effect materially distorts the user’s decision.

The Digital Services Act already targets manipulative design. Article 5(1)(a) extends the prohibition to AI-driven manipulation specifically. If your company has AI touching customer-facing products — and at this point, whose doesn’t — this is the one that deserves the longest look in the mirror.

2. Exploitation of vulnerabilities

Article 5(1)(b). An AI system that exploits vulnerabilities due to age, disability, or specific social or economic situation — same “objective or effect” standard, same requirement of material distortion and significant harm.

Three categories of vulnerability. Children and elderly (age). Physical or mental disability. Financial desperation or socio-economic disadvantage.

The guidelines give one example that’s worth sitting with: AI systems creating “personalized and unpredictable rewards through addictive reinforcement schedules.” Targeting the underdeveloped impulse control in children. Targeting cognitive decline in the elderly. Designed — or, remember, merely having the effect of — exploiting the people least equipped to resist.

This is where the cases stop being hypothetical.

France’s CAF system. Since 2010, France’s national social security agency has used an AI-driven risk-scoring algorithm to flag welfare fraud — affecting over 13 million households. The parameters that increase your score: low income, unemployment, living in a disadvantaged neighborhood, having a disability while working. The agency’s director confirmed they have never audited the model for bias or discrimination. In October 2024, Amnesty International and 14 coalition partners filed a complaint demanding the system be stopped. Source code obtained by investigators in 2023 exposed the design.

A system built to detect fraud. Scoring people higher for being poor, disabled, or living in the wrong neighborhood. The intent was fraud detection. The effect was systematic targeting of the most vulnerable people in the system. Under Article 5(1)(b) — you already know which word matters.

The Netherlands childcare benefits scandal. Dutch tax authorities used algorithmic profiling from 2013 to 2020 that classified non-Dutch nationals as “higher risk.” Tens of thousands of parents were wrongly accused of fraud. Benefits suspended. Families destroyed. A court ruled the system violated proportionality and privacy under the European Convention on Human Rights (ECHR). The political fallout was severe enough to bring down the Dutch government.

These aren’t edge cases from authoritarian regimes. These are European governments. Well-funded. Democratically accountable. And they built exactly the kind of systems that Article 5(1)(b) now prohibits.

3. Social scoring

Article 5(1)(c). An AI system that evaluates or classifies natural persons based on social behavior or personal characteristics, resulting in detrimental treatment that is either (1) in social contexts unrelated to where the data was collected, or (2) unjustified or disproportionate to the behavior assessed.

This is the one most readers will dismiss. We don’t do social scoring.

Read the cumulative requirements again. The prohibition isn’t about building China’s social credit system. It’s about what happens when a score travels.

A credit score based on financial behavior, used for lending decisions? Not social scoring under Article 5. That same credit score leaking into housing eligibility, school enrollment decisions, or employment screening? Now you’re in Article 5 territory. A customer loyalty score from a retail platform used to determine insurance premiums? Same problem.

The prohibition triggers when evaluation in one context produces detrimental treatment in an unrelated context — or when the treatment is disproportionate to the behavior being assessed.

For compliance teams, the question isn’t “do we score people?” Almost everyone does. The question is: where does the score travel? If the answer is “only within the context it was designed for, with proportionate consequences” — you’re likely fine. If the answer is “we’re not sure” — that’s the assessment you need to do.

France’s CAF system sits here too. A welfare fraud score — collected in the context of benefits administration — used to subject people to invasive investigations that affect their access to housing, childcare, and social services. One score. Multiple contexts. Disproportionate consequences.

4. Predictive policing

Article 5(1)(d). An AI system that assesses or predicts the likelihood of a person committing a criminal offense, solely on the basis of profiling or personality traits and characteristics.

“Solely” — that one word makes this a partial ban, not an absolute one.

“Personality traits and characteristics” gets a broad reading in the guidelines: gender, race, ethnicity, address, income, health, preferences, behavior, financial status. Non-exhaustive. AI systems that support human assessment based on objective, verifiable facts directly linked to criminal activity are still permitted — provided the human decision-maker actually relies on the assessment. Rubber-stamping an algorithmic output doesn’t count.

Geographic crime mapping — identifying high-crime areas from historical data — is not prohibited. It targets patterns, not people.

Here’s where it gets interesting. Geolitica (formerly PredPol), deployed in Plainfield, New Jersey. A predictive policing system that made over 23,000 crime predictions. Accuracy: less than 0.5%. The system is a case study in two things — the unreliability of person-based prediction, and the loophole built into Article 5(1)(d). Reframe person-based prediction as geographic analysis and you move from “prohibited” to “permitted.” Same underlying data. Different framing. Different legal outcome. The regulation bans predicting whether you will commit a crime. It doesn’t ban predicting whether a crime will happen near you. That distinction is thinner than it looks.

5. Untargeted facial image scraping

Article 5(1)(e). An AI system that creates or expands facial recognition databases through untargeted scraping of facial images from the internet or CCTV footage.

This is the hardest line in Article 5. An absolute ban. No exceptions. No law enforcement carve-out. No “but we really need it for security” path. Nothing. Of all eight prohibitions, this is the only one where even law enforcement gets no door to knock on.

“Untargeted” means indiscriminate mass collection not focused on specific individuals. “Scraping” means automated extraction using crawlers and bots. And the detail that matters: consent to posting images on social media does not equal consent for facial recognition databases. You put your photo on LinkedIn — that doesn’t mean a company can feed it into a facial recognition system. The guidelines are clear on this.

One more thing. Multiple targeted scrapes that incrementally build the same database still count as untargeted scraping. You can’t slice an ocean into cups and call each one a glass of water.

Clearview AI is the case that defines this category. A US company that scraped the internet to build a database of over 60 billion facial images. GDPR enforcement hit from four directions — Italy fined them €20 million in February 2022, France €20 million in October 2022, Austria issued a decision in 2023, and the Netherlands fined them €30.5 million in October 2024. Total: approximately €100 million in GDPR fines across four jurisdictions.

Under the AI Act, Clearview’s entire model is now explicitly a prohibited practice — not just a data protection violation, but a banned activity carrying up to €35 million or 7% of turnover.

The enforcement gap tells its own story. Those GDPR fines were imposed on a US company with no EU presence. Collection has been... let’s call it aspirational. Noyb went a different route — filing a criminal complaint against Clearview executives in Austria. If successful, that means personal liability for anyone who travels to Europe. The AI Act doesn’t solve cross-border enforcement. But it raises the ceiling on what happens when enforcement catches up.

6. Emotion recognition in workplace and education

Article 5(1)(f). An AI system whose purpose is to infer emotions of natural persons in a workplace or educational institution.

The scope is broader than most people expect. “Workplace” covers any setting where work is performed — including recruitment, hiring, temporary work, remote work. The prohibition applies from the moment someone is a job candidate. Not from day one on the job. From the application. “Educational institutions” means public and private, all levels, in-person and online, including admissions.

Two narrow exceptions. Medical — but only CE-marked medical devices for actual therapeutic purposes. Monitoring employee stress because HR wants a “wellness dashboard”? That’s not medical. Safety — but only for concrete risks to life or health. Construction workers at height. Pilots. Truck drivers on long shifts. A general interest in “employee wellbeing” doesn’t meet the threshold.

If you’ve evaluated — or already deployed — video interview analysis tools, employee engagement monitoring, classroom attention tracking, or proctoring systems that analyze facial expressions... this is the prohibition with your name on it. Remember the person who asked “So, the AI Act. What do we need to do?” in that meeting? This is what I’d tell them to check first. Because these products were actively marketed to companies until very recently. Some still are.

The grey zone worth watching: systems that track behavioral signals — cursor hesitation, typing cadence, mouse movement patterns — without calling the output “emotion.” A product labeled “engagement scoring” or “confidence assessment” instead of “emotion recognition”. The guidelines focus on purpose — inferring emotions. But when the function is analyzing human behavior to deduce internal states, the label you put on the output starts to look like a distinction without a difference. This is how I understand it, it’s not the law. But I wouldn’t want to be the test case.

7. Biometric categorization by sensitive characteristics

Article 5(1)(g). Biometric categorization systems that categorize individuals based on biometric data to deduce or infer race, political opinions, trade union membership, religious or philosophical beliefs, sex life, or sexual orientation.

One narrow exception: labeling or filtering lawfully acquired biometric datasets for training purposes — ensuring ethnic diversity in medical imaging training data, for example. That’s permitted. Using categorization operationally, against real individuals in real time? That’s the prohibition.

The formulation “deduce or infer” is deliberately broad. A confidence score correlated with race triggers the prohibition — the system doesn’t need to output a categorical label that says “this person is [race].” A probability is enough. A security system that wasn’t designed to infer race but whose outputs happen to correlate with it? Still caught. The question isn’t what you built the system to do. It’s what the system does.

8. Real-time remote biometric identification by law enforcement

Article 5(1)(h). Real-time remote biometric identification in publicly accessible spaces for law enforcement. The most politically charged prohibition in the entire AI Act — and the only one where the EU built a detailed exception framework directly into the article. Which tells you something about the lobbying pressure behind it.

“Real-time” means simultaneous with data capture — live identification as it happens. Analyzing recorded footage after the fact (post-RBI) is a different legal category — classified as high-risk, not prohibited. That distinction sounds clean. In practice, the boundary is blurry. If you analyze CCTV footage ten minutes after capture, is that “real-time”? An hour? The guidelines don’t draw the line.

Three narrow exceptions — all requiring prior judicial or independent authority authorization, a fundamental rights impact assessment, and EU database registration:

1. Searching for specific crime victims (trafficking, abduction, sexual exploitation)

2. Preventing a specific, substantial, imminent threat to life — or a foreseeable terrorist attack

3. Locating suspects for serious crimes listed in Annex II of the AI Act, punishable by at least four years imprisonment

Austria currently has a framework authorizing law enforcement to access public surveillance data in real-time without judicial permission. That framework is non-compliant with Article 5(1)(h). Hungary is developing a nationwide facial recognition database for law enforcement. Compliance status unclear.

For most corporate readers, this prohibition is primarily relevant if you’re a vendor selling biometric identification technology to law enforcement — or if you’re concerned about the “national security” exemption. Article 2(3) exempts AI systems used exclusively for national security purposes. A real-time biometric system reframed as national security escapes Article 5 entirely. The guidelines don’t close this door.

The Patterns Worth Seeing

Eight practices, one article. It’s tempting to treat them as a flat list. They’re not. Step back and three patterns emerge.

Not all prohibitions are created equal. Three tiers. Absolute bans — no exceptions at all. Untargeted facial scraping sits here, with biometric categorization close behind. Near-absolute bans — manipulation, exploitation, social scoring, predictive policing — where the path through is so narrow it barely exists. And conditional bans — emotion recognition and real-time biometric ID — where exceptions are real but come with procedural safeguards heavy enough to deter most uses. Knowing which tier you’re dealing with changes the conversation from “are we allowed to do this?” to “what would we need to do to be allowed?”

Context determines everything for social scoring. The prohibition isn’t about scoring. It’s about spillover. Where does the score travel? Who sees it? What decisions does it touch? A score that stays in its lane is fine. A score that leaks into unrelated contexts — or produces disproportionate consequences — triggers Article 5.

Three prohibitions involve law enforcement — with three different levels of restriction. Predictive policing: partial ban — the “solely” requirement creates a narrow path. Facial scraping: absolute ban — no exceptions at all. Real-time biometric ID: conditional ban — exceptions exist but come with procedural safeguards. The EU drew lines even for law enforcement. But the lines are drawn differently for each practice. And the national security exemption in Article 2(3) creates a potential backdoor for all three.

What the Guidelines Leave Open

Nine questions without answers

100+ pages of guidance. And the hardest questions? Left for another day.

1. The “solely” threshold. How much additional objective data allows AI use in criminal risk assessment? No standard.

2. How to identify “vulnerability.” Where does “specific socio-economic situation” begin? Is a single parent on minimum wage vulnerable? A recent graduate with student debt? No line drawn.

3. “Reasonably likely to cause significant harm.” What probability? How significant? No quantitative threshold.

4. National security vs. law enforcement. A real-time biometric system reframed as national security escapes the prohibition entirely. The boundary isn’t defined.

5. Untargeted scraping circumvention. Multiple targeted scrapes building the same database — how many? Over what timeline? The principle is stated, the mechanics aren’t.

6. Where “real-time” ends. If you analyze CCTV footage an hour after capture, is that real-time? A day? The line between prohibited real-time identification and permitted retrospective analysis isn’t drawn.

7. Generative AI and manipulation. How does Article 5(1)(a) apply to foundation models and LLMs? The guidelines don’t address this.

8. GDPR and Digital Services Act interplay. The prohibited practices overlap with both. How the obligations interact — or conflict — is unresolved.

9. The “material distortion” threshold. How much behavior change triggers the prohibition? The standard says “material.” It doesn’t say what that means in practice.

These aren’t academic gaps. They’re the questions that will land on your — or someone else’s — desk when trying to answer “what do we need to do about the AI Act?” — and there won’t be a clear answer.

What to Do

Having no clear answer is fine. Having no answer is not. You need an answer that’s something else than “it’s complicated.”

I’d say this:

Start by mapping your AI systems against Article 5. Not a theoretical exercise — a real one, with the technical team in the room. For each system: could it be deploying manipulative techniques, even unintentionally? Could it be exploiting vulnerable users — through its design, its targeting, or its effects? Does any scoring or classification travel across context boundaries? Does anything in the workplace or education space infer emotions or internal states, even under a different label?

The standard isn’t “did we intend this.” It’s “does the system do this.”

Trace where your scores go. If you score, classify, or categorize people — and most AI systems do, somewhere in the pipeline — follow the output. Who consumes it. What decisions it touches. If a score generated for one purpose is influencing decisions in another context, you have an Article 5(1)(c) question that needs an answer.

Check your vendors. If you’re using third-party AI tools — video interview platforms, employee monitoring software, customer analytics, proctoring systems — ask what they actually do under the hood. If a vendor’s product turns out to be prohibited under Article 5, the vendor isn’t the only one with a problem. You’re liable as a deployer. “We bought it from someone else” is not a defense. “Putting into service” triggers the prohibition — regardless of who built the system.

Document your reasoning. For every system where you conclude “this isn’t a prohibited practice” — write down why. Article by article. Element by element. Not because the regulator has asked for it yet. Because when enforcement starts — and it will — a documented assessment is the difference between a defensible position and an assumption you can’t explain.

No AI Act fines for prohibited practices have been issued yet. It’s April 2026. But the machinery is in place. Complaints have been filed — France’s CAF, Clearview’s criminal exposure in Austria. Market Surveillance Authorities are operational. GDPR enforcement against the same conduct has already cleared €100 million. The AI Act just raised the ceiling.

So if someone turns to you in a meeting and asks “what do we need to do about the AI Act?” — you probably don’t need a full answer by Friday. But you need to know three things: the prohibitions exist, they’re already in force, and the law doesn’t care what you intended.

Start there. High-risk classification, documentation, conformity assessment — that all comes next. But it comes after this.

You don’t build a house from the roof down.

I had dinner with a friend recently.

Smart guy. Corporate Counsel in a Big Tech company, who deals with compliance daily.

We got to talking about the EU AI Act — as you do when two lawyers meet and the wine hasn’t arrived yet — and he offered what he clearly considered a clean, practical test.

“If it’s software,” he said, “it’s not AI. And if it’s not AI, the AI Act doesn’t apply.”

He said it like someone closing a door.

Simple. Done. Next topic.

And I sat there thinking — that’s not quite right.

But it’s also not entirely wrong.

And the distance between “not quite right” and “not entirely wrong” is exactly where most companies are going to get stuck.

The EU AI Act doesn’t regulate “artificial intelligence” the way most people understand that term.

It regulates “AI systems” — a legal concept with a specific definition, seven elements, and a set of boundaries that don’t map neatly onto what your IT team thinks AI is or what your legal team thinks software is.

If you don’t know whether your system qualifies as an AI system under Article 3(1), nothing else in the regulation makes sense. Not the risk classification. Not the transparency requirements. Not the documentation obligations. Not the fines.

This is the first question. Everything else comes after.

Subscribe now

The Definition — Seven Elements, One Sentence

Article 3(1) of the EU AI Act defines an “AI system” as:

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

One sentence. Seven elements. And the European Commission needed an entire set of guidelines — published on 6 February 2025 — to explain what it means.

The definition is aligned with the OECD’s definition of an AI system, which matters for international consistency. But consistency in wording doesn’t mean clarity in application.

First, a machine-based system. Software, hardware, or both. Running on a server, a device, embedded in a product. This is the least interesting element — if it runs on a machine, it qualifies. Moving on.

Second, designed to operate with varying levels of autonomy. The system needs some degree of independence from human involvement. Not full autonomy — partial counts. But a system “designed to operate solely with full manual human involvement and intervention” is out. The word “designed” matters. It’s about intent, not just current operation. A system designed to run autonomously but currently supervised by a human? Still designed for autonomy.

Third, may exhibit adaptiveness after deployment. “May” is the word doing the heavy lifting. Self-learning, runtime adaptation — these are features some AI systems have. But their absence doesn’t disqualify a system. A model trained once, frozen, and deployed without ever updating itself can still be an AI system if it meets the other elements. Adaptiveness is a characteristic, not a requirement.

Fourth, for explicit or implicit objectives. The system pursues goals. Explicit ones are programmed in. Implicit ones are derived from the system’s behavior — a large language model doesn’t have a stated “objective” in the traditional sense, but it implicitly aims to produce coherent outputs. This element is broad by design.

Fifth, infers, from the input it receives. This is the one that matters most. The element that separates AI systems from traditional software. Inference means the system derives outputs through a process that goes beyond executing pre-programmed rules. It involves deriving models or algorithms, reasoning, pattern recognition — something more than “if X, then Y.”

Recital 12 puts it plainly: “A key characteristic of AI systems is their capability to infer.” It then excludes “simpler traditional software systems or programming approaches” and systems “based on the rules defined solely by natural persons to automatically execute operations.”

The techniques that enable inference, according to the Act and the guidelines, fall into two families:

• Machine learning approaches — systems that learn patterns from data, whether from labeled examples, from finding structure in data on their own, or from improving through trial and error. This includes deep learning and neural networks — the technology behind image recognition, language models like ChatGPT, and most of what makes AI headlines.

• And logic- and knowledge-based approaches — systems that reason using structured knowledge, like expert systems that apply a web of rules and relationships to reach conclusions (think medical diagnosis tools or legal reasoning engines).

Sixth, how to generate outputs such as predictions, content, recommendations, or decisions. Four output types, non-exhaustive. Predictions, newly generated content (text, images, audio), recommendations, and decisions.

Seventh, that can influence physical or virtual environments. The outputs must have potential to affect something. Physical environments (robotics, autonomous vehicles) or virtual ones (content moderation, search results, recommendations). Broadly interpreted.

Seven elements. All must be present. Miss one, and the system falls outside the definition.

What the Guidelines Say Is Not an AI System

A few weeks after that dinner, I was talking to an IT architect.

He mentioned a program his team was building — a prediction system for capacity planning.

Nothing fancy, he said. Takes last year’s data, runs a simple statistical formula, estimates next quarter’s numbers. No model training. No learning. Just math.

Something clicked.

Because the Commission’s February 2025 guidelines describe almost exactly that kind of system. And they say — explicitly — it’s not an AI system under the AI Act.

The guidelines identify four categories of systems that fall outside the definition.

The common thread: although some of these systems have a capacity to infer, they fall outside scope “because of their limited capacity to analyze patterns and adjust autonomously their output.”

That phrase — “limited capacity” — is doing enormous work.

The guidelines aren’t saying these systems can’t infer at all. They’re saying the inference is too limited to qualify.

With that laid out, here are the four categories:

1. Systems for mathematical optimisation

Systems used to improve or approximate traditional, well-established optimisation methods — including linear or logistic regression.

In practice, this covers a logistic regression model estimating credit default probability with fixed coefficients. A linear regression forecasting demand. The guidelines follow the OECD’s line here: simple statistical techniques like linear or logistic regression fall outside the AI system definition.

For financial services, this is significant. Logistic regression is a workhorse in underwriting, credit scoring, and risk assessment. If these fall outside the definition, a meaningful number of systems in banking and insurance are potentially out of scope — even systems that would qualify as “high-risk” under Annex III if they were AI systems.

The catch: the guidelines say "linear or logistic regression methods." They don't address what happens as you move up the complexity ladder. If your data science team uses terms like ridge regression, lasso, polynomial regression, or random forests — those aren't covered by this exclusion. And nobody knows yet where they land. The further you get from simple linear or logistic regression, the harder it becomes to rely on this carve-out.

2. Basic data processing

Systems that follow “predefined, explicit instructions or operations... developed and deployed to execute tasks based on manual inputs or rules, without any learning, reasoning or modelling at any stage of the system lifecycle.”

In practice: database management systems that sort and filter based on specific criteria. Standard spreadsheet applications without AI functionality. Inventory management systems with fixed rules. Traditional business logic engines. Workflow engines that route documents based on if/then logic.

This is the clearest exclusion. If a system simply executes human-written rules with no learning component at any stage, it’s not an AI system under the AI Act.

3. Classical heuristics

Rule-based problem-solving systems that “typically involve rule-based approaches, pattern recognition, or trial-and-error strategies rather than data-driven learning.” They do not evolve through data or experience.

The guidelines give the example of chess programs based solely on minimax algorithms. Also in this category: rule-based spam filters using keyword matching, basic pattern-matching systems, traditional search algorithms.

These are systems that might feel smart — that might even be called “AI” internally — but aren’t learning from data. A fraud detection system with 500 hand-coded rules (”flag transactions over €10,000 from new accounts”) is a classical heuristic. Even if the compliance team has been calling it their “AI fraud system” for three years.

4. Simple prediction systems

Systems that predict using basic statistical rules and do not adapt or evolve over time.

The guidelines give a specific example: “a program that estimates future stock prices by using an estimator with the ‘mean’ strategy to establish a baseline prediction.” A system that predicts next month’s temperature by averaging the last ten years of data falls here too.

This is the exclusion that will generate the most friction between legal and technical teams. To a data scientist, a prediction system — even a simple one — is doing something that looks like AI. To the guidelines, if the prediction mechanism is a fixed statistical rule that doesn’t learn or adapt, it’s out.

What Clearly Qualifies

The other side of the line is less controversial. The guidelines and Recital 12 make clear that the following approaches create AI systems when used as part of a system meeting the full Article 3(1) definition.

Machine learning systems

Systems that learn from data — whether they learn from labeled examples (this is called supervised learning), find hidden patterns or groupings on their own (unsupervised learning), or improve through trial and error (reinforcement learning). Deep learning and neural networks fall here too — the technology behind image recognition, large language models, and most of what the world currently calls "AI." If your technical team says a system was "trained on data," you're almost certainly in this category.

Logic- and knowledge-based systems

Systems that reason using structured knowledge — expert systems (medical diagnosis tools, legal reasoning engines), systems that represent relationships between concepts and draw conclusions from them, and systems that use logical rules to infer new information from existing knowledge. The distinguishing feature from the excluded "basic" rule-based systems: these don't just execute rules mechanically. They reason with them.

In practice, this means:

• A machine learning model trained on historical data to predict credit defaults — in scope.

  • Contrast with a logistic regression estimator using fixed coefficients — that’s out.

• A recommendation engine that learns user preferences over time — in scope.

• A chatbot powered by a large language model — in scope.

• A computer vision system trained to detect defects on a production line — in scope.

• An expert system for medical diagnosis that uses a knowledge base and inference engine — in scope.

• A natural language processing system for document classification — in scope.

The pattern: if the system learns from data, reasons beyond its explicit rules, or derives models through training — it’s in.

The Paradox

I've written before about why the AI Act is generating more confusion than clarity. The same applies when it comes to the definition of an AI system.

Recital 12 excludes systems “based on the rules defined solely by natural persons to automatically execute operations.” Rules written by humans, executed mechanically. Out.

But the same guidelines include logic- and knowledge-based approaches — expert systems, symbolic reasoning, inference engines — where the rules are “encoded by human experts” through “rules, ontologies, or knowledge graphs.”

Both are rule-based. Both have rules defined by humans. One is out. One is in.

The guidelines never draw an explicit line between a “simple” rule-based system that’s excluded and a “complex” rule-based system that’s included as a logic- or knowledge-based approach. There’s no test. No threshold. No “if your rule-based system has more than N rules, it’s in.” Nothing.

My reading — and this is my interpretation, not settled law — is that the distinguishing factor is the inference capacity. An if/then business logic engine applies rules mechanically. It does what the programmer told it to do, every time, the same way. An expert system with an inference engine can chain rules together, handle uncertainty, weigh competing rules, and reach conclusions that weren’t explicitly programmed as a single path. One executes. The other reasons.

But the guidelines don’t say this explicitly. And multiple law firm analyses have flagged the same contradiction. One noted that the guidelines “appear to lack an obvious underlying logic to the examples that fall inside and outside of scope.” Another pointed out the paradox of excluding “rules defined solely by humans” while including expert systems where the rules are... defined by humans.

The logistic regression question adds another layer. Logistic regression is out. But what about a logistic regression model used as part of a larger ensemble? One whose parameters are updated periodically with new data? One used for feature selection that feeds results into a neural network? The guidelines address the technique in isolation. Real systems use combinations.

And the adaptiveness element creates its own trap. The definition says adaptiveness is not required — “may exhibit.” But one of the key reasons the four exclusion categories are excluded is precisely that they “do not adapt or evolve over time.” Adaptiveness isn’t required to be an AI. But its absence is one reason it might not be an AI. This isn’t a contradiction exactly, but it creates a zone where a non-adaptive system might or might not qualify depending on how sophisticated its inference is.

The "limited capacity" phrase — the reason all four exclusion categories are out — is never defined. Where does "limited" end and "sufficient" begin? The guidelines don't say. Which leaves a genuine grey zone for a whole class of techniques that sit between simple statistics and full-blown machine learning. If your technical team mentions gradient boosted trees, simple neural networks, nearest-neighbor methods, naive Bayes, or support vector machines — ask them to explain what those systems actually do. Because the guidelines don't address any of them.

All more sophisticated than logistic regression. All arguably capable of inference. All potentially falling into the “limited capacity” gap that the guidelines created but didn’t fill.

Two Conversations, One Problem

I keep coming back to those two conversations.

The lawyer who drew a clean line — software on one side, AI on the other — and moved on with his meal. The IT architect who described a prediction system that would be unambiguously “AI” in his professional world but falls outside the AI Act’s definition entirely.

Neither was wrong, exactly. But neither had the full picture. And the space between their perspectives is where compliance actually lives.

The lawyer’s instinct — “if it’s software, it’s not AI” — gets at something real. The AI Act doesn’t regulate all software. It regulates a specific subset of software with specific characteristics. But “it’s software, not AI” is imprecise to the point of being dangerous. An expert system is software. A deep learning model deployed as a web service is software. A chatbot running on an API is software. All of them are AI systems under the AI Act.

What the lawyer probably meant was: if it’s traditional software using fixed rules, it’s not an AI system under the AI Act. That’s closer to correct. But only if the system truly has no inference capability beyond mechanical rule execution. And the only way to know that is to look inside the system — at what it actually does, not what it’s called.

The IT architect’s perspective carries a different risk. In his world — and in the world of every data science team I’ve encountered — “AI” includes any system that makes predictions. Any system that uses data to generate outputs. Logistic regression, linear regression, decision trees — all “ML/AI.” All part of the toolkit.

Under the EU AI Act, many of those are not AI systems. A logistic regression model with fixed coefficients? Not AI under the AI Act. A simple averaging prediction system? Not AI. A rule-based system with hand-coded rules? Not AI.

This matters in both directions. Technical teams may flag systems for compliance that don't need it — burning resources, delaying projects, creating unnecessary work. Or they may hear "your logistic regression isn't AI under the AI Act" and conclude that nothing in their pipeline needs attention — missing the more sophisticated model sitting right next to it that probably does qualify.

The translation both teams need is this: “AI” under the EU AI Act is a legal definition. It doesn’t match the colloquial understanding and it doesn’t match the technical one. Something can be artificial intelligence in every data science textbook and not be an “AI system” under Article 3(1). And something your legal team dismisses as “just software” can still qualify if it has the right kind of inference capability.

Neither team can do this analysis alone. Legal can’t assess scope without understanding what the system technically does. Tech team can’t assess it without understanding what the legal definition actually requires. The exercise has to be joint.

Borderline Cases — Where the Line Gets Blurred

Theory is useful. Specific examples are better.

So, let’s take a look where the definition meets actual systems.

The credit scoring model. A bank uses logistic regression to score credit applications. Trained on historical data, fixed coefficients, no post-deployment learning. The data science team calls it an ML model. The guidelines say logistic regression falls outside the AI system definition. Likely not in scope. But — if the bank periodically retrains with new data and redeploys, the picture gets murkier. And if the logistic regression is one component in a larger pipeline that includes ML elements, the pipeline as a whole might still qualify.

The rule-based fraud detection system. An insurer runs a system with hundreds of hand-coded rules — “if claim amount exceeds €50,000 and policyholder tenure is under one year and no police report was filed, flag for review.” Rules written by domain experts. No learning component. The guidelines would classify this as basic data processing or classical heuristics. Not AI. The moment the insurer adds a machine learning layer — a model that scores flagged claims by likelihood of actual fraud based on historical outcomes — that component moves toward the definition. One layer changes everything.

The recommendation engine. An e-commerce company runs two versions. Version A uses machine learning to learn patterns from user behavior — what people browse, buy, and ignore — and generates personalized recommendations based on those patterns. Likely an AI system. Version B uses a simple lookup — "customers who bought X also bought Y" — based on counting how often products are purchased together. No learning, no adaptation, just a fixed rule. Closer to basic data processing. Probably not an AI system. Two systems, same job, different classifications — because the definition cares about how the system works, not what it does.

The chatbot spectrum. A basic FAQ chatbot that matches keywords in your question to pre-written answers from a fixed database? Not AI under the AI Act. A chatbot powered by a large language model that generates its own responses? Unambiguously AI. The interesting case: a chatbot that uses a small machine learning model to figure out what you're asking about (intent classification, in technical terms), then serves a pre-written response based on that classification. The classification component has inference capability — it learned from data how to categorize questions. Likely an AI system — even though the answers themselves are canned.

Even If It’s an AI System — It Might Still Be Out of Scope

The definition question and the scope question are different analyses. A system can be an AI system under Article 3(1) and still fall outside the AI Act’s obligations through exemptions in Article 2.

Research and development. AI systems in research, testing, or development before being placed on the market or put into service are excluded. But testing in real-world conditions is covered. The moment you go from lab to live users, the exemption ends.

Open source. Free and open-source AI models are generally exempt — unless they’re classified as high-risk, involve prohibited practices, or trigger transparency obligations. Not a blanket pass.

Military, defence, national security. AI systems used exclusively for these purposes are excluded. “Exclusively” is load-bearing — any dual-use or civilian spillover brings the system back in scope.

Personal non-professional use. Natural persons using AI for purely personal purposes are exempt from deployer obligations.

The distinction matters: a logistic regression model isn't an AI system at all — the definition question. A deep learning model used in defence is an AI system, but it's exempt — the scope question. Different analyses, different conclusions. Both necessary. And if you're outside the EU wondering whether any of this applies to you — it probably does.

The Bigger Picture

I’ve been thinking about what that dinner conversation really exposed.

It wasn’t about one lawyer being wrong. It was about how instinctively everyone reaches for a simple answer to this question. Software or AI. In or out. Regulated or free. And the regulation — whether by design or by accident — doesn’t give you a simple answer.

Every obligation in the AI Act flows from the AI system definition. Risk classification under Article 6? Only applies to AI systems. Transparency requirements under Articles 50 and 52? Only AI systems. GPAI obligations under Articles 51 through 56? Only AI models and systems. Documentation, conformity assessment, registration — all triggered by having an AI system.

The definition is the on/off switch for the entire regulation.

The Commission’s guidelines got the extremes right. A spreadsheet macro is not an AI system. A deep learning model is. The four exclusion categories give specific examples that many companies can use to sort their obvious cases.

What the guidelines left unresolved is the middle. The “limited capacity” standard is too vague to resolve borderline cases without system-by-system analysis. The rule-based paradox — excluded as “traditional software” but included as “expert systems” — has no clear test. The interaction between techniques in real-world pipelines, where a system might use both excluded and included approaches, isn’t addressed at all.

Which means most companies will need to do what regulations always end up requiring when the text is ambiguous: the actual work.

Map your systems. Not by their names, not by their marketing labels — by what they technically do. Have the technical team describe the actual mechanism. Have the legal team apply the seven elements of Article 3(1). For every system where inference is the question — and it usually will be — assess whether the system’s inference capacity is “limited” in the way the guidelines describe, or whether it goes beyond the four exclusion categories.

Document the reasoning. Especially for borderline cases. “We assessed this system against Article 3(1) and concluded it does not qualify because...” is a sentence that will matter when enforcement starts.

Don’t take this lightly. The guidelines leave gaps — real ones — and the temptation is to read those gaps in your favor. To call something “just software”. To assume a system is exempt because it uses a technique that sounds like one of the four exclusion categories.

The gaps will be filled. Through enforcement, through case law, through updated guidance. And the companies that did the rigorous assessment — system by system, element by element, with legal and tech teams in the same room — will be the ones who aren’t scrambling when that clarity arrives.

The definition is where compliance starts.

It’s also where most companies stop thinking too soon.

Don’t be most companies.

Someone asked you in a meeting — maybe your product manager, maybe your CTO, maybe a client — “does the EU AI Act apply to us? We’re not in the EU.”

You said no.

Or you shrugged.

Or you said “I’ll look into it” — which is code for “I hope this goes away.”

However, it didn’t go away. So here you are, googling it.

The short answer is: it depends.

But the EU AI Act reaches further than most non-EU companies expect — and the line between “in scope” and “not in scope” isn’t where you think it is.

Subscribe now

What the Law Actually Says

Article 2(1) of the EU AI Act lists seven categories of entities this regulation applies to. For non-EU companies, three separate hooks matter the most — and you only need to trigger one.

(a) Providers placing on the market or putting into service AI systems in the EU — regardless of where they're established. A US company that sells an AI-powered SaaS product to EU customers is "placing on the market" in the EU. Same logic as GDPR — location of the company is irrelevant, location of the market matters.

(b) Deployers of AI systems located in the EU — this one catches EU-based companies using non-EU AI tools. But it also indirectly affects the non-EU provider, because the EU deployer will demand compliance from their vendor. Even if the Act doesn't directly apply to you, your EU customer's obligations flow uphill.

(c) Providers and deployers in third countries where the OUTPUT of the AI system is used in the EU — this is the broadest hook, and the one most non-EU companies underestimate. If your AI system generates an output — a prediction, a recommendation, a decision, a piece of content — and that output ends up being used by someone in the EU, you're potentially in scope.

A few terms worth understanding before we go further:

“Placing on the market” means the first time an AI system becomes available on the EU market. Selling, licensing, offering as SaaS — any way a system reaches an EU user for the first time.

“Putting into service” means supplying an AI system directly to a deployer for first use, or using it yourself for its intended purpose. If you deploy your own AI system and it touches EU operations — this is you.

“Output produced by the AI system is used in the Union” is the broadest trigger. It doesn't require physical presence. It doesn't require an EU customer relationship. If the output lands in the EU and gets used there, the connection is made.

The Nuance

Recital 22 narrows the “output used in the Union” trigger somewhat. It frames this as intended use — the example given is an EU provider contracting with a non-EU provider to process data and send back AI-generated outputs.

The AI system processes data lawfully collected and transferred from the EU, and the output goes back to the EU contracting party.

This matters because the level of “intention” is still open to interpretation.

There’s no official guidance yet on what counts as intended vs. incidental output reaching the EU. This is a grey area that will likely be clarified through enforcement and guidance — but companies shouldn’t wait for that.

When You’re Caught

Here's where it gets practical. These are scenarios where the EU AI Act catches you even if your business is headquartered nowhere near the EU.

Scenario 1: US SaaS company with EU customers

A US company offers an AI-powered hiring tool. EU companies subscribe and use it to screen candidates in the EU. The US company is a provider placing an AI system on the EU market. Fully in scope. If the tool qualifies as high-risk (employment is Annex III, point 4), they need full compliance — risk management, data governance, transparency, human oversight, the works.

Scenario 2: The API provider

A Singapore-based fintech provides a credit scoring API. EU banks call the API to assess loan applications from EU citizens. No EU office, no EU entity, no EU employees — but the output (credit scores) is used in the EU to make decisions about EU persons. The Singapore company is in scope as a provider under Article 2(1)(c).

Scenario 3: The outsourced AI processing

An EU insurer contracts with an Indian AI company to process claims data. The Indian company uses AI to generate risk assessments, which are sent back to the EU insurer for decision-making. This is the Recital 22 scenario — output generated outside the EU, used inside the EU. The Indian company is caught.

Scenario 4: Internal AI tools used globally

A US multinational builds an internal AI system for performance reviews. It's used by managers globally — including at the company's EU offices. The output (performance assessments affecting EU employees) is used in the EU. The US parent company is likely in scope — both as provider and deployer.

Scenario 5: GPAI model providers

A US company develops and releases a general-purpose AI model (think: foundation models, LLMs). If the model is made available on the EU market — including via API access to EU developers — the GPAI-specific obligations under Articles 51-56 apply. Technical documentation, transparency about training data, copyright compliance.

When You’re Probably Not Caught

Not every non-EU company needs to worry. Here's when you can exhale.

Scenario A: Purely domestic, no EU touchpoint

A US company builds an AI tool used only by US employees, for US customers, processing US data. No EU customers, no EU users, no output reaching the EU. Not in scope.

Scenario B: Open-source with no EU market targeting

Free and open-source AI models are generally exempt under Article 2(12) — unless they're classified as high-risk AI systems, prohibited AI practices, or have transparency obligations. This exemption has conditions and edges. It's not a blanket free pass.

Scenario C: R&D only

AI systems in research, testing, or development — before being placed on the market or put into service — are excluded under Article 2(8). But the moment you move from testing to deployment with EU users, the exemption ends.

Scenario D: Military/defence/national security

AI systems whose output is used in the EU exclusively for military, defence, or national security purposes are carved out under Article 2(3). But "exclusively" is doing heavy lifting there — any dual-use or civilian spillover could bring it back in scope.

The Grey Zone

If your AI system’s output could reach EU users but you’re not specifically targeting them — this is genuinely unclear.

The GDPR analogy would suggest some form of “targeting” test (like GDPR’s Recital 23, which looks at language, currency, and other indicators that you’re aiming at EU users). But the AI Act doesn’t have that explicit test. Recital 22 hints at intentionality, but it hasn’t been tested through enforcement.

My reading: incidental or unintended output reaching the EU is probably not enough to bring you in scope. But no one has confirmed that yet. This is an open question — and if it matters for your business, it’s worth getting a proper legal opinion rather than betting on a “probably”.

You Need a Person in the EU

Article 22 adds a practical requirement that catches some non-EU companies off guard.

Providers established outside the EU who place high-risk AI systems on the EU market must appoint an authorized representative in the EU — by written mandate — before making the system available. Not after. Before.

The representative verifies that the declaration of conformity and technical documentation exist. They provide information to competent authorities when requested. They cooperate on corrective actions. They flag complaints and risks to the provider. They ensure registration obligations are met under the database in Article 71.

What the representative does not do: take over the provider’s core compliance obligations (Articles 9-17). You still have to do the actual compliance work. The representative is your EU-facing contact point — not a compliance outsourcer.

If you went through GDPR, this mirrors the Article 27 representative requirement. Same structure, same logic. If you didn’t go through GDPR... this is your wake-up call.

One more thing about your EU representative. The representative can terminate the mandate if they believe the provider is acting contrary to the regulation. And when they do, they must report it to market surveillance authorities. Your EU representative isn’t just an address on file. They’re a compliance checkpoint with the power to blow the whistle.

The GDPR Déjà Vu

If this whole article feels familiar — it should.

The EU AI Act’s extraterritorial reach follows the GDPR playbook. It applies regardless of where the company is established. It requires an authorized representative for non-EU entities. “output used in the EU” mirrors GDPR’s “offering goods or services to” or “monitoring behavior of” EU data subjects. And the fines are higher — up to €35 million or 7% of global annual turnover for the most serious violations, compared to GDPR’s ceiling of €20 million or 4%.

But there are differences worth knowing.

The AI Act’s “output used in the Union” hook is arguably broader than GDPR’s targeting test. Under GDPR, you need to be “offering” to or “monitoring” EU persons. Under the AI Act, even being a subcontractor whose output happens to be used in the EU could be enough.

GDPR has had years of enforcement, case law, and guidance to clarify the grey zones. The AI Act has none of that yet. Everything right now is interpretation — informed interpretation, but interpretation nonetheless.

And the AI Act layers on top of GDPR. It doesn’t replace it. If your AI system processes personal data, you need to comply with both.

It’s Not Just the EU

Here’s the part that might matter even more than the extraterritorial reach.

The EU AI Act gets the headlines. But if you’re dismissing it because “we don’t operate in the EU” — you might want to check what’s happening closer to home.

United States — the patchwork

There’s no federal AI law. The current administration is actively trying to prevent one — the December 2025 executive order (”Ensuring a National Policy Framework for AI”) directed the Attorney General to challenge state AI laws and the Commerce Secretary to flag “burdensome” state regulation by March 2026.

But executive orders don’t override existing law. And the states aren’t waiting.

Colorado’s AI Act takes effect June 30, 2026 — delayed from February, but still coming. It requires developers and deployers to exercise reasonable care to prevent algorithmic discrimination, conduct impact assessments, and provide consumer disclosures. This is the closest a US state has come to EU-style AI obligations. California’s Transparency in Frontier AI Act hit January 1, 2026. Texas’s Responsible AI Governance Act — same date.

Until Congress acts or courts rule, state laws remain enforceable. Even if you’re a US company that doesn’t touch the EU — check Colorado, California, and Texas. The regulation is coming from inside the house.

United Kingdom — no law yet, but don't get comfortable

The UK doesn’t have a dedicated AI statute. Its current approach is the 2023 “Pro-Innovation” white paper — five principles applied by existing sector regulators rather than a central AI authority.

But legislation is expected in the second half of 2026, likely covering the most powerful general-purpose AI models. In January 2026, the government wrote to 19 regulators asking them to publish plans for safe AI innovation. The Financial Conduct Authority and others are already issuing sector-specific AI guidance.

The UK hasn’t passed an AI law yet. That doesn’t mean it isn’t building one.

Singapore — "voluntary" until it isn't

Singapore governs AI through voluntary frameworks — the Model AI Governance Framework (updated for generative AI in 2024-2025), the Agentic AI Governance Framework (January 2026, first of its kind globally), and AI Verify, a government-developed testing toolkit.

“Voluntary” sounds comfortable. But the Monetary Authority of Singapore already has mandatory AI governance requirements for financial institutions as of December 2024. Sector by sector, the voluntary frameworks are hardening into rules.

Singapore is building the infrastructure — the frameworks, the testing tools, the sectoral requirements — that makes binding regulation easy to switch on. When it does, the companies already following the frameworks won’t notice. The ones that ignored them will.

AI regulation used to be one law in one place. It isn’t anymore. It’s a permanent, growing area of law — worldwide — and the companies that figure that out now are the ones that won’t be scrambling later.

You already took the first step. You’re here, reading this, instead of shrugging it off in a meeting.

That matters more than you think.

You have some AI systems in the company. You are aware there is some AI Act.

But what are you supposed to do? Classify them? Report them somewhere? Write documentation? Put them in a spreadsheet and hope for the best?

So you decide you need help. You hire a consultant — the one whose LinkedIn posts freaked you out. Only to realize he doesn’t understand half of what he’s talking about.

So you try something else. Online courses. In-person workshops. Seminars with important-sounding titles.

And they read you the regulation.

They read it to you.

But they don’t tell you what to do. What are the steps. How to actually be compliant. You walk out knowing the AI Act exists (you already knew that) and not much else.

You have no idea what to do.

It looks hopeless.

It’s not. And here’s the thing nobody is saying out loud:

You’re confused because the people writing the rules haven’t finished explaining them.

A study of 106 enterprise AI systems found 40% had unclear risk classification. That’s not company incompetence — that’s a guidance gap. If you don’t have your AI systems classified, if you genuinely don’t know what to do next, the reason is not you.

Psst. It’s them.

Subscribe now

So what happened?

The Commission missed its own deadline

The guidelines on high-risk AI classification — Article 6, the single most important question every company has — were due February 2, 2026.

It’s still missing at the end March 2026.

“Is my AI system high-risk?” That’s the question. The Commission was supposed to answer it over a year ago. They haven’t.

The guidance they did publish made things worse

In February 2025, the Commission published guidelines on the definition of an AI system. The idea was to bring clarity. Legal analysts noted the guidelines “may actually lead to more debate.” The guidance on “limited capacity” machine learning systems created new borderline cases instead of resolving old ones.

Ambiguity creates confusion. Confusion creates more ambiguity.

The standards won’t be ready before enforcement starts

CEN and CENELEC — the bodies creating the technical standards companies need to demonstrate compliance — are targeting Q4 2026 for key harmonized standards.

The high-risk obligations become enforceable August 2, 2026.

Read that again. Companies are supposed to comply with rules whose technical standards don’t exist yet on the enforcement date.

Guidance arrives weeks before deadlines

The transparency Code of Practice under Article 50? First draft came out December 2025. Final version expected June 2026. Enforcement starts August 2, 2026.

That gives companies two months. Two months to implement something they just learned about.

Nobody knows who enforces this

Only 8 out of 27 EU member states have established designated national competent authorities. In most countries, the body responsible for enforcing the AI Act hasn’t been appointed yet.

You can’t comply with confidence when you don’t know who’s watching — or whether anyone is.

The deadlines themselves keep moving

On March 13, 2026, the Council agreed to a position that would push the high-risk deadline from August 2026 to December 2027 for stand-alone systems, and August 2028 for systems embedded in regulated products.

But this is a Council position. Not finalized law. So companies are planning against deadlines that might change — again.

What do you actually need to remember?

Here’s where it stands as of March 2026:

Prohibited AI practices — social scoring, certain biometric systems, manipulative AI — have been enforceable since February 2, 2025. This is not coming. This is here.

GPAI provider obligations — if you provide a general-purpose AI model — have been in force since August 2, 2025.

Full enforcement for high-risk AI systems is currently set for August 2, 2026 — but the Council’s March position suggests December 2027 is more likely.

There has been no major public enforcement action yet.

The penalty structure, when enforcement does come:

• Prohibited AI practices: EUR 35 million or 7% of global turnover

• High-risk AI violations: EUR 15 million or 3% of global turnover

• Incorrect or misleading information: EUR 7.5 million or 1% of global turnover

Whichever is higher. That’s the ceiling. Most companies won’t get anywhere near it — but you need to know what the ceiling is.

If I were you

I would focus on three things right now.

First — make absolutely sure you are not running any prohibited AI practices. That’s the one category where enforcement is already live and the fines are the steepest. If you’re not sure what counts as prohibited, that’s a future article. But start there.

Second — get a rough inventory of the AI systems in your company. You don’t need to classify them perfectly yet (the Commission hasn’t given you the tools to do that). But you need to know what you’re working with. You can’t comply with regulation you can’t map to your actual systems.

Third — come back here regularly. I’ll be covering each of these topics in depth — what high-risk actually means, how to classify your systems, what the documentation requirements look like, and what happens as the deadlines shift. This is not a one-time problem. It’s an ongoing one, and I’ll be tracking it so you don’t have to.

The EU AI Act is confusing right now. That’s a fact. But it won’t always be — and the companies that start preparing now, even imperfectly, will be in a much better position than the ones still waiting for someone to hand them a checklist.

Nobody is going to hand you a checklist.

But I might build you one.