The EU AI Act's timeline changed after this post was first drafted. The Digital Omnibus entered into force on July 27, 2026. For Annex III high-risk systems, the main application date is now December 2, 2027; high-risk AI embedded in regulated products has an August 2, 2028 date. Transparency obligations still begin August 2, 2026. The penalty for non-compliance is the larger of €15 million or 3% of worldwide annual turnover (Help Net Security).

Agent runtimes in the high-risk categories (credit decisions, employment, education, critical infrastructure, law enforcement, biometric identification, justice administration, migration) face one question: what does the Act require the runtime to do, and what evidence must it produce?

This article treats Articles 12 and 14 as requirements to prepare for when a deployment is in scope. It does not claim every business agent is already subject to the high-risk rules. Check the European Commission FAQ and the current legal text for the scope and dates that apply to a particular deployment.

Five Articles 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 ones 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.

Engineering coding agents, customer-support agents on non-essential services, and 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.

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. Operationally, it asks for:

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 means a documented threat model of the deployment: the data the agent can reach, the actions it can take, the operators it serves, and the foreseeable misuse patterns. The Article specifies no format but requires continuity: the document cannot be a point-in-time exercise.

The runtime supplies the artifacts the process consumes: the policy in force, the actions the agent attempted, the gate's decisions, and the audit log. The provider owns the risk management document; the runtime produces the record it is compared against.

Article 12: record-keeping and automatic logging#

Article 12 is the most directly operational Article for runtime designers. A high-risk system in scope when the provision applies shall technically allow for the automatic recording of events (logs) over its lifetime. "Automatic" means generated by the system itself; manual documentation cannot satisfy the obligation (Truescreen).

The logged events shall enable:

Identifying situations in which the high-risk AI system presents a risk.
Facilitating post-market monitoring.
Monitoring the operation of the high-risk AI system.

Retention is a minimum of six months for most high-risk systems and twenty-four months for biometric identification and certain law enforcement systems. Member states can impose longer retention.

For an agent runtime, Article 12 is the audit log requirement: machine-readable records specific enough 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?

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 are prEN 18229-1 (AI logging and human oversight) and ISO/IEC DIS 24970 (AI system logging). Neither is final as of mid-2026, so 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 transparent enough for deployers to interpret outputs and use them appropriately. It also requires accompanying instructions for use that state 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, the runtime shows deployers what the agent did and why, in a form they can interpret: the audit row, the policy version that evaluated each action, and the structured reasoning record kept separate from the SIEM log (see the earlier audit-row post).

Second, it requires the documentation the deployer relies on. The runtime supplier produces the instructions for use, and the deployer operates within them. A runtime that allows policy configurations missing from the instructions creates compliance risk for deployers who use them.

Article 14: human oversight#

Article 14 mandates that a high-risk AI system in scope be designed and developed so natural persons can effectively oversee it while it is in use. Those 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 maps to two surfaces: approval keeps the human in the loop for actions marked require-approval, and containment lets the human stop the agent when something goes wrong.

A runtime that stops the agent but leaves credentials in flight, sub-agents running, or destructive operations partially executed has not reached a safe state. The pattern in Stopping a running agent (run-level revocation, in-flight action accounting, sub-agent cascade rules) is what Article 14 requires in practice.

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 matters most for runtime designers. 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 names 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 act outside its scope.
The containment surface, which lets the operator stop an agent that is being driven outside its scope.
The audit log, which provides the post-incident record needed to investigate and remediate.

Article 15 sets the bar at "appropriate to the risk" without specifying how to meet it; conformity assessment interprets it and post-market enforcement tests it. A runtime that ships with identity, policy, containment, and tamper-evident audit meets a reasonable reading of that bar today.

How this differs from US state laws#

US state laws use different scopes, duties, and effective dates. Colorado’s framework has been amended more than once, so check the current Colorado General Assembly text instead of relying on a generic deadline. Consequential-decision rules tend to emphasize transparency, oversight, and risk management, but the obligations depend on the law and the deployment.

Three differences:

State laws apply duties to deployers, developers, or both. The EU Act applies to providers and deployers, with most obligations on providers.
State laws emphasize reasonable care and consumer rights such as notice, explanation, and appeal. The EU Act adds conformity assessment for relevant systems.
A state-law risk-management duty resembles the EU Act’s Article 9 process, but the scope and evidence required are not interchangeable.

Map the exact laws that apply to the deployment, then design for the stricter control where requirements overlap. Article 12 record-keeping, Article 14 oversight, and Article 15 cybersecurity are useful design targets, but they do not replace a legal scope analysis.

Runtime, deployer, and operator responsibilities#

The Act splits responsibility across runtime, deployer, and operator.

The runtime:

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

The deployer:

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

The operator:

Acts on the oversight surfaces the runtime provides: approving when prompted, intervening when the agent's actions warrant it.
Reports incidents and supports post-market monitoring.

Deixic supplies identity, policy and approval decisions, action history, and recorded spend for work routed through it. These records support review of the deploying company’s controls. They do not establish compliance with the Act; pause behavior and the runtime’s actual stop path need separate inspection. See Trust for the current security posture.