Most infra and security teams I talk to have quietly filed the EU AI Act under "legal's problem." That filing expires on August 2, 2026. That's the date the high-risk obligations stop being a bullet on a governance slide and turn into something a notified body, a national market-surveillance authority, or a plaintiff can actually hold you to. The twist that makes this messy: Brussels itself is now trying to move the date, and the proposal isn't law. You're being asked to build to a deadline that might slip, with no certainty that it will.

The deadline is real until a law says otherwise

Here's the part people are getting wrong. On May 7, 2026, EU institutions reached a provisional political agreement on a Digital Omnibus package that would push the high-risk obligations back. Stand-alone Annex III systems would move to December 2, 2027, and AI embedded in regulated products to August 2, 2028. If you read the headlines, that sounds like eighteen months of breathing room dropped in your lap.

It isn't. As of early June 2026, that deferral has not been enacted. The text in force still reads August 2, 2026. A "provisional political agreement" is a press release with good intentions, not an instrument you can wave at a regulator who shows up asking for your conformity documentation. I've watched enough "it'll definitely get delayed" bets go sideways in security to know the shape of this one. The downside of planning to August 2026 and being wrong is that you finish early. The downside of planning to December 2027 and being wrong is 3 to 7 percent of global turnover. That asymmetry settles the argument.

So the posture is simple: build to August 2, 2026, watch the Omnibus, and treat any slip as a bonus you bank only after it's signed.

Who actually gets caught by this

The trigger is Annex III. If your system touches recruitment or worker management, credit scoring, biometric identification, critical-infrastructure safety components, or AI used in education, essential services, or law enforcement, you're in scope. The Act then reaches you as either a provider (Articles 9 through 17) or a deployer (Article 26).

This is where teams misread their own exposure. Plenty of groups who describe themselves as "just running a model" or "just calling an API" are providers under the legal definition and have no idea. The provider/deployer split isn't cosmetic. It decides which article set applies and which penalty ceiling you're sitting under. The fines are GDPR-scale and designed to get a CISO's attention: up to €15 million or 3 percent of global turnover for high-risk non-compliance, and €35 million or 7 percent for prohibited practices. The enforcement machinery (national authorities, conformity assessments, an EU registration database) is being stood up to match those numbers, not as a deterrent that never fires.

Most of these requirements are engineering work, not paperwork

The reason this can't wait for legal to "hand over the requirements" in July is that a good chunk of the Act is platform behavior, not policy text. Read Articles 9 through 15 as a backlog:

  • A documented risk-management system (Art. 9)
  • Data-governance controls over training and input data (Art. 10)
  • Technical documentation that matches Annex IV (Art. 11)
  • Automatic logging and record-keeping (Art. 12)
  • Transparency to deployers (Art. 13)
  • Human oversight that actually intervenes (Art. 14)
  • Accuracy, robustness, and cybersecurity safeguards (Art. 15)

Automatic logging, post-market monitoring, and serious-incident reporting inside fixed timeframes are features that have to live in your stack. You don't write those into existence in a Word document. In practice, the one that bites teams is logging under Article 12: not "do you have logs" (everyone has logs) but "can you reconstruct what a specific high-risk decision saw, which model version produced it, and who the human in the loop was, on demand, for the retention period." If your inference path doesn't capture model version, input lineage, and oversight events as first-class records today, that's weeks of work, not an afternoon.

The release-blocking part everyone underestimates

Before a high-risk system ships, you need a conformity assessment, an EU declaration of conformity, CE marking, and registration in the EU database. I keep seeing this treated as paperwork you backfill after launch. It isn't. It's a gate in front of the release, structurally closer to a SOC 2 audit than to a README update. If your CI/CD pipeline can push a high-risk model to production without any of those artifacts existing, your pipeline is the compliance gap.

There's a separate clock on transparency, too. Chatbot-disclosure rules land in August 2026. AI-generated-content labeling gets only a short deferral to December 2, 2026 under the current text. So even the "lighter" transparency duties are closer than the headline date suggests.

ISO 42001 is a scaffold, not a shield

A lot of teams are reaching for ISO 42001 as their answer, and I understand why. It maps cleanly onto roughly seven articles: risk management (9), data governance (10), technical documentation (11), record-keeping (12), transparency (13), human oversight (14), and quality management (17). It gives you a management-system discipline and a credential that customers recognize.

But certification does not equal compliance, and representing it to a regulator or notified body as proof of conformity is a mistake. ISO 42001 leaves real gaps: the depth of Annex IV technical documentation, the conformity-assessment procedure itself, CE marking, EU-database registration, and incident reporting. None of those fall out of the certificate. Use 42001 as the frame you hang the management system on and as a commercial signal. Then map every gap it doesn't cover and own those separately, with names attached.

You're aiming at a target that isn't finished

Here's the genuinely unfair part. prEN 18286, the harmonized European standard that will eventually grant a presumption of conformity for Article 17, is still in public inquiry through CEN-CENELEC JTC 21 and isn't expected until the end of 2026. That's after the deadline it's supposed to support. Early compliers are shooting at a target that hasn't finished being drawn.

The practical consequence: don't wait for the harmonized checklist, because it won't arrive in time to help you in August. You have to write your own justification for how each control satisfies the relevant article, and be ready to defend that reasoning rather than point at a standard number. And the readiness data is what you'd expect from any deadline that catches teams flat. Industry research, including a Cloud Security Alliance readiness note, points to a wide gap between enterprises that have an Annex III system and those that can actually demonstrate the controls for one.

Where to start before August 2

Concrete, in rough priority order, and each tied to something above:

  1. Run a shadow-AI and model inventory this month, then classify every system against Annex III. You cannot scope any of this until you know what's in scope, and the systems that bite are the ones nobody registered. This is the prerequisite for everything else.
  2. Assign provider-or-deployer to each in-scope system, in writing. This determines whether Articles 9 through 17 or Article 26 applies, and which penalty ceiling (3 percent versus 7 percent) you're exposed to. Don't let it stay ambiguous.
  3. Audit Article 12 logging against the real bar. For each high-risk system, prove you can reconstruct a single decision: model version, input lineage, and the human-oversight event. If you can't, that's the longest-lead engineering item, so start it first.
  4. Make conformity artifacts a release gate. Conformity assessment, EU declaration of conformity, CE marking, and database registration should block deploy, not trail it. Wire the check into the pipeline that ships high-risk models.
  5. Stand up post-market monitoring and incident reporting as pipelines, not policies. Serious-incident reporting runs on fixed timeframes, so the plumbing has to exist before the first incident, not after.
  6. Treat ISO 42001 as scaffolding and document the gaps explicitly. Annex IV documentation depth, conformity assessment, CE marking, database registration, and incident reporting are not covered by the certificate. List them, assign owners, track them separately.
  7. Plan to the in-force date; bank the Omnibus deferral only if it's signed. Build to August 2, 2026. If December 2, 2027 becomes law, you've bought slack. If it doesn't, you're covered. The reverse bet puts turnover on the table.

The teams that come through this cleanly won't be the ones who guessed the deadline right. They'll be the ones who already knew which systems they were running and could show the logs to prove how they ran.

Sources

  • https://artificialintelligenceact.eu/implementation-timeline/
  • https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines-and-other-key-changes/
  • https://labs.cloudsecurityalliance.org/research/csa-research-note-eu-ai-act-high-risk-compliance-deadline-20/
  • https://www.modulos.ai/blog/-your-iso-42001-certification-won-t-make-your-ai-system-compliant/