On June 16, 2026, the European Parliament adopted the Digital Omnibus on AI by 423 votes to 57. On June 29, the Council of the European Union formally adopted it, completing the co-legislative process. The headline that most compliance teams forwarded to their leadership: Annex III high-risk AI systems now have until December 2, 2027 — not August 2, 2026 — to comply.
Sixteen additional months. It reads like a reprieve.
It is not.
Morgan Lewis, in their June 24, 2026 analysis of the amendment, put the correct frame on it: “Overall, we would suggest that businesses treat these developments primarily as an extension of time to complete their AI Act compliance efforts, rather than as a material relaxation of the underlying obligations as such.”
The obligations are identical to what they were before the amendment. What changed is the date by which those obligations must be met. For critical infrastructure operators who are behind on compliance — and most are — this is meaningful runway. For those who treat the extension as evidence that the regulation is softening, December 2027 will arrive with the same program gaps that exist today.
This post addresses two audiences: CISOs accountable for the operational security and governance of AI systems embedded in critical infrastructure, and Model Risk Officers responsible for maintaining defensible evidence of AI system governance. Both need to understand what Annex III actually requires, where organizations typically fall short, and what the technical architecture of a compliant program looks like in practice.
What Annex III Actually Covers
Annex III of the EU AI Act defines the categories of high-risk AI systems subject to the most stringent compliance requirements under the regulation. Point 2 of Annex III covers AI systems intended to be used as safety components in the management and operation of critical digital infrastructure, road traffic, or in the supply of water, gas, heating, or electricity.
This is a precise definition. It covers AI systems that function as safety components in those sectors — not every AI tool an energy company or water utility deploys. The test is whether the system is integrated into the management or operation of critical infrastructure and whether it functions as a safety component within that context.
For operators in energy, transport, water, and critical digital infrastructure, the practical scope is broader than it may initially appear. AI systems used for predictive grid management, anomaly detection in SCADA environments, traffic signal optimization, or operational monitoring of water treatment systems are likely to fall within it. AI systems used for HR, marketing, or general enterprise IT functions are not.
Classification is the first compliance obligation. You cannot build a compliant program for a system you have not correctly classified. And incorrect classification — whether it excludes a genuinely high-risk system or mis-categorizes an excluded system as in-scope — creates its own regulatory exposure.
Six Obligations That Did Not Move With the Deadline
The December 2, 2027 date shifted. The substance of what that date requires did not. The following six obligations, drawn directly from the EU AI Act as adopted, govern every high-risk AI system placed on the market or put into service under Annex III after that date.
Article 9 — Risk Management System. This is not a one-time assessment. The Act requires a risk management system that is established, implemented, documented, and maintained as a continuous, iterative process throughout the entire lifecycle of the system. It must include regular systematic review and updating. The system must identify and analyze known and reasonably foreseeable risks, estimate risks arising from misuse, and document the risk management measures adopted. Residual risk must be acceptable. Organizations that conduct a point-in-time AI risk assessment and archive it are not building an Article 9-compliant risk management system — they are building documentation that will fail on inspection.
Article 10 — Data and Data Governance. Training, validation, and test data must meet documented quality criteria: relevant, sufficiently representative, and to the best extent possible free of errors and complete in view of intended purpose. Data governance practices must cover collection processes, data origin, preparation operations, examination for possible biases, and measures to detect and mitigate those biases. For critical infrastructure operators deploying third-party AI systems, Article 10 creates an audit obligation toward your vendor: their data governance documentation must be available for your review. Assuming it is adequate is not a compliant posture.
Article 11 — Technical Documentation. Technical documentation must be drawn up before the system is placed on the market or put into service and kept up to date. It must demonstrate compliance and provide competent authorities with comprehensive information to assess it. For critical infrastructure systems under Annex III points 2 through 8, conformity assessment is conducted through internal control under Annex VI — meaning the burden of producing and maintaining this documentation falls entirely on the provider or deployer. There is no notified body to prompt the process. That fact cuts both ways: the process is self-directed, and the gaps will only surface when a competent authority requests the documentation.
Article 12 — Record-Keeping and Logging. High-risk AI systems must technically allow for the automatic recording of events over the system’s lifetime. Logs must enable identification of situations where the system presents a risk, facilitate post-market monitoring, and support the monitoring obligations under Article 26. For infrastructure operators, this means purpose-built AI audit logging — not application performance monitoring repurposed for compliance. The distinction matters: application logs capture system behavior at the infrastructure level; AI audit logs must capture model inputs, outputs, and decision-relevant context in a format that supports regulatory inspection.
Article 13 — Transparency and Instructions for Use. High-risk AI systems must be designed and developed so that their operation is sufficiently transparent to enable deployers to interpret outputs and use them appropriately. Systems must be accompanied by instructions for use that include the characteristics, capabilities, and limitations of the system’s performance; human oversight measures; and, where relevant, a description of mechanisms that allow deployers to collect, store, and interpret logs. For operators deploying vendor-provided AI systems, Article 13 creates a direct requirement on your procurement process: the vendor must provide this information, and your contracts must require it.
Article 14 — Human Oversight. High-risk AI systems must be designed so they can be effectively overseen by natural persons during use. Oversight measures must be commensurate with the risks, level of autonomy, and context of use. The assigned human overseers must be able to understand the system’s capacities and limitations, detect anomalies and unexpected performance, correctly interpret outputs, override or reverse outputs, and intervene or interrupt the system. For agentic AI systems — systems that can take sequences of consequential actions without step-by-step human direction — Article 14 requires that the boundaries of autonomous action be defined, documented, and technically enforced. The question is not aspirational: “we intend for humans to oversee this.” The question is mechanical: at what point, in which conditions, is human review required before the system’s output becomes consequential action?
Where Organizations Are Falling Short
Three patterns account for most of the compliance gap among critical infrastructure operators with AI deployments today.
The first is classification avoidance. Organizations that have not formally assessed which of their AI systems fall under Annex III cannot build a compliant program because they have not defined the program’s scope. This is the most common gap and the easiest to address — classification requires legal and technical analysis, not technology investment.
The second is treating governance as documentation rather than process. Article 9’s risk management system requirement is explicitly a lifecycle process, not a deliverable. Organizations that produce a risk assessment document and stop have met the letter of neither the spirit nor the text of Article 9. The regulatory test is not “do you have a document?” It is “is your risk management system current, updated in response to changes in the system, and producing ongoing risk management decisions?”
The third is the vendor assumption problem. For operators deploying third-party AI systems, Articles 10, 11, and 13 create obligations that cannot be met without active vendor engagement. If your AI vendor cannot provide data governance documentation, technical documentation, and transparency information in the form Articles 10, 11, and 13 require, you are not in a position to complete your own compliance obligations for that system. This needs to be a contract-time requirement — not a compliance-time discovery.
The Prompt Layer: Where External Enforcement Boundaries Close the Remaining Gaps
Annex III compliance requires governance controls that extend from the organizational and contractual level down to the technical enforcement layer. For many critical infrastructure operators, the weakest link in that chain is the absence of real-time, inference-level governance — the ability to apply and enforce policy at the point where an AI model receives a prompt and produces a response.
This is not a compliance workaround. It is the technical implementation of several specific Article requirements.
Article 12’s logging obligation requires automatic recording of events over the system’s lifetime. Logging at the infrastructure level — capturing requests and responses as network traffic — is insufficient if the logs do not capture the semantic content of model interactions in a format that supports regulatory inspection. Inference-level audit trails, which record the full context of model interactions including inputs, policy evaluations, and outputs, are the technical substrate that makes Article 12 compliance meaningful.
Article 14’s human oversight requirement for agentic systems requires that boundaries on autonomous action be technically enforceable. A policy that says “the system should not take consequential actions without human review” is not an oversight control. A prompt-layer enforcement mechanism that blocks or gates model outputs against defined policy criteria before they become consequential actions is.
Article 9’s continuous risk management obligation requires a feedback mechanism. Risk management that does not observe what the deployed AI system is actually doing in production — what inputs it receives, what outputs it produces, what anomalous patterns emerge — is not continuous. It is periodic.
Two vendors are building at this layer for enterprise deployments. Prompt Security provides enterprise-grade AI security across the full range of LLM touchpoints: prompt injection defense, shadow AI discovery, data privacy enforcement, and risk assessment across both managed and homegrown AI applications. Their platform is LLM-agnostic and supports both cloud and on-premises deployment, covering indirect prompt injection, privilege escalation, and agentic AI environments.
SafePrompts.ai (TVR Labs) positions itself as an AI governance control plane sitting at the prompt layer between users, applications, agents, and models. The platform combines deterministic policy enforcement (aligned to enterprise rules and IAM/Zero Trust integration), probabilistic risk scoring for adversarial prompt detection, and semantic understanding for context-aware policy application. For regulated industries, it provides the inference-level audit trail and real-time policy enforcement that Articles 9, 12, and 14 require but do not specify how to implement.
Neither platform is an EU AI Act compliance solution in itself — compliance is an organizational and legal obligation, not a technology purchase. But for critical infrastructure operators building toward December 2027, the prompt enforcement layer is where the gap between documented governance intent and provable operational control gets closed.
The GPAI Enforcement Activation: August 2, 2026
Before the Annex III deadline arrives, a different enforcement clock activates. On August 2, 2026 — three weeks from today — the European Commission gains enforcement authority over general-purpose AI (GPAI) model providers under Article 101. Fines reach up to €15 million or 3% of annual worldwide turnover, whichever is higher.
For critical infrastructure operators, this matters in a specific way. If your AI system is built on or integrates a GPAI model — a GPT-series model, Claude, Gemini, or their successors — you depend on that provider’s GPAI compliance for part of your own evidence chain. The GPAI obligations have been in force since August 2, 2025. What activates on August 2, 2026 is the Commission’s ability to enforce them.
The governance implication is not about your provider’s fine exposure. It is about your documentation dependency. Your Article 11 technical documentation must describe the system’s capabilities, limitations, and performance characteristics. For systems built on GPAI models, a significant portion of that characterization depends on documentation the model provider is now legally required to maintain. If they have not maintained it, your technical documentation is incomplete. If they update the model — a routine occurrence — your evidence chain must reflect it.
The conversation to have with your AI model vendor before August 2 is not about their compliance posture. It is about what documentation they will provide to you, in what format, on what schedule, when the model changes. That is a contract requirement, not a vendor relationship question.
Closing the Gap Before December 2027
The organizations that arrive at December 2, 2027 in compliance will not be those that started building in the third quarter of 2027. They will be those that used the 16-month deferral for its stated purpose: to complete compliance work that was already underway.
The practical sequence is:
- Classify. Identify every AI system in your environment and determine whether it falls under Annex III, point 2 or any adjacent Annex III category. Document the analysis, not just the conclusion.
- Establish the risk management system. Build it as a continuous process, not a document. Define the review cadence, the triggering conditions for an update, and the governance body responsible for it.
- Audit your vendors. Require Article 10 and Article 11 documentation from every vendor whose AI system is within scope. Make this a contract-time requirement going forward.
- Build the audit trail. Implement inference-level logging that captures the semantic context of model interactions, not just infrastructure-level request and response records.
- Define and enforce human oversight boundaries. For agentic AI systems, document the specific conditions under which human review is required before model output becomes consequential action. Then enforce it technically.
- Close the GPAI documentation gap. Before August 2, confirm what GPAI model documentation your providers will deliver and how they will notify you of model updates that affect your technical documentation.
December 2027 is 17 months away. The organizations that treat those months as runway will be positioned for it. The organizations that treat the deferral as a signal that the regulation is softening will discover in 2027 that the obligations are exactly what they were in 2026.
Morgan Lewis said it plainly. Treat this as more time to complete the work, not as a relaxation of the underlying obligation.
For us in the Unted States, this set of regulations is not compulsory, but they do point the direction for proper governance of the use of AI in critical infrastructure, something we should be interested in as a matter of good business, regardless of regulation.
Recent Comments