AI Omnibus: new dates for high-risk obligations

The AI Omnibus, formally adopted by the European Parliament and Council in 2026, moved the EU AI Act’s core obligations for high-risk AI systems to 2 December 2027 for standalone high-risk systems and 2 August 2028 for high-risk systems embedded in products (Addleshaw Goddard, 2026). The obligations themselves, including automatic logging under Article 12 and the deployer’s duty to keep the logs under Article 26, are unchanged.

This post sets out what the Omnibus is, what moved, what else changed, what did not, and what a team running agents should do with the time. It is part of the guide to audit trails for AI agents under the EU AI Act. Where we interpret rather than report we say “in our reading”, and none of this is legal advice.

What is the AI Omnibus?

Regulation (EU) 2024/1689, the AI Act, entered into force in 2024 with a staged timetable in Article 113. The Regulation as a whole applied from 2 August 2026, with earlier dates for the prohibitions and general provisions and a later date, 2 August 2027, for the obligations tied to Article 6(1), the route by which a safety component of a regulated product becomes high-risk (Regulation (EU) 2024/1689).

The AI Omnibus is an amending measure. The European Commission introduced it in November 2025, and the European Parliament and the Council formally adopted it in 2026. Its best-known effect is to push back the dates on which the high-risk obligations apply, but it also changes a number of other provisions, summarised below. It enters into force on the third day after its publication in the Official Journal (Addleshaw Goddard, 2026).

It should not be confused with the separate Digital Omnibus, which proposes amendments to other EU laws including the GDPR, NIS2 and the Data Act, and which was still going through the legislative process when the AI Omnibus was adopted (Addleshaw Goddard, 2026).

What are the new dates for high-risk obligations?

The core obligations for providers and deployers of high-risk AI systems were due to apply in August 2026. The Omnibus extends them to two new dates, depending on the kind of system (Addleshaw Goddard, 2026).

The new dates come from the Addleshaw Goddard briefing on the adopted text. The original dates come from Article 113 of the 2024 Regulation, where the general application date is 2 August 2026 and Article 6(1) with “the corresponding obligations in this Regulation” applies from 2 August 2027 (Regulation (EU) 2024/1689).

So standalone systems gained sixteen months and embedded systems gained twelve. For a team that had planned to be ready in August 2026, the work is the same and the deadline is later. For a team that had not started, the delay is the difference between an impossible timetable and a tight one.

What do “standalone” and “embedded” mean?

The briefing uses the words “standalone” and “embedded in products” and does not use the Annex labels. In our reading the two categories map onto the two routes to high-risk status in Article 6 of the Regulation (Regulation (EU) 2024/1689).

Embedded corresponds to Article 6(1): a system intended as a safety component of a product, or that is itself a product, covered by the Union harmonisation legislation listed in Annex I, where that product must undergo a third-party conformity assessment. Machinery, medical devices and vehicles are typical Annex I products. These systems reach the market through an existing product-safety regime, which is why their AI Act obligations were always scheduled later.

Standalone corresponds to Article 6(2): a system used in one of the areas listed in Annex III, such as biometrics, critical infrastructure, education, employment, access to essential services, law enforcement, migration, and the administration of justice. These systems are high-risk because of what they are used for, not because they sit inside a regulated product.

For agent teams the distinction is usually easy. An agent that screens candidates, triages benefit claims or assists with a credit decision is in an Annex III area and is standalone. An agent that forms part of the control software of a machine or a medical device is embedded. The large majority of agents that are high-risk at all will be standalone, which means the date that matters for most readers of this post is 2 December 2027.

Article 6(3) adds a derogation: an Annex III system is not high-risk where it does not pose a significant risk of harm and, for example, performs only a narrow procedural task or a preparatory task to a human assessment, unless it profiles natural persons (Regulation (EU) 2024/1689). The Omnibus did not change that test according to the briefing, so classification work done before the Omnibus still stands.

What else did the Omnibus change?

The dates got the headlines, but the adopted text touches several other parts of the Act. The following is what the briefing reports (Addleshaw Goddard, 2026).

Two of these matter directly for agent teams. The registration change means that providers of standalone high-risk systems still have to register them, so an agent in an Annex III area still ends up in the EU database. The AI literacy outcome means the duty on providers and deployers, which has applied since February 2025, stays where it is.

The briefing does not report any change to Articles 12, 19 or 26, the logging and retention provisions, and it does not mention harmonised standards or penalties. We treat those as unchanged until the consolidated text says otherwise.

What did not change?

