The Legal State of Play
The EU AI Act’s high-risk compliance deadline is August 2, 2026. That is not a projection. It is the date written into the enacted text, confirmed by artificialintelligenceact.eu, the independent tracker of official EU AI Act provisions. No amendment extending this deadline has been published in the EU Official Journal. Until that publication occurs, no extension is law, regardless of what negotiators reportedly agree in trilogue.
The Omnibus proposal seeks to defer high-risk compliance obligations to December 2, 2027. Reports published April 29 indicate the second political trilogue ended without agreement. The June legislative calendar represents the remaining window for a deal that could reach the Official Journal before August. What a political agreement “in principle” actually requires is worth stating plainly: a formal Council decision, a European Parliament vote, and Official Journal publication. Statements of intent do not change compliance obligations. Compliance teams cannot defensibly plan for a deferral that has not completed that process.
That means two scenarios remain live. If the Omnibus reaches the Official Journal before August: obligations shift to December 2027. If it does not: August 2 applies. Any compliance program that has not stress-tested the August 2 scenario is carrying legal risk it may not have priced in.
The TJS brief published this week on the two-scenario framework covers the political mechanics. This piece addresses the operational question: for teams planning to the original deadline, what does “compliant” actually look like in 94 days?
Annex III: What the Deadline Actually Requires
Annex III of the EU AI Act defines eight categories of high-risk AI use cases, including biometric identification, critical infrastructure, employment decisions, and access to essential services. Systems in these categories face a specific set of requirements that must be satisfied before they can be lawfully placed on the EU market.
The core obligations are:
Conformity assessment
Providers must complete a conformity assessment demonstrating the system meets the Act’s requirements. For most Annex III categories, this is a self-assessment. For remote biometric identification systems, a third-party notified body assessment is required. Notified body capacity is already a known bottleneck, organizations requiring third-party assessment should not assume availability.
Fundamental Rights Impact Assessment (FRIA)
Deployers in public-body contexts and certain private deployers must complete an FRIA documenting how the system affects fundamental rights. This is not a checkbox exercise. The assessment requires documented methodology, specific rights analysis tied to the use case, and review by the responsible party before deployment. Organizations that have not started this work face a timeline problem.
Technical documentation
A comprehensive technical file covering system architecture, training data characteristics, performance metrics, known limitations, human oversight mechanisms, and post-market monitoring plans. This documentation must exist before the system is registered, not as a post-launch exercise.
EU database registration
Providers and deployers must register systems in the EU-wide AI database before placing them on the market or putting them into service. The database requires information drawn directly from the technical documentation.
The provider/deployer distinction matters for obligation allocation. A company that builds an AI system and a company that deploys it into a use case can each carry compliance obligations, and the allocation depends on the contractual and operational relationship between them. Organizations deploying third-party AI systems in Annex III contexts cannot assume the provider has satisfied all obligations on their behalf.
One compliance challenge the 94-day window makes visible: agentic AI systems. As covered in prior TJS analysis, agentic systems present a certification challenge the Act’s conformity assessment framework was not designed around. Systems that adapt behavior based on context drift from the documented characteristics that conformity assessments are built on. Teams deploying agentic systems in Annex III categories should factor this into their assessment methodology now, not in July.
GPAI Systemic Risk: The Parallel Track
The Annex III obligations apply to deployers and providers of specific use cases. A separate compliance track runs in parallel for developers of general-purpose AI models that cross the EU AI Act’s systemic risk threshold: 10^25 floating point operations (FLOP) of training compute, per Article 51 of the enacted text.
This threshold matters because designation as a GPAI model with systemic risk triggers a distinct set of requirements that do not apply to lower-compute models. These include: model evaluation against standardized benchmarks, adversarial testing (red teaming), cybersecurity incident reporting, systemic risk assessment, and ongoing cooperation with the EU AI Office.
Epoch AI’s independent compute tracking provides the current landscape. As of April 20 reporting, 12 AI models had crossed the 10^25 FLOP threshold. The April 27 Epoch AI update may revise that count, teams should check current Epoch data directly, as this figure changes with new model releases and methodology updates. The number matters for one specific reason: if your organization is a provider of a model that crosses this threshold, or a deployer building on top of one, the GPAI systemic risk obligations apply to the provider, and deployers should verify their vendors are in compliance.
The GPAI systemic risk requirements are not duplicative of Annex III. A foundation model developer can face GPAI obligations whether or not their model is used in a high-risk application. And a company deploying a GPAI-threshold model in an Annex III context may face obligations under both tracks simultaneously.
The 90-Day Implementation Reality
For a mid-market company deploying one or two Annex III use cases, a hiring tool, a credit scoring model, a medical device AI, what does a realistic 94-day compliance sprint look like?
Weeks 1–3: Gap assessment and scope confirmation
Which systems are in scope? Who is the provider, who is the deployer, and what does your contract say about obligation allocation? What documentation currently exists, and what is missing? This is not optional groundwork, it determines the size of the sprint ahead.
Weeks 3–6: Technical documentation
If documentation does not exist, building it from scratch takes time proportional to system complexity. For organizations with existing AI governance programs, this stage compresses significantly. For organizations that have deferred documentation, this is the bottleneck.
Weeks 5–8: FRIA completion (where required)
The FRIA methodology should be in place before the assessment begins, not developed during it. Organizations without an established FRIA framework should prioritize this early.
Weeks 7–10: Conformity assessment
Self-assessments can proceed in parallel with documentation. Third-party notified body assessments require engagement now, do not wait until June to book a notified body if one is required. Notified body capacity is finite and demand is rising.
Weeks 10–13: Registration and final sign-off
EU database registration requires completed documentation. Build in time for internal governance review before submission. Waiting until week thirteen to discover a documentation gap leaves no recovery window.
What this schedule makes clear: organizations that have not started documentation, FRIA methodology development, or notified body engagement are already running late. The June political window for the Omnibus does not give compliance teams additional time to begin, it only potentially changes the deadline they are working toward. Planning to the later date while delaying the work is a compounding risk, not a legitimate hedge.
What to Watch in May
The next 30 days will determine whether the Omnibus can still move. The June legislative calendar is the constraint, a political agreement that does not reach the Official Journal before August provides no legal relief.
Three things to monitor:
Official Journal publication
This is the only legally operative signal. Political statements, press releases, and trilogue summaries do not change compliance obligations. The EU Official Journal is the single source of truth.
Civil society opposition
Groups including Amnesty International and EPIC have opposed aspects of the Omnibus on fundamental rights grounds, particularly regarding biometric and medical AI systems. Their opposition is not dispositive, but it represents a structural tension in the negotiations that has slowed agreement. If their specific concerns about Annex III scope for biometric systems drive a narrower compromise, the scope of any deferral matters, not just its timing.
Notified body availability
If the Omnibus fails and August 2 stands, notified body demand will spike in June and July. Organizations that require third-party conformity assessment and have not begun that process are competing for a finite resource in a shrinking window.
TJS Synthesis
The Omnibus debate has consumed significant attention in EU AI Act coverage. The more useful question for compliance teams is one the political calendar cannot answer: are your systems documented, assessed, and registerable before August 2?
The operational answer to that question does not change depending on whether a deal happens in May. If the documentation exists and the assessments are complete, a deferral means breathing room. If the documentation does not exist, a deferral means more time to catch up, but the work still has to happen. The teams that will be in the best position regardless of the political outcome are the ones treating August 2 as the operative date right now.
One implication worth sitting with: the organizations most likely to benefit from an Omnibus deferral are the ones least prepared for August. For compliance teams that have been running a genuine program, the more important question is whether the Omnibus’s proposed scope changes, particularly around retroactivity, would affect systems already in deployment. Legal analysts note that non-retroactive rules could leave systems placed on the market before late 2027 outside ongoing oversight requirements, which cuts both ways: it is relief for early deployers, and a governance gap for everyone else.