EU AI Act Article 9 — Risk Management System Requirements

What Article 9 actually requires

Article 9 of Regulation (EU) 2024/1689 obliges providers of high-risk AI systems to establish, implement, document and maintain a risk management system. It is not a one-off risk register. It is a continuous, iterative process that runs throughout the system's lifecycle.

Reg text — Article 9(2): "The risk management system shall be understood as a continuous iterative process planned and run throughout the entire lifecycle of a high-risk AI system, requiring regular systematic review and updating."

The continuity requirement is the part most teams miss. A risk register written once before launch and never touched again is, by itself, evidence of non-conformity.

The five-step process — Article 9(2)(a)–(e)

Article 9(2) defines the iterative loop in five steps:

• (a) Identification and analysis of the known and reasonably foreseeable risks that the system can pose to health, safety or fundamental rights when used in accordance with its intended purpose.
• (b) Estimation and evaluation of 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.
• (c) Evaluation of other risks possibly arising, based on the analysis of data gathered from the post-market monitoring system referred to in Article 72.
• (d) Adoption of appropriate and targeted risk management measures designed to address the risks identified pursuant to point (a).
• (e) (read together with paragraphs 3, 4 and 5) Eliminating risks where possible through design, otherwise mitigating them; informing deployers via Article 13 instructions for use of any residual risks; and, where relevant, providing training to deployers.

The hierarchy in Article 9(5) is mandatory: eliminate → mitigate → inform. Inform is the last resort, not the first.

Special protections — Article 9(9) for persons under 18

Article 9(9) requires that where the high-risk system is likely to be accessed by or used by persons under 18 years of age or other vulnerable groups, the risk management measures must specifically take into account those groups.

In practice: edu-tech models (Annex III §3) and any consumer-facing high-risk system that may be used by minors trigger this paragraph. The risk register must have a dedicated row per vulnerable group with group-specific mitigations.

Who is covered

Article 9 is a provider obligation. But the boundary is porous:

• A deployer who substantially modifies the system or changes the intended purpose is upgraded to provider under Article 25 — and inherits Article 9.
• Even pure deployers must run an Article 26 oversight regime that feeds back into the provider's Article 9 system. Article 26(5) requires deployers to inform the provider of any serious incident or risk.
• For deployers required to perform a FRIA under Article 27, the FRIA risk catalogue must mesh with the provider's Article 9 register — same risks, different perspective.

What to do — the practical risk register

A defensible Article 9 risk register has, per row:

1. Risk identifier and description. Plain language.
2. Affected persons / groups. Named, including any vulnerable groups under Article 9(9).
3. Likelihood and severity estimates, with the methodology documented (qualitative scale, quantitative scoring, hybrid).
4. Risk source. Training data, model architecture, deployment context, foreseeable misuse.
5. Mitigation measures. What you did. Hierarchy: design fix → guardrail → operational control → instructions for use.
6. Residual risk after mitigation. Be honest. A "low" residual risk on every row is not credible.
7. Owner. A named person, not a team.
8. Review cadence. Quarterly minimum for high-priority risks; annual for low-priority.
9. Evidence link. Pointer to the test report, the validation result, the deployment log.

A typical high-risk system has 30–80 risk rows. A platform with multiple high-risk models has a master register plus per-model sub-registers.

A worked example

A French legal-tech vendor offers a contract-analysis model used by deployer law firms (Annex III §8 administration of justice — provider-deployed via legal-services platform). One row of their Article 9 register:

That row, multiplied by 30–80 risks, plus a master document explaining the methodology and the review process, is what an Article 9 system looks like on paper.

Linking Article 9 to Article 11 / Annex IV §4

The Article 9 system is described in Annex IV §4 as part of the technical documentation. The Annex IV §4 entry is a description of the system, not the register itself. The full register is a referenced artefact — a competent authority can request it under Article 21.

A common audit pattern: regulator reads Annex IV §4, then asks for the underlying register. If the description in §4 says "we run quarterly reviews" and the register has no entries from the last quarter, that's a non-conformity.

What regulators look at first

1. The most recent review entry. Date, attendee list, decisions taken. Should be within the last quarter for high-priority risks.
2. The post-market feedback loop. Article 9(2)(c) requires Article 72 post-market data to feed back into the register. Show the input.
3. Vulnerable-groups rows under Article 9(9). If any are likely to be affected, show specific rows for them.
4. The Article 73 / 79 incident integration. When an incident is reported under Article 79, it must update the Article 9 register. Show the link.

Inline crosswalk to ISO 42001 and NIST AI RMF

• ISO/IEC 42001:2023 Clause 6.1.2 — AI risk assessment. The Article 9 process is the EU-AI-Act realisation of Clause 6.1.2.
• ISO/IEC 42001:2023 Clause 6.1.3 — AI risk treatment. Article 9 mitigation, residual-risk recording and quarterly review provide the risk-treatment evidence.
• NIST AI RMF GOVERN 1.1 — Legal and regulatory requirements involving AI are understood, managed, and documented. Article 9 captures the regulatory requirements GOVERN 1.1 wants documented.
• NIST AI RMF MANAGE 1.3 — Responses to the AI risks deemed high priority are developed, planned, and documented. Article 9 mitigation plans for residual high-priority risks are exactly the responses MANAGE 1.3 expects.

A team running ISO/IEC 23894:2023 (AI risk management standard) is, in practice, doing 80% of Article 9. The remaining 20% is the AI-Act-specific obligations: vulnerable groups (Article 9(9)), foreseeable-misuse coverage (Article 9(2)(b)), and the eliminate→mitigate→inform hierarchy (Article 9(5)).

Penalties

Article 99(4) sets non-compliance with Article 9 at up to €15 million or 3% of worldwide annual turnover. As elsewhere in Chapter III Section 2, the practical enforcement risk is market-withdrawal under Article 79 during the remediation period.

Common mistakes

1. Static risk register. Written once, never updated. Article 9(2) explicitly requires continuous review.
2. Skipping foreseeable misuse. Article 9(2)(b) is mandatory, not optional.
3. No vulnerable-groups analysis. Article 9(9) is mandatory for systems likely to be used by minors or vulnerable groups.
4. Mitigation hierarchy inverted. Teams that lead with "instructions for use" before exhausting design fixes are non-compliant under Article 9(5).
5. No feedback from Article 72 post-market data. Article 9(2)(c) requires the loop.

---

Disclaimer. This page is a reference summary of EU AI Act Article 9. It is not legal advice. Verify with qualified counsel before relying on it for compliance decisions. Reg text quoted from the Official Journal version of Regulation (EU) 2024/1689.