Your AI Was Already in Production. That Doesn't Make It Grandfathered.
The AI Act's transitional provisions look like a reprieve for systems that were already on the market. They are — right up until the design significantly changes. For a product that retrains on a sprint cadence, that condition is the whole story, and almost nobody is recording the evidence needed to rely on it.
What the Carve-Out Actually Says
Most compliance plans we see contain a sentence like "our platform predates the high-risk obligations, so we're covered by the legacy provision." That sentence is doing two jobs it cannot do. It is asserting a date nobody has documented, and it is treating a conditional carve-out as though it were unconditional.
The transitional rule for Annex III high-risk systems is conditional in its own text: systems placed on the market or put into service before the high-risk obligations apply fall within scope where, after that point, those systems are subject to significant changes in their design. The exemption is a snapshot. It protects the thing you shipped, in the state you shipped it, for as long as it stays in that state.
For classical software, that framing is workable — a payroll engine can sit still for three years. For a machine-learning product, "sitting still" is not the normal operating mode. Weekly fine-tunes, a swapped embedding model, a new feature added to the input vector, a foundation model version bump underneath you: each is a candidate for a design change, and each is invisible unless someone wrote it down.
The Test Is Pre-Planned vs. Unplanned, Not Big vs. Small
Teams instinctively reach for magnitude: a small change is fine, a big one is not. That is the wrong axis. The Act's treatment of substantial modification turns on whether the change was foreseen and assessed in advance. Changes that the provider pre-determined and evaluated at the time of the initial conformity assessment — including continued learning that stays inside a documented envelope — are not treated as substantial modifications. Changes that were not are exposed, even when the delta looks small on a dashboard.
This inverts the usual engineering intuition in a way worth stating plainly:
The last row is the one that catches SaaS vendors. Intended purpose is part of the system's identity under the Act. A go-to-market decision made by someone who has never read the technical file can move a system across the line without a single commit.
You Cannot Rely on a Date You Cannot Evidence
Suppose the carve-out does apply to you. Relying on it means asserting, to a market surveillance authority or to an enterprise buyer's diligence team, that a specific system was placed on the EU market before a specific date and has not significantly changed since. That is an evidentiary claim, and the evidence has to be contemporaneous.
The minimum record set that survives scrutiny:
- A dated technical file describing the system as it existed at the reference date — inputs, intended purpose, architecture, performance envelope, human oversight design.
- An immutable artefact reference: model hash, container digest, release tag. "v3.2" in a wiki is not an artefact reference.
- Proof of EU availability before the date: a signed contract, an order form, a public price list, an invoice. Availability in the EU market is what counts, not the date of your internal launch.
- A continuous change log from that date forward, where every model update is classified as pre-planned (with a pointer to where it was pre-planned) or not.
- A record of intended-purpose changes, owned by product rather than engineering, because that is where they originate.
The fourth item is the one that has to start now regardless of your position. A change log that begins the day you are asked for it proves nothing. A change log that has been running for a year, with unflattering entries in it, proves a great deal — including that you were not curating it.
The Portfolio Problem: One Date Does Not Cover You
The transitional provisions are not a single date. Different tracks run on different clocks: Annex III high-risk systems, high-risk systems embedded in products covered by existing EU product legislation, general-purpose AI models already on the market, systems intended for use by public authorities, and large-scale EU IT systems each have their own treatment.
If you ship a high-risk system built on a third-party GPAI model, you are downstream of a clock you do not control and upstream of one you do. Your provider obligations do not pause because the model provider's own transitional window is longer, and the information you need from them — documentation, capability changes, deprecation notices — is contractual, not automatic. That is a renewal-cycle problem, and it is the same negotiation described in our vendor contract terms guide.
A Note on Moving Deadlines
There has been active discussion at EU level about adjusting the timing of parts of the high-risk regime, and simplification proposals have been floated. Two things are true at once: the exact application dates are worth re-verifying against the current official text before you rely on them, and none of the proposals change the structure described here. A carve-out conditioned on design stability requires change-control evidence whether it bites in 2026, 2027, or later. Building that record is the part that does not become wasted work under any scenario.
What To Do in the Next Two Weeks
Frequently Asked Questions
Are AI systems already in production exempt from the EU AI Act?
Not exempt — transitionally carved out, and conditionally. The transitional provision covers high-risk systems placed on the market or put into service before the high-risk obligations apply, but pulls them into scope if they are subsequently subject to significant changes in design. It attaches to the specific system as placed on the market, not to a product line or a company.
Does retraining count as a significant change in design?
It turns on whether the change was pre-planned and assessed rather than on how large it is. Continuous learning inside a documented, pre-declared envelope is treated differently from an unscoped retrain that adds inputs or shifts behaviour. If the retraining regime was never documented in advance, there is nothing to point to when someone asks whether it was pre-planned.
We changed the model but not the intended purpose. Are we fine?
Possibly, and the reverse case is the one people miss: you can keep the model identical and still create a problem by broadening the intended purpose. Both dimensions need change control. Product decisions about who a feature is sold to belong in the same log as engineering decisions about what the model does.
How do we prove when a system was placed on the market?
Dated technical documentation, an immutable artefact reference such as a model hash or container digest, and independent proof of EU commercial availability before the date — a contract, order form, or published price list. Internal launch announcements and wiki version numbers are weak evidence because they are trivially editable after the fact.
Our system is deployed by a public authority customer. Does that change anything?
Yes. Legacy high-risk systems intended for use by public authorities are handled more strictly, with an outer date by which compliance must be achieved rather than an open-ended carve-out. If public-sector revenue matters to you, plan on full compliance rather than on the transitional provision.
Should we just comply anyway and skip this analysis?
For most teams with one or two in-scope systems, yes — the analysis costs more than the compliance work it might defer. The transitional provision earns its keep for organisations with large legacy estates, where it lets you sequence remediation instead of doing everything at once. Sequencing still requires the evidence described above.
The Carve-Out Is a Record-Keeping Exercise
Every version of this question resolves to the same artefact: a change log that distinguishes planned evolution from unplanned change, running continuously from a date you can independently evidence. Teams that have one can decide how much of the high-risk regime to take on and when. Teams that do not have one are, in practice, in scope — because they cannot demonstrate otherwise.
Start the log before you finish the legal analysis. The log is what the analysis will need.