Article 25 provides that a distributor, importer, deployer or other third party is considered to be the provider of a high risk AI system where it puts its name or trademark on a system already placed on the market, makes a substantial modification to a high risk system that remains high risk, or modifies the intended purpose of a system that was not high risk so that it becomes high risk. Substantial modification is defined in Article 3 by reference to a change that was not foreseen or planned in the initial conformity assessment and that affects compliance or changes the intended purpose. Whether a particular update is substantial must be assessed on the facts, with the conformity file and the intended purpose as the starting point, and confirmed with a competent authority or legal adviser where the answer is borderline.
How does the AI Act define substantial modification?
Article 3 defines substantial modification as a change to an AI system after its placing on the market or putting into service which was not foreseen or planned in the initial conformity assessment carried out by the provider and as a result of which the compliance of the AI system with the requirements in Chapter III, Section 2 is affected or a change to the intended purpose for which the AI system has been assessed occurs. That definition has two limbs. The first is foreseeability and planning: a change that was foreseen and planned in the initial assessment, with the assessment covering the change, is not substantial modification on that ground. The second is effect: the change must affect compliance with the high risk requirements or change the assessed intended purpose. A change that meets both limbs is substantial. A change that meets neither is not. A change that meets one limb but not the other needs careful reasoning, recorded with the evidence. The definition should be read with Article 25, which deals with who becomes the provider when a substantial modification is made, and with the sector legislation, which may have its own change control and re assessment rules. The sector rules and the AI Act rules must both be satisfied.
What kinds of product change raise the question?
Product changes that raise the substantial modification question include changes to the AI model, to training or validation data, to sensors or actuators, to safety logic, to the user interface that affects human oversight, to the operating environment, to the intended purpose as presented in instructions or marketing, and to the integration of the AI system with other systems. Software updates are a common source of change, because an update can alter behaviour without any visible change to the product. A model retrained on new data, a threshold changed in a safety function, a new data source added to a diagnostic function, or a feature added that extends the product to a new user group can each be substantial. Routine maintenance, like for like replacement of a component, and bug fixes that restore the assessed behaviour without changing the intended purpose or affecting compliance may not be substantial, but that conclusion must be evidenced rather than assumed. The change record should describe the change, the reason, the parts affected, the testing performed and the assessment against the definition, with the initial conformity assessment cited. A change log that records only version numbers does not answer the question.
For the broader regulatory framework, see products, machinery and vehicles overview.
How does a change to intended purpose differ from a substantial modification?
A change to intended purpose is treated separately in Article 25(1)(c). Where a person modifies the intended purpose of an AI system, including a general purpose AI system, that has not been classified as high risk and has already been placed on the market or put into service, in such a way that the system becomes high risk under Article 6, that person is considered to be the provider of the high risk system. That provision matters for products because a product supplied for one purpose can be repurposed by a distributor, deployer or integrator for a different purpose. For example, a general vision system supplied for quality inspection can be repurposed for safety guarding, or a consumer product can be repurposed for a clinical or workplace safety use. The repurposing person must then meet the provider obligations for the high risk system, and the initial provider is no longer considered the provider of that specific system, subject to the cooperation duties in Article 25(2) and the exception where the initial provider clearly specified that the system is not to be changed into a high risk system. The boundary between use within the intended purpose and repurposing must be examined in the instructions, the marketing and the actual use, not in a disclaimer alone.
What happens when a third party becomes the provider?
Where Article 25(1) applies, the third party is subject to the provider obligations under Article 16 for the high risk system. That includes the quality management, documentation, conformity assessment, registration, post market monitoring and corrective action duties that apply to providers, to the extent they apply to the system as modified or repurposed. The initial provider must closely cooperate with the new provider and make available the necessary information and reasonably expected technical access and assistance required for fulfilment of the obligations, in particular for conformity assessment, subject to the exception described in the previous section and to the detailed cooperation provisions added by Regulation (EU) 2026/1744. Contractual allocation of obligations does not by itself change the regulatory position, although Article 25(1)(a) preserves contractual arrangements for the name or trademark case. In practice, a modification or repurposing should be planned as a new provider project, with access to the original documentation, test evidence and limitations, rather than as a minor configuration change. A third party that makes a substantial modification without access to that material will struggle to meet the provider duties, and should seek the material and the cooperation before the change is released.
How should product manufacturers plan for foreseeable changes?
Manufacturers can reduce the substantial modification burden by planning for changes in the initial conformity assessment. The assessment can foresee defined updates, model retraining within defined limits, data refreshes, and configuration options, and can set out the testing and documentation required for each planned change. Where a change stays within the foreseen and planned envelope and does not affect compliance or change the assessed intended purpose, it is less likely to be a substantial modification. Where a change goes beyond the envelope, a fresh assessment is needed. The planning must be genuine: a general statement that all future updates are foreseen does not satisfy the definition. The envelope should specify the parameters that can change, the limits, the tests, the acceptance criteria and the documentation. The product instructions should also state the limits of the intended purpose and the changes that require the manufacturer to be consulted. That planning should be reviewed when the sector legislation, the standards or the AI guidance changes, because a change that was foreseen under an earlier standard may need a fresh assessment under a later one. The record of the planning should be kept with the conformity file.
Continue with machinery and safety components.
What does this guide not decide?
This guide does not decide whether any named update, retraining, integration or repurposing is a substantial modification, and it does not describe the change control rules of any sector legislation in full. The definition in Article 3, the provider provisions in Article 25, the sector change rules and the initial conformity assessment must all be checked for the specific product and change. Borderline changes, and changes to safety critical functions, should be confirmed with a competent authority or legal adviser and, where relevant, with the notified body before the changed product is placed on the market or put into service. A general guide cannot make a change control decision for a product that is already in use.
Frequently asked questions
Is every software update a substantial modification?
No. A change is substantial only where it was not foreseen or planned in the initial conformity assessment and it affects compliance with the high risk requirements or changes the assessed intended purpose. Routine maintenance and like for like fixes may not meet that test, but the conclusion must be evidenced in the change record. Updates to safety functions, models and intended purpose need particular care.
Can a deployer become a provider by changing a system?
Yes, under Article 25. A deployer, distributor, importer or other third party that makes a substantial modification to a high risk system that remains high risk, or that modifies the intended purpose of a non high risk system so that it becomes high risk, is considered to be the provider and is subject to the provider obligations. Contractual terms alone do not change that regulatory position.
Does planning for updates in the initial assessment help?
Yes, where the planning is specific. A change that was foreseen and planned in the initial conformity assessment, within defined limits and with defined testing, is less likely to be substantial. A general statement that all future updates are foreseen is not sufficient. The envelope, limits, tests and documentation must be specified and kept with the conformity file.
What should happen before a borderline change is released?
The change should be logged, assessed against Article 3 and Article 25 and the sector change rules, and confirmed with a competent authority or legal adviser and, where relevant, the notified body. The assessment, the testing and the decision should be recorded before the changed product is placed on the market or put into service, not after a problem arises.
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 ↗