Annex I

29
Sep
2026

Significant change vs substantial modification: same thing?

Article 111(2) of the EU AI Act (Regulation (EU) 2024/1689) grandfathers high-risk systems already on the market unless they undergo “significant changes” in design after the general application date. Article 3(23), in a completely separate part of the Regulation, defines “substantial modification.” Recital 177 says the two are equivalent in substance. White & Case’s own Handbook commentary on this point is unusually blunt for a law-firm guide: “It is not entirely clear why two separate terms are used.” Whether your legacy AI estate stays outside the Act’s high-risk rules turns on a distinction its own drafters apparently didn’t mean to create.

What the grandfathering actually gives you

Article 111(2) applies the Regulation to operators of legacy high-risk systems — those placed on the market or put into service before the general application date — only if those systems undergo significant changes in their design from that date onward. Read that structure carefully: it isn’t a grace period that eventually expires on its own. It’s an indefinite exemption, conditional on one thing only — that you don’t significantly change the system. Stand still, and the exemption holds indefinitely. Change it, and you’re pulled into the full regime from that point.

The three exceptions to the free pass

Three categories don’t get to rely on standing still.

  • Public authority deployers. Regardless of whether a system undergoes any change at all, providers and deployers of high-risk AI systems intended for use by public authorities have to comply with the Regulation’s requirements no later than six years after entry into force — 2 August 2030.
  • Annex X large-scale IT systems. AI components of the large-scale IT systems established under the legal acts listed in Annex X have their own fixed deadline: 31 December 2030, for systems placed on the market before the relevant cutoff.
  • The Article 5 prohibitions. These were never grandfathered in the first place. Both of Article 111’s grandfathering provisions open with “without prejudice to the application of Article 5” — the prohibited-practices regime has applied since 2 February 2025, full stop, regardless of when any given system was placed on the market.

The GPAI cliff edge

Article 111(3) draws its own hard line, and it’s worth seeing exactly how sharp it is. A general-purpose AI model placed on the market before 2 August 2025 gets until 2 August 2027 to come into compliance. A model placed on the market on or after 2 August 2025 faces enforcement immediately, from the moment it’s placed on the market. White & Case’s own framing of this makes the stakes concrete: a model placed on the EU market on 1 August 2025 faces no enforcement risk for two years; the same model placed one day later, on 2 August 2025, faces immediate risk. Providers of GPAI models were, in the Handbook’s words, incentivised to place those models on the EU market before that specific deadline. One day either side of a date is worth two years.

Does the Omnibus reset the clock?

Article 111(2)’s grandfather clause attaches to “the general date of application” — and the Digital Omnibus reform moved that date, deferring Annex III high-risk obligations to 2 December 2027 and Annex I obligations to 2 August 2028. That’s not a cosmetic shift. If the cutoff itself moves, the population of systems that count as “legacy” moves with it: a system placed on the market in, say, October 2027 — which would have squarely missed the old 2 August 2026 cutoff and faced the full regime immediately — can now fall on the grandfathered side of a later line, provided it isn’t significantly changed afterward.

The honest caveat, consistent with everything else tied to this reform: the new dates bind only once the amending regulation is published in the Official Journal and enters into force. Until then, the original 2 August 2026 cutoff remains the legally operative one. The GPAI timeline in Article 111(3) is a separate matter entirely — nothing in the Omnibus reform touched the 2 August 2025 / 2 August 2027 dates, since that deferral was built specifically around the Annex I and Annex III high-risk regime, not the general-purpose AI rules.

So what is a significant change?

Since Recital 177 treats the two concepts as equivalent, the operative test is the one Article 3(23) actually writes down: a change that was not foreseen or planned in the initial conformity assessment, and that either affects the system’s compliance with the Chapter III, Section 2 requirements, or modifies the intended purpose the system was assessed for. That’s the same test this piece’s companion article on Article 43(4) walks through in detail for systems that keep learning after deployment — the pre-determined change envelope you document there is, in substance, the same boundary that decides whether a legacy system has quietly lost its grandfathering here.

Frequently asked questions

Does a UI change count as a significant change?

