Article 43(4) of the EU AI Act (Regulation (EU) 2024/1689) provides that, for high-risk systems that keep learning after being placed on the market or put into service, changes to the system and its performance that were pre-determined by the provider at the time of the initial conformity assessment — and that form part of the technical documentation required under Annex IV, point 2(f) — do not count as a substantial modification. No new conformity assessment follows. The entire cost of staying compliant while you keep retraining rests on documentation you write once, at the start, and almost nothing written for MLOps teams says so plainly.
The rule and the timing that makes or breaks it
Read the timing again, because it’s the whole mechanism: the changes have to be pre-determined at the time of the initial conformity assessment. Not documented eventually. Not written up after a retraining cycle already happened and worked out fine. If it isn’t in the technical file the assessment was actually based on, it doesn’t get the exemption — it’s just an undocumented change, and undocumented changes are exactly what Article 3(23) is built to catch.
What “pre-determined” has to look like in a technical file
Annex IV, point 2(f) — the specific provision Article 43(4) cross-references — requires, where applicable, a detailed description of pre-determined changes to the AI system and its performance, together with all relevant information about the technical solutions put in place to ensure the system’s continued compliance with the Chapter III, Section 2 requirements as those changes happen. That’s two things, not one: a description of what can change, and an explanation of how you’ve engineered continued compliance despite it changing.
Two companion provisions in the same Annex turn this from a paperwork exercise into something that has to actually be tested. Point 2(g) requires dated, signed test logs and reports specifically covering the pre-determined changes described in point (f) — you don’t just describe the envelope, you have to show testing that happened inside it. And point 6, separately, requires an ongoing description of the relevant changes the provider actually makes over the system’s lifetime — a running log distinct from the upfront envelope, recording what happened against what was planned.
In practice, the envelope worth drafting into that technical file covers: the retraining cadence itself; the bounds of the data sources involved, not just their identity; the performance ranges you expect, tied to the specific metrics you’re measuring against; drift thresholds that would trigger a stop; rollback conditions if a retrained version underperforms; and, most importantly, a clear statement of the point at which a change would leave this envelope and stop being “pre-determined” at all. Tie each of these back to your Article 11 technical documentation as a whole and your Article 17 quality management system — the envelope isn’t a standalone document, it’s a component of both.
What is definitely outside the envelope
Article 3(23) defines a substantial modification as a change to an AI system, after it’s placed on the market or put into service, that the provider did not foresee or plan in the initial conformity assessment, and that either affects the system’s compliance with the Chapter III, Section 2 requirements, or changes the intended purpose the system was assessed for. Two disjunctive triggers, either one sufficient, sitting on top of the same threshold question: was this foreseen at the time of the initial assessment or wasn’t it.
A retraining run using the data sources, cadence and performance bounds you described in your point 2(f) envelope, producing a model that still does the same job to the same standard, sits inside the exemption — that’s precisely what Article 43(4) exists to cover. A retraining run that pulls in a materially different data source you never documented, or that shifts the system toward a new use case, sits outside it on both available grounds: it wasn’t foreseen, and it plausibly touches compliance or purpose. The difference isn’t how big the change feels. It’s whether you wrote it down before you were assessed.
Where the envelope has to be re-declared
Once a change actually crosses into substantial modification, the practical consequence is that a new conformity assessment applies — the system is, in effect, being placed on the market again in its modified form. That loops back to registration: the EU database registration duty attaches to placing a system on the market or putting it into service in the first place, so a substantially modified system re-triggers that same duty rather than quietly inheriting the original entry. Treat a substantial modification as resetting the compliance clock, not just the model weights.
The neighbouring clocks
A few retention and monitoring duties sit right next to this one, and they’re worth having straight rather than confusing with each other. Article 12 requires high-risk systems to automatically log events across their lifecycle, and one of the three purposes that logging capability is explicitly built for is identifying situations where a substantial modification occurs — the log isn’t just an audit trail, it’s part of how you’re meant to notice you’ve left your own envelope. Article 19 then sets how long those logs have to be kept: a period appropriate to the system’s intended purpose, and at least six months, unless other Union or national law — particularly data protection law — requires longer. Separately, Article 18 requires the provider to keep the technical documentation, the quality management system documentation, any documentation of changes approved by a notified body, notified-body decisions, and the declaration of conformity available to national authorities for ten years after the system was placed on the market or put into service.
Frequently asked questions
Does a fine-tune count as a substantial modification?
It depends entirely on whether it falls inside your documented envelope. A fine-tune using the data sources and staying within the performance bounds you described in your point 2(f) file isn’t a substantial modification — that’s the exemption working as intended. A fine-tune that pulls in undocumented data or pushes performance outside the ranges you committed to isn’t covered, regardless of how routine it felt to run.
Does swapping the base model count?
Almost certainly, yes. Swapping the underlying model is rarely something a provider pre-determined as a continued-learning change in the original technical file — it’s closer to a different system than a retrained version of the same one, and it’s hard to argue it doesn’t touch Chapter III Section 2 compliance or the assessed intended purpose. Treat a base-model swap as a substantial modification by default, and build the case for an exception only if your original documentation genuinely anticipated it.
Does a new training run on the same pipeline count?
Only if it stays inside what you documented. The same pipeline producing a run that matches the data-source bounds and performance ranges already on file is exactly what the exemption is for. The same pipeline producing a run against new data, or aimed at different performance characteristics than what you described, has left the envelope even though nothing about the infrastructure changed.
Who decides — us or the notified body?
For Annex VI self-assessed systems, the provider makes this call itself, as part of its ongoing Article 17 quality management obligations — there’s no notified body in the loop to consult. Where a notified body is involved under Annex VII, changes it has specifically approved get their own retention requirement under Article 18, which suggests an ongoing role in confirming certain categories of change — but the initial pre-determination is still the provider’s own documentation choice, made before that body ever assessed anything.
Does the December 2027 date change any of this?
Not the substance. Article 43(4) is part of the Chapter III framework that, for Annex III systems, now applies from 2 December 2027 rather than 2 August 2026 following the Digital Omnibus reform. The rule itself is unchanged — only the date it starts binding on stand-alone Annex III systems moved, alongside every other obligation in that same package.