- The EU AI Act’s high-risk system compliance deadline is deferred to December 2027, reflecting challenges in translating safety obligations into auditable systems.
- ISO/IEC 42001 and HITRUST AI Security Assessment are emerging compliance benchmarks, while vulnerabilities like CVE-2025-53773 highlight the need for system-level security audits.
- Genuine AI safety requires concrete, verifiable actions and detailed evidence of risk management, moving beyond performative “AI safety theatre.”
The EU delayed its landmark AI Act enforcement deadline by 16 months this springand the gap between that decision and the industry’s readiness to comply tells you almost everything about where AI governance actually stands. A political agreement reached in early May 2026 pushed the compliance date for high-risk use-based systems from August 2, 2026 to December 2, 2027, and new classification guidelines published on May 19, 2026 made clear just how much operational work remains before the law’s safety principles become verifiable practice.
The EU AI Act’s Operational Reality Check
The deferral is not purely procedural. It reflects genuine difficulty in translating broad safety obligations into auditable systems at scale. The May 2026 AI Omnibus simplification proposal, negotiated between the European Parliamentthe Council of the European Union and the European Commission, gives organisations more time to bring high-risk AI deployments, particularly those classified under Annex III, into conformity, but more time does not resolve the underlying challenge: the gap between stating a safety commitment and being able to demonstrate it to a regulator or auditor.
A simplification proposal, negotiated between the European Parliament, the Council of the European Union and the European Commission, gives organisations more time to bring high-risk AI deployments, particularly those classified under Annex III, into conformity, but more time does not resolve the underlying challenge: the gap between stating a safety commitment and being able to demonstrate it to a regulator or auditor.
Beyond Declarations: Unpacking ‘AI Safety Theatre’
“AI safety theatre” describes performative actions or public statements that create the appearance of safety measures without addressing the underlying risks. Companies issue high-level ethical principles, sign voluntary pacts, and reference internal review processes, yet often lack the detailed, verifiable implementation plans needed to make those principles operational. The divergence between stated commitment and demonstrable action can mask insufficient investment in the technical and organisational safeguards that actually prevent harm.
Pressure to project a strong safety posture comes from several directions: regulatory scrutiny, public concern following incidents, and competitive positioning. Without transparent processes and measurable outcomes, though, these efforts risk becoming public relations exercises. A company that touts its red-teaming efforts without disclosing the methodology, the qualifications of the team or the specific vulnerabilities identified and addressed offers little tangible proof of enhanced safety. External observers cannot verify what they cannot see. For enterprises, the standard is moving toward detailed evidence of risk management, auditability and continuous monitoring, particularly as AI becomes embedded in core business processes.
Identifying Genuine AI Safety Commitments
Genuine AI safety shows up in concrete, verifiable actions rather than aspirational language. The NIST AI Risk Management Framework (AI RMF) offers one credible structure: its govern, map, measure and manage functions treat AI as a socio-technical system where risks arise from deployment context and human interaction, not just from the model itself. The ISO/IEC 42001 standard goes further, providing a certifiable AI management system that allows independent auditing. KPMG International became the first Big Four firm to achieve ISO/IEC 42001 certification in late 2025, according to reports, with Microsoft also certifying M365 Copilot, a concrete signal that verifiable governance is becoming a procurement consideration.
The “Bleeding Llama” vulnerability in Ollama (affecting versions prior to a patched release) is an example of the kind of concrete, technical transparency that distinguishes genuine safety practice from broad assurance.
The Imperative of Independent Scrutiny and Metrics
Many executives report low confidence in their organisation’s ability to pass an independent AI governance audit, even as AI systems handle critical business functions. That gap points to a structural problem: internal claims of safety readiness are not the same as externally verified compliance. The HITRUST AI Security Assessment addresses this directly, focusing on 44 prescriptive controls covering AI security risks including threat management and access controls. ISO/IEC 42001 certification and HITRUST assessments offer different but complementary paths to third-party validation, the kind that regulators and procurement teams can actually act on.
The EU AI Act’s enforcement architecture reflects this logic. Its conformity assessment requirements and post-market monitoring obligations are designed to mandate a shift from qualitative assurance to quantitative proof. At the state level in the US, New York City’s requirement for bias audits of automated hiring tools, with results published, illustrates the same direction: transparency and accountability through measurable metrics, not declarations. As AI systems become harder to evaluate from the outside, the EU’s approach of setting technical thresholds to trigger scrutiny represents one attempt to make that evaluation tractable.
Translating Principles into Deployed Safeguards
The sixteen-month deferral of the EU AI Act’s high-risk system obligations is not just an administrative adjustment. It reflects the depth of engineering and policy work required to ensure AI systems are demonstrably safe in practice, documented, tested and assessable by a third party. NIST’s AI RMF is explicit on this point: risk emerges not from models in isolation, but from how people build, deploy and use them. Continuous monitoring and runtime controls are part of the compliance picture, not optional additions.
System-level security is increasingly the crux of the problem, particularly as AI agents proliferate. CVE-2025-53773, a prompt injection vulnerability in GitHub Copilot that enabled remote code execution, illustrates the attack surface that opens when AI is integrated across enterprise applications. Strong access controls, training data integrity, API security and behavioural monitoring are all components of a defensible posture. The EU AI Act provides a compliance framework, but the engineering work required to meet it is substantial, and the deadline extension suggests the industry understood that before regulators did. For more coverage of AI policy and regulation, visit our AI Policy & Regulation section.
