Article 25 provides that a deployer, importer, distributor or other third party shall be considered a provider of a high-risk AI system 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. A substantial modification is defined as a change to a system after placing on the market or putting into service that affects compliance with the Act or results in a change to the intended purpose. Where Article 25 applies, the original provider is no longer considered the provider for the modified system in the circumstances the article sets, and the person who made the change must meet provider obligations, with cooperation and information duties between the parties.
What is a substantial modification?
Article 3(23) defines substantial modification as a change to an AI system after it has been placed on the market or put into service, which affects the compliance of the system with the Act or results in a change to its intended purpose. The definition has two limbs: compliance effect and purpose change. A change that affects compliance includes a change to the model's behaviour, the data, the safety function, the oversight design, or the operating conditions, where that change affects whether the system still meets the Chapter III requirements. A change that only updates a user interface, fixes a spelling error, or patches a security vulnerability without affecting compliance or purpose is less likely to be substantial, but the assessment must be made on the actual effect, not on the label given to the change.
How does rebranding trigger Article 25?
Putting a name or trademark on a high-risk system already placed on the market or put into service makes the person who does so the provider, where the other conditions in Article 25 are met. Rebranding is not a cosmetic act in this regime: the brand owner becomes responsible for the system's compliance, because deployers, authorities and affected persons will look to the brand owner as the provider. A distributor that only sells a system under the original provider's brand, without putting its own name on it, does not trigger this limb on those facts. A white-label arrangement where the brand owner is a different legal person from the builder should therefore be structured with the provider duties in mind from the start, not discovered after the product is supplied.
For the broader regulatory framework, see provider responsibilities.
How does a change of intended purpose trigger Article 25?
Modifying the intended purpose of an AI system that was not high-risk, so that it becomes high-risk, makes the person who modifies the purpose the provider of the resulting high-risk system. The trigger is the combination of purpose change and new high-risk status. A deployer that takes a general tool and uses it for a listed Annex III purpose, a distributor that markets a system for a new high-risk use, and a third party that adapts a system for a new purpose can each trigger the provision. The person who changes the purpose must then carry out the provider duties, including conformity assessment, documentation and registration, before the system is supplied or used for the new purpose. The original provider's duties for the original purpose do not automatically cover the new purpose.
What happens to the original provider?
Where Article 25 applies, the provider that originally placed the system on the market or put it into service shall no longer be considered the provider for the modified system, subject to the conditions and cooperation duties in the article. The original provider must still cooperate, provide information, and give access to the documentation and technical information needed for the new provider to meet its duties, to the extent the article requires. The original provider's responsibility for the system in its original form, and for the period before modification, is not erased by the change. The record should show the modification, the date, the person who made it, the new provider, and the information transferred, so that responsibility for each version of the system is traceable.
How should modification decisions be governed?
A modification governance process should require a proposal, a compliance and purpose impact assessment, a decision on whether the change is substantial, a decision on whether Article 25 is triggered, and a plan for the provider duties that follow. The process should cover model updates, data changes, integration changes, branding changes, and purpose changes, and should require sign-off by a person with authority to accept provider responsibility. A change log should record every modification, its classification, and its reviewer, so that a series of small changes that together amount to a substantial modification is visible. Where the assessment is uncertain, the change should be treated as substantial and reviewed, rather than released on an assumption.
Continue with provider definition and edge cases.
What is not decided here?
This guide explains Article 25 and substantial modification in outline. It does not decide whether any particular change is substantial, whether a purpose has been modified, or whether a particular person has become the provider. Those questions need the change, its effect on compliance, the purpose before and after, and the branding facts, read against Articles 3(23) and 25 in the consolidated text. Changes that move a system into high-risk status, or that rebrand a high-risk system, should be confirmed with a competent authority or legal adviser before the changed system is supplied or used.
Frequently asked questions
Is every software update a substantial modification?
No. A substantial modification is a change after placing on the market or putting into service that affects compliance or changes intended purpose. Routine patches that do not affect compliance or purpose are less likely to be substantial, but the effect must be assessed, not assumed from the word update.
Does Article 25 apply to non-high-risk systems?
It applies where a modification makes a system high-risk, or where a high-risk system is rebranded or substantially modified. The purpose-change limb is specifically aimed at a non-high-risk system that becomes high-risk through the change.
Can the original provider remain responsible after a modification?
The original provider must cooperate and provide information, but where Article 25 applies it is no longer considered the provider for the modified system. Responsibility for the original version and for the period before modification remains a separate question, to be recorded in the change file.
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 ↗