EU AI Act High-Risk Obligations: Enforcement Dates After the Digital Omnibus

What changed, and when

The AI Act (Regulation (EU) 2024/1689) originally stated that it would apply from 2 August 2026. For high-risk obligations, that date no longer holds.

On 19 November 2025 the Commission proposed targeted amendments, the Digital Omnibus on AI. The stated aims included addressing delays in standards for the high-risk rules and in designating national competent authorities and conformity assessment bodies. The Commission's first approach tied the high-risk timeline to confirmation that standards and tools were available, with up to 16 months of adjustment. On 7 May 2026 the Council and Parliament reached a provisional agreement that replaced this mechanism with fixed dates.

The result is Regulation (EU) 2026/1744 of 8 July 2026, which amends Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230. It sets the application of Chapter III Sections 1 to 3 (the high-risk system requirements and obligations) to 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and to 2 August 2028 for systems classified under Article 6(1) and Annex I. Other provisions of the Omnibus enter into application in a staggered way, all by 2 August 2027. Because Commission web pages and legal texts may be updated at different times, compliance teams should have counsel confirm the dates in the final legal text before they appear in external statements.

Enacted, scheduled and superseded dates

The table of dates below separates what is binding today from what is scheduled. Nothing in this list is a pending proposal.

• 2 February 2025: applicable: Definitions, general provisions, prohibited practices and AI literacy obligations.
• 2 August 2025: applicable: Governance structure rules, penalty provisions and obligations for providers of general-purpose AI models. The AI Office holds enforcement powers over these models.
• 2 August 2026: superseded: The original general application date no longer governs high-risk obligations.
• By 2 August 2027: scheduled: Other Omnibus provisions enter into application in a staggered way, all by this date.
• 2 December 2027: scheduled: High-risk requirements apply to Annex III use cases under Article 6(2).
• 2 August 2028: scheduled: High-risk requirements apply to AI embedded in regulated products under Article 6(1) and Annex I.

Common misreadings, corrected

"The whole Act is postponed." It is not. Prohibited practices, AI literacy, governance, penalties and general-purpose AI model obligations are already applicable. Penalties are set as a percentage of annual turnover or a predetermined amount, whichever is higher, with adjustments for SMEs, start-ups and small mid-caps. A programme that treats the Act as dormant will miss duties that exist today, such as evidencing AI literacy measures for staff and others operating AI systems on the organisation's behalf.

"The whole Act is fully in force." Also wrong. Chapter III high-risk requirements are not yet applicable, so no authority can enforce them against a system today.

"Prohibited-practice and general-purpose AI duties are high-risk duties." They are separate sets of provisions with separate dates. Run them as a distinct workstream from the high-risk programme.

"Annex III and Annex I share one date." They do not. Annex III use cases, including biometrics, critical infrastructure, education, employment, migration, asylum and border control, apply from 2 December 2027. High-risk AI embedded in regulated products has until 2 August 2028.

"The delay is only a proposal." That was accurate in late 2025. It is no longer accurate. The fixed dates are set in an adopted regulation, which also removes the earlier idea of a floating date tied to standards availability.

Classification and legacy systems

Classification determines which date, if any, applies to a system. Under Article 6, a provider that considers an Annex III system not to be high-risk must document that assessment before placing the system on the market or putting it into service. Deployers should expect to be asked who made each classification decision and on what basis.

The Commission has published guidelines on high-risk classification, including practical examples of high-risk and not-high-risk use cases. They are not legally binding, but they reflect the Commission's interpretation and will guide enforcement. The Commission has said further guidelines on high-risk compliance obligations will follow, and it reviews the lists of high-risk uses and prohibited practices annually, so a classification register needs periodic review.

Regulation (EU) 2026/1744 also addresses systems already in the market. High-risk systems placed on the market or put into service before the Chapter III application date are covered only if, from that date, they undergo significant changes in design. That makes change control a compliance control: teams need a defined trigger to test whether a model swap, new tool integration or workflow redesign counts as a significant change. Providers and deployers of high-risk systems intended for use by public authorities have a separate duty to take steps to comply, and counsel should review that provision directly.

A no-regret plan for the interim

The dates are now fixed in law, so the main planning risk is no longer a moving deadline. It is starting late. The work below does not depend on the exact application date, and none of it needs to wait for further guidance.

Start with the register and the already-applicable duties, since those carry present exposure. Then build the technical capabilities that high-risk obligations will rely on, such as risk management, record-keeping, human oversight and post-market monitoring. The detailed requirements of each Article should be mapped by legal and technical owners against the Regulation text. What can be settled now is the engineering pattern: per-interaction records and a defined route for human escalation can be put in place before 2027 and refined as guidance arrives.

• Inventory and classify: List every AI system, classify it against Annex III or Article 6(1) and Annex I, and record who signed off. Keep documented assessments for systems judged not high-risk.
• Separate the workstreams: Track prohibited practices, AI literacy, general-purpose AI and governance duties apart from the high-risk programme.
• Evidence AI literacy now: Article 4 has applied since February 2025. Assign an owner and keep records of the measures taken.
• Add a change-control trigger: Test each design change to a system already on the market for whether it may bring the system into scope.
• Build per-interaction records: Capture what each system was asked, what it was allowed to do and what it did, in a form an auditor can inspect.
• Keep a regulatory-change log: Separate enacted law, scheduled dates and pending proposals, and send any discrepancy to legal counsel.

Where runtime enforcement fits

Human oversight and traceable records of system operation are difficult to retrofit if controls only review activity after the fact. Policy that is enforced at runtime, in the execution path, produces records as a by-product of each decision rather than as a separate reconstruction exercise.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. For each individual interaction or tool call it can allow, redact, block, rate limit or escalate for human approval. That enforcement generates continuous, audit-ready evidence, mapped to frameworks including the EU AI Act. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

The scope is specific. Trussed works at the level of individual interactions and tool calls. It does not provide model or dataset provenance, or end-to-end tracing of agentic workflows, and it does not deliver EU AI Act compliance on its own. Classification, risk management, documentation and organisational accountability remain the responsibility of the regulated enterprise. Runtime enforcement and evidence are one technical layer within that programme.