Does the EU AI Act Apply to AI Systems Already on the Market?

You have had an AI system in production since 2024. It screens job applications, or scores credit, or routes support tickets, and it works. Now the high-risk rules are landing. Does the Act pull your existing system into full compliance, or does being there first buy you anything?

The short answer is yes, it buys you something real. The Act treats systems already on the market differently from new ones. The rule that does this is Article 111. However, it would be a mistake to assume grandfathering is broader and safer than it is.

Article 111 grandfathers existing high-risk systems

Article 111 sets the transitional provisions for systems already placed on the market or put into service. The core rule for most businesses is in Article 111(2). A high-risk AI system that was on the market before the high-risk obligations start to apply does not have to meet those obligations, so long as it does not undergo a “significant change in design”.

Article 111(2) says the Regulation applies to operators of existing high-risk systems “only if, as from that date, those systems are subject to significant changes in their designs.” Keep the system stable and it stays outside the high-risk requirements. Change it materially and the full suite applies.

The Digital Omnibus moved the application date for the high-risk rules, so the grandfathering window moved with it. For standalone Annex III high-risk systems, the cut-off is now 2 December 2027, not the original 2 August 2026. A recruitment-screening tool you placed on the EU market in 2024 and leave unchanged is grandfathered against the high-risk obligations. One you first place on the market on 3 December 2027 gets no grace at all.

The dates that matter

Article 111 has three separate buckets, each with its own cut-off and its own deadline. They are easy to mix up.

System already on the market	Cut-off for grandfathering	What you owe, and by when
Standalone Annex III high-risk (private sector)	Placed before 2 December 2027	Full high-risk compliance only if you significantly change the design after that date
High-risk embedded in a regulated product (Annex I)	Placed before 2 August 2028	Same trigger, later cut-off
Any high-risk system used by public authorities	No open-ended grace	Must comply by 2 August 2030 regardless of changes
GPAI models placed before 2 August 2025	Fixed	Comply with GPAI obligations by 2 August 2027 (Article 111(3))
AI in large-scale EU IT systems (Annex X)	Placed before 2 August 2027	Bring into compliance by 31 December 2030 (Article 111(1))

Two things to read off this table. First, the public-authority backstop in Article 111(2) is a hard deadline rather than a grace period: if you sell high-risk AI to a government body, you are working to 2 August 2030 whatever you do to the product. Second, the grace attaches to the first time a unit was placed on the market or put into service. If you sell many identical copies of the same high-risk system, the Act lets you keep placing unchanged units after the cut-off on the strength of the first one, without a fresh conformity assessment, for as long as the design holds.

A significant design change resets the clock

Grandfathering is not a state you reach and keep. It is a state you lose the moment you make a material change. This is where the “already on the market” comfort gets dangerous for the kind of AI most of our readers run: live, cloud-hosted software that ships updates every few weeks.

“Significant change in design” is not defined in Article 111, and Article 111(2) pointedly avoids the Act’s defined term “substantial modification” (Article 3(23)). Recital 177 bridges the gap: the significant-change test should be read as “equivalent in substance to the notion of substantial modification.” You borrow the idea in substance rather than word for word. In substance, a substantial modification is a change that affects the system’s compliance with the high-risk requirements in Chapter III, Section 2, or that changes its intended purpose. That is the same test item 4.14 of the checklist uses.

The “in substance” qualifier earns its keep for a legacy system. Article 3(23) frames the change as one “not foreseen or planned in the initial conformity assessment”, and a grandfathered system never had a conformity assessment. So there is no document to measure against. The baseline is the system as it actually stood when you placed it on the market before the cut-off, and the question is whether the change is material enough that, judged against that starting state, it affects the high-risk requirements or alters what the system is for. If it is, Recital 128 says the system counts as “a new AI system” that must undergo conformity assessment, its first, which Article 43(4) then requires.

The practical line runs roughly here:

