Your role is not a label you select. It is a legal consequence of what you do with a system, and it can change without anyone sending you a notice. A company that buys a high-risk AI system, puts its own logo on the interface and rolls it out to staff has not made a branding decision. It has made itself the provider of that system, with everything Article 16 attaches to the word.
The six AI Act roles, and why you hold more than one
Regulation (EU) 2024/1689 distributes obligations across six operator roles. Each is defined by conduct, so the determination is made per system and not per company.
- 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. This role carries almost every substantive obligation in the high-risk regime.
- Deployer - uses an AI system under its own authority in a professional capacity. The duty set is real but materially lighter, and it is built around using the system the way the provider assessed it.
- Importer - established in the Union and places on the Union market a system carrying the name or trademark of a person established outside the Union.
- Distributor - anyone else in the supply chain who makes a system available on the Union market, other than the provider or the importer.
- Product manufacturer - places a product on the market together with a high-risk AI safety component under its own name or trademark, and by doing so takes the provider seat. Art 25(3)
- Authorised representative - appointed in writing by a provider established outside the Union to act for it within the Union.
These roles stack. Picture a mid-sized insurer. It builds an internal pricing model for health cover, which is an Annex III point 5 use case, so it is the provider and the deployer of that model at once. It buys a CV screening tool from a US vendor for its own hiring, so it is the deployer of that one, and it would additionally be the importer only if it made the vendor-branded system available to others on the Union market rather than using it internally. It resells an unmodified, vendor-branded claims-triage tool to a subsidiary, so it is the distributor of a third. Three systems, one legal entity, four separate role assignments, and every duty attaches to the specific system it arose from. If you want the per-system answer for your own estate, the free AI Act triage classifier runs role determination as its final stage.
Provider vs deployer: what each role actually owes
The reason role determination matters is the size of the gap. Nearly the whole compliance burden of the high-risk regime sits on one side of it.
| Duty | Provider | Deployer |
|---|---|---|
| Core high-risk requirements | Articles 9 to 15 in full: risk management, data governance, technical documentation, logging, instructions for use, human oversight, accuracy, robustness, cybersecurity | None directly. You operate inside the design and the instructions for use |
| Technical documentation | Annex IV, nine blocks, drawn up before market placement, kept current, retained around ten years | Records of your own use only |
| Conformity assessment | Article 43, via Annex VI internal control or the Annex VII notified-body route | None |
| Declaration and marking | EU declaration of conformity under Article 47, plus CE marking | None |
| EU database | Registration under Article 49, and registration even where you self-assess out of high-risk under Article 6(3) | Not the provider registration |
| Article 6(3) derogation | Must document the assessment before market placement, per Article 6(4) | Cannot claim it for a system you did not place on the market |
| Article 50 transparency | 50(1) chatbot disclosure, and 50(2) synthetic-content marking from 2 December 2026 for systems placed on the market before 2 August 2026, from placement for later ones | 50(3) emotion and biometric notice, 50(4) deepfake and public-interest text |
| Penalty exposure | The higher of 15,000,000 EUR or 3% of total worldwide annual turnover. SMEs and start-ups pay the lower of the two under Article 99(6) | The higher of 15,000,000 EUR or 3% of total worldwide annual turnover. SMEs and start-ups pay the lower of the two under Article 99(6) |
Two rows deserve attention. The penalty tier is the same for both roles, so the flip does not raise your exposure ceiling, it raises the number of ways you can breach and reach it. And Article 50 runs on its own logic: the disclosure duties split provider and deployer differently from the high-risk regime, which is why a company can be a pure deployer with no Article 16 duties at all and still owe the Article 50 transparency disclosures from 2 August 2026.
The Article 25 flip: three acts that make you a provider
Article 25 is the provision that catches organisations who never intended to build anything. A deployer, importer or distributor is treated as a provider of a high-risk system, and inherits the provider obligations, on any one of three triggers.
| Trigger | What it looks like | What it takes to fire |
|---|---|---|
| Name or trademark on a high-risk system already on the market | You licence a high-risk tool and present it to staff or customers under your own brand | Branding alone. No code change, no retraining, no new feature is required |
| Substantial modification that leaves the system high-risk | You retrain on your own data, or extend the system past what its assessment covered | A post-market change not foreseen in the initial conformity assessment that affects compliance or changes intended purpose Art 3(23) |
| Modified intended purpose that makes a system high-risk | You point a general-purpose assistant at CV shortlisting, credit decisions or access to public benefits | Applies to any system, including a general-purpose AI system, and applies even where the system was not high-risk before you touched it |
The flip is all or nothing. Inheriting provider status hands you the full Article 16 obligation set, not the parts that seem proportionate to what you changed. Rebranding a system you did not build still obliges you to hold the Articles 9 to 15 requirements, produce Annex IV technical documentation, run conformity assessment under Article 43, issue the EU declaration of conformity and register the system. There is no reduced tier for the accidental provider, and no authority sends you a notice when the trigger fires.
The corollary matters just as much. Once you are the provider of the modified or rebranded system, the vendor conformity assessment describes the vendor system, not yours. You cannot rely on paperwork that was drawn up for a different configuration and a different intended purpose, and you will need the underlying technical information to build your own. Article 25(2) obliges the original provider to cooperate and to make available the information reasonably required to meet the Article 16 obligations, but the practical time to pin down what that means, and in what format and on what timescale, is before signature.
Substantial modification under Article 3(23), and where the line sits
Article 3(23) is the definition that decides trigger two. A substantial modification is a change made to an AI system after it has been placed on the market or put into service, which was not foreseen or planned in the initial conformity assessment, and which affects compliance with the high-risk requirements or changes the intended purpose.
Read it as two limbs, both of which have to be satisfied.
- Not foreseen in the initial assessment. A provider that anticipated periodic retraining, documented it, and covered it in its conformity assessment has already absorbed that change. Updates inside that envelope do not flip anyone. Changes the provider never contemplated fall outside it.
- Affects compliance or changes intended purpose. Cosmetic and integration work generally does not. Changing what the system decides, what data it decides on, or how a human can intervene generally does.
Trigger two only applies where the system stays high-risk after the change. If your modification takes a high-risk system out of scope entirely, you are in a different analysis, and one you should document with the same care as the Article 6(3) derogation assessment. If your modification takes a system that was not high-risk into a high-risk use, you are in trigger three, not trigger two.
Be honest about how thin the guidance is here. The Commission missed its February 2026 statutory deadline for the Article 6 high-risk classification guidelines, so authoritative worked examples are scarce across the whole classification question, and modification sits directly downstream of it. The conservative reading is the defensible one: if you cannot point to a line in the vendor conformity assessment that anticipated your change, assume the change was not foreseen and record why you concluded it did or did not affect compliance.
Article 25(3): when the product manufacturer is the provider
Article 25(3) handles the embedded case. Where a high-risk AI system is a safety component of a product and is placed on the market together with that product under the name or trademark of the product manufacturer, the manufacturer is the provider of the AI system. The component supplier does not carry it for you.
This is the Annex I route into the high-risk regime, where the AI is a safety component of, or is itself, a product covered by Annex I harmonisation legislation requiring third-party conformity assessment. Two practical points follow. The Digital Omnibus gave AI embedded in Machinery Regulation products a targeted carve-out from the AI Act direct high-risk rules, layering the AI-specific requirements in through the Machinery Regulation instead, so a machinery manufacturer reads a different rulebook for the same component. Medical devices and toys remain fully in scope. And the applicable date for embedded Annex I systems is 2 August 2028, not the 2 December 2027 date that governs standalone Annex III systems.
Fine-tuning a GPAI model can make you the provider of a new model
Two different flips live in the same neighbourhood and they are easy to confuse. Article 25(1) operates on AI systems: repurposing a general-purpose AI system into a high-risk use makes you the provider of a high-risk system. The GPAI rules operate on models: fine-tuning or substantially modifying a general-purpose AI model can make you the provider of a new model, which pulls you into the Article 53 baseline.
That baseline is Annex XI technical documentation, Annex XII information for downstream providers, a copyright policy and a public summary of training data. If the resulting model crosses into systemic risk, presumed above 10^25 FLOPs of training compute under Article 51, Article 55 adds model evaluation and adversarial testing, systemic-risk assessment and mitigation, serious-incident reporting to the AI Office, cybersecurity protection and Commission notification within two weeks. The full GPAI obligation set is set out separately, including the Article 3(63) generality test and the indicative 10^23 FLOPs figure that marks a model as general-purpose in the first place.
The one-third-compute threshold is guidance, not law. The July 2025 Commission guidance offers an indicative threshold of about one third of the original training compute for when a fine-tune creates a new model provider. It is an interpretive figure, it is not written into Regulation (EU) 2024/1689, and it is not a safe harbour. Fine-tunes below it can still change a model behaviour enough to matter, and downstream providers frequently cannot measure the original compute at all. Document the reasoning you actually used rather than pointing at a number you cannot verify.
Four ways companies become an accidental provider
The same four mistakes recur. None of them looks like a compliance decision at the moment it is made, which is precisely the problem.
1. Assuming vendor compliance covers you
A CE marking and a declaration of conformity attach to the vendor system as assessed. They are not a transfer of liability and they say nothing about your deployer duties, which you owe in your own right whatever the vendor has done. A procurement team that files the compliance pack and considers the matter closed has documented the vendor position, not its own. Worse, the pack becomes actively misleading the moment any Article 25 trigger fires, because it then describes a system you are no longer running.
2. Rebranding a purchased system
This is the cheapest way to become a provider and the one teams walk into blind. Putting your name or trademark on a high-risk system already on the market is trigger one on its own. It does not require you to change a single line of code. White-labelling, reselling under your own brand, or presenting a licensed tool to customers as your product all reach it. If your brand team is applying a logo to a third-party high-risk system, that is a compliance event and it should route through the same review as a code change.
3. Repurposing a general tool into a high-risk use
Trigger three applies to any system, including a general-purpose AI system, and it does not care that the system was harmless in its prior use. Picture a general-purpose assistant licensed for drafting internal memos. A team quietly starts using it to rank job applicants against a role description. The tool has not changed at all, but the intended purpose now sits in Annex III point 4, and the organisation that made that decision is the provider of a high-risk system. See the recruitment and HR guide for how quickly the employment use case is reached. This mistake is usually invisible to central compliance because nothing was procured and nothing was announced.
4. Procurement contracts that never allocate the triggers
AI vendor contracts commonly carry a general warranty of AI Act compliance without allocating the Article 25 triggers. That warranty is close to worthless if a trigger fires on your side. Article 25(1)(a) does preserve contractual arrangements that allocate the obligations otherwise, so the branding trigger is one you can and should address in the contract. Triggers two and three follow the conduct, and a clause cannot undo a substantial modification or a change of intended purpose that you actually made. A contract that actually handles this does four things: it states who may apply branding and on what terms; it defines which modifications the provider has anticipated in its conformity assessment and which fall outside it; it records the assessed intended purpose in writing so a departure is detectable; and it obliges the provider to hand over the information you would need to stand up as provider if the flip did land, on notice, both ways.
The practical defence against all four is the same. Determine the role per system, write down the determination with its date and the facts it rested on, and re-run it whenever the branding, the model or the use changes. That record is what you would put in front of a market surveillance authority, and it is the difference between a documented role determination and a rebranding decision nobody can account for. The penalty tier that sits behind it is the higher of 15,000,000 EUR or 3% of total worldwide annual turnover. The primary text is worth reading directly at EUR-Lex, alongside the European Commission AI policy pages.