The EU AI Act has been in force since August 2024. Its requirements for high-risk AI systems — defined broadly to include AI used in credit, employment, essential services, law enforcement, migration, and administration of justice — are now operative compliance obligations, not future-dated requirements.
Three articles of the Act establish the technical requirements that AI governance infrastructure must satisfy. Understanding what those articles actually require — at the implementation level, not the summary level — reveals why probabilistic governance approaches cannot produce compliant deployments, and what deterministic infrastructure must provide instead.
Article 9: Risk Management System
Article 9 requires that high-risk AI systems implement a risk management system consisting of a continuous iterative process run throughout the entire lifecycle. The system must: identify and analyze known and reasonably foreseeable risks; estimate and evaluate risks that may emerge; evaluate risks following post-market monitoring data; and adopt appropriate risk management measures.
The operative phrase is "continuous iterative process run throughout the entire lifecycle." This is not a pre-deployment assessment. It is an ongoing operational requirement.
What this means for governance infrastructure:
- Continuous evaluation. Every decision the AI system makes must be evaluated against the current risk management framework at the time it is made, not against a framework that was valid at some prior point. A static rulebook reviewed at deployment and not updated is not a continuous risk management system.
- Risk estimate documentation. Each evaluation must produce a record that captures the risk assessment performed, the rules applied, and the outcome. The record is not the output of the AI — it is the output of the risk management evaluation.
- Post-market monitoring integration. New failure modes discovered in production must be incorporated into the risk framework and applied prospectively. A governance system that cannot trace which rule version was applied to which decision cannot satisfy this requirement.
A moderation classifier or output filter that produces probability-scored classifications cannot satisfy Article 9's documentation requirements. The risk evaluation must be auditable — an auditor must be able to review the specific risk assessment applied to a specific decision. A probability score from a black-box classifier is not a reviewable risk assessment.
Article 12: Record-Keeping
Article 12 requires that high-risk AI systems be designed and developed to enable automatic recording of events throughout their lifetime, sufficient to enable post-market monitoring and to verify that the AI system functions according to its intended purpose.
Critically, Article 12 specifies that logging capabilities shall ensure traceability of AI system output throughout the lifetime, and the ability to identify the reason for any decision, recommendation, or prediction made by the AI system.
"Traceability of output throughout the lifetime": This phrase establishes an archival requirement. A log that is overwritten after 90 days does not satisfy lifetime traceability. A log that cannot be independently verified does not satisfy traceability. Traceability requires append-only records with integrity guarantees.
"Ability to identify the reason for any decision": This phrase establishes a decision lineage requirement. A log entry of the form "request ID 12345 — BLOCKED" does not identify the reason. A signed record containing the rule set version hash, the specific rules that triggered, and the input hash that enables input reconstruction does identify the reason.
The Article 12 requirements for traceability and decision reason identification map directly to hash-chained, cryptographically signed audit records. Each record contains: the canonical input hash, the rule set version hash, the triggered rules, the verdict, a cryptographic signature over the full record, and a chain link to the preceding record. The chain link proves no records have been inserted, deleted, or modified. The signature proves the record was produced at the stated time.
Output logs from a moderation API do not satisfy Article 12. They document what the model produced — not why a governance decision was made, not what rules applied, not whether those rules were the approved and current rules.
Article 14: Human Oversight
Article 14 requires that high-risk AI systems be designed and developed with tools that allow natural persons to effectively oversee the AI system during the period in which it is being used. Oversight must enable individuals to understand the capabilities and limitations of the AI system, monitor its operation, and intervene and stop the AI system.
- "Understand the capabilities and limitations": This requires that oversight personnel can access documentation of what the AI system can and cannot do, expressed in terms that enable effective monitoring. A governance system presenting oversight personnel with black-box probability scores does not enable understanding of capabilities and limitations.
- "Detect and understand discrepancies and failures": This requires that the oversight infrastructure actively surfaces anomalies — situations where the AI system behavior deviates from its specified governance framework. Active monitoring that alerts oversight personnel to governance anomalies satisfies this requirement. A passive log that must be manually reviewed to detect anomalies does not.
- "Intervene and stop": This requires that oversight personnel have a technically effective mechanism to halt AI system operation. An immutable runtime configuration with a formally specified override pathway satisfies this requirement. A governance system where intervention requires modifying prompts or coordinating changes across multiple systems does not.
The Integration: What Compliance Requires
Reading Articles 9, 12, and 14 together establishes a set of technical requirements that form a coherent whole:
- Continuous, documented risk evaluation at every inference, with records linking each decision to its governing rules (Article 9)
- Append-only, independently verifiable audit records with cryptographic integrity and decision lineage (Article 12)
- Active governance monitoring with effective oversight mechanisms and a formal change management process (Article 14)
These three requirements cannot be satisfied by middleware governance. They require a deterministic enforcement gate, a hash-chained audit log, a real-time monitoring interface, and an immutable runtime configuration with a formally audited change management pathway.
What "High-Risk" Means in Practice
The EU AI Act's high-risk category covers AI systems in: credit scoring and assessment of creditworthiness; employment, workers management, and access to self-employment; access to essential private and public services; law enforcement; migration, asylum, and border control management; and administration of justice.
For financial services, HR technology, public sector technology, and legal technology companies deploying AI in these domains, EU AI Act compliance is operative now. A regulatory examiner applying Articles 9, 12, and 14 will ask:
- Show me the risk assessment record for a specific decision made six months ago.
- Show me that the rules applied to that decision were the currently approved rules at the time.
- Show me that the audit record linking that decision to its governing rules has not been modified.
- Show me how your oversight personnel monitor governance compliance in real time.
- Show me the process by which your governance configuration is updated and the audit trail for that process.
These questions have clear, demonstrable answers for a deterministic governance infrastructure. They do not have clear answers for probabilistic middleware.
The gap between what the EU AI Act requires and what most current AI deployments provide is the compliance risk that organizations in high-risk AI categories are accumulating. The technical solutions to close that gap are available. The question is whether organizations implement them before or after a regulatory examination makes the gap visible.