• Does not reset the clock: routine bug fixes, security patches, and changes you already described and bounded in your technical documentation. A system that keeps learning inside pre-defined limits set at the original assessment is explicitly carved out by Article 43(4).
• Resets the clock: a new scoring or ranking model, a new data source that changes behaviour, an expansion into a new use case, or any change that alters what the system is for.

Take a fictional but ordinary case. TalentFilter has sold an AI CV-screening tool to EU employers since 2024. Left alone, it is grandfathered past 2 December 2027. In the first quarter of 2028 the team swaps in a new ranking model to improve accuracy. That is a significant change in design. From that release, the system has to meet the full high-risk requirements: risk management, data governance, technical documentation, conformity assessment, the lot. The grandfathering is gone, and it is gone for a system that is now shipping to customers on a compressed timeline.

For software as a service, this makes grandfathering thin. The whole point of a live product is that it changes. If you cannot commit to freezing a high-risk system’s design, plan to comply on the merits rather than banking on the transitional bridge.

Grandfathering is narrower than it looks

Even where it applies, Article 111(2) is a carve-out from the high-risk obligations only. Three limits catch people out.

The bans apply anyway. Article 111(2) is expressly “without prejudice to the application of Article 5.” The prohibited practices have applied since 2 February 2025 and reach every system, new or legacy. If your existing tool does something Article 5 bans, being on the market first is no defence.

Transparency applies anyway. The Article 50 transparency duties are not high-risk obligations, so grandfathering does not touch them. A customer-service chatbot you launched in 2025 still owes users disclosure that they are talking to an AI from 2 August 2026, and AI-generated content still needs marking from 2 December 2026. Your legacy status under Article 111 does nothing here.

It only helps systems already placed. The grace is for systems on the market before the cut-off. Anything you first place on the market or put into service after 2 December 2027 is in full scope from day one.

There is a live debate about whether even this narrow grace is too generous. Because the Act does not apply retroactively, a high-risk system placed before the deadline and never significantly changed can sit outside the high-risk rules for years. Laura Caroli, a former AI Act co-negotiator, has warned that a hiring system placed before the date “may remain outside the AI Act indefinitely, unless it is substantially altered after that date.” The Corporate Europe Observatory put it more bluntly, arguing that a large share of high-risk systems placed before December 2027 “will never have to comply with the rules.” Critics also note the obvious incentive the delay creates: ship a high-risk system before the cut-off to lock in grandfathered status. Whether or not you find that troubling, it tells you how the provision is being read, and that regulators and civil-society groups are watching the legacy category closely. Do not assume a lightly-touched grandfathered system will stay quietly off the radar.

One caveat on the dates. The Digital Omnibus that moved these deadlines was adopted by the Parliament on 16 June 2026 and the Council on 29 June 2026, and enters into force on the third day after it is published in the Official Journal. Until that publication, the original text technically governs, though enforcement of the old 2 August 2026 date is not expected. The 2 December 2027 cut-off is the one to plan against.

What to do now

1. Date-stamp your inventory. For every AI system, record when it was first placed on the market or put into service. Grandfathering turns entirely on that date, and you cannot claim it without evidence. If you have not built an inventory yet, start with our practical walkthrough.
2. Flag the high-risk ones. Grandfathering only matters for systems that are high-risk in the first place. Classify before you rely on any transitional relief.
3. Decide, per system, whether to freeze or comply. A genuinely stable legacy system can ride the bridge to its cut-off. A product you intend to keep developing will trip the significant-change trigger, so build compliance in rather than betting on a freeze you will not keep.
4. Define your change threshold in advance. Write down what your team will treat as a “significant change in design”, anchored to the substantial modification test in Article 3(23). Then a routine release does not become an accidental compliance event, and a real one is caught deliberately.
5. Do not let grandfathering mask the near-term duties. The Article 5 bans already bite, and the Article 50 transparency clock runs from 2 August 2026. Neither waits for December 2027, and neither cares how long your system has been live.

Being on the market first is a bridge, not a moat. It gives a stable legacy system time, and it gives a changing one almost nothing.