Original EU AI Act vs Digital Omnibus: What Changed for Your Compliance Roadmap

From proposal to enacted law

Many 2025 roadmaps treated the Digital Omnibus as a pending proposal and carried the original application dates as the working assumption. That framing is now out of date. The Commission proposed the Digital Omnibus on AI on 19 November 2025 as targeted amendments to the AI Act and the civil aviation common rules regulation. A political agreement followed on 7 May 2026. The adopted act, Regulation (EU) 2026/1744 of 8 July 2026, amends Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230, and it entered into force on 27 July 2026.

The Commission's stated reason was practical. Harmonised standards were delayed, and so was the designation of national competent authorities and conformity assessment bodies. Those delays put the 2 August 2026 entry into application of the high-risk rules in jeopardy. The Commission describes the result as targeted simplification that preserves strong safeguards for people's safety and fundamental rights.

One distinction matters for planning. The November 2025 proposal would have tied the high-risk application date to the availability of support measures such as harmonised standards, common specifications or Commission guidelines. The in-force Omnibus instead sets fixed dates. A roadmap that still waits on a standards-availability trigger is built on the proposal, not on the law.

Side-by-side by roadmap assumption

The comparison below is organized by the assumptions a 2025 roadmap typically encoded, not by article number. Where the original and amended positions are identical, the row says so.

• Annex III high-risk readiness date: Original: 2 August 2026. Amended: 2 December 2027. Re-baseline stand-alone high-risk use cases to this date.
• Annex I embedded high-risk readiness date: Original: 2 August 2026. Amended: 2 August 2028. AI embedded in regulated products follows a separate, later date.
• Trigger for high-risk application: Proposal (November 2025): linked to availability of standards, common specifications or guidelines. In force: fixed calendar dates. Remove standards-availability triggers from milestone logic.
• Prohibitions 1-8: Original: February 2025. Amended: unchanged. Existing roadmap items stay as they are.
• General-purpose AI (GPAI) rules: Original: August 2025. Amended: unchanged. These already apply.
• Ninth prohibition: Not in the original sequence. Added by the Omnibus and applicable from 2 December 2026, earlier than either high-risk date.

What to re-validate, and what is still unsettled

Start with classification. Because Annex III systems and Annex I embedded systems now have different dates, a single enterprise-wide high-risk milestone no longer fits. Inventory each system and tag it by route. A date change then affects only the controls tied to that route, rather than forcing a whole-program replan.

Next, check the earlier date. The new prohibition applies from 2 December 2026, which falls before either high-risk deadline. Review current and planned systems and features against it now, since this is the one change that pulls an obligation forward instead of pushing it back.

Then look at ownership and documentation tasks. A later date changes when obligations apply, not whether the work is needed. The Commission describes the Omnibus as preserving safeguards, and a date shift alone does not show that any substantive obligation was removed. Re-validate ownership, documentation and control tasks against the consolidated AI Act text before deferring anything, and record Regulation (EU) 2026/1744 as the legal basis for each roadmap date so decisions remain traceable.

Two dependencies remain open. Standards availability and the designation of national competent authorities and conformity assessment bodies were the causes of the delay, and they still shape high-risk conformity work. Assign an owner to track both. Separately, the Commission calls the Omnibus a first step and says it is stress-testing the Digital Rulebook through the Digital Fitness Check. Further simplification proposals are possible, so treat anything beyond the enacted text as unsettled and schedule periodic re-checks rather than planning around speculation.

Controls and evidence that do not depend on the date

A regulator or auditor will ask what an AI system was allowed to do and what it actually did. That question does not move with an application date. Policies, approvals and reviews that exist only as documents or as after-the-fact reviews cannot answer it for individual interactions.

For systems that call models and tools, the practical answer is enforcement in the execution path. Each interaction and tool call is evaluated against policy at runtime, with a defined outcome: allow, redact, block, or escalate for human approval. The decision itself becomes the record. This design has two properties that suit an uncertain timeline. It can be rolled out per system, so Annex III and Annex I routes can be sequenced separately. And the same layer that enforces policy can produce the evidence, so evidence does not have to be reconstructed later from scattered sources.

The tradeoff is scope. Runtime enforcement addresses what AI does at the level of interactions and tool calls. It does not replace classification, conformity assessment, or documentation work, which still need owners and a plan tied to the correct date. Treat it as the operational foundation under those programs, not a substitute for them.

Before finalizing evidence schemas, map each record type to the current wording of the relevant AI Act obligations. Designing evidence around assumed requirements risks rework if the text differs.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Outcomes include allow, redact, block, rate limit, and escalate for human approval, applied to individual interactions and tool calls. Enforcement is at runtime, not reviewed after the fact.

That enforcement generates continuous, audit-ready evidence mapped to the EU AI Act, alongside HIPAA, NAIC, NYDFS and NIST. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency. It is built for the regulated enterprise that must show what its AI was allowed to do and what it did, and it is useful whichever application date applies to a given system.