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.