A new conformity assessment is required where a high-risk AI system undergoes a substantial modification, meaning a change that affects its compliance with the Section 2 requirements or results in a modification to its intended purpose, as the Act provides. Changes that were pre-determined in the technical documentation and assessed as part of the original conformity work, including certain post-placement learning within defined bounds, are treated differently, and the provider must assess each change, record the decision, and carry out a new assessment where the threshold is met.
What is a substantial modification?
A substantial modification is a change to a high-risk AI system, after it has been placed on the market or put into service, that affects its compliance with the requirements in Section 2 or results in a modification to its intended purpose. The test is effects-based: it looks at whether the change could affect the system's ability to meet the requirements, or whether the system is now intended for a different purpose from the one assessed. Examples in outline include a change to the model's core behaviour, a change to the data that materially alters performance for the affected population, a change to the deployment context that introduces new risks, and a change to the oversight design that removes a safeguard. The provider should assess each change against both limbs, compliance effect and purpose change, and should record the reasoning, even where the conclusion is that the change is not substantial.
What changes are not substantial modifications?
Not every change is a substantial modification. Minor updates, bug fixes, security patches, and configuration changes that do not affect compliance or intended purpose may not trigger a new assessment, provided they are assessed and recorded as such. Pre-determined changes are treated distinctly: where the technical documentation sets out, in advance, the changes that are foreseen, the bounds within which they will occur, and the assessment of their effect, and those changes were assessed as part of the original conformity work, a change within those bounds does not by itself require a new assessment. The provider must be able to show that the change falls within the pre-determined bounds, that the monitoring and testing for it were carried out, and that the documentation accurately described it. A change described only in general terms, without bounds or assessment, does not meet that test.
For the broader regulatory framework, see Conformity assessment and CE marking overview.
How should a change be assessed?
A change should be assessed through a documented change review, before the changed system is relied on. The review should describe the change, the version affected, the reason for the change, the effect on compliance and intended purpose, the testing carried out, and the decision on whether a new conformity assessment is required. The review should involve the people who own risk management, data, testing and oversight, and should be approved by a person with authority to decide on the conformity consequence. Where the review concludes that a new assessment is required, the assessment should be carried out before the changed system is placed on the market or put into service in its changed form. Where the review concludes that no new assessment is required, the reasoning should be strong enough to withstand scrutiny by a market surveillance authority.
Who becomes the provider after a modification?
A modification can also change who is the provider. Under Article 25, a deployer, importer, distributor or other third party that makes a substantial modification to a high-risk system, or changes its intended purpose so that it becomes high-risk, is considered the provider of the modified system and faces the provider obligations for it. That includes quality management, documentation, conformity assessment, declaration, marking and registration for the modified system. Teams that modify a system supplied by another provider should therefore assess both questions together: whether the change is substantial for conformity purposes, and whether it makes them the provider. The two assessments should be recorded in the same change file, with the role conclusion and the conformity decision both stated, so that neither is overlooked.
How should the version and declaration history be kept?
Each version of a system should have a version record, a change record, a conformity record, and, where applicable, a declaration and registration record, all linked together. When a new assessment is carried out, the new declaration should be issued, the CE marking position reassessed, and the registration updated where required, with earlier versions retained. When no new assessment is required, the change record should still be added to the file, with the reasoning, so that the history shows why the original assessment still holds. A version history that records only release dates, without change assessments and conformity decisions, cannot show whether the system on the market is the system that was assessed. The history should be controlled, dated, and retrievable for the retention period the Act sets.
Continue with Conformity assessment routes under Article 43.
What does this guide not decide?
This guide does not decide whether a particular change is a substantial modification, whether a pre-determined change falls within its bounds, or whether a party has become the provider under Article 25. It does not assess a change review or a version history. Those questions depend on the change, its effect on compliance and purpose, the technical documentation, and the consolidated legal text. A provider or modifier should assess each material change in writing, seek qualified review where the position is borderline, and carry out a new conformity assessment before relying on a changed system where the threshold is met.
Frequently asked questions
Does every software update need a new assessment?
No. Only a substantial modification, or a change that affects compliance or intended purpose in a material way, triggers a new assessment. Every change should still be assessed and recorded, with the reasoning, so that the decision not to reassess is evidenced and can be reviewed.
What are pre-determined changes?
Pre-determined changes are changes foreseen and described in the technical documentation, with bounds and an assessment of their effect, that were assessed as part of the original conformity work. A change within those bounds, with the monitoring and testing the documentation provides for, does not by itself require a new assessment, but the provider must show the change falls within the bounds.
Can a deployer become the provider by modifying a system?
Yes, under Article 25, where a deployer or other third party makes a substantial modification or changes the intended purpose so the system becomes high-risk. That party is then considered the provider for the modified system and faces the provider obligations, including a new conformity assessment where required.
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 ↗Commission AI Act Service Desk timeline ↗European Commission AI Act overview ↗