A deployer becomes a provider under Article 25 where it puts its name or trademark on a high-risk system already placed on the market or put into service, makes a substantial modification to a high-risk system that remains high-risk, or modifies the intended purpose of an AI system that was not high-risk so that it becomes high-risk. The consequence is that the deployer must meet provider obligations for the resulting system, including ensuring compliance with Chapter III Section 2, quality management, documentation, conformity assessment, declaration, CE marking and registration, in the circumstances the Act sets. The change should be assessed before it is made, the original provider should be informed and should cooperate, and the new provider duties should be planned before the changed system is supplied or used.
Which deployer actions trigger Article 25?
The first trigger is rebranding: putting the deployer's name or trademark on a high-risk system already placed on the market or put into service. The second is substantial modification: changing a high-risk system after placement in a way that affects compliance or changes its intended purpose, where the system remains high-risk. The third is purpose change: modifying the intended purpose of a non-high-risk system so that it becomes high-risk. Each trigger is an action by the deployer, not a label in a contract. A deployer that rebrands a system for internal use, fine-tunes a model in a way that changes its behaviour and compliance, or extends a tool to a listed Annex III use has taken an action that must be tested against Article 25, even where the deployer still thinks of itself as only a user.
What is not a trigger?
Ordinary use in accordance with instructions, configuration within the provider's specified parameters, routine maintenance, and security patching that does not affect compliance or purpose are not, on their own, Article 25 triggers. A deployer that uses a system as instructed, with the data and users the provider specified, remains a deployer. A deployer that customises a user interface, adds a dashboard, or integrates a system through a standard interface, without changing the system's behaviour, compliance or purpose, needs a careful assessment, but the integration alone is not automatically a substantial modification. The record should describe the change, its effect on compliance and purpose, and why it was or was not treated as substantial, so that the decision is visible.
For the broader regulatory framework, see deployer responsibilities.
What duties follow a role change?
A deployer that becomes a provider must meet the provider duties in Articles 16 to 21 and the conformity duties in Articles 43 to 49, for the system in its new form. That includes ensuring the system meets the Chapter III Section 2 requirements, operating a quality management system, drawing up and keeping technical documentation, carrying out the conformity assessment, drawing up the declaration, affixing CE marking, and registering the system, where those provisions apply. The new provider must also supply instructions for use, operate post-market monitoring, and report serious incidents. Those duties cannot be met retrospectively after the changed system is already in use. The plan, the evidence and the conformity work must be in place before the changed system is supplied or used for the new purpose.
What must the original provider do?
Article 25 requires the original provider to cooperate with the new provider, and to provide the information and technical access needed for the new provider to meet its obligations, subject to the conditions in the article. The original provider must provide the documentation, the technical information, and the cooperation that the new provider reasonably needs, while protecting its intellectual property and trade secrets through appropriate handling. The original provider is no longer considered the provider for the modified system in the circumstances the article sets, but remains responsible for the system in its original form and for the period before modification. The cooperation should be recorded, with the information supplied, the date, and any limits agreed, so that a later dispute about access can be resolved from the record.
How should a deployer plan a change that might trigger Article 25?
A deployer planning a rebranding, a substantial change, or a purpose change should start with a change proposal, a classification assessment on the new facts, an Article 25 assessment, and a plan for the provider duties that would follow. The deployer should inform the original provider early, request the information needed, and assess whether it has the competence, resources and systems to act as provider. Where it does not, it should not make the change, or should arrange for the original provider or another competent party to act as provider for the changed system. The decision, the assessment, and the plan should be recorded and approved before the change, with a named owner for the new provider duties if the change proceeds.
Continue with Article 25 substantial modification and change of role.
What is not decided by this guide?
This guide explains Article 25 from the deployer side in outline. It does not decide whether any particular rebranding, modification or purpose change triggers Article 25, or whether a deployer has met the provider duties that follow. Those questions need the change, its effect on compliance and purpose, and the classification on the new facts, read against Articles 3(23) and 25 in the consolidated text. A deployer planning a change that could make it a provider should confirm the position with a competent authority or legal adviser before the change, because the duties that follow are substantial and cannot be assumed informally.
Frequently asked questions
Does fine-tuning a model always make the deployer a provider?
No, not always. Fine-tuning must be tested as a substantial modification and as a purpose change. Fine-tuning that affects compliance or changes the intended purpose, and makes a non-high-risk system high-risk or keeps a high-risk system high-risk after substantial change, can trigger Article 25. Fine-tuning within the provider's specified parameters that does not affect compliance or purpose is assessed differently.
Can a deployer avoid Article 25 by keeping the original brand?
Keeping the brand avoids the rebranding trigger, but not the substantial modification or purpose-change triggers. A deployer that modifies a system substantially or changes its purpose can still become the provider even where the original brand remains.
Must the original provider help the new provider?
Yes, Article 25 requires the original provider to cooperate and to provide the information and technical access the new provider needs to meet its obligations, subject to the conditions in the article. The cooperation should be recorded, and intellectual property should be handled through appropriate safeguards.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689 ↗AI Act Service Desk timeline ↗European Commission regulatory framework for AI ↗