When do the EU AI Act high-risk obligations actually apply now?

Standalone high-risk systems under Annex III apply from 2 December 2027, and AI embedded in products already covered by EU product safety law under Annex I from 2 August 2028. Both were deferred from the original date of 2 August 2026, and the deferral came through the Digital Omnibus shortly before that date arrived.

Was the whole EU AI Act postponed?

No. General application began on 2 August 2026 as planned, and the Article 50 transparency obligations, the prohibitions on unacceptable-risk practices, and the AI literacy duty were not deferred. A specific set of high-risk obligations moved while the rest of the regulation proceeded on its original schedule.

Why were the high-risk obligations deferred?

Because the supporting systems were not ready rather than because the requirements were reconsidered. Harmonised technical standards were late, supporting guidance was still in draft, and several member states had not designated or resourced the market surveillance authorities that would supervise compliance.

Does the deferral mean the obligations might be dropped entirely?

Treating it that way is the expensive interpretation, because the stated reason was readiness of the enforcement system rather than doubt about the requirements. A plan built on the assumption that the rules will quietly disappear has no backup plan if they do not.

Does the EU AI Act apply to a company based outside the EU?

It can, because scope follows where a system is placed on the market or where its output is used, not where the developer is established. Assuming you are outside scope because the company is not European is the most common scoping error teams make.

What is the one thing to do first, regardless of the deadline?

Log the system's behaviour over its lifetime: inputs, outputs, model version, and decision context, retained. It is the only obligation where a late start leaves a permanent gap in the records, because every other artefact can be produced when needed while data you did not capture cannot be recovered.

How do you plan engineering work against a date that keeps moving?

Build the artefacts that are useful whether or not the date holds, and treat anything that is only useful for the filing as work to defer. That test separates a decision inventory and an evaluation suite, which improve the product, from documentation packaging, which does not.

What is Article 50 and why does it matter more than people expect?

It is the transparency duty requiring disclosure to users when they are interacting with an AI system, and it was not deferred. It is the provision most likely to reach an ordinary product today, it is cheap to satisfy, and it is worth doing in any market because a user who discovers afterwards that they were talking to a model has a trust problem regardless of jurisdiction.

Who decides whether a system is high-risk?

That determination belongs with counsel, because it depends on whether the system falls into one of the enumerated Annex III categories such as employment, creditworthiness, or certain uses in education. What engineering owes the conversation is an accurate description of what each feature decides and whether a human reviews the output before it takes effect.

What should a team stop doing after a deadline moves?

Stop any work whose only purpose was arriving before that date, and say so explicitly rather than letting it continue without a decision. Work that continues only because nobody stopped it after its reason has gone is the most reliable way to spend a deferral without gaining anything from it.

The EU AI Act deadline that moved, and what to do with the time: Reveneau

Q: How does an evaluation suite relate to AI Act compliance?

Accuracy and robustness are demonstrated with measurement, so a suite built now produces a documented history by the time anyone asks for it. That history is the part that cannot be manufactured retrospectively, which is why starting it early is worth more than starting it well.

For two years, most AI compliance planning in Europe was built around a single date. The second of August 2026 was in the roadmaps, in the board decks, and in the budget arguments that got made and lost. Then, shortly before it arrived, the obligations everyone was preparing for moved.

The specifics matter, because this is being described loosely in a lot of places and the loose version leads to the wrong decisions.

High-risk obligations for standalone systems under Annex III now apply from 2 December 2027. For AI embedded in products already covered by EU product safety law, under Annex I, the date is 2 August 2028. The deferral came through the Digital Omnibus package.

What did not move is more interesting than what did. General application of the Act still began on 2 August 2026. The Article 50 transparency obligations, including telling users they are interacting with an AI system, were not deferred. The prohibitions on unacceptable-risk practices and the AI literacy duty did not change. The general-purpose AI transparency rules had already been in force since August 2025.

So a specific set of obligations was delayed by sixteen months and twenty-four months respectively, and everything else arrived on time.

Why it moved, and why the reason changes your reading

The original timeline assumed a working enforcement system would exist by the deadline: harmonised technical standards to build against, notified bodies able to run conformity assessments, and national supervisory authorities with the staff to supervise anyone.

By late 2025 that system was behind schedule. The standards work was running late, supporting guidance was still in draft, and a number of member states had not designated or resourced market surveillance authorities at all. A deadline is not enforceable when nobody is in a position to enforce it and nothing exists to be measured against.

That is a delay in the enforcement systems, and it says nothing about whether the requirements are wanted. The interpretation being repeated widely, that this is the first sign of weakness and the obligations may quietly disappear, is a risky assumption with an expensive downside. If you are wrong, you have sixteen months less than you thought, and the one obligation with a hard dependency on time is the one you skipped.

