What does Article 9 of the EU AI Act require for risk management?

Updated 9 August 2026 for Regulation (EU) 2026/1744.

Article 9 requires providers of high-risk AI systems to establish, implement, document and maintain a risk management system: a continuous iterative process across the entire lifecycle, built on four defined steps, a residual-risk acceptability judgement, and testing against prior defined metrics.

Quick answer

• Who it binds: The provider. Deployers have separate duties under Article 26, not Article 9.
• What it is: "A continuous iterative process planned and run throughout the entire lifecycle", with "regular systematic review and updating" and the four steps in Article 9(2) — not a one-off assessment.
• The scope limit: Article 9(3) covers only risks that "may be reasonably mitigated or eliminated" through design, development or adequate technical information.
• The output: Residual risk per hazard and overall "judged to be acceptable" (Article 9(5)), plus testing "against prior defined metrics and probabilistic thresholds" before market placement (Article 9(8)).
• From when: Article 9 applies from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I systems (Article 113, third paragraph, point (c), as amended by Regulation (EU) 2026/1744). Article 9 itself was not amended; its application date was.

What counts as a risk management system under Article 9?

Article 9(1) requires that "a risk management system shall be established, implemented, documented and maintained in relation to high-risk AI systems." All four verbs carry weight: a register that is never updated fails "maintained"; a process that leaves no records fails "documented."

Article 9(2) then defines what the system is: "a continuous iterative process planned and run throughout the entire lifecycle of a high-risk AI system, requiring regular systematic review and updating." That sentence rules out the most common shortcut — a risk assessment performed once before launch and filed away.

Article 9 does not stand alone. Under Article 8(1), "the risk management system referred to in Article 9 shall be taken into account when ensuring compliance" with all the Section 2 requirements, and under Article 17(1), point (g), it is a mandatory component of the provider's quality management system. For how Article 9 fits into the full high-risk obligation set, see the high-risk obligations overview; if you have not yet confirmed your system is high-risk, run the classification check first.

What are the four steps in Article 9(2)?

Article 9(2) prescribes four steps:

• Article 9(2), point (a) — identification and analysis of "the known and the reasonably foreseeable risks that the high-risk AI system can pose to health, safety or fundamental rights" under the intended purpose. Fundamental rights sit alongside health and safety: a hiring tool's discrimination risk belongs in the same register as a safety component's failure modes.
• Article 9(2), point (b) — estimation and evaluation of risks that may emerge under intended use "and under conditions of reasonably foreseeable misuse" — the predictable wrong uses, such as a shortlisting tool run as an automatic rejector.
• Article 9(2), point (c) — evaluation of other risks based on "the analysis of data gathered from the post-market monitoring system referred to in Article 72." Field data feeds back into the register after launch.
• Article 9(2), point (d) — adoption of "appropriate and targeted risk management measures designed to address the risks identified pursuant to point (a)."

Note that point (d) refers back to the risks identified under point (a) — keep documentation traceable from each measure to an identified risk.

Which risks does Article 9 actually cover?

Fewer than most first drafts assume. Article 9(3) limits the exercise: the risks "shall concern only those which may be reasonably mitigated or eliminated through the development or design of the high-risk AI system, or the provision of adequate technical information." Risks you cannot influence through design, development or the information you provide — general societal effects, a deployer's independent misconduct — fall outside the required scope. Every register entry should map to something the provider can actually do.

Article 9(4) adds a balancing rule: measures must give "due consideration to the effects and possible interaction resulting from the combined application" of all Section 2 requirements — the training-data choices under Article 10's data governance rules, the records demanded by Article 11's technical documentation — managed as one design problem, not seven parallel checklists.

When is residual risk acceptable?

Article 9(5) sets the end state: measures must be such that "the relevant residual risk associated with each hazard, as well as the overall residual risk" is "judged to be acceptable." Two judgements, per hazard and overall — a system can pass every individual hazard and still fail on accumulated risk.

In choosing measures, Article 9(5) fixes a hierarchy: first, elimination or reduction of risks "in as far as technically feasible through adequate design and development"; second, "where appropriate, implementation of adequate mitigation and control measures addressing risks that cannot be eliminated"; third, "provision of information required pursuant to Article 13 and, where appropriate, training to deployers." Warning deployers is the last resort, not the first move — and when you rely on it, Article 9(5) requires due consideration of "the technical knowledge, experience, education, the training to be expected by the deployer, and the presumable context" of use. A warning your actual buyers will never read does not discharge the duty.

What the Act does not do is define "acceptable." No threshold appears in Article 9, and the harmonised standards meant to concretise the requirements were still incomplete at the time of writing. Until they land, acceptability is the provider's own documented, defensible judgement.

What testing does Article 9 require?

Under Article 9(6), high-risk AI systems "shall be tested for the purpose of identifying the most appropriate and targeted risk management measures," and testing must ensure they perform "consistently for their intended purpose" and comply with Section 2. Testing here is not generic QA — it is the evidence base for your risk measures.

Article 9(8) sets timing and method: testing "as appropriate, at any time throughout the development process, and, in any event, prior to their being placed on the market or put into service," carried out "against prior defined metrics and probabilistic thresholds that are appropriate to the intended purpose of the high-risk AI system." Two traps follow from the text: metrics defined after seeing the results are not "prior defined", and a pass/fail judgement with no probabilistic threshold behind it fails the second limb.

Article 9(7) permits — but never requires — testing in real-world conditions in accordance with Article 60, which sets its own regime of plans, approvals and safeguards outside regulatory sandboxes.

What about children and other vulnerable groups?

Article 9(9) adds a mandatory lens: when implementing the risk management system "as provided for in paragraphs 1 to 7," providers must consider "whether in view of its intended purpose the high-risk AI system is likely to have an adverse impact on persons under the age of 18 and, as appropriate, other vulnerable groups." This applies to every high-risk system, not only products aimed at minors — documentation should show the question was asked even where the answer is no.

Can you build on an existing risk process?

Yes, within limits. Article 9(10) provides that for providers already "subject to requirements regarding internal risk management processes under other relevant provisions of Union law" — medical-device or financial-services regimes, for instance — the Article 9 elements "may be part of, or combined with, the risk management procedures established pursuant to that law." One integrated process is expressly permitted; a duplicate parallel system is not required.

The boundary: the allowance covers procedures required by Union law. An ISO-based enterprise risk process is not that — you can build on it, but Article 9(10) does not automatically bless it, and every Article 9 element must remain demonstrably present. Demonstrating it happens in the technical documentation: Annex IV requires "a detailed description of the risk management system in accordance with Article 9" — covered in the technical documentation guide.

What this means for you

If you're a provider: Article 9 binds you, and it applies to Annex III systems from 2 December 2027. Work the text in order: a risk register built on the four steps of Article 9(2), including foreseeable misuse and a documented Article 9(9) vulnerable-groups check; written acceptability criteria before you judge residual risk against them; test reports with metrics and thresholds that predate the results; a feed from Article 72 post-market monitoring back into the register; the whole system anchored in your Article 17 QMS. Complipath's requirements checklist tracks every obligation the classification triggers, with status, owner, evidence link and notes — so recurring Article 9 reviews have an owner and a paper trail.

If you're a deployer: Article 9 does not bind you — but its outputs reach you. The instructions for use should reflect the provider's residual risks and any mitigation passed to you under Article 9(5); read them as the provider's risk disclosure, and ask for training where Article 9(5) contemplates it. Before purchase, ask what the acceptability judgement rests on and how testing was done — a provider who cannot answer has an Article 9 problem that becomes your operational problem. Unsure which role you hold? See provider vs deployer.

Which of your systems owe an Article 9 system?

Classify your system now — 7 questions on the main line, plus follow-ups where they apply, no account, and the classification runs in your browser: answers stay there unless you choose to keep the result.

FAQ

Is a one-off risk assessment enough under Article 9? No. Article 9(2) defines the risk management system as "a continuous iterative process planned and run throughout the entire lifecycle," requiring "regular systematic review and updating." A pre-launch assessment is one input; without scheduled reviews and a post-market feedback loop under Article 9(2), point (c), the obligation is not met.

Does Article 9 apply to deployers? No. Article 9 sits in Section 2 of Chapter III, whose requirements the provider must ensure are met under Article 16, point (a). Deployers carry separate obligations under Article 26 — but they receive Article 9's outputs through the instructions for use and any training under Article 9(5).

Do all risks have to be eliminated? No. Article 9(3) limits the scope to risks that can reasonably be mitigated or eliminated through design, development or adequate technical information, and Article 9(5) requires residual risk — per hazard and overall — to be "judged to be acceptable," not zero. The Act sets no numeric acceptability threshold.

Can we reuse our existing ISO or sector risk process? Partly. Article 9(10) lets providers bound by internal risk-management requirements under other Union law combine Article 9 with those procedures. An ISO-based process is not Union law, so the allowance does not formally cover it — you may build on it, but each Article 9 element must remain demonstrable.

Sources: Regulation (EU) 2024/1689 (EUR-Lex), Articles 8, 9, 16, 17, 60, 72 and 113, and Annex IV. Regulation (EU) 2026/1744 (EUR-Lex) left Article 9 untouched but replaced Article 113, third paragraph, point (c), which sets when Chapter III, Section 2 applies. The Article 40 harmonised standards expected to concretise the Section 2 requirements, including acceptability practice under Article 9(5), were still incomplete at the time of writing; the obligations apply regardless, and "acceptable" residual risk remains a provider judgement until standards or case law say otherwise.