EU AI Act Digital Omnibus: The New High-Risk AI Timeline

The EU AI Act Digital Omnibus changed the compliance calendar, but it did not move every EU AI Act duty to one later date. Regulation (EU) 2026/1744 separates the application dates for two high-risk categories. It also changes transitional treatment for systems already on the market and sets a near-term date for certain synthetic-content providers. A security team that replaces its whole roadmap with "delayed" will miss both category differences and obligations already in force.

TL;DR

• Regulation (EU) 2026/1744 is an enacted amendment to the EU AI Act, not a pending simplification proposal.
• Chapter III Sections 1 and 2, plus Section 3, apply to Annex III high-risk systems from December 2, 2027, and to Article 6(1) product-linked systems from August 2, 2028.
• The amendment does not pause the entire Act. Existing duties and separate transition dates still need their own entries.
• Classify each system and operator role before changing a compliance milestone. Record the applicable article and date with the evidence owner.

The EU AI Act Digital Omnibus is now part of the law

The official text is Regulation (EU) 2026/1744, adopted on July 8, 2026 and published in the Official Journal on July 24. Its title identifies it as the "Digital Omnibus on AI." It amends Regulation (EU) 2024/1689, the EU AI Act, along with two product-law instruments.

The consolidated AI Act dated July 27, 2026 integrates those amendments for reading. EUR-Lex warns that a consolidated text is a documentation tool and that the Official Journal texts are authentic. A compliance record should therefore link the amending regulation for legal provenance and use the consolidated text for day-to-day analysis.

This source distinction matters because planning from a proposal or press release can preserve a date that the enacted text replaced. An old summary can do the same. Our AI governance deadlines guide applies the same enacted-source rule across current AI requirements.

High-risk AI now has two principal dates

Article 113, as amended, assigns different dates to Chapter III Sections 1 and 2, plus Section 3. Those sections cover classification and the core requirements and obligations for high-risk AI systems.

• December 2, 2027: AI systems classified as high-risk under Article 6(2) and Annex III.
• August 2, 2028: AI systems classified as high-risk under Article 6(1) and Annex I.

Annex III covers listed use cases such as certain systems used in employment and education. It also covers essential services and law enforcement, plus migration and justice. Article 6(1) concerns regulated products and their safety components when the relevant law requires third-party conformity assessment. Product teams and enterprise deployers should not share a date merely because both records carry the label "high-risk."

The amended text also excludes Article 6(5) from that two-date clause. A schedule that stores only "high-risk" and "due date" loses the legal path that explains the result. Store the classification provision and relevant annex beside the date.

A later date is not a general pause

The Digital Omnibus leaves a staggered regulation in place. Some EU AI Act provisions already apply, while other articles and transition rules have their own dates. Article 113 now says Articles 102 to 110 apply from July 27, 2026. Those provisions cover penalties and related enforcement matters. Chapters I and II have applied since February 2, 2025, subject to the specific exceptions added by the amendment.

A separate transition addresses providers of AI systems, including general-purpose systems, that generate synthetic audio, image, video, or text. If those systems were placed on the market before August 2, 2026, the amended Article 111 requires the provider to take the necessary steps to comply with Article 50(2) by December 2, 2026.

That December milestone can disappear when a program labels the whole Act "delayed." Review the duties by article and role. The EU AI Act compliance checklist is a useful inventory base, but every date in an existing copy now needs reconciliation against the consolidated text.

Existing systems need a transition decision

The amendment also revises Article 111 for high-risk systems placed on the market or put into service before the relevant Chapter III application date. Apart from specified systems, the regulation applies to those earlier systems only when they undergo significant design changes from that date. High-risk systems intended for use by public authorities have a separate compliance endpoint of August 2, 2030.

Do not turn "significant change" into a blank exception field. Keep a dated system version and intended-purpose statement. Preserve the architecture record and release notes, along with the approved assessment of whether a change crosses the legal threshold. A reviewer should be able to reconstruct which model and application logic were in service before and after the change, together with the data flow and decision function.

A dog-eared spreadsheet with one row per vendor will not carry that analysis. The unit of review is the AI system and its use for each operator role. One vendor can supply several systems, and one general-purpose model can sit behind applications with different purposes and classifications.

Build a date register around classification and role

Use a register that can survive another amendment or guidance update. One row should represent one system and use for each operator role.

• System and intended purpose: Name the deployed use and affected people. Record the decision within the business process.
• Operator role: Record the relevant role. This may be provider, deployer, importer, distributor, product manufacturer, or authorised representative.
• Classification route: Cite Article 6(1) or Article 6(2) and Annex III. Otherwise record the reason the system falls outside those paths.
• Applicable provisions: List the articles behind each requirement instead of using a generic EU AI Act label.
• Date and source: Link the Official Journal amendment and record the date derived from the current text.
• Evidence owner: Assign the accountable function. This may be product, legal, security, privacy, procurement, HR, or another function.
• Transition basis: Preserve market-placement dates and design versions. Also record significant-change decisions and public-authority use.

This format keeps legal interpretation separate from technical proof while connecting them. It also exposes disagreement early. If legal classifies an employment tool under Annex III and engineering tracks it as an ordinary assistant, the conflict appears before the evidence package is due.

Security evidence should follow the deployed path

For an AI system reached through authenticated HTTP requests, the evidence set can include caller identity and application, plus the destination model and route. It can also record the policy version and decision, together with the time and correlation identifier. That record helps establish which deployed path was used and whether an enterprise access or data rule ran before transmission.

The third-party AI risk management guide explains how to gather evidence for models embedded in vendor services. The AI incident response runbook covers the operational handoff from a suspicious model interaction to triage, containment, and retained evidence.

These records cover one layer and do not establish a system's intended purpose or prove conformity assessment. They also do not validate training data or determine whether a design change is legally significant. Traffic that bypasses the controlled route is outside the record as well. Keep product and legal artifacts beside runtime evidence rather than claiming that one log satisfies the regulation.

DeepInspect

DeepInspect can support evidence for authenticated HTTP traffic between users or agents and LLM endpoints. It evaluates identity-aware policy on traffic routed through the proxy and records the decision with the route and model, plus the policy and correlation context.

That record can support access review and data-policy enforcement, along with logging and incident investigation for the controlled model path. DeepInspect does not classify a system under the EU AI Act or perform conformity assessment. It also does not govern model training or observe traffic that bypasses the authenticated HTTP route.

Book a demo today.