Responsible AI
EU AI Act: Roles, Scope, and Risk Categories
Apply the EU AI Act’s territorial scope, value-chain roles, prohibited practices, risk categories, exclusions, and classification logic.
By the end you can
- Explain why EU AI Act classification requires documented facts about scope, actors, intended purpose, modification, market connection, and risk category
- Distinguish Provider, Deployer, and Importer or distributor
- Identify evidence that connects scope and exclusions to applicable obligations
- Design a review that moves from record the system facts to approve and maintain
Example
How EU AI Act scope and classification becomes an operating problem
A US software company offers an interview-analysis model to an EU recruitment platform. The platform modifies the scoring workflow. An employer configures the thresholds. A reseller markets the system under its own name.
Each party assumes another is the "provider." Four companies touch the same candidate, and not one of them has written down which duties are its own.
- Territorial reach: The system is placed on or used in the EU market and affects EU candidates.
- Role ambiguity: Provider, deployer, importer, distributor, product manufacturer and downstream provider may all be different parties.
- Purpose change: Workflow and marketing can alter intended purpose or create a substantial modification.
- Risk classification: Employment use may fall within high-risk categories, subject to current legislative timing.
- Parallel law: Data protection, equality, labor, consumer, and sector duties remain relevant.
Steps
Facts first, label last
Facts before labels. The classification is written last, with its reasoning, its uncertainty, and the name of whoever approved it. A label with nothing underneath it is a guess that someone has signed.
1. Record the system facts
Definition, purpose, functionality, users, outputs, market, and affected people.
2. Map every actor
Developer, provider, deployer, importer, distributor, integrator, reseller, and manufacturer.
3. Test scope and exclusions
Territory, research, personal use, security, and other statutory boundaries.
4. Classify the use
Prohibition, high-risk category, transparency duty, GPAI role, or other status.
5. Approve and maintain
Document reasoning, obligations, owners, effective dates, and change triggers.
What EU AI Act scope and classification changes in practice
Obligations attach to conduct, not to authorship. Whoever trained the model may carry none of them. The Act asks a different set of questions. What the system is. What it is for. Who the actors are, where it sits, where it was placed on the market. Then whose lives the output touches, what has been modified, what is excluded, and which risk category the use falls in.
Answer that list party by party and the interview-analysis chain resolves itself. Substantial modification and own-name marketing are what turn a deployer into a provider.
Above the fact list sits a risk-based structure: prohibited practices, high-risk systems, transparency obligations for certain systems, duties for general-purpose AI models, requirements for the other actors in the value chain. Document which one you landed in. Then revisit it after any change in purpose, branding, integration or control. The category is not a property of the system. It is a property of the situation.
Work the fact list party by party before naming a risk category. A classification argued from who trained the model answers a question the Act never asked.
Case
Regulation 2024/1689, and the dates in Article 113
The AI Act does not arrive on a single date. Regulation (EU) 2024/1689 was published in the Official Journal on 12 July 2024 and entered into force twenty days later, on 1 August. Article 113 then staggers the rest. Prohibitions apply from 2 February 2025. General application is 2 August 2026. Article 6(1) products, as first enacted, followed on 2 August 2027. That last date has already moved, replaced by Regulation (EU) 2026/1744 in July 2026.
Duties travel with roles, not with job titles. A distributor, importer, deployer or other third party becomes the provider of a high-risk system where "they put their name or trademark on a high-risk AI system already placed on the market or put into service". That is Article 25(1)(a).
A deployer that puts its own name on a high-risk system becomes a provider. Nobody has to agree to it.
Figure
Visual
The layers an EU AI Act review must connect
Five layers, in order: scope, role in the value chain, intended purpose, risk category, obligations. Each one is decided by the layer above it. Change anything, anywhere, and every layer below it has to be worked again.
- 1
Scope and exclusions
AI-system definition, territorial connection, research or other exclusions, and effective dates.
- 2
Value-chain role
Provider, deployer, importer, distributor, product manufacturer, authorized representative, or GPAI provider.
- 3
Intended purpose and modification
Marketing, instructions, configuration, integration, and substantial change.
- 4
Risk category
Prohibited, high-risk, transparency-scoped, GPAI, or other use.
- 5
Applicable obligations
Documentation, controls, notices, monitoring, registration, cooperation, and enforcement.
Comparison
Provider, Deployer, or Importer or distributor?
Provider, deployer, importer. Nobody picks which one they are — the role follows from what the organization actually does. Rebrand a system, or substantially modify it, and you have moved yourself into the first column.
Provider
Develops or has an AI system developed and places it on the market or puts it into service under its name.
- Carries core lifecycle duties for covered systems
- Role can arise through rebranding or substantial modification
- May be outside the EU but still in scope
- Needs technical and post-market evidence
Deployer
Uses an AI system under its authority in a professional context.
- Controls local workflow and input relevance
- Has duties for operation, monitoring, records, and affected people
- Is not merely an end consumer
- Cannot outsource local accountability
Importer or distributor
Makes an external provider’s system available in the EU value chain.
- Checks required conformity information
- Has cooperation and traceability duties
- Can acquire provider duties in some situations
- Needs role clarity before sale
Example
The role chain from developer to employer
Everyone who touched the system has a role under the Act, including the parties who assumed they had none.
- Role chain: Map the interview model from original developer through reseller, platform, and employer.
- Purpose comparison: Compare the vendor instructions with the employer's actual decision workflow.
- Classification record: Write the facts, sources, conclusion, uncertainty, and approver.
- Change trigger: List modifications that require role or risk reclassification.
Key idea
The contract label is not conclusive
A contract can say who the provider is. The Act does not have to agree. Rebranding, a changed intended purpose or a substantial modification can move a role whatever the paperwork says. Article 25(1)(a) says so expressly: contractual allocation of obligations does not prevent it.
So "low-risk AI" is not a label a product team gets to apply. It is a conclusion, and it needs evidence underneath it. What counts as evidence keeps moving too. Guidance evolves. Delegated and implementing acts, case law, amendments and the exact design of the use all feed the answer.
Split the work accordingly. Legal counsel owns how the Act is read. Product teams own the technical and operational facts it gets read against.
The reseller has already changed role. It did that the day it began marketing the interview-analysis system under its own name. The contract in front of it was never consulted.
A contract can allocate commercial risk. It cannot allocate the duties the Act attaches. A team that files the label instead of the facts has kept the wrong record.
Classification rests on facts that move
The facts a classification rests on move. Purpose drifts, systems get modified, roles change hands. So the record holds two things, not one: the reasoning, and the changes that would invalidate it.
Name the modification, purpose drift, or role change that would force the provider to redesign, restrict, remedy, or retire the system. Write it down now, while none of it has happened.
Key takeaways
- EU AI Act obligations follow what an organization actually does: role, intended purpose, market connection, use.
- Provider duties can arise through branding, substantial modification, or changed intended purpose.
- Deployers govern local operation, and cannot outsource that to the provider's compliance.
- Risk classification should be documented, approved, and revisited after material change.
- The AI Act operates alongside data protection, equality, labor, safety, consumer, and sector law.
- Effective dates and transitional rules belong in the classification record, not in informal memory.