The content of the high-risk obligations. A high-risk system must still “technically allow for the automatic recording of events (logs) over the lifetime of the system” under Article 12(1). Providers must still keep those logs where under their control, for a period appropriate to the intended purpose “of at least six months”, under Article 19(1). Deployers must still keep them on the same terms under Article 26(6) (Regulation (EU) 2024/1689). Risk management, data governance, technical documentation, human oversight and the rest of Chapter III, Section 2 remain as they were.

The classification. What makes a system high-risk is its intended use under Annex III or its role in an Annex I product. The Omnibus does not turn high-risk agents into low-risk ones, and the Article 6(3) derogation is the same test it was.

The roles. The provider still designs the logging capability and the deployer still keeps the logs. A team that builds an agent on a third-party model and runs it in-house is, in our reading, likely to be both, with both sets of duties.

The direction. The dates moved later. Nothing in the adopted measure, as the briefing reports it, suggests they will move again, and planning on a second delay is a bet rather than a strategy.

Why does a later date not mean less work?

Three features of the logging provisions mean the delay changes the deadline but not the amount of work, and in one respect makes it larger.

Logging is “over the lifetime of the system”. Article 12 does not ask for a log from the application date onwards. It asks for a capability that runs for the lifetime of the system. In our reading a system in production in 2026 that only starts keeping an adequate record in late 2027 will have an unrecorded period in its history that cannot be filled afterwards, because a record of what an agent did can only be made while it is doing it. Every month of delay in building the record is a month that will be missing when someone asks.

Retention is a floor with an open top. The six months in Articles 19 and 26 is a minimum; the operative period is whatever is “appropriate to the intended purpose” (Regulation (EU) 2024/1689). A team cannot set that period, or the storage and access arrangements that go with it, without first knowing what the log contains and how large it will be. That design work takes time and does not get shorter because the date moved.

The record has to be outside the agent’s reach. This is the part that takes longest to retrofit. An agent’s own trace is not an audit log if the agent can edit it, and Qin et al. found that most of the agent harnesses they tested let the agent delete or rewrite its own trace, with agents doing so when it served their goal (Qin et al., 2026). Their recommendation is logging outside the agent’s control. Moving a record out of the agent’s reach is an architectural change to how the agent is run, not a configuration flag, and an architectural change to a production system takes quarters, not weeks.

How should an agent team use the time?

For a team deploying agents in a use that is or might be high-risk, four pieces of work are worth starting now, because each takes longer than it looks and each depends on the one before.

1. Classify, per agent and per use. Work out whether Annex III or Annex I applies, and whether the Article 6(3) derogation does. The same agent can be in scope in one department and out of scope in another, so the unit of analysis is the deployment. Write the intended purpose down; the adequacy of the log will be judged against it.

2. Decide what an event is. Article 12’s logging has to give traceability appropriate to the intended purpose. For an agent, in our reading, the record must be able to say what the agent was asked, what it did, what it changed and why it stopped. Settle that definition before building anything, because it decides what the record has to capture and what it can leave out.

3. Get the record outside the agent’s reach. Logging produced by something other than the agent, stored where the agent cannot reach it, and kept tamper-evident afterwards is the design the article’s purpose implies. Start with what already exists: the systems the agent touches keep their own records, version control keeps its history, and the environment the agent runs in can be observed from outside. None of those is complete on its own, and the gaps between them are where the design work is.

4. Set retention and access. Decide how long the record is kept for each intended purpose, reconcile that with data protection law, and decide who can read it and how a market surveillance authority or an auditor would be given access. Then test that the record can actually answer a reviewer’s questions by running a mock review against it.

A team that does these four things in 2026 and early 2027 will arrive at 2 December 2027 with a year of history it can show. A team that starts in mid-2027 will arrive with a capability and no history.

Common misreadings of the Omnibus

Because the Omnibus was widely reported as a “delay”, a few misreadings are circulating. The table sets them against what the briefing and the Regulation say.

In our reading the honest summary is that the Omnibus bought time for the hardest obligations and tightened or clarified several smaller ones. It did not reduce what a high-risk agent must be able to show about its own operation.

What this means for teams deploying agents

The date that matters for most agent deployments is 2 December 2027, because most agents that are high-risk at all are standalone Annex III systems. The work has not changed: classify each deployment, define what an event is for the agent, put the record outside the agent’s reach, and set retention and access. Start with classification, because it decides whether any of the rest applies, and start now, because the record can only be made while the agent is running. Confirm the dates and the retention wording against the consolidated text with your own counsel before you commit a budget to them.

Inoku is building an independent record of what agents did for teams in this position; it is research-stage work, and the plan above does not depend on it. For how the dates fit with Article 12, the deployer’s duties and what an auditor will accept, see the full guide to audit trails for AI agents under the EU AI Act.