Risk Management for AI Systems: What Article 9 of the EU AI Act Requires

Article 9 of the EU AI Act requires providers of high-risk AI systems to establish, implement, document, and maintain a risk management system. This is not a one-time exercise you complete and file. It’s a continuous, iterative process that runs throughout the AI system’s entire lifecycle.

Many organisations approach risk management as a project. Identify risks, document mitigations, get sign-off, and move on. Article 9(2) explicitly describes the system as a continuous iterative process “requiring regular systematic review and updating” to reflect new information, changes in the system, and lessons from operational experience.

Article 9 is one of the core obligations for high-risk systems. For most Annex III high-risk AI systems, the compliance deadline is now 2 December 2027, pushed back from 2 August 2026 by the Digital Omnibus (provisionally agreed in May 2026, pending formal adoption).

What Article 9 requires

The risk management system must include the following elements:

Identification and analysis of known and reasonably foreseeable risks

You need to identify the risks that your high-risk AI system poses to health, safety, and fundamental rights. Article 9(2)(b) requires this assessment to consider the risks “that may emerge when the high-risk AI system is used in accordance with its intended purpose, and under conditions of reasonably foreseeable misuse.”

“Reasonably foreseeable” is key. You’re not expected to anticipate every possible misuse, but you are expected to think beyond the intended use case. If you provide a recruitment screening tool, it’s reasonably foreseeable that a deployer might apply it to roles it wasn’t trained on. If you provide a credit scoring model, it’s reasonably foreseeable that edge cases in the input data could produce discriminatory outputs.

The analysis must consider risks both to individual users and to broader groups of affected people. A system that performs well on average but fails systematically for a specific demographic group presents a risk that an aggregate assessment would miss.

Estimation and evaluation of risks

Once identified, risks must be assessed for likelihood and severity.

This is where quantification matters. “There is some risk of bias” is an observation, not an evaluation. “Testing on [specific dataset] showed a 12-percentage-point accuracy gap between [demographic group A] and [demographic group B], affecting approximately [X%] of expected inputs” is an evaluation that supports informed decision-making about mitigations.

Where quantification isn’t possible, qualitative assessment with clear reasoning is the next best approach. But avoid vague risk ratings (“medium risk”) without supporting analysis.

Adoption of appropriate and targeted risk management measures

Identified risks must be mitigated. Article 9(5) sets out the hierarchy. Measures must first aim at the “elimination or reduction of risks identified and evaluated pursuant to paragraph 2 in as far as technically feasible through adequate design and development” of the system. Where risks cannot be eliminated, the provider implements mitigation and control measures, then provides the information required under Article 13 and, where appropriate, training to deployers.

The Act establishes a hierarchy of controls:

1. Design out the risk: Modify the system to eliminate the risk source.
2. Reduce through engineering: Add technical safeguards (input validation, output filtering, confidence thresholds).
3. Inform and train: Provide documentation and guidance to deployers and users.
4. Monitor and respond: Detect when residual risks materialise and respond.

This hierarchy mirrors established safety engineering principles. The most effective mitigations are baked into the system design.

Residual risk management

Article 9(5) requires that the residual risk remaining after mitigations, both for each hazard and overall, is “judged to be acceptable.” The residual risk must be:

• Assessed and judged acceptable in view of the system’s intended purpose
• Communicated to deployers through the instructions for use
• Considered in the context of the overall risk-benefit balance

If the residual risk is unacceptable, the system shouldn’t be deployed, or its use case should be narrowed until the residual risk falls within acceptable bounds.

Testing

Article 9(6) requires testing of the high-risk AI system “for the purpose of identifying the most appropriate and targeted risk management measures.” Under Article 9(8), testing must be carried out “against prior defined metrics and probabilistic thresholds that are appropriate to the intended purpose.”

This means:

• Define your performance metrics and acceptable thresholds before testing.
• Test against those metrics systematically.
• Use the results to inform your risk management measures.
• Document the test methodology, results, and how they influenced your risk decisions.

Remember, testing must cover the conditions of intended use and reasonably foreseeable misuse.

What auditors will expect to see

Whether your system undergoes internal conformity assessment or third-party assessment by a notified body, the assessor will evaluate your risk management system. Here’s what they’ll look for:

A living document, not a snapshot

The risk management system must show evidence of iteration. A document dated 18 months ago with no updates suggests a one-off exercise, not a continuous process. Expect questions about:

• When was the risk assessment last updated?
• What triggered the last update?
• What changed between versions?
• What new risks have been identified since the initial assessment?

Traceability from risks to mitigations

For each identified risk, the assessor should be able to trace a clear path to the mitigation measure and the evidence that it works. Risk → Mitigation → Validation → Residual Risk Assessment. Gaps in this chain (risks without mitigations, mitigations without evidence of effectiveness) may be flagged.

Evidence-based risk evaluation

Risk ratings should be supported by analysis. If you rate a bias risk as “low,” the assessor will ask what testing you conducted to support that rating. If you rate an accuracy risk as “acceptable,” they’ll want to see the performance data.

Coverage of the full lifecycle

The risk management system must cover:

• Design and development: risks from architecture, data, and algorithm choices.
• Testing and validation: risks identified through testing.
• Deployment: risks from the operational environment.
• Post-market operation: risks that emerge in production.
• Decommissioning: risks from system withdrawal or data disposal.

A risk management system that only covers the development phase is incomplete.

Stakeholder input

Article 8(1) requires high-risk systems to meet the Section 2 requirements “taking into account their intended purpose as well as the generally acknowledged state of the art.” Conforming to a harmonised standard under Article 40 gives a presumption of conformity, so assessors will check whether you’ve referenced applicable industry standards.

They’ll also look for evidence that affected stakeholders were considered. Not necessarily consulted directly, but that the risk assessment accounts for the perspectives of people affected by the AI system.

Building your risk management system

Start with the system description

Before assessing risks, document what the system does, how it works, what data it processes, who it affects, and in what context. This system description is the foundation of the risk assessment — you can’t identify risks without understanding the system.

Use a structured risk identification method

Don’t rely on brainstorming alone. Use structured methods:

• Failure mode analysis: For each component and decision point, what could go wrong?
• Misuse scenarios: How might the system be used outside its intended purpose?
• Stakeholder perspective: For each category of affected person, what risks do they face?
• Data-related risks: What if the data quality changes, distributions shift, or biases exist?
• Interaction risks: How does the system interact with other systems, and what risks arise from those interactions?

Document decisions, not just outcomes

For each risk and mitigation decision, document the reasoning. Why was this risk rated at this level? Why was this mitigation approach chosen over alternatives? Why is the residual risk considered acceptable?

This reasoning is valuable both for auditors (who need to understand your thought process) and for future iterations (when you revisit decisions with new information).

Connect to monitoring

Your risk management system should specify what monitoring is needed to detect when risks materialise in production. Each significant risk should have an associated monitoring metric or trigger. This connects Article 9 (risk management) to Article 72 (post-market monitoring) — they’re not separate activities but parts of a continuous cycle.

Plan for updates

Define the triggers for updating your risk management system:

• Scheduled reviews (at least annually, more frequently for newer or higher-risk systems).
• New information about system performance from post-market monitoring.
• Feedback from deployers or affected individuals.
• Changes to the system (model updates, data changes, use case expansion).
• Relevant new standards, guidance, or regulatory interpretations.
• Incidents or near-misses.

Each update should be documented with the date, trigger, changes made, and the person responsible.

The mindset shift

For organisations accustomed to project-based risk assessments, Article 9 requires a shift in thinking. The risk management system is not something you build once and maintain passively. It’s an operational process (like financial auditing or quality management) that requires ongoing attention, resources, and governance.

Organisations should integrate risk management into their AI development and deployment workflows. When risk assessment is part of every design decision, every deployment decision, and every model update, it becomes part of normal operations rather than a periodic burden.

Article 9 is one of several interlocking high-risk obligations. Compliance with Article 9 is ultimately tested through the conformity assessment, where the risk management file is reviewed alongside the technical documentation (Annex IV).

The EU AI Act compliance checklist maps how risk management connects to data governance (Article 10) and post-market monitoring (Article 72), so none of the dependencies fall through the gap between them.