August 2026 or December 2027? A Developer's Guide to the Omnibus Uncertainty

The situation

If you are building AI systems for the European market, the applicable timeline depends on the provision and system category. Regulation (EU) 2026/1744 now sets 2 December 2027 for Annex III high-risk obligations and 2 August 2028 for Annex I product-embedded obligations.

On 26 March 2026, the European Parliament adopted its negotiating position after the Council's 13 March general approach. The 28 April trilogue ended without agreement, but a follow-up reached agreement on 7 May. Parliament and Council subsequently approved the text, which entered into force on 27 July 2026 as Regulation (EU) 2026/1744.

The negotiation uncertainty described when this article was first published is now resolved. The amended dates are enacted law; contextual classification and the other application dates still need provision-by-provision review.

The useful part of the original planning framework remains: do not treat the EU AI Act as one deadline. Treat the relevant provisions as separate tracks, each with its own application date and scope.

Three tracks, not one deadline

The EU AI Act phases in across separate tracks: prohibited practices under Article 5 (applicable since February 2025), transparency obligations under Article 50 (generally applicable from August 2026, with specific transition provisions), and high-risk system obligations under Annex III (2 December 2027). Each track has its own scope and timeline.

The EU AI Act does not have a single compliance date. It phases in over several years, and the Omnibus changed only specified provisions. Treating it as a single event obscures which obligations are already applicable and which apply later.

What the Omnibus actually changes

The enacted amendment changes substantially more than the two high-risk application dates. Among other changes, it amends definitions, Article 4, Article 6, conformity-assessment and registration provisions, regulatory sandboxes, Article 50, codes of conduct, governance arrangements, and the application schedule. The table below focuses only on selected timeline effects and is not a summary of every amendment.

Most coverage collapses everything into "the deadline is delayed" without distinguishing what is delayed from what isn't. The detail matters.

The Omnibus also changes regulatory sandbox provisions and adjusts the Article 6(3) procedural-task carve-out, but those are less relevant to the planning question most developers face. The short version: GPAI and transparency obligations stay exactly where they are. Only the high-risk application dates for Annex III and Annex I systems move.

The engineering argument for planning to August

This article was written while the timing was uncertain and originally argued for planning against August 2026. That uncertainty is resolved: Regulation (EU) 2026/1744 is in force, and 2 December 2027 is the enacted Annex III application date.

The high-risk obligations under Articles 9 through 15 aren't checkbox items you knock out in a sprint. They require:

• Risk management systems (Article 9) that are iterative, documented, and updated throughout the system lifecycle. You need to identify risks, estimate them, adopt mitigation measures, and test those measures. This isn't a document you write once.
• Data governance (Article 10) covering training, validation, and testing datasets. You need documented practices for data collection, preparation, labelling, and bias examination. If you don't already have this infrastructure, building it takes months, not weeks.
• Technical documentation (Article 11) that describes how the system was designed, developed, and validated. The level of detail required goes well beyond a README file.
• Automatic logging (Article 12) with traceable records of system operation for the entire period it is in use. This means audit logging that is tamper-resistant, time-stamped, and retained.
• Human oversight mechanisms (Article 14) that allow a natural person to understand the system's outputs, intervene, and override. This is an interface design problem as much as a backend one.
• Accuracy, robustness, and cybersecurity (Article 15) with documented performance metrics and resilience measures.

Each of these takes real engineering time. Not because the requirements are unreasonable, but because most teams haven't been building these capabilities in from the start. You're retrofitting governance into systems that were built for speed.

Two scenarios:

Current planning case: You start now against the enacted December 2027 Annex III date. Early work creates time for iteration, evidence gathering, and human validation; it does not by itself establish compliance.

Delay case: You defer implementation until close to the applicable date. That leaves less time to build and validate risk management, logging, technical documentation, human oversight, and any required conformity-assessment work.

The downside of Scenario A is starting early. Scenario B risks insufficient implementation and review time. Article 99 specifies the applicable penalty framework. Primary legislation.

This is an asymmetric bet. Being early costs you nothing beyond the engineering time, and that time isn't wasted even if you didn't need it yet.

The work is not wasted anyway

The requirements in Articles 9 through 15 also overlap with controls found in other governance and security frameworks:

• NIST AI RMF has concepts that can be cross-referenced with risk management, documentation, and testing work. A crosswalk does not establish conformity with either framework.
• ISO 42001 (AI management systems) covers governance structures, risk assessment, and documentation requirements that run parallel to Articles 9 and 11.
• SOC 2 audit criteria for security, availability, and processing integrity overlap with Article 15's accuracy and cybersecurity requirements.
• NIST CSF and ISO 27001 cover the cybersecurity baseline that Article 15 expects.

This isn't a coincidence. AI governance frameworks converge because they're all trying to answer the same question: can you demonstrate that your system is reliable, documented, and auditable? The specific article numbers change. The underlying engineering work doesn't.

Building proportionate logging, documentation, risk assessment, and human oversight capabilities can support several governance frameworks. The appropriate controls and timing still depend on the system, organisational role, and applicable law.

What to do right now

Start by running regula check . to identify code-observable indicators, then determine legal classification from intended purpose and deployment context with qualified reviewers. If the system is confirmed high-risk, plan the applicable documentation, risk-management and record-keeping work against the amended legislation.

1. Find out which track you're on

   Run regula check . in your project root to identify code-observable indicators for review. The scan does not determine whether a system is prohibited, high-risk or subject to Article 50; that requires the intended purpose, organisational role, deployment context, conditions and exceptions.

2. If you're high-risk, start documenting now

   The single highest-value thing you can do today is start writing your Article 11 technical documentation and your Article 9 risk management plan. These are the most time-consuming requirements, and they only get harder to write the longer you wait, because institutional knowledge about design decisions fades. Start now while the people who made those decisions are still around.

3. Get your logging in order

   Article 12 requires automatic logging that records system operation throughout its lifecycle. If your current logging is ad-hoc application logs, you need to build audit-grade logging infrastructure. This is backend work that takes time to design, implement, and validate. Run regula gap . to see where your logging falls short of what Articles 12 and 15 expect.

4. Check your framework crosswalks

   Run regula gap . --project . to review cross-references between selected EU AI Act provisions and other frameworks. Treat the crosswalk as orientation: it does not prove equivalence, certification, or that one control satisfies multiple legal requirements.

The bottom line

Regulation (EU) 2026/1744 is enacted and in force. It sets 2 December 2027 for the Annex III path and 2 August 2028 for the Annex I product-embedded path. Those dates do not determine whether a particular system is high-risk or which transition rule applies.

Use the enacted dates for planning, but establish scope, role, intended purpose, Article 6 classification, and any transition provision before treating a date as applicable to a specific system.

Last reviewed: 14 August 2026 · Author: Regula maintainers · Not legal advice. Regula identifies risk indicators for developer review.

Related reading

• The EU AI Act Omnibus delay — Full timeline, deadline table, and risk-tier-specific guidance
• What happened in the Omnibus trilogue — The 28 April failure, Annex I sticking point, and what followed
• Does the EU AI Act apply to your AI app? — Decision tree for scope, provider vs deployer, and extraterritorial reach

Discuss on Hacker News