The deadline moved. The gaps didn’t.
If you’ve been tracking EU AI Act coverage this year, you’ve likely seen the headline already: the Digital Omnibus on AI, approved by the European Parliament on 16 June 2026 and adopted by the Council of the EU on 29 June 2026, moved the application date for stand-alone high-risk AI-system requirements to 2 December 2027. Requirements for high-risk AI systems embedded in products covered by EU sectoral safety legislation move to 2 August 2028.
That’s a confirmed legislative extension, not a proposal. What has not moved in the same way includes Article 5 prohibited-practice obligations, applicable since 2 February 2025, and the main Article 50 transparency application date of 2 the amended EU AI Act timetable. The amendment gives certain systems already placed on the market before that date until 2 December 2026 to implement machine-readable marking. General-purpose AI (GPAI) obligations began applying on 2 August 2025, subject to the Act’s transitional rules for models placed on the market before that date.
It’s tempting to read “deadline moved” as “problem solved.” It isn’t. The operational gaps identified in ODA3’s comparative design review of major AI-security and incident-response materials do not depend on which application date governs stand-alone high-risk systems. An organization with no MCP endpoint authentication, no shadow-AI discovery, and no signed AI-BOM has the same exposure in December 2027 that it had in the amended EU AI Act timetable. The calendar changed. The attack surface didn’t.
Here’s what we found, and what’s still true.
Where we looked
We reviewed incident-response coverage across CoSAI materials, NIST SP 800-61r3, OWASP’s Top 10 for Large Language Model Applications, OASIS CACAO v2.0, MITRE ATLAS, and ISO/IEC 42001, then compared the resulting coverage against AI-specific response scenarios addressed by AI-IRF™ v1.0. This was a source-bounded design comparison, not an empirical measurement of framework adoption or incident frequency. Some source materials use incident-response terminology that can look similar to ours at a glance; we therefore name each source plainly without applying ODA3 trademark formatting to third-party terms.
Ten recurring coverage differences stood out as operationally material. They should be read as ODA3’s design findings within the stated comparison scope, not as proof that every listed source omits each capability.
Gaps that leave a real incident unaddressed today
1. MCP and A2A protocol blind spot. AI communication protocols such as the Model Context Protocol (MCP) and agent-to-agent channels may be logged as telemetry without being governed as security boundaries. Weakly authenticated endpoints and excessive trust between agents create an exploitable control surface. AI-IRF™ v1.0’s response to this gap: mutual authentication, semantic inspection, and policy enforcement on protocol traffic.
2. Shadow AI visibility. Inventory-based security approaches depend on an organization knowing what AI is running. Personal AI tool use, SaaS AI feature rollouts, and embedded AI features can create blind spots that periodic audits may not detect. AI-IRF™ v1.0 calls for continuous runtime discovery rather than point-in-time inventory.
3. Response speed mismatch. Many existing playbooks assume human-paced decision-making. Autonomous AI agents can act on the order of milliseconds. AI-IRF™ v1.0 specifies automated containment targets for high-confidence threats, with human-in-the-loop gates reserved for actions above a defined impact threshold — we’re citing this as the framework’s design target, not as a benchmark independently verified across deployments.
Gaps that reduce effectiveness or create exposure
4. Model extraction not operationalized. Model extraction or distillation — systematic approximation of proprietary model behavior through repeated interaction — may be acknowledged as a risk without being translated into concrete detection and response procedures. AI-IRF™ v1.0 specifies behavioral analytics, dynamic rate limiting, and output perturbation as candidate controls.
5. Limited cryptographic chain of custody for AI artifacts. Models, embeddings, training data, and dependencies may lack an equivalent of a signed bill of materials. AI-IRF™ v1.0 calls for a cryptographically signed AI-BOM per production system to support forensic reconstruction.
6. Over-provisioned agent permissions. General incident-response guidance may not fully address architectural permission failures in which agents have more access than their assigned task requires. Such failures can cause harm even without adversarial input. AI-IRF™ v1.0 specifies pre-execution validation and task-scoped, auto-expiring permission tokens.
Governance and compliance-posture gaps
7. Regulatory awareness without operational routing. Being “regulation-aware” in policy language is different from having embedded decision logic that routes a specific incident type to the correct notification deadline. This is exactly the kind of gap that matters more, not less, once you’re tracking multiple regulatory timelines (EU AI Act, GDPR, NIS2, sector-specific rules) that no longer all land on the same date. AI-IRF™ v1.0 embeds jurisdictional decision trees into incident playbooks — though, as our TCR-HAI-001 correction from earlier this month makes clear, those decision trees need to reflect each regulation’s actual tiered timing, not a single flat window.
8. Physical AI safety coverage. General-purpose incident-response materials do not always provide detailed cyber-safety command procedures for AI systems that control physical infrastructure. AI-IRF™ v1.0 extends coverage to cyber-safety incident command for systems with actuator control.
Advisory-level gaps
9. Model rollback without a defined recovery target. Model lifecycle management may be implemented without treating rollback as a security control with a documented and tested recovery target. AI-IRF™ v1.0 specifies signed artifacts and a target rollback capability, with periodic drill requirements.
10. Zero Trust not systematized for AI. Individual zero-trust controls can exist without a coherent architecture spanning AI-specific identity, segmentation, and continuous verification. AI-IRF™ v1.0 defines this as a named architecture pattern for AI systems specifically.
What this means for your timeline
None of the above requires waiting for 2 December 2027. If your organization provides or deploys GPAI models, determine which obligations and transitional provisions apply to its role and model-placement date. If you are building toward high-risk-system readiness, the extended timeline is a planning window, not a reason to pause: organizations that start classification, documentation, control implementation, and evidence collection now will not be starting from zero in 2027.
Notably absent from this piece
This article does not claim that AI-IRF™ v1.0 is the first or only framework to address these gaps, that adopting it satisfies any specific legal obligation, or that the response-time and rollback figures cited above have been independently verified across production deployments — they represent the framework’s specified targets. For control-by-control detail and evidence-tier-tagged claims, see the paired Technical Report (ODA3-2026-06-TCR-HAI-001) and its machine-readable companion (ODA3-2026-06-TCR-HAI-003). For governance and commercial framing aimed at Boards and CISOs, see the Executive Brief (ODA3-2026-06-EXB-HAI-002).
External references: - EU AI Act full text (EUR-Lex) - Council of the EU — Digital Omnibus final approval, 29 June 2026 - European Parliament — Digital Omnibus approval, 16 June 2026 - MITRE ATLAS - OWASP AI Security Top 10 - NIST SP 800-61r3 - OASIS CACAO v2.0 - CoSAI publications