Most organisations using AI are deployers. Putting your name on a system, modifying it substantially, or changing what it is for can make you a provider, and the obligations are an order of magnitude heavier.
Every obligation in the EU AI Act attaches to a role. Get the role wrong and you will either do work you do not owe or miss work you do. For most organisations the answer is deployer. Article 25 sets out three ways that changes, and two of them are things ordinary product teams do without thinking of it as building an AI system.
The roles
| Role | Who it is | Typical example |
|---|---|---|
| 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 | A vendor selling a CV-screening tool |
| Deployer | Uses an AI system under its own authority, other than in a personal non-professional activity | An employer running that tool on applicants |
| Importer | Places on the EU market a system carrying the name of a provider established outside the EU | An EU reseller bringing in a US vendor's product |
| Distributor | Makes a system available on the EU market without being the provider or importer | A channel partner reselling under the vendor's brand |
The three switches in Article 25
A distributor, importer, deployer or other third party is considered a provider of a high-risk system, and takes on the provider obligations, in three circumstances:
- 1You put your name or trademark on a high-risk AI system already placed on the market or put into service. White-labelling a vendor's system makes you its provider.
- 2You make a substantial modification to a high-risk system already on the market, such that it remains high-risk.
- 3You modify the intended purpose of an AI system, including a general-purpose AI system, in a way that makes it high-risk.
The third is the one that catches internal teams. A general-purpose model used to summarise documents is one thing. The same model wired into a shortlisting step in recruitment has a different intended purpose, and recruitment sits in Annex III. Building that internally can make you the provider of a high-risk system, with the Chapter III obligations attached.
When a switch trips, the original provider's obligations pass to you and they stop being the provider for that system. They must cooperate and give you the information and reasonably expected technical access you need, unless they clearly specified that their system was not to be changed into a high-risk one.
What each role owes
| Area | Provider of a high-risk system | Deployer of a high-risk system |
|---|---|---|
| Risk management | Establish and maintain a risk management system across the lifecycle | Use the system per the provider's instructions |
| Data | Data governance for training, validation and testing sets | Ensure input data is relevant and sufficiently representative for the intended purpose |
| Documentation | Technical documentation, instructions for use, conformity assessment, CE marking | Keep the provider's instructions and follow them |
| Oversight | Design the system so it can be effectively overseen | Assign oversight to people with the competence, training and authority to do it |
| Logs | Design automatic logging into the system | Retain the automatically generated logs for at least six months |
| Monitoring | Post-market monitoring and serious incident reporting | Monitor operation, inform the provider of risks, suspend use where needed |
| People | - | Inform workers and their representatives before workplace deployment |
Five questions that settle most cases
- 1Whose name is on it at the point a user meets it? If it is yours, start from provider and work backwards.
- 2Did you change what the system is for, or only how your team uses it? Configuration is not a change of intended purpose. Repointing it at a different decision usually is.
- 3After the change, is the system doing something Annex III lists? The switch in Article 25 only trips into high-risk territory.
- 4Did you build or fine-tune the model behind it, or configure a product someone else maintains?
- 5Did the vendor's terms explicitly exclude high-risk use? That matters both for their position and for yours.
Why this is the first question rather than a detail
Provider obligations under Chapter III and deployer obligations under Article 26 differ by an order of magnitude in effort. Conformity assessment, technical documentation and post-market monitoring are programmes. Following instructions, assigning oversight and retaining logs are processes. Discovering in 2027 that you have been the provider of a high-risk system since 2026 is not a gap you close in a quarter.
The role also decides who owes a fundamental rights impact assessment under Article 27, who registers the system, and who a market surveillance authority contacts first.
Record the decision per system, with the reasoning and the date, and re-check it whenever the system or its use changes. Treat it the way you treat a lawful basis decision under GDPR: the conclusion matters less than being able to show how you reached it.
Role classification is a legal determination with real consequences and this post is not legal advice. Where a system is close to the line, particularly on substantial modification, get the position reviewed rather than settled internally.
Sources & references
- Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (AI Act) - EUR-Lex
- Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 (Digital Omnibus on AI) - EUR-Lex
- Regulation (EU) 2024/1689 - consolidated text as at 27 July 2026 - EUR-Lex
- AI Act - regulatory framework for artificial intelligence - European Commission