The question worth asking about your own plan

A moved deadline is a useful accident. It lets you sort your compliance work into two piles that are otherwise hard to separate.

Pile one is work that was only ever about the date. Documentation assembled in a format nobody reads. A conformity file prepared for a submission process that did not exist yet. Diagrams drawn for an audience that had not been appointed. If the date moves and this work becomes pointless, it was compliance work done only for show, with a deadline attached, and the deferral has helped you by showing it.

Pile two is work that improves the product whether or not any regulator ever looks. Knowing what each feature decides. Retaining inputs, outputs, and model versions. Knowing where your training data came from. Being able to demonstrate accuracy with measurement rather than assertion.

Everything in pile two you should be doing regardless of jurisdiction, and a team that has done it is in a good position whichever way the timeline moves next. That is the whole method for planning against a date that is not fixed: build the things that are useful either way, and let the date decide only the sequencing of the rest.

The one item with a real time limit

Most compliance artefacts can be produced when they are needed. Documentation can be written in a quarter. A risk management process can be set up. A conformity assessment happens when it happens.

Logging is different, and it is the reason a deferral is not a reason to stop.

The obligation covers the system's behaviour over its lifetime: inputs, outputs, model version, decision context, retained. If you start capturing that in eighteen months, you will have eighteen months of history when someone asks about a period that started three years earlier. There is no way to fill in the missing history later. The data you did not capture does not exist, and no extension gives it back.

This is also the single most expensive thing to add afterwards for ordinary engineering reasons, since it usually means changing every path where a decision is made rather than adding a separate module. Doing it while there is no emergency, over a couple of quarters, is a completely different project from doing it under a deadline. The detail is in building an audit-ready codebase.

Scope is still the question most teams get wrong

Two determinations decide whether any of this reaches you, and neither is an engineering judgment.

Where you are does not settle it. The Act's reach follows where systems are placed on the market and where their output is used, rather than where the developer is based. A team in the United States selling into Europe, or whose system's output is used there, can be in scope. Concluding otherwise because the company is not European is the most common scoping error we hear.

Risk category is a legal reading, not a technical one. The Annex III categories include employment and worker management, access to essential private and public services including creditworthiness evaluation, and certain uses in education and law enforcement. A scoring or screening product touching credit, housing, or hiring should assume the question is open rather than settled.

Both belong with counsel. What engineering owes that conversation is an accurate inventory of what each feature decides, what it uses to decide, and whether a person reviews the output before it takes effect. That inventory takes about an hour a quarter to maintain and it is the input to every conversation of this kind you will ever have. The design side of it is covered in when a human must stay in the loop.

Article 50 is the part that reaches ordinary products now

Often missed in the discussion about high-risk deferrals is the obligation that actually applies today to a lot of software that nobody would call high-risk.

If a user interacts with an AI system, they have to be told. That is cheap to satisfy, it requires no conformity assessment, and it is worth doing in any market. A customer who finds out afterwards that the support agent was a model has a trust problem with you, and that is true in jurisdictions with no AI regulation at all.

Check every user-facing AI feature against this now rather than in 2027. It is the smallest item on the list and the only one with a deadline that has already passed.

What the delay is good for

Sixteen extra months on high-risk obligations is enough time to build the four things that matter, in an order that spreads the cost.

Start the logging, because it is the one with a time limit. Keep a decision inventory, because it is nearly free and it answers the scoping question. Reconstruct the provenance of your training and validation data while the people who assembled it still work there, since teams that gathered datasets casually over several years find this genuinely hard. And build the evaluation suite, because accuracy and robustness are demonstrated by measurement, and a suite started now produces a documented history by the time anyone asks for it. That history is the part that cannot be manufactured later, which is covered in the business case for evals.

Read that list again and notice that the regulation is not the reason to do any of it. Each one makes the software more maintainable, more debuggable, and easier to hand to somebody else. The Act mostly asks for evidence that you know what your system does, which is a reasonable thing for a company to have regardless of who is asking.

Thanks to the teams who shared what they paused when the date moved. The ones who paused the documentation and kept the logging are in a much better position than the ones who did the opposite, and at the time both decisions looked equally sensible.

A deadline tells you when. It was never the thing telling you what.

Related guide: The EU AI Act and your product.

Sources

EU AI Act implementation timeline, artificialintelligenceact.eu: general application from 2 August 2026; Annex III high-risk obligations from 2 December 2027; Annex I high-risk obligations from 2 August 2028; general-purpose AI obligations applying from 2 August 2025.

The EU AI Act deadline that moved, and what to do with the time