Did the Digital Omnibus Move EU AI Act Enforcement to the AI Office? Partly, With Scope Limits

What changed, and what is now law

The European Commission proposed the Digital Omnibus on AI on 19 November 2025. Parliament and Council reached a political agreement on 7 May 2026. The resulting instrument, Regulation (EU) 2026/1744 of 8 July 2026, amends Regulations (EU) 2024/1689 (the AI Act), (EU) 2018/1139 and (EU) 2023/1230, and entered into force on 27 July 2026.

Any internal planning that still treats the Omnibus as a pending proposal should be updated. The AI Office and Member State authorities have been responsible for implementing, supervising and enforcing the AI Act since 2 August 2026.

The Omnibus also moved the high-risk dates. The original 2 August 2026 date was extended to 2 December 2027 for stand-alone high-risk systems and 2 August 2028 for high-risk AI embedded in products. The delay was attributed to delayed standards, and the final dates are fixed calendar dates rather than being tied to the availability of standards.

How competence is split between the AI Office and national authorities

The Commission describes the AI Act as a two-tiered system. National competent authorities oversee and enforce rules for AI systems, while the AI Office governs and enforces obligations for providers of general-purpose AI models and for a subset of certain AI systems. The Omnibus reinforces the AI Office's powers and centralizes oversight of AI systems built on general-purpose AI models, with the stated aim of reducing governance fragmentation.

The test for AI Office competence is defined by system category, not by the scope of the whole Act. When it supervises and enforces obligations for systems within its competence, the AI Office has the same role and responsibility as a market surveillance authority under the AI Act.

• AI system built on a general-purpose AI model, with system and model from the same provider: AI Office has exclusive competence.
• AI system built on a general-purpose AI model, with providers in the same undertaking: AI Office has exclusive competence.
• System in AI Office competence that is high-risk and subject to third-party conformity assessment under Article 43: AI Office handles conformity assessments and tests before placing on the market or putting into service.
• Cases with specific sectoral supervision: Responsibility can remain with the relevant national competent authority.
• Systems outside the AI Office categories: National competent authorities continue to oversee and enforce.

Why this is not a blanket transfer

Headlines that describe enforcement as moving to the AI Office compress a more specific rule. The regulation's own language ties exclusive competence to a relationship between a system and a general-purpose AI model, and it expressly leaves room for national authorities where sectoral supervision applies. The Commission's earlier staff document made a related point: because the AI Act is product safety legislation by design, much supervision and enforcement takes place at national level.

For a regulated enterprise, this means the answer to "who may ask us for evidence" differs by system. One deployment built on a model from the same provider may sit with the AI Office. Another, in a sector with its own supervisor, may sit with a national authority. A single organization can face both.

The Commission has also said adequate human, financial and technical resources, including permanent technical staff, should be allocated to the AI Office for enforcement. That signals an intent to build real supervisory capacity, which is a reason to treat the AI Office as an active counterpart rather than a distant coordinator.

Implementation decisions and tradeoffs

The main design decision is whether to build evidence around the supervisor or around the system. Building around the supervisor means separate packages that diverge as competence is reassessed. Building around the system means one consistent record of what each AI system was allowed to do and what it did, which can be filtered or exported for whichever authority asks. The second approach costs more design effort up front but is more resilient if competence shifts or a system is reclassified.

The competence determination itself remains a judgment call. The same-provider and same-undertaking tests depend on corporate structure and on how models are sourced, and they can change after an acquisition, a vendor switch or a model upgrade. Treat the mapping as a living record with a named owner and a review cadence tied to changes in architecture, vendors and AI Office or AI Board guidance.

Because enforcement began on 2 August 2026 while high-risk application dates sit in 2027 and 2028, some obligations are not yet in scope for every system. Do not assume that later high-risk dates mean evidence practices can wait. Records that were never captured cannot be reconstructed later.

Where runtime enforcement fits

Evidence is strongest when it is produced by the control that governs behavior, not assembled afterward. Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, applying allow, redact, block, rate limit or escalate-for-approval decisions to individual interactions and tool calls. That enforcement generates continuous, audit-ready evidence, mapped to the EU AI Act among other frameworks.

This is one way to produce a consistent record regardless of which authority asks. Trussed does not determine which supervisor has competence over a system or whether a given obligation applies. Those determinations remain with the enterprise and its legal advisers, and no tooling guarantees compliance.