Articles 3, 16, 25 and 26 · Roles · Accountability
Provider vs deployer under the EU AI Act
Short answer: a provider develops or has an AI system developed and places it on the market or puts it into service under its own name. A deployer uses the system under its authority. Buying a product does not shift every responsibility to the vendor, and a user that rebrands or changes a system can become its provider.
01The difference at a glance
AI Act roles describe concrete activities, not abstract job titles. The same organisation may hold different roles for different systems and may sometimes combine several roles in one value chain.
| Question | Provider | Deployer |
|---|---|---|
| What does it do? | Develops or has the system developed, then places it on the market or puts it into service under its own name or trademark, whether for payment or free. | Uses the system under its authority, except for personal non-professional activity. |
| Example | A company offers an automated recruitment platform under its own brand. | An employer uses that platform to filter applications. |
| Key question | Who defines the offered system, its intended purpose and declared conditions? | Who decides the real context, input data and how the output is acted upon? |
| Common mistake | Assuming it is always the person who physically wrote the code. | Treating it as a passive customer with no duties of its own. |
02How high-risk duties differ
For high-risk systems, the distinction becomes operational. Providers design and document system compliance; deployers govern its use in the real setting. This simplified outline does not replace the applicable articles or sector-specific law.
| Provider | Deployer |
|---|---|
| Ensures the system meets high-risk requirements, including risk management, data governance, documentation, registration, transparency, oversight and robustness. | Uses the system in line with instructions and adopts appropriate technical and organisational measures. |
| Runs a quality-management system, keeps documentation and takes corrective action when required. | Assigns oversight to people with the competence, training, authority and support to intervene effectively. |
| Gives integrators and users the information needed to understand and operate the system. | Controls input data where it has that control, monitors operation, keeps logs under its control and reports risks or incidents. |
03When a deployer can become a provider
Article 25 identifies important role changes for high-risk systems. A deployer, distributor, importer or other third party may take on provider obligations when it:
- puts its name or trademark on a high-risk system already placed on the market or put into service;
- makes a substantial modification while the system remains high-risk;
- changes the intended purpose of a system not classified as high-risk so that it becomes high-risk.
Integrating a general-purpose model, customising a product or changing its use does not always lead to the same answer. Intended purpose, documentation, the actual modification and the resulting risk all matter. The useful question is not merely “did we buy it?”, but “what did we transform and under whose name is it put into service?”.
If you are taking stock for your own company, AI Act for business puts these questions in the order worth tackling them.
04Checklist before buying or using a system
- Map the chain: who develops, integrates, sells, decides the purpose and acts on the output.
- Define the context: affected people, influenced decisions, data and consequences of failure.
- Check classification: prohibited practice, high-risk use, transparency duty or another regime.
- Ask for evidence: instructions, limits, logs, data quality, performance, oversight, incidents and updates.
- Assign internal authority: someone must be able to stop or correct use, not merely watch it.
- Track changes: new purposes, fine-tuning, integrations and rebranding may alter the role.
05Transparency also divides the work
Article 50 shows why the roles are not interchangeable. In simplified terms, providers make certain interactions or synthetic outputs recognisable; in situations such as publishing deepfakes or operating some biometric systems, particular duties fall on deployers. See the guide to AI transparency obligations for details.
06Why the game asks who is responsible
In NO AI ACT, recognising risk is not enough. In “The Opaque Tender”, a public body buys a system without obtaining documentation or building governance around its use. Blaming every failure on the vendor produces a weak report: the provider must make the system verifiable, while the deployer decides how it enters a process and how it is supervised.
07Official sources and limits
The authoritative source is Regulation (EU) 2024/1689 on EUR-Lex. For navigation, consult the Commission AI Act Service Desk on Article 3, Article 25 and Article 26, together with the Commission's Navigating the AI Act FAQ. Always check the current consolidated text and applicable sector law.