In short
- Article 25 lists 3 triggers that turn a deployer, distributor or importer into a provider of a high-risk system.
- Putting your own name or trademark on a high-risk system already on the market is trigger 1, and it catches white labelled products routinely.
- Changing the intended purpose of a system that was not high risk, so that it becomes high risk, is trigger 3. It applies to general purpose models too.
- The consequence is the full provider set: Annex IV technical documentation, conformity assessment, and the Article 73 reporting duty with its 2 to 15 day clocks.
- A contract cannot move a statutory obligation. Article 25(2) requires the original provider to cooperate and hand over information, which is the clause worth negotiating instead.
What do AI assistants say about your organisation?
Model answers are becoming a channel your communications team does not control. EntityRise audits how assistants describe your company and whose name they give instead. From $19.
Most organisations file themselves as deployers and stop reading. The heavy obligations belong to providers, and the provider is the vendor.
Article 25 is the provision that quietly reassigns that role, and it does so by describing conduct rather than by asking anyone’s intention.
01Which three triggers move provider status?
| Trigger | Provision | Common way it happens |
|---|---|---|
| Own name or trademark on a high-risk system | Article 25(1)(a) | White labelled screening or scoring tool |
| Substantial modification of a high-risk system | Article 25(1)(b) | Retraining on internal data, changed thresholds |
| Change of intended purpose making a system high risk | Article 25(1)(c) | General purpose model pointed at hiring decisions |
The third trigger is the one that reaches organisations that never bought anything labelled high risk. A general purpose model is not high risk in itself. Point it at candidate ranking, and the intended purpose has changed into an Annex III use.
02What actually counts as a substantial modification?
A change that affects compliance or alters the intended purpose, rather than any change at all.
Routine operation does not trigger it. Applying a vendor patch does not. Changing a decision threshold so that the system rejects a different population, retraining on your own historical data, or extending the system to a new category of decision are all capable of doing so, because each affects the basis on which conformity was assessed.
The honest position is that the line is not bright, and organisations should document why they concluded a change was not substantial. That memo is cheap to write at the time of the change and expensive to reconstruct two years later.
03What obligations arrive with the title?
The full provider set, not a subset.
| Obligation | Provision | Applies from |
|---|---|---|
| Risk management system | Article 9 | 2 Dec 2027 |
| Technical documentation, 9 points | Annex IV | 2 Dec 2027 |
| Automatic logging | Article 12 | 2 Dec 2027 |
| Conformity assessment and CE marking | Chapter III | 2 Dec 2027 |
| Serious incident reporting | Article 73 | 2 to 15 days |
Annex IV is the row that surprises people. It requires a general description, a detailed account of the development process across seven sub-points, monitoring and control details, a justification of the performance metrics, the risk management system, a record of lifecycle changes, the standards applied, the declaration of conformity and the post-market monitoring plan.
Assembling that pack for a system somebody else built is possible only with that party’s cooperation, which is exactly what Article 25(2) is for.
04What should the contract say instead?
Not that the vendor remains responsible, because that clause does nothing.
Article 25(2) provides that once another party becomes the provider, the original provider is no longer considered the provider of that specific system, but must cooperate closely, make information available, and provide the reasonably expected technical access needed for the new provider to comply.
The clause worth drafting is the operational version of that duty, and it belongs in the questions asked before signing. Name the artefacts you will need, the format, and the time within which they arrive: the Annex IV pack, training data documentation sufficient for Article 10, the logging schema, and a contact who responds inside the Article 73 window rather than inside a standard support SLA.
05How should this be checked?
With one question per system, asked once a year.
Whose name does the customer see, what have we changed since procurement, and what is it deciding now that it was not deciding then? Three answers, recorded, with a date. Any system where the answers have drifted since the last review is the one to look at properly.
The failure mode is not a company deciding to become a provider. It is a company that became one eighteen months ago through an ordinary sequence of product decisions, and finds out during an inspection.
06Frequently asked questions
What makes a deployer legally a provider under the AI Act?
Three things. Placing a high-risk system on the market under your own name or trademark, making a substantial modification to a high-risk system already on the market, or changing the intended purpose of a system so that it becomes high risk.
Does fine tuning a model make you a provider?
It can. Fine tuning is capable of being a substantial modification, and if the result is shipped under your own brand the naming trigger applies independently. The question is not whether you trained anything but what you changed and whose name is on the output.
Can a contract keep the provider obligations with the vendor?
No. Article 25 allocates the obligations by conduct rather than by agreement, so a clause assigning regulatory responsibility to the supplier does not move a duty the Regulation places on you.
What does the original provider have to do once you become the provider?
Cooperate. Article 25(2) removes the original provider's status for that specific system while requiring it to provide the information and technical access reasonably needed for the new provider to meet its obligations.
07References and method
- Regulation (EU) 2024/1689, Article 25, for the three circumstances in which another party is considered a provider and for the cooperation duty in Article 25(2).
- Regulation (EU) 2024/1689, Article 3(3) and Article 3(4), for the definitions of provider and deployer.
- Regulation (EU) 2024/1689, Annex IV and Article 73, for the technical documentation and serious incident reporting obligations that follow provider status.
- Application dates reflect the amendments approved by the European Parliament on 16 June 2026, deferring Annex III high-risk obligations to 2 December 2027.