Change management should record every material change to an AI system, its data, its intended purpose, or its deployment, assess whether the change affects classification, requirements, conformity, transparency or risk, carry out the reassessment and testing the change requires, and communicate the change to deployers, authorities and affected people where needed, before the changed system is relied on. Pre-determined changes within documented bounds are assessed differently from unplanned changes, and both must be recorded.
What changes trigger reassessment?
Reassessment triggers include a change in intended purpose, a change in the affected population or deployment geography, a change in model, data, or software that affects performance or risk, a change in the operating environment or workflow, a change in the supplier or model dependency, an incident or complaint pattern, and updated official guidance or legal requirements. The trigger list should be recorded in the governance file for each system, with the owner who monitors each trigger. A change that is not on the list, but that could affect compliance or risk, should still trigger an assessment, because the list cannot foresee every change. Teams should treat the trigger list as a minimum, not as an exhaustive definition, and should err on the side of assessment where the effect of a change is uncertain.
How should a change be assessed?
A change should be assessed through a documented change review, before the changed system is placed on the market, put into service, or relied on in a new deployment. The review should describe the change, the version affected, the reason, the effect on classification, requirements, conformity, transparency, oversight and risk, the testing carried out, and the decision on whether a new assessment, a new conformity assessment, or a notification is required. The review should involve the owners of risk, data, testing, oversight and governance, and should be approved by a person with authority to decide on the change. Where the review finds that the change is substantial, the new conformity assessment, declaration, marking and registration steps must be carried out before the changed system is relied on. Where the review finds no substantial change, the reasoning should be strong enough to withstand later scrutiny.
For the broader regulatory framework, see AI governance planning checklist.
How should versions be controlled?
Version control should give every system version a stable identifier, a change record, a test record, a documentation version, and a conformity and registration record, all linked together. A version should not be overwritten or reused for a different configuration, and a rollback to an earlier version should be treated as a change with its own assessment. The version history should show the sequence of versions, the changes between them, and the assessment for each, so that a reviewer can tell which version was assessed, which version is on the market, and which version a log entry refers to. For hosted systems, where the version can change without a deployment by the deployer, the provider should notify deployers of material changes, with the version, the effect, and the date, so that deployers can reassess their own deployment.
How should deployers reassess their deployment?
Deployers should reassess their deployment when the provider notifies a change, when the deployment context changes, when the affected population changes, or when monitoring or incidents suggest the original assessment no longer holds. Reassessment should cover the deployer's role, the instructions for use, the oversight design, the FRIA where one was carried out, and the transparency notices, and should be recorded with the date and the reviewer. A deployer that continues to rely on an original assessment after a material change to the system or the context, without reassessment, risks operating a system whose assessment no longer matches its actual use. The deployer should agree with the provider, in advance, how changes will be notified, what information will be provided, and how long the deployer has to reassess before the change takes effect in its deployment.
How should changes be communicated?
Changes should be communicated to the parties affected, in a form they can act on, before the changed system is relied on. Providers should notify deployers of material changes, with the version, the effect on instructions, oversight, and risk, and the date the change takes effect. Deployers should brief affected staff, update oversight and monitoring, and inform affected people where the change affects them. Authorities and notified bodies should be notified where the Act requires it, including for substantial modifications and certificate changes. Communication should be recorded, with the recipients, the date, and the version notified, so that a question about who was told what and when can be answered from the record. A change that is implemented silently, without notification to the parties who rely on the system, breaks the evidence chain for every deployment it affects.
Continue with Substantial modification and new conformity assessment.
What does this guide not decide?
This guide does not decide whether a particular change is substantial, whether a new conformity assessment is required, or whether a deployer reassessment is sufficient. It does not assess a change review or a version history. Those questions depend on the change, its effect on compliance and purpose, the documentation, and the consolidated legal text. A provider or deployer should assess each material change in writing, seek qualified review where the position is borderline, and carry out the reassessment and notification the change requires before relying on the changed system.
Frequently asked questions
Does a minor patch need reassessment?
Every change should be assessed and recorded, but a minor patch that does not affect compliance, purpose, risk or performance may not need a full reassessment or a new conformity assessment. The change review should record the reasoning, the testing, and the decision, so the conclusion can be reviewed later.
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.
Must deployers be told about hosted model changes?
Yes, where the change is material to the deployer's assessment, instructions, oversight or risk. Providers should notify deployers with the version, effect and date, and deployers should reassess their deployment and brief staff before relying on the changed system.
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 ↗