Usually not, unless it touches how the system actually meets the Chapter III Section 2 requirements — a change to how oversight information or output explanations are presented to a human reviewer could cross that line, where a purely cosmetic interface refresh wouldn’t. The test is whether compliance or intended purpose is affected, not how visible the change is to an end user.

Does deploying into a new customer segment count?

Likely yes, if the new segment amounts to a different intended purpose than what the system was originally assessed for. This is close to the paradigm case the “modifies the intended purpose” limb of Article 3(23) is written for — the same system, doing a materially different job for a materially different population, is exactly the scenario grandfathering isn’t meant to protect.

Does a routine security patch count?

Generally not, if it’s the kind of maintenance foreseeable at the time of the initial assessment and doesn’t itself change how the system meets the substantive requirements or what it’s for. A patch significant enough to materially alter the system’s behaviour or outputs is a different matter, and the size of the change matters more than its label as “just a patch.”

What if we never carried out a conformity assessment in the first place?

This is a harder problem than a grandfathering question, and this piece won’t pretend otherwise. Article 3(23)’s test explicitly measures a change against what was foreseen or planned in the initial conformity assessment — without one, there’s no documented baseline to test a change against at all. A system in that position has a more fundamental compliance gap than whether a later change was “significant”; that gap is worth resolving before the grandfathering question becomes the relevant one.

Can we deliberately freeze a system’s design to stay exempt?

Yes, and White & Case’s own commentary treats this as a real, foreseeable incentive rather than a loophole — not changing a legacy system’s design keeps it inside Article 111(2)’s exemption indefinitely, subject to the three exceptions above. Freezing the system’s design doesn’t freeze every other obligation that might apply regardless of risk tier, though — Article 4 AI literacy, for instance, isn’t tied to this grandfathering at all and applies whether or not the underlying system changes.

Posted by admin in Digital Operational Compliance & EU AI Act Knowledge Base
23
Sep
2026

Retraining a high-risk model without a new assessment

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.

Posted by admin in Digital Operational Compliance & EU AI Act Knowledge Base
18
Aug
2026

“Safety component” after the Omnibus: a narrower test

The Digital Omnibus narrows the definition that decides whether AI embedded in a regulated product counts as high-risk under the EU AI Act (Regulation (EU) 2024/1689). AI used solely for user assistance, performance optimisation, service efficiency or automation, or convenience or quality control no longer makes a component a “safety component” — and doesn’t trigger high-risk classification by virtue of sitting inside a regulated product — unless its failure or malfunction would actually endanger health or safety. Separately, the Machinery Regulation moved out of Annex I Section A into Section B entirely, so AI-enabled machinery now complies with sectoral safety rules instead of both regimes at once. Every guide written before May 2026 is describing a test that no longer applies.

The old test and why it swept too wide

Article 6(1) classifies an AI system as high-risk when two conditions are both met: it’s intended for use as a safety component of a product, or is itself a product, covered by the Annex I Union harmonisation legislation; and that product requires third-party conformity assessment under that legislation before it can be placed on the market. Whether an AI function counts as a “safety component” in the first place decides whether this whole test even applies.

The original definition of safety component covers a component that fulfils a safety function for a product or AI system, or whose failure or malfunction endangers the health and safety of persons or property. That second limb is where the trouble sits. Read expansively, almost any function embedded in a regulated product can be argued into it — an optimisation model inside a lift or a boiler doesn’t itself perform a safety function, but a sufficiently loose reading of “failure… endangers health and safety” could sweep it in anyway, on the theory that anything going wrong inside safety-regulated machinery carries some attenuated safety implication.

What the new test asks

The narrowed definition collapses this to one question: could the component’s failure or malfunction actually endanger health or safety? If the answer is no, and the function is assistance, optimisation, efficiency, automation, convenience, or quality control, it isn’t a safety component — regardless of what product it happens to sit inside.

Two examples on either side of the line. A predictive-maintenance model that flags when industrial machinery needs servicing is squarely an optimisation function: if it fails, the direct consequence is a missed maintenance window, not an immediate safety event, so it’s a strong candidate for falling outside the safety-component definition under the new test. A torque-limiting or collision-avoidance function built into the same machinery is a different case entirely — its failure directly creates a safety risk, which is exactly what the carve-out was never meant to exempt. The label attached to a function matters far less than what actually happens when it fails.

Annex I Section A vs Section B

This distinction decides how much of the Act applies at all. Section A covers New Legislative Framework legislation — medical devices, toys, personal protective equipment, gas appliances, and, until this reform, machinery. Section B covers other Union harmonisation legislation, including aviation security, agricultural and forestry vehicles, motor vehicle type-approval, marine equipment, and rail interoperability. For systems in Section B, only Article 6(1) itself, Articles 102 to 109, and Article 112 apply — essentially none of the Act’s substantive high-risk apparatus, the conformity assessment procedures, or the registration duties reach them at all.

The Omnibus moved only the Machinery Regulation from Section A to Section B. That’s a narrower outcome than what was actually on the table during trilogue: the deadlock that briefly collapsed negotiations centred on a Parliament proposal to exclude far more broadly — medical devices, toys, connected cars, and industrial machinery all together. The final compromise pulled back to Machinery alone. It isn’t a deregulation of industrial AI, either — the Commission is empowered to adopt delegated acts under the Machinery Regulation itself, not the AI Act, adding AI-specific health and safety requirements for systems that would otherwise have been high-risk. Oversight doesn’t disappear; it moves into the sectoral regime.

The other overlap relief, and its condition

Products that stayed in Section A — medical devices and toys among them — get a different, conditional form of relief instead of a full carve-out. Where the sectoral legislation already contains AI-specific requirements equivalent to or higher than the AI Act’s own, the Commission may, by implementing act, limit how far Articles 9 to 15 and 17 to 25 actually apply to those systems. That’s a genuinely different legal instrument from the Machinery-specific delegated acts, and it comes with its own timing: implementing acts addressing this general sectoral overlap are expected by 2 August 2027, while the Machinery-specific delegated acts are expected by 2 August 2028, tied to when Annex I obligations actually start binding. Both dates are worth putting on a calendar. Neither is a rule you can rely on today — nothing is actually limited until the Commission acts.

When any of this binds

Annex I high-risk obligations now apply from 2 August 2028 rather than 2 August 2027, under the same Digital Omnibus reform that deferred Annex III obligations to 2 December 2027. As with every date in this reform, it binds only once the amending regulation is published in the Official Journal and enters into force — as of this writing, formal adoption and publication were still pending, with the original 2 August 2026/2027 calendar remaining the legally operative one until that happens.

Frequently asked questions

Is a predictive maintenance model a safety component?

Generally not, under the narrowed test — unless the specific machine’s failure mode makes a missed service interval itself a direct safety event rather than an efficiency loss. That’s genuinely fact-specific: the same category of model can land on either side depending on what actually happens when the maintenance flag is missed.

Does the Medical Devices Regulation change?

Not in the same way. Medical devices remain in Annex I Section A — they didn’t get the Machinery-style move to Section B. What they get instead is the conditional relief described above: if the Commission determines, by implementing act, that the sectoral legislation already imposes equivalent AI-specific requirements, application of the relevant AI Act articles can be limited. Until that happens, the full parallel regime still applies.

What about toys and lifts?

Both stay in Section A, on the same footing as medical devices — eligible for the conditional implementing-act relief if the Commission acts, but not moved to Section B the way Machinery was. Lifts in particular sit under their own directive, separate from the Machinery Regulation, and nothing in this reform touched that separately.

Does “quality control” cover visual inspection?

Often, but not automatically. A visual-inspection model that flags defective units for human review before they’re used is a strong fit for the quality-control carve-out — its failure means a defect goes unflagged, not an immediate safety event. But if that inspection is the only safeguard standing between a genuinely dangerous defective unit and its use, the “failure would endanger health or safety” test can still catch it. The function’s name doesn’t decide the answer; the actual consequence of it failing does.

Who decides — us or the notified body?

The provider makes the initial classification call, consistent with how Article 6 works generally — nobody else does it for you upfront. Where third-party conformity assessment still applies, a notified body’s scope determination matters downstream, but a market surveillance authority retains the ordinary power to review a provider’s classification later and require correction if it disagrees, the same oversight mechanism that applies to Article 6(3) classification calls elsewhere in the Act.

Posted by admin in RegTech Glossary & Standards