EU AI Act Article 9: Continuous Risk Management for AI Agents

Most engineering teams treat AI risk assessment as a pre-deployment activity. You assess the risks, document them, get sign-off, and ship. Done.

EU AI Act Article 9 has a different model: risk management is a continuous system that runs throughout the entire lifecycle of the AI system. Assessment before deployment is the starting point, not the endpoint.

For AI agents — which evolve, encounter new input distributions, and operate in changing business contexts — this distinction matters enormously.

TL;DR

• Article 9 requires a documented risk management system, not a one-time risk assessment
• The system must operate throughout the AI system’s lifecycle, including post-deployment
• Risk must be estimated, evaluated, and mitigated continuously — not just at go-live
• Residual risk must be documented after mitigation, and that documentation must be accessible
• AI agents present specific Article 9 challenges: they encounter novel inputs, change over time, and interact with other systems

What Article 9 Actually Requires

Article 9 is titled “Risk management system.” The operative paragraph defines it as:

“…a continuous iterative process run throughout the entire lifecycle of a high-risk AI system, requiring regular systematic updating.”

The phrase “continuous iterative process” is the core requirement. It rules out the “assess once, ship, and move on” approach. A static risk assessment document that isn’t updated as the system operates does not satisfy Article 9.

The required elements of the risk management system under Article 9 are:

1. Identification and analysis of known and foreseeable risks — You must systematically identify what can go wrong. This includes risks to fundamental rights, health, safety, and discriminatory outcomes.

2. Estimation and evaluation of risks — Not just identification: you must assess likelihood and severity. The risk matrix must be documented.

3. Adoption of appropriate risk management measures — Risk management measures must be proportionate to the risks identified. Documenting a risk without a commensurate mitigation does not satisfy Article 9.

4. Residual risk documentation — After mitigation, the remaining risk must be documented and deemed acceptable. The bar for “acceptable” residual risk must be defined.

5. Testing for consistency and adequacy — The risk management measures must be tested to verify they actually work. Testing is not optional; it is part of the Article 9 system.

Why AI Agents Make Article 9 Harder

A static software application — a rule-based decision engine, a fixed-logic classifier — operates with predictable risk profiles. The risk assessment done at deployment remains accurate as long as the application doesn’t change.

AI agents are different in three ways that make static risk assessment insufficient.

Agents encounter novel inputs. A contract review agent trained on standard commercial contracts will eventually encounter non-standard inputs — atypical deal structures, unusual jurisdiction clauses, documents formatted outside its training distribution. Each novel input pattern is a potential new risk that wasn’t present in the original assessment.

Agent behavior changes with model updates. When the underlying model is updated — whether by you or by the model provider — the agent’s behavior can change in ways that aren’t captured by the original risk assessment. An Article 9-compliant system must evaluate risk impacts of model updates.

Agents interact with other systems. An agent that calls external APIs, accesses customer databases, or orchestrates sub-agents creates systemic risks that don’t exist in isolated applications. The risk of a data access error, an API failure, or an unauthorized cross-agent action must be continuously managed.

Building a Continuous Risk Management System

Step 1: Define the risk taxonomy

Before you can manage risks continuously, you need a structured way to categorize them. Article 9 doesn’t prescribe a taxonomy, but a practical taxonomy for AI agents includes:

Risk class	Description	Examples
Output risk	Agent produces harmful or unauthorized output	Discriminatory decision, inaccurate advice, data leakage
Scope risk	Agent operates outside its authorized domain	Accessing unauthorized data, taking unsanctioned actions
Authorization risk	Agent acts without required human approval	Auto-approving decisions that require escalation
Data risk	Agent processes data improperly	Exceeding data minimization, improper retention
Interaction risk	Agent creates cascading effects through other systems	Sub-agent errors, API failures, race conditions

Step 2: Establish risk measurement mechanisms

Continuous risk management requires continuous measurement. The measurement mechanisms for AI agents include:

• Constitutional rule violation rates — How often are governance checks triggered? What fraction are DENY vs PERMIT? Rising DENY rates signal a drift between agent behavior and policy.
• Escalation trigger frequency — How often does the system escalate to human review? Sustained high escalation rates indicate either misconfigured thresholds or genuine risk concentration.
• Input distribution monitoring — Are incoming requests staying within the distribution the system was designed for? Significant distribution shift is a risk signal.
• Output anomaly detection — Do outputs systematically deviate from expected patterns? Statistical anomaly detection on output distributions catches drift that rule-based checks miss.

Step 3: Define update triggers

Article 9’s “regular systematic updating” requirement needs to be operationalized. Define explicit triggers that force a risk management system review:

1. Model version update (provider or internal)
2. Significant change in agent scope or capabilities
3. New use case added to the agent’s mandate
4. Compliance framework change (new regulation, updated guidance)
5. Incident or near-miss occurrence
6. Quarterly scheduled review (at minimum)

Document these triggers in your risk management system specification. When a trigger fires, the review must occur and the results must be documented.

Step 4: Document residual risk acceptance

After mitigation measures are in place, Article 9 requires that residual risk be documented and accepted. This means:

• Explicitly stating what risk remains after mitigation
• Defining the basis for accepting that residual risk (benchmarks, analogous systems, legal guidance)
• Identifying who has authority to accept residual risk on the organization’s behalf
• Recording the acceptance decision with a date and version reference

This step is where most organizations have gaps. The mitigation is documented; the residual risk acceptance is informal or absent.

For related requirements on audit evidence for your risk management decisions, see EU AI Act Article 12: Logging Requirements Decoded.

Article 9 and Runtime Governance

The relationship between Article 9 and runtime governance infrastructure is direct: the governance layer is how Article 9’s continuous risk management becomes operational.

A risk identified in the Article 9 assessment must have a corresponding mitigation. For AI agent risks, the most common mitigations are:

• A constitutional rule that prevents the risky action
• An escalation gate that requires human review for high-risk actions
• A monitoring alert that flags the risk pattern when it occurs

Without a runtime governance layer, these mitigations exist only on paper. Article 9 requires that risk management measures be tested and verified to work. A governance rule that isn’t enforced at runtime fails the verification test.

FAQ

Q: Does a “risk assessment” done before deployment satisfy Article 9?

Only the identification and initial estimation components. Article 9 requires a continuous system — the assessment must be updated throughout the lifetime of the system. A pre-deployment assessment is the starting point of Article 9 compliance, not the end.

Q: What does “regular systematic updating” mean in practice?

Article 9 doesn’t specify a review frequency. The NIST AI Risk Management Framework — often used as a practical reference — recommends quarterly reviews for high-risk systems with event-triggered reviews for significant changes. Match the review cadence to the rate of change in your system and its risk environment. For AI agents in active development, monthly reviews may be necessary.

Q: Are third-party model providers responsible for Article 9 compliance?

Article 9’s obligations fall on the provider of the high-risk AI system — typically the organization deploying the agent, not the model provider. Anthropic, OpenAI, and Google provide the model; your organization builds and deploys the AI system using that model. The AI system includes your governance layer, your agent logic, and your deployment environment. You own Article 9.

Q: How does Article 9 interact with Article 17 (quality management system)?

Article 17 requires a quality management system for providers of high-risk AI systems. The risk management system required by Article 9 is a required component of the Article 17 quality management system. In practice: Article 9 defines what you must do to manage risk; Article 17 defines how that risk management practice must be embedded in your organizational quality system.

Q: We operate in the US, not the EU. Does Article 9 apply to us?

If you deploy AI systems that affect EU natural persons — EU citizens using your products, EU employees subject to your AI decisions, EU residents processed by your AI systems — the EU AI Act applies regardless of your organization’s location. The regulatory scope is defined by the data subjects’ location, not the provider’s.

---

By Nikola Kovtun, founder of Infracortex AI Studio. Cortex implements the runtime enforcement layer required by Article 9 — continuous policy evaluation, risk-classified decisions, and audit evidence that documents your risk management system in operation. Book a call to map your Article 9 compliance gaps.

See also: EU AI Act Article 12: Logging Requirements Decoded | EU AI Act Article 14: Building Practical Human Oversight | Why Runtime is Commodity and Governance is the Moat

Cortex build: 0.1.35-260423