You buy an AI tool, switch on an AI feature inside an existing SaaS application, or finetune a language model on your own data. In all three cases the AI Act asks the same question: which role do you have, and which set of duties comes with it? Someone who only uses a system carries a different load than someone who places it on the market. The tricky part is that you can shift roles without noticing: your own name on a tool, a modification that goes further than intended, or a use case the supplier never had in mind. This piece sets the four roles side by side, shows exactly when a deployer becomes a provider, and works through three recognisable situations.
The four roles at a glance
The AI Act defines four main roles in the value chain3. They are not equal: the provider carries the heaviest package, the other three carry a lighter, complementary responsibility.
The provider develops an AI system or GPAI model and places it on the market under its own name or trademark, or puts a high-risk system into service under its own name. The deployer uses a system under its own authority, unless it is a purely personal, non-professional activity. The importer is established in the EU and places on the market a system that carries the name or trademark of a party established outside the EU. The distributor is any other party in the chain that makes the system available on the market without altering its properties.
| Role | What you do | Core duties (short) | When enforceable | |---|---|---|---| | Provider | Places a system or GPAI model on the market under its own name | Art. 16: quality system, technical documentation, conformity assessment, CE marking, registration1 | High risk: 2 Dec 2027 (Annex III) / 2 Aug 2028 (Annex I); GPAI: since 2 Aug 2025 | | Deployer | Uses the system under its own authority | Art. 26: per instructions, human oversight, monitoring, log retention, informing staff1 | High risk: 2 Dec 2027 / 2 Aug 2028 | | Importer | Places a system from outside the EU on the market | Art. 23: four checks with the provider before supply, ten-year retention duty1 | High risk: 2 Dec 2027 / 2 Aug 2028 | | Distributor | Makes the system available without altering it | Art. 24: check marking and documentation, correct or recall on non-conformity1 | High risk: 2 Dec 2027 / 2 Aug 2028 |
Two things already apply now, for every role: the ban on unacceptable AI practices in Article 5 and the AI literacy duty of Article 4 have been in force since 2 February 20251. The European Commission has published guidelines that mark out exactly which practices Article 5 covers4. As of 27 July 2026, Article 4 was rewritten into a measures duty: you take measures that support AI literacy, you do not guarantee an individual skill level2. The high-risk duties for providers and deployers in the table only apply from 2 December 2027 for Annex III systems, after the shift the Digital Omnibus made to the amended Article 1132.
When you become a provider: the core of this piece
Article 25(1) states that a distributor, importer, deployer, or other third party is considered a provider of a high-risk AI system as soon as one of three things happens:
- You put your own name or trademark on the system.
- You modify the system substantially.
- You change the intended purpose so that a system that was not high risk becomes high risk.
This is not theoretical. It mostly happens to organisations that white-label AI, deploy a generic model for an Annex III use case, or develop a supplier tool into their own product1. From that moment, the lighter duties of your original role no longer apply; the full twelve points of Article 16 apply instead: quality management system, technical documentation, conformity assessment, CE marking, registration, and more1. Contracts can allocate those obligations differently, but only if you made those arrangements in advance and can show them. Build the role question into every AI project as a standing step, not a one-off check at purchase.
Three situations
Situation 1: standard SaaS with an AI feature
An organisation uses a CRM or HR platform in which the supplier has built in an AI summary or recommendation. The organisation uses the feature as delivered, without its own brand on it, without modifying the model, for the purpose the supplier described. This stays a deployer. The duties of Article 26 only start applying once the system is high risk; until then, Article 4 remains relevant, especially if the AI feature influences decisions about staff or customers. Keep the supplier's documentation: you will later turn it into your own file if the system does end up falling under Annex III.
Situation 2: finetuning a language model and offering it as your own tool
An organisation finetunes an open language model on its own customer data and offers the result as its own tool to clients, under its own product name. Putting your own brand on the result is exactly the first trigger of Article 25: the organisation becomes a provider, with the full duties of Article 16 for the resulting system and possibly the duties of Article 53 if the underlying model qualifies as a GPAI model5. Not every modification makes you a provider of the GPAI model itself: the indicative threshold sits at a modification that uses more than a third of the original model's training compute; stay below that, and your own duties remain limited to the modification you made. The provider role for the end system you offer under your own name to clients stands apart from that.
Situation 3: a different purpose than the supplier intended
An organisation buys an AI system the supplier positions for administrative document classification, then deploys it for screening job applicants or evaluating staff performance. That is the third trigger of Article 25: if that change of purpose brings the system into an Annex III category, such as recruitment and selection, a role shift with consequences follows. The organisation gets the full provider duties of Article 16, plus things it never budgeted for: human oversight by competent people with a mandate, informing the works council before deployment, and, for a public-law body or a private party delivering public services, a fundamental rights impact assessment under Article 271. That FRIA duty follows the Annex III calendar of 2 December 2027, and relevant parts of an existing DPIA may be reused or referenced.
Incidents: who you inform first (Article 26(5))
For a serious incident with a high-risk system, the deployer follows a fixed order, not a free choice: inform the provider first, and in parallel the importer or distributor and the competent market surveillance authority1. If the provider cannot be reached, the deployer then carries its own Article 73 notification duty, with its own deadlines. Write this two-channel pattern into your incident procedure now, including up-to-date supplier contacts, so you are not figuring out who is responsible for what during an actual incident.
Fines: the role decides who is on the hook, not how high the ceiling is
Article 99 has two ceilings: up to thirty-five million euro or 7% of worldwide turnover for prohibited practices under Article 5, and up to fifteen million euro or 3% for most other infringements1. For SMEs and start-ups, the lower of the two amounts applies, not the higher one. Which ceiling and party apply depends on whose duty was breached: a provider that skipped a conformity assessment, or a deployer that never set up human oversight. Role determination under Article 25 is therefore not only a compliance question; it also decides who the supervisory authority approaches.
Five-question self-test
- Does your name or trademark appear on the system, or does the original supplier's?
- Have you substantially modified the system after delivery, for example a different underlying model, new functionality, or your own training data?
- Are you deploying the system for the purpose the supplier described, or for something else?
- If the purpose has changed: does that use bring the system into an Annex III category?
- Do you know who to inform first in a serious incident, and is that contact still current?
If you answered yes to question 1 or 2, or "something else" plus "yes" to questions 3 and 4: assume a role shift toward provider, and break the twelve points of Article 16 into separate work packages.
Frequently asked questions
Can I be both a provider and a deployer at the same time?
Yes. That happens, for example, when you build or modify a system yourself and also use it internally: then you carry both sets of duties for the same system, and they add up. You can also hold a different role for different systems.
Does the Digital Omnibus change who counts as a provider?
No. The definition and the three triggers in Article 25 are unchanged. The Digital Omnibus mainly shifts the application dates of the high-risk duties and rewrites Article 4 into a measures duty.
If the high-risk duties only apply in 2027, do I need to do anything now?
Yes, on two points. Article 4 and Article 5 have already applied since February 2025, for every role. And if you already know a system will fall under Annex III in 2027, informing the works council and setting up human oversight takes more time than you'd think: start that track well ahead of the deadline.
What if the provider does not respond during a serious incident?
The notification duty to the provider still stands as the first step, but the responsibility shifts: the deployer then gets its own notification duty under Article 73, with its own deadlines toward the supervisory authority.
Does finetuning automatically make me a provider?
Not automatically for the underlying GPAI model: the indicative threshold sits at a modification using more than a third of the original training compute. If you do offer the result to clients under your own name or trademark, you become a provider of that end system regardless.
What is the difference between an importer and a distributor?
The importer is the EU party that first places a system from outside the EU on the market and must check four things with the provider beforehand. The distributor is any other party further along the chain that makes the system available without altering it, and mainly has to check marking, documentation, and compliance by the provider and importer.
