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.

For high-risk AI systems, Article 9 requires a documented risk management system maintained throughout the lifecycle. The initial assessment must feed regular review and updates as the system and its risks change.

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

At a glance

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:

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.
Estimation and evaluation of risks — Not just identification: you must assess likelihood and severity. The risk matrix must be documented.
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.
Residual risk documentation — After mitigation, the remaining risk must be documented and deemed acceptable. The bar for “acceptable” residual risk must be defined.
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:

Model version update (provider or internal)
Significant change in agent scope or capabilities
New use case added to the agent’s mandate
Compliance framework change (new regulation, updated guidance)
Incident or near-miss occurrence
Scheduled review at the documented, risk-based interval

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

Runtime controls are one way to put documented risk measures into operation. Connect each selected control to the risk it addresses, its responsible owner, and a test that shows whether it works.

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

Test the selected mitigations in the workflow where they operate. Technical controls, human procedures, and monitoring may all contribute; a policy entry alone does not demonstrate that its associated risk measure is effective.

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 calls for regular systematic review and updating but sets no universal quarterly interval. Set a documented cadence based on risk and the pace of change, with additional reviews after material updates, incidents, or changes in use.

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

The provider of the high-risk AI system bears the provider obligations; the deployer has separate duties. Using a third-party model does not automatically make your organization the system provider. Determine the roles from how the system is developed, supplied, branded, and modified.

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?

Article 2 can cover organizations outside the EU, including providers or deployers whose AI system outputs are used in the EU. Assess the specific territorial route, system classification, and operator role; EU citizenship or the presence of EU personal data alone does not settle Article 9 applicability.

By Nikola Kovtun, founder of Infracortex AI Studio. Cortex supports runtime policy evaluation and records that teams can connect to their risk management process. Book a call to map your Article 9 compliance gaps