Insights

EU AI Act Article 9: A Plain-English Guide to the Risk Management System for High-Risk AI

Last updated · July 27, 2026

Article 9 of Regulation (EU) 2024/1689 is the provision that turns "we take AI risk seriously" from a marketing claim into a legal obligation. If you are a provider of a high-risk AI system - meaning you develop it, place it on the EU market, or put it into service - Article 9 requires you to establish, implement, document, and maintain a risk management system (RMS) for that system. Not once. Continuously.

This guide walks through every substantive requirement in Article 9, explains how it connects to the rest of the AI Act's compliance architecture, and gives you a practical starting point for building an RMS that will hold up to scrutiny.

This post is for informational purposes only and does not constitute legal advice. Always verify requirements against the official text of Regulation (EU) 2024/1689.

Who Article 9 Binds - and When

Article 9 applies to providers of high-risk AI systems. If you build the system and place it on the EU market or put it into service, you are the provider and Article 9 is your obligation. Deployers - organisations that use a provider's system in their own context - have separate obligations under Article 26, but the RMS itself sits with the provider.

On timing: Article 9 requirements were originally set to enter into application on 2 August 2026 under Article 113 of Regulation (EU) 2024/1689.

The picture has shifted. On 7 May 2026, the Council of the EU and the European Parliament reached a provisional political agreement on the Digital Omnibus on AI, which defers high-risk obligations for standalone Annex III systems to 2 December 2027. The Council of the EU gave its final formal green light to the Omnibus on 29 June 2026, following the European Parliament's formal endorsement on 16 June 2026.

What this means for your planning: The Digital Omnibus is now formally adopted and will enter into force shortly after publication in the Official Journal. For standalone Annex III systems (recruitment, credit scoring, law enforcement, education, border control, and others), the Article 9 compliance deadline is 2 December 2027. For AI embedded in regulated Annex I products (medical devices, machinery, vehicles), the deadline is 2 August 2028. The underlying compliance work — risk identification, documentation, testing — takes months to do properly. The delay gives you more runway, not permission to wait.

Not sure whether your system is high-risk? Our guide to high-risk AI classification under Articles 6 and Annex III covers the criteria and the exceptions most summaries miss.

What Article 9 Actually Requires: Four Verbs, Not One

Article 9(1) opens with a sentence that is short and unambiguous: a risk management system shall be established, implemented, documented, and maintained in relation to high-risk AI systems.

Each verb carries weight:

Established - the system must exist as a designed structure, not an ad hoc process.
Implemented - it must run operationally, not sit in a policy binder.
Documented - it must produce evidence. The RMS must be described in your technical documentation under Article 11 and Annex IV.
Maintained - it must keep going and be updated as the system and its context evolve.

A risk assessment performed once and filed away satisfies, at best, one of these four obligations.

The Continuous Iterative Loop: Article 9(2)

Article 9(2) is where the real architecture lives. The RMS is defined as "a continuous iterative process planned and run throughout the entire lifecycle of the high-risk AI system," requiring regular and systematic review and updating. It comprises four steps:

(a) Identify and analyse known and reasonably foreseeable risks to health, safety, or fundamental rights when the system is used for its intended purpose.

(b) Estimate and evaluate risks arising both under intended use and under conditions of reasonably foreseeable misuse. This is the step most teams underweight. You cannot limit your analysis to the happy path - you must actively consider how the system could be misused and what harm that would cause.

(c) Evaluate other risks that emerge from post-market monitoring data collected under Article 72. This is the feedback loop that makes the RMS genuinely continuous: real-world performance data flows back in and triggers re-evaluation.

(d) Adopt appropriate, targeted risk management measures based on steps (a) through (c).

A clean circular diagram showing four connected stages of a continuous risk management loop: Identify & Analyse, Estimate & Evaluate (intended use + misuse), Evaluate from Post-Market Data, Adopt Measures - with arrows flowing clockwise and a central label reading 'Entire AI Lifecycle'. Minimal, professional style on a white background.

One important scoping rule from Article 9(3): only risks that can reasonably be mitigated or eliminated through development choices, design decisions, or the provision of technical information fall within the RMS's scope. Risks that are entirely outside the provider's control are not in scope - but you must be able to demonstrate why.

The "Acceptable Residual Risk" Standard

Article 9(5) sets the outcome standard: residual risk for each individual hazard and the overall residual risk of the system must be judged acceptable. This is a two-level test - passing on individual hazards is not enough if the aggregate picture is unacceptable.

The measures you adopt must follow a priority order:

Eliminate or reduce risk by design as far as technically feasible. Design-out comes first.
Adequate mitigation and control for risks that cannot be eliminated by design.
Information under Article 13 and, where appropriate, training to deployers - factoring in the deployer's technical knowledge, experience, education, and the context of use.

This hierarchy matters legally. Reaching for an instruction-manual fix when a design fix was technically feasible is not compliant. The law expects you to work down the list in order.

Practical implication of the hierarchy: If your model produces biased outputs in a specific demographic context, the first question is whether you can fix it in training data or model architecture (step 1). Only if that is not technically feasible do you move to runtime controls (step 2), and only then to deployer instructions (step 3). Document why each step was or was not feasible — that reasoning is what an auditor will look for.

Testing: Article 9(6)-(8)

High-risk AI systems must be tested to identify the best risk management measures. Key requirements:

Testing happens throughout development, not just at the end.
Testing must occur before placing on the market or putting into service.
Testing is conducted against prior defined metrics and probabilistic thresholds appropriate to the intended purpose. You cannot test against vague criteria - the thresholds must be set in advance.
Testing may include real-world testing under Article 60 (AI regulatory sandboxes).

The requirement for pre-defined metrics and probabilistic thresholds is one of the most technically demanding aspects of Article 9. It means your ML team and your compliance team need to agree, before testing begins, on what "acceptable" performance looks like - not after the results come in.

For the technical requirements that sit alongside the RMS - accuracy, robustness, and cybersecurity - see our guide to Article 15.

Vulnerable Groups and Persons Under 18: Article 9(9)

Article 9(9) adds a specific obligation: providers must consider whether the system is likely to adversely affect persons under 18 and, as appropriate, other vulnerable groups. This is not a general aspiration - it is a named requirement that must be addressed in your risk analysis.

If your system could be used in contexts involving children (education, healthcare, consumer services), or groups with reduced capacity to protect their own interests, your risk identification step must explicitly address those populations and your measures must be calibrated accordingly.

Integrating with Existing Risk Frameworks: Article 9(10)

Article 9(10) provides a practical relief valve for providers already operating under sector-specific Union law that imposes its own internal risk management processes. Where such processes exist - for example, under the Medical Devices Regulation (MDR) or financial services legislation - Article 9 aspects may be integrated with or combined into those existing procedures.

The goal is a single coherent risk management process, not two parallel systems. If you are building AI for medical devices, map your MDR risk management documentation to Article 9's four-step loop rather than creating a separate AI Act RMS from scratch.

This integration principle also applies to voluntary standards. Two frameworks are particularly useful as scaffolding:

ISO/IEC 23894:2023 - ISO/IEC 23894:2023 provides guidance on how organizations that develop, produce, deploy, or use AI products and systems can manage risk specifically related to AI, and is designed to be used in connection with ISO 31000:2018. It introduces AI-specific risk categories - algorithmic transparency, fairness and bias, robustness, and human-AI interaction risks - that map well onto Article 9's identification and evaluation steps.
NIST AI Risk Management Framework (AI RMF 1.0) - The NIST AI RMF, published in January 2023, organises AI risk management work into four functions: Govern, Map, Measure, and Manage, aligned with trustworthy AI characteristics such as validity, safety, security, accountability, and fairness. Its Map function (contextualising the system and identifying potential harms) and Measure function (quantifying risk likelihood and consequences) align closely with Article 9(2)(a) and (b).

Neither standard substitutes for legal compliance with Article 9. They are operational scaffolding - useful for structuring the work and building a vocabulary your team can use. The legal standard is the Regulation.

How the RMS Connects to the Rest of the AI Act

Article 9 does not operate in isolation. It is the engine inside a larger compliance machine:

Article 9 RMS — Key Connections

Article / Annex	What it does	Connection to Article 9
Article 8	Compliance with requirements for high-risk AI	The RMS is the mechanism through which compliance with Art. 8 requirements is demonstrated.
Article 11 / Annex IV	Technical documentation	The RMS — its design, outputs, and residual risk judgements — must be described in the technical file.
Article 13	Transparency and information to deployers	Deployer instructions are the third-tier measure in the Art. 9(5) hierarchy.
Article 15	Accuracy, robustness, cybersecurity	Testing under Art. 9(6)–(8) must cover these technical properties against pre-defined thresholds.
Article 17	Quality management system (QMS)	The RMS lives inside the QMS. Art. 17 is the organisational wrapper; Art. 9 is one of its core elements.
Article 72	Post-market monitoring	Post-market data feeds directly into Art. 9(2)(c) — the third step of the continuous loop.
Article 73	Incident reporting	Serious incidents identified through post-market monitoring may trigger RMS updates.
Recital 65	Interpretive guidance	Provides context on the purpose and scope of the RMS obligation.

The relationship with Article 17 (Quality Management System) is particularly important. The QMS is the organisational backbone that holds every high-risk obligation together. The RMS is one of the 13 elements the QMS must cover. If you are building your compliance programme in the right order, you design the QMS first, then build the RMS as a defined process within it.

For post-market monitoring and incident reporting - the mechanisms that feed step (c) of the Article 9 loop - see our guides to Articles 72 and 73.

Article 9 RMS Readiness Self-Assessment

Use this interactive tool to check where your current risk management practices stand against Article 9's requirements.

A Practical "Start Now" Checklist

Building an Article 9-compliant RMS is a programme of work, not a document. Here is a sequenced starting point:

Confirm your high-risk classification

Before building an RMS, confirm the system falls within Article 6 / Annex III scope. Document your classification reasoning — it belongs in the technical file.

Define the RMS scope and lifecycle boundaries

Map the system's full lifecycle: design, development, validation, deployment, operation, and decommissioning. The RMS must cover all of it.

Conduct structured risk identification (Art. 9(2)(a))

Use a structured method — FMEA, HAZOP, or an AI-specific approach informed by ISO/IEC 23894 — to identify known and reasonably foreseeable risks to health, safety, and fundamental rights. Document sources and assumptions.

Evaluate misuse scenarios (Art. 9(2)(b))

Run a dedicated misuse analysis. Who could use this system in ways you did not intend? What harm would result? This step is separate from intended-use analysis and must be documented separately.

Assess impacts on under-18s and vulnerable groups (Art. 9(9))

Explicitly address whether the system could adversely affect children or other vulnerable populations. If yes, calibrate your risk measures accordingly.

Define pre-testing metrics and probabilistic thresholds (Art. 9(6)–(8))

Before testing begins, agree and document the metrics and thresholds against which the system will be evaluated. Involve both ML engineers and compliance leads in setting these.

Apply the measure hierarchy and document residual risk (Art. 9(5))

For each identified risk: attempt design-out first, then controls, then deployer information. Document why each tier was or was not feasible. Record your residual risk judgement — per hazard and overall.

Integrate with your QMS and technical documentation

Embed the RMS as a defined process within your Article 17 QMS. Ensure the RMS design, outputs, and residual risk judgements are captured in your Article 11 / Annex IV technical file.

Set up post-market monitoring to close the loop (Art. 9(2)(c))

Establish the Article 72 post-market monitoring process that will feed real-world performance data back into your RMS. Define the triggers that require a formal RMS review.

Schedule regular systematic reviews

The RMS must be reviewed and updated regularly. Set a review cadence — at minimum annually, and triggered by significant model changes, new deployment contexts, or post-market findings.

The Timeline in Plain English

Under the Digital Omnibus on AI, formally endorsed by the European Parliament on 16 June 2026 and given final Council approval on 29 June 2026, high-risk obligations for standalone Annex III systems are deferred to 2 December 2027, and for AI embedded in regulated Annex I products to 2 August 2028.

The delay is real. But the compliance work - risk identification, testing, documentation, QMS integration - takes six to eighteen months to do properly for a complex system. Organisations that treat December 2027 as the start date, rather than the deadline, will find themselves in the same position as those who waited for August 2026.

This post is part of our "Article X: A Plain-English Guide" series on the EU AI Act. Related guides: Article 17 - Quality Management System · Article 15 - Accuracy, Robustness and Cybersecurity · Article 26 - Deployer Obligations.