The EU AI Act's high-risk-system obligations come into effect on August 2, 2026 for systems listed in Annex III. The penalty for non-compliance is the larger of €15 million or 3% of worldwide annual turnover (Help Net Security). For agent runtimes that fall under the high-risk categorization — credit decisions, employment, education, critical infrastructure, law enforcement, biometric identification, justice administration, migration — the question now is operational: what does the Act require the runtime to do, and what evidence does the runtime have to produce.

The Act is written in regulatory prose. The translation into runtime requirements is doable but takes work. This post walks the five Articles that bear most directly on a runtime: Article 9 (risk management), Article 12 (record-keeping and automatic logging), Article 13 (transparency), Article 14 (human oversight), and Article 15 (accuracy, robustness, cybersecurity).

Annex III: which systems are high-risk#

Annex III lists the categories the Act treats as high-risk. The categories relevant to agent runtimes:

Critical infrastructure — agents that act on energy grids, water systems, transport networks.
Education and vocational training — agents that affect access to education or score students.
Employment — agents that screen candidates, recommend promotions, manage performance.
Access to essential services — credit scoring, public benefits, emergency response.
Law enforcement — risk profiling, polygraph-equivalent assessments, evidence reliability.
Migration and border control — risk assessments, document verification.
Justice and democratic processes — judicial assistance, election integrity.
Biometric identification — face recognition, biometric categorization.

Most agents the operator-pain framing of this site addresses — engineering coding agents, customer-support agents on non-essential services, business-ops agents — are not high-risk under Annex III. Agents that act on hiring decisions, credit decisions, healthcare triage, or anything in critical infrastructure are. The classification is not soft; it's a legal status that triggers a defined set of obligations.

Article 9 — risk management system#

Article 9 requires providers of high-risk AI systems to establish, implement, document, and maintain a risk management system throughout the system's lifecycle. This is the lifecycle-process Article. What it asks for, operationally:

Identification of known and reasonably foreseeable risks the system can pose to health, safety, or fundamental rights.
Estimation and evaluation of risks when the system is used in accordance with its intended purpose and under reasonably foreseeable misuse.
Adoption of appropriate risk management measures, with residual risks judged acceptable.
Testing the system against the risk management measures, including in conditions reasonably representative of intended use.

For an agent runtime, this maps to: a documented threat model of the agent's deployment, including the data it can reach, the actions it can take, the operators it serves, and the foreseeable misuse patterns. The Article does not specify a format, but it does specify continuity — the risk management is throughout the lifecycle, not a point-in-time document.

The runtime supports compliance with this Article by providing the artifacts the risk management process consumes: the actual policy in force, the actions the agent attempted and the gate's decisions, and the audit log. The risk management document is the provider's responsibility; the runtime's responsibility is to produce reality the document can be compared against.

Article 12 — record-keeping and automatic logging#

Article 12 is the most directly operational Article for runtime designers. The high-risk system shall technically allow for the automatic recording of events (logs) over the lifetime of the system. "Automatic" means generated by the system itself; the obligation cannot be satisfied with manual documentation (Truescreen).

The logged events shall enable:

Identifying situations that may result in the high-risk AI system presenting a risk.
Facilitating post-market monitoring.
Monitoring the operation of the high-risk AI system.

Retention requirements: minimum six months for most high-risk systems, twenty-four months for biometric identification and certain law enforcement systems. Member states may impose longer retention.

In agent-runtime terms, Article 12 is the audit log requirement. The runtime has to emit machine-readable records of the agent's actions, with enough specificity that an investigator can answer: what did the agent do, who launched it, what data did it access, what decision did the policy gate emit, what was the outcome. The retention has to survive routine SIEM rotation; the cold tier described in What an agent audit row should carry is the architectural answer.

The technical-standard work for Article 12 is in progress. Two drafts to watch: prEN 18229-1 (AI logging and human oversight) and ISO/IEC DIS 24970 (AI system logging). Neither is final as of mid-2026; runtime designs should anticipate the final standards but ship against the Article's text now.

Article 13 — transparency and information provision#

Article 13 requires that high-risk AI systems be designed and developed so their operation is sufficiently transparent to enable deployers to interpret outputs and use them appropriately. The Article also requires accompanying instructions for use that include the system's intended purpose, its level of accuracy, the foreseeable circumstances of unintended outcomes, and the human oversight measures.

For agent runtimes, this Article does two things. First, it requires the runtime to expose to deployers what the agent did and why, in a form they can interpret. The audit row is part of this; the policy version that evaluated each action is part of this; the structured reasoning record (separate from the SIEM log, per the earlier audit-row post) is part of this.

Second, it requires the documentation the deployer relies on. The runtime supplier produces instructions for use; the deployer is then responsible for using the system within those instructions. This separation matters: the runtime's compliance depends on the documentation being accurate, and on the deployer respecting it. A runtime that allows policy configurations not documented in the instructions for use creates compliance risk for deployers who use them.

Article 14 — human oversight#

Article 14 mandates that high-risk AI systems be designed and developed in such a way that they can be effectively overseen by natural persons during the period in which they are in use. The natural persons must be able to:

Fully understand the relevant capacities and limitations of the system.
Remain aware of the tendency of automation bias.
Correctly interpret the system's output.
Decide not to use the system or otherwise disregard, override, or reverse its output.
Intervene in the operation of the system or interrupt it through a "stop" function or similar procedure that results in the system coming to a halt in a safe state.

For an agent runtime, this Article maps directly to two surfaces: the approval mechanism and the containment mechanism. The approval mechanism is how the human stays in the loop for actions the runtime designates as require-approval. The containment mechanism is how the human stops the agent when something goes wrong.

The Article's language about "coming to a halt in a safe state" is worth attention. A runtime that stops the agent but leaves credentials in flight, sub-agents running, or destructive operations partially executed has not brought the system to a safe state. The architectural pattern in Stopping a running agent — run-level revocation, in-flight action accounting, sub-agent cascade rules — is what Article 14 operationally requires.

Article 15 — accuracy, robustness, cybersecurity#

Article 15 requires high-risk AI systems to achieve appropriate levels of accuracy, robustness, and cybersecurity. The levels must be declared in the instructions for use, and the system must perform consistently in those respects throughout its lifecycle.

The cybersecurity language is the relevant one for runtime designers. The Article specifies that high-risk AI systems shall be resilient against attempts by unauthorized third parties to alter their use, behavior, or performance, by exploiting system vulnerabilities. The text explicitly contemplates AI-specific attacks: "data poisoning, model poisoning, model evasion, confidentiality attacks, or model flaws."

For agent runtimes, this implicates:

The identity layer, which prevents credentials from being lifted and reused.
The policy gate, which prevents the agent from being induced to perform actions outside its scope.
The containment surface, which lets the operator stop the agent if it is being driven outside its bounds.
The audit log, which provides the post-incident record needed to investigate and remediate.

Article 15 does not specify how cybersecurity is to be achieved, but it does set the bar: appropriate to the risk. For agent runtimes operating on high-risk systems, "appropriate" is interpreted by the conformity assessment process and ultimately by post-market enforcement. The runtime that ships with identity, policy, containment, and tamper-evident audit is the runtime that meets a reasonable interpretation of the bar today.

How this differs from Colorado AI Act#

The Colorado AI Act, enforceable June 2026 (this month), is the first US state law in the same shape as the EU AI Act. The two share the focus on consequential decisions (Colorado uses the term "consequential decision"; the EU uses "high-risk") and the focus on transparency, oversight, and risk management.

The differences worth noting:

The Colorado Act applies primarily to deployers of consequential-decision AI; the EU Act applies to providers and deployers, with most obligations on providers.
The Colorado Act emphasizes a duty of reasonable care and consumer rights (notice, explanation, appeal); the EU Act emphasizes pre-market conformity assessment.
The Colorado Act's risk-management duty applies to developers of high-risk AI; the EU Act's Article 9 risk-management obligation is similar in shape.

For agent runtime designers, the practical guidance is to design for the more demanding of the two regimes the deployment will encounter. In most cases, that's the EU AI Act; runtimes that meet its Article 12 record-keeping bar, Article 14 oversight bar, and Article 15 cybersecurity bar are likely to meet the Colorado Act's analogous duties.

Runtime, deployer, and operator responsibilities#

The Act splits responsibility across runtime, deployer, and operator. The runtime's responsibility:

Emit Article 12 logs with the retention the Article requires.
Provide the Article 14 oversight surfaces (approval, containment) with the safe-halt property.
Provide the Article 15 cybersecurity primitives (identity, policy, audit, containment).
Provide the Article 13 documentation: instructions for use, accuracy claims, foreseeable misuse, oversight measures.

The deployer's responsibility:

The Article 9 risk management process, run continuously, with the runtime's artifacts as inputs.
The conformity assessment, where required.
Deployment within the instructions for use.

The operator's responsibility:

Acting on the oversight surfaces the runtime provides — approving when prompted, intervening when the agent's actions warrant it.
Reporting incidents and supporting post-market monitoring.

Deixic ships the runtime side. The audit log, the policy gate, the containment surface, and the documentation set are the artifacts the deployer and operator need to discharge their parts of the obligations. See Trust for the regulatory and compliance posture.