Provider or Deployer? Finding Your Role Under the EU AI Act
Almost every obligation in the EU AI Act attaches to a role rather than to a company. Get the role wrong and you will either prepare for requirements that were never yours, or miss the ones that were. For most businesses this is the first question to settle, and it is simpler than it looks.
The two roles that matter to most organisations
A 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. Providers carry the heaviest obligations, because they are the ones who can design compliance in.
A deployer uses an AI system under its own authority in the course of a professional activity. If you bought or subscribed to a tool and your staff use it at work, you are almost certainly a deployer.
The Act also defines importers, distributors and authorised representatives, which matter to companies bringing AI systems into the EU market. Most ordinary businesses are deployers and nothing else.
Why the distinction matters
Deployer obligations are real but far lighter. They centre on using the system in line with the provider instructions, assigning human oversight to people with the competence and authority to exercise it, keeping logs where these are under your control, and being transparent with people affected by the system.
Provider obligations for high-risk systems are a different order of magnitude: risk management systems, data governance, technical documentation, conformity assessment, registration, CE marking and post-market monitoring. These are the requirements that now apply from 2 December 2027 for standalone Annex III systems and 2 August 2028 for high-risk AI embedded in already-regulated products.
Where the line moves
A deployer can become a provider. The Act sets out circumstances in which this happens, and they are easy to trigger without noticing:
- You put your own name or trademark on a high-risk system that is already on the market
- You make a substantial modification to a high-risk system
- You modify the intended purpose of a system so that it becomes high-risk
The second and third are the ones that catch people. Building a customer-facing product on top of a general-purpose model, or repurposing a tool for a use case its supplier never intended, can move you across the line and bring the full provider obligations with you.
Working through it
A short exercise settles it for most organisations. List every AI system in use, including ones embedded in software you already licence. For each one, record who built it, whose name is on it, what it is used for, and whether that use matches what the supplier says it is for. Then ask whether the use case falls into any of the Annex III categories – areas such as employment decisions, access to essential services, credit assessment, education and critical infrastructure.
Most lists come back the same way: a set of ordinary productivity tools where you are the deployer and nothing is high-risk, plus one or two items that need a closer look. The closer look is where the effort belongs.
What applies regardless of role
Two things apply to providers and deployers alike. The Article 4 AI literacy obligation, covered in our guide to AI literacy under Article 4. And the Article 50 transparency duties, which have applied since 2 August 2026 and reach anyone whose systems interact with people or generate synthetic content.
For the full timeline of what is in force and what moved, see what applies now and what was delayed.
Training for the governance side
The Deployer and Governance Course is built for organisations that have established they are deployers and need to put oversight, documentation and internal controls in place. If the literacy obligation is the more pressing item, the EU AI Act Article 4 Training Course covers that ground directly.