Most organisations that buy or build on someone else’s AI system assume they’ll stay a deployer for as long as they use it. Article 25 is the provision that quietly breaks that assumption. It sets out three situations where a deployer, distributor, importer, or other third party automatically becomes the provider of a high-risk AI system, taking on the full Article 16 provider obligation set, whether or not that was the intention.
The three triggers are rebranding a system under your own name or trademark, making a substantial modification to a system that remains high-risk as a result, and changing a system’s intended purpose in a way that makes it high-risk when it wasn’t before. The second trigger is where most surprises happen. Article 3(23) defines a substantial modification as a post-market change that wasn’t foreseen in the original conformity assessment and that affects the system’s compliance with the Chapter III requirements, or changes what it was assessed to do. Fine-tuning a model on proprietary data, restructuring a retrieval pipeline, or training on a new domain-specific dataset can all qualify, depending on what the change actually does to the system, not on how the change was labelled internally.
The three triggers
| Trigger | What it requires | Legal basis |
|---|---|---|
| Rebranding | Placing your own name or trademark on a high-risk AI system already on the market | Article 25(1)(a) |
| Substantial modification | Modifying a high-risk system already on the market in a way that affects its Chapter III compliance, while it remains high-risk | Article 25(1)(b) |
| Purpose change | Changing a system’s intended purpose so that a system not originally high-risk becomes high-risk | Article 25(1)(c) |
A fourth, narrower trigger sits outside this Article 25(1) list under Article 25(3), where a high-risk AI system is a safety component of a product covered by Annex I harmonisation legislation, such as medical devices or machinery, the product manufacturer becomes the provider of the AI system when it places the integrated product on the market under its own name.
What counts as a substantial modification
Article 3(23) sets out the definition precisely: a change to an AI system after it’s placed on the market or put into service, which wasn’t foreseen or planned in the provider’s original conformity assessment, and which either affects the system’s compliance with the Chapter III, Section 2 requirements or changes the intended purpose it was originally assessed for. Three things have to be true together: the change happens after the system is already on the market, it wasn’t anticipated in the original assessment, and it actually affects compliance or intended purpose, not just internal implementation details that leave both untouched.
This is deliberately open-textured, and formal Commission guidance on where the line sits precisely is still developing. What’s already confirmed, specifically for general-purpose AI models, is narrower: the AI Office’s guidelines clarify that only significant modifications trigger provider status, while minor adjustments such as prompt customisation, retrieval integration, or basic fine-tuning on a narrow task do not. Extensive fine-tuning that changes a system’s intended purpose or performance profile carries the higher risk of crossing the line. This same boundary gets more complicated for multi-agent and agentic systems, where an orchestration layer built on top of third-party models can itself cross into provider territory for the composite system it creates.
A higher bar for systems that weren’t already high-risk
The purpose-change trigger appears to work differently depending on where a system starts. Turning an already high-risk system into a different high-risk system through modification is one thing. Turning a system that wasn’t high-risk at all into one that now is may require meeting something closer to the threshold for “development” or “having a system developed” under Article 3(3), though this specific reading isn’t yet settled by official guidance. If that reading holds, it would presuppose meaningful technical work, functional engineering, or a genuine commissioning relationship with whoever builds the change, rather than simply deploying a tool for a new purpose without touching how it works. On that basis, repurposing a general-purpose chatbot to screen job candidates without any development work behind that change would likely sit in a different, more careful analysis than retraining a model specifically to perform that screening function, but this distinction is worth treating as a reasonable interpretation rather than a confirmed rule until the Commission or AI Office addresses it directly.
What happens to the original provider
Once Article 25 applies, the original provider’s obligations for that specific system end. They don’t disappear from the value chain entirely, though: the original provider must still cooperate with the new provider, supplying the documentation and technical access needed to help the new provider meet its own obligations going forward.
Reducing the risk of being caught out
- Document any modification made to a vendor’s system, and assess its significance against the Article 3(23) test before deployment, not after.
- Address the Article 25 question directly in vendor contracts: which party bears provider obligations if the deployer makes changes, and what cooperation the original provider commits to providing if that happens.
- Treat fine-tuning, RAG integration, and custom training as events that trigger a fresh classification review, not as routine engineering work that sits outside compliance scope by default.
How Deeploy helps to keep oversight
The moment a deployer’s own modification triggers Article 25 is rarely obvious at the time it happens, a fine-tuning run, a new dataset, a restructured pipeline, and it’s exactly the kind of change that’s easy to lose track of across a growing AI estate.
Deeploy tracks how a system’s actual behaviour and configuration change over time, so a modification significant enough to raise the Article 25 question gets flagged against the classification already on record, rather than surfacing for the first time when a regulator or a vendor contract dispute asks who the provider actually is.
Frequently asked questions
Yes. Under Article 25, a substantial modification, retraining, rebranding, or repurposing a high-risk system for a new use, can shift an organisation from deployer to provider for that system, regardless of whether that was the intended outcome.
Their obligations for that specific system end, but they must still cooperate with the new provider, supplying the documentation and technical access needed for the new provider to meet its own obligations.
No. Article 25 allocates legal responsibility directly and can't be contracted away. A contract can, however, address which party bears the resulting obligations and what cooperation is owed if a modification does trigger reclassification, which is worth negotiating before deployment rather than after.
Possibly, though this isn't yet settled by official guidance. Turning a previously non-high-risk system into a high-risk one through a purpose change may require conduct closer to the "development" threshold under Article 3(3), meaningful technical work or a genuine commissioning relationship, rather than simply using an existing tool differently, but this is a reasonable reading rather than a confirmed rule.
Yes. The same three triggers apply to GPAI systems, and the AI Office's published guidance specifically addresses how the substantial modification threshold applies to fine-tuning and similar adaptation work on top of a GPAI model.
Potentially. If your fine-tuning constitutes a "substantial modification" to the original model, you may be reclassified as a provider and take on the associated obligations. The AI Office has provided partial guidance on this boundary but it remains a grey area. Extensive fine-tuning that changes the system's intended purpose or performance profile carries the higher risk of triggering provider status.
