A customer sends a security questionnaire. Halfway down is a question nobody in the company has answered before: “For the AI functionality in your product, are you a provider or a deployer under Regulation (EU) 2024/1689?”
The engineering lead says deployer, because the model came from someone else. Legal says it depends. Nobody can produce a document showing the determination was ever made. The questionnaire sits for eleven days.
That question is the whole compliance analysis compressed into one line — and it is the one most companies get wrong, because they answer it with instinct instead of with the text. Your risk tier tells you how much obligation exists. Your role tells you whose obligation it is. Those are two separate determinations, they resolve independently, and getting the second one wrong means building a compliance program for somebody else’s duties.
This guide covers how to make both determinations defensibly: where the Act actually reaches, how to classify without over-classifying, the four facts that decide your role, and what the obligations look like once they stop being legal language and start being work.
Why role comes before everything else
Most AI Act guidance starts with the risk pyramid. That is the wrong order for an operator.
Risk tier is a property of the system. Role is a property of what you did with it. Two companies can run identical systems and carry completely different obligations, because one white-labelled it and the other didn’t. You cannot determine whether you are a provider or a deployer in the abstract, and you cannot do it at company level. You do it system by system, and you write down why.
This is also the determination with the shortest path to value. Run it across your inventory and within a day you know which handful of systems carry provider obligations. Everything else is a lighter lift. That is a genuinely useful answer, and you get it before writing a single policy.
Where the Act actually reaches
Companies outside Europe approach EU regulation with a familiar threshold question: do we have an EU entity? Under the AI Act, that is the wrong place to stop.
Article 2 brings providers into scope when they place AI systems or general-purpose AI models on the EU market, whether or not they are established in the Union. It goes further — providers and deployers established outside the EU fall within the Act where the output produced by the system is used in the Union.
That second clause is the one people miss. A U.S. company can process everything on U.S. infrastructure and still be in scope because the result is used by a business in Europe. The model running in Virginia rather than Frankfurt does not settle the question. The regulation was drafted with exactly this cross-border architecture in mind.
Four questions get you to an answer faster than any org chart:
- Where is the system placed on the market?
- Who uses it?
- Where are its outputs used?
- What is it used to do?
“We don’t have an EU office” is not a compliance strategy. It is not even a defence.
Classifying without over-classifying
Here is where the analysis goes wrong in the first hour, and it goes wrong in both directions.
Read the Act too narrowly and you conclude nothing applies because you are not doing biometric surveillance. Read it too broadly — usually after a vendor webinar — and every system with a machine learning feature becomes high-risk, your programme needs a headcount you do not have, and the work stalls before it starts.
The Act does not treat every meaningful use of AI as high-risk. The European Commission describes the vast majority of AI systems currently used in the EU as minimal or no risk. That is worth saying plainly, because a great deal of marketing implies the opposite.
Four levels, in descending order of obligation:
Prohibited practices. Banned outright. No compliance path.
High-risk systems. The substantial obligation set — risk management, technical documentation, logging, human oversight, post-market monitoring, quality management.
Transparency obligations. Disclosure duties attaching to things like human interaction with AI and certain AI-generated or manipulated content.
Minimal or no risk. Where most ordinary business applications land. Covered by your acceptable use policy and nothing more.
“Uses AI” is not a classification. The use case is. For a standalone system, Annex III is where the analysis becomes concrete — it lists high-risk use cases across biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential services, law enforcement, migration and border control, and the administration of justice.
Take a hiring tool. Annex III specifically covers AI intended for recruitment or selection, including systems that place targeted job advertisements, filter applications, or evaluate candidates. Employment systems land inside the high-risk framework.
Even there, “employment AI equals high-risk” is too fast. Article 6 carves out certain Annex III systems that do not pose a significant risk of harm and do not materially influence decision-making — systems performing narrow procedural or preparatory tasks. Profiling of natural persons stays high-risk regardless. And a provider relying on that exception has to document the assessment.
Read that last sentence twice. The exception is not a shortcut. It is a deliverable. An undocumented Article 6 exception is indistinguishable from never having done the analysis.
Calibration: if most of your systems are landing in high-risk, your reading is too loose and you have built a programme nobody can staff. If none of them are, check your employment, credit, and access-control systems again.
The role determination
This is where I see the most dangerous assumptions.
Almost everyone wants to be the deployer. It sounds passive — you bought someone else’s technology, turned it on, carry a narrower set of duties. Sometimes that is exactly what happened. Often it is not.
The Act defines four roles, and they are not interchangeable commercial descriptions:
- Provider — 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
- Deployer — uses an AI system under its authority
- Importer — EU-established party placing a third-country provider’s system on the Union market
- Distributor — another party in the chain making the system available on that market
The harder issue is that your role can change under you. Article 25 is the mechanism, and I went to the operative text rather than the shorthand summaries, because this is the part that gets misread.
A distributor, importer, deployer, or other third party becomes the provider of a high-risk AI system if it puts its own name or trademark on the system, makes a substantial modification while the system remains high-risk, or changes the intended purpose of a system such that it becomes high-risk.
Four questions settle it for any given system:
- Whose name or trademark is on it when the customer sees it?
- Have we modified it substantially, or are we configuring it within the intended purpose the developer defined?
- Are we using it for a purpose the developer did not intend — and does that purpose make it high-risk?
- Who decides what the system is for? Not who operates it. Who defines its purpose.
White-label a high-risk system under your brand and you are the provider. Take a general-purpose system never designed for a high-risk use and configure it to materially influence employment decisions and you are the provider. You cannot assume the original developer remains the only provider because they wrote the underlying code. The Act looks at what you did.
This is also why contract language alone cannot solve role allocation. Contracts matter enormously — documentation, cooperation, audit rights, data access, allocation of responsibility between parties. But a contract calling you a deployer does not erase conduct the regulation treats as provider activity.
Map the facts, then the role, then the obligations. Companies that run that sequence backwards end up negotiating indemnification language for a compliance model they never correctly classified.
The timeline moved — check the date on anything you read
This is an area where older articles will actively mislead you, including ones still ranking well.
The Act entered into force in August 2024 and phased in from there. The first major obligations applied from 2 February 2025 — the initial prohibited-practice provisions and the AI literacy framework. Rules for general-purpose AI models and parts of the governance framework followed on 2 August 2025. Most of the Act became applicable on 2 August 2026, including the major transparency provisions, with the AI Office and national authorities exercising enforcement responsibilities.
Then the high-risk timeline changed. Following the 2026 AI Omnibus amendments, core requirements for high-risk systems under Article 6(2) and Annex III are scheduled to apply from 2 December 2027. For high-risk systems tied to regulated products under Article 6(1) and Annex I, the date is 2 August 2028.
The extension is not permission to shelve the work. The dates moved in part because the supporting standards and implementation guidance were not developing fast enough to make high-risk compliance workable — which tells you something about the scale of what is required. Treat it as runway, not reprieve.
What the obligations look like as work
Legal summaries stop exactly where operators need them to start. They tell you a provider of a high-risk system needs a “risk management system.” What does that mean on Tuesday morning?
The same gap opens under technical documentation, logging, human oversight, post-market monitoring, and quality management system. On paper they read as separate regulatory requirements. Inside an operating company they become artifacts with owners, evidence, and review cycles.
If you have built a cybersecurity compliance programme, you already own the discipline. Working through something like NIST SP 800-171 teaches the same sequence: identify what is in scope, assign responsibility, document how controls operate, retain evidence that they operated, find gaps, remediate, repeat as the environment changes. The AI Act is not 800-171 with “AI” written across the top — different legal requirements, different risks, different objects governed. But the operational muscle transfers, and that is worth knowing before you budget for a programme built from nothing.
What each requirement actually becomes:
- Article 9 risk management → a documented lifecycle process with named owners, defined risk criteria, testing, treatment decisions, and retained evidence. Not a policy document. A process that produces records.
- Technical documentation → maintained system records: architecture, intended purpose, limitations, data characteristics, validation results, performance metrics, oversight mechanisms, change history. The Act expects a detailed description of the risk-management system and relevant changes across the lifecycle — so it is a living file, not a launch artifact.
- Human oversight → a named role, a defined intervention point, and a record that intervention was possible. A sentence in a policy will not survive a request for evidence.
- Logging → a retention period and a monitoring owner.
- Post-market monitoring → a feedback loop with somewhere for the output to go.
- Vendor management → supply-chain role mapping. For each vendor: which of the four roles do they hold, and which do you.
- Change management → the control most existing programmes are not set up to catch. A sufficiently significant change affects both your conformity obligations and who is legally treated as the provider.
This part gets less attention than billion-euro fines and banned algorithms. It is also where compliance succeeds or fails.
What good looks like
You should be able to answer these in under five minutes, from documents rather than memory:
- Which of our systems reach the EU market, or produce output used there?
- For each one, what is our role — and what facts support that determination?
- Which systems are high-risk, and where we claimed an Article 6 exception, where is the written assessment?
- What would change our role, and who would notice if it did?
That last question is the one that separates a programme from a snapshot. Role transfer under Article 25 does not announce itself.
Five failure patterns worth avoiding
- Answering the role question at company level. You are not “a deployer.” You are a deployer of some systems and possibly a provider of others. The determination is per system.
- Treating the contract as the answer. Papering someone as the provider does not make them one. The Act looks at conduct.
- Claiming the Article 6 exception without documenting it. An undocumented exception is the same as no analysis, and it fails in exactly the moment you need it.
- Reading guidance published before the Omnibus amendments. Check the date on everything, including this. The high-risk dates moved.
- Waiting for legal certainty before starting. An eighty percent determination you act on beats a perfect one delivered after the deadline. Document your reasoning, act, revisit.
Where this leads
Scope and role are the determinations everything else depends on. Once they exist on paper, the control set stops being an open-ended question and becomes a defined build against a known obligation set.
If you have not built the inventory yet, start there — you cannot determine roles for systems you have not found.
Get the template
Our EU AI Act Scope & Role Determination template ships with the four role questions formatted as a per-system worksheet, the Article 6 exception assessment record, and the change triggers that require a role re-check. It is included in the AI Governance Starter Kit, tailored to your sector and size.
Not sure whether you are a provider or a deployer? Book a free 30-minute call. No slides — you leave with the two or three things worth doing first, whether or not you hire us.
About the author
References
– Regulation (EU) 2024/1689 (EU AI Act) — Articles 2, 6, 9, 25; Annex I; Annex III
– European Commission, Digital Strategy — AI Act implementation timeline
– 2026 AI Omnibus amendments — revised high-risk application dates
Advisory content, not legal advice.