EU AI Act Article 9 Risk Management System Guide

Article 9 of the EU AI Act requires every provider of a high-risk AI system to run a documented risk management system for the whole life of the system, yet most programmes treat it as a one-off risk register. The article is short, but it sets the method that every other high-risk requirement depends on: the metrics behind Article 15 accuracy, the bias questions behind Article 10, and the residual risk information that goes into the Article 13 instructions for use. This guide works through Article 9 paragraph by paragraph, then turns it into a process, a testing approach and an evidence pack an assessor can follow. It is for providers of high-risk systems, the risk, quality and security teams asked to build the process, and deployers who want to know what a provider should be able to show them. For the wider regime, start with the EU AI Act High-Risk AI Systems Guide.

Source note: this page summarises the official text and the sources listed at the end. Confirm against the official text before relying on it.

Key takeaways

It is a process, not a document. Article 9(2) describes a continuous, iterative process run across the entire lifecycle and regularly reviewed and updated, so an assessment frozen at release does not meet it.
Four steps, one of them fed by the field. Identify and analyse risks, estimate and evaluate them under intended use and reasonably foreseeable misuse, evaluate new risks from post-market monitoring under Article 72, and adopt targeted measures.
The order of controls is fixed. Article 9(5) puts elimination or reduction by design first, mitigation and control measures second, and information and training for deployers last. Warnings in the instructions for use cannot replace a design fix that was technically feasible.
Tests need pass marks set in advance. Article 9(8) requires testing against prior defined metrics and probabilistic thresholds, at least before placing on the market or putting into service, so the thresholds must be written before the results exist.
The deadline moved, the duty did not. According to the Commission's AI Act Service Desk text of Article 113 as amended by the Digital Omnibus on AI, Chapter III Sections 1 to 3 apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I product systems. That is the time to build the evidence, not to wait.

Where Article 9 sits and who it binds

Article 9 opens Chapter III, Section 2 of Regulation (EU) 2024/1689, the requirements for high-risk AI systems. It is followed by data governance (Article 10), technical documentation (Article 11), record keeping (Article 12), transparency (Article 13), human oversight (Article 14) and accuracy, robustness and cybersecurity (Article 15). The duty to establish the risk management system falls on the provider. The quality management system under Article 17(1)(g) must include it, and Annex IV point 5 requires a detailed description of it in the technical documentation, so it is examined in every conformity assessment. See the EU AI Act Conformity Assessment and Harmonised Standards Guide.

Deployers are not required to run an Article 9 system, but they are its main audience: Article 9(5) requires the provider to consider the deployer's technical knowledge, experience, education and training and the presumable context of use. A deployer that uses a system outside the intended purpose, or substantially modifies it, can become a provider and inherit the duty. See the EU AI Act Provider vs Deployer Obligations Guide.

Check the dates on the official consolidated text before relying on them. The Service Desk version used here is based on the EUR-Lex consolidated text as at 27 July 2026 and shows no Digital Omnibus amendment to Article 9 itself. The EU AI Act Implementation Timeline Tracker follows further changes.

Article 9 paragraph by paragraph

The table paraphrases each paragraph from the Commission's AI Act Service Desk text, checked in November 2026, and pairs it with the evidence that answers it.

Paragraph	What it requires	Evidence that answers it
9(1)	A risk management system is established, implemented, documented and maintained for the high-risk AI system.	Risk management procedure, named owner, approval record, version history
9(2)	A continuous iterative process across the lifecycle with regular systematic review, comprising: (a) identification and analysis of known and reasonably foreseeable risks to health, safety or fundamental rights under intended use; (b) estimation and evaluation of risks under intended use and reasonably foreseeable misuse; (c) evaluation of other risks arising from post-market monitoring data under Article 72; (d) adoption of appropriate, targeted measures.	Hazard and risk register, misuse analysis, review calendar, link from post-market monitoring reports into the register
9(3)	Only risks that can be reasonably mitigated or eliminated through development or design, or the provision of adequate technical information, are in scope.	Scoping rationale for risks recorded as outside the provider's control
9(4)	Measures take account of the effects and possible interaction of the Section 2 requirements, to minimise risks while achieving an appropriate balance.	Trade-off records, for example accuracy against bias, or oversight against automation
9(5)	Residual risk per hazard and overall is judged acceptable. Measures follow the order: elimination or reduction by design; mitigation and control for risks that cannot be eliminated; information under Article 13 and, where appropriate, training for deployers. Deployer knowledge and context of use are considered.	Risk acceptance criteria, residual risk evaluation signed off, control hierarchy recorded per risk
9(6)	High-risk systems are tested to identify the most appropriate and targeted measures and to ensure consistent performance for the intended purpose and compliance with Section 2.	Test plan traced to risks and requirements
9(7)	Testing may include testing in real-world conditions under Article 60.	Real-world testing plan where used, with the Article 60 conditions met
9(8)	Testing takes place as appropriate throughout development and in any event before placing on the market or putting into service, against prior defined metrics and probabilistic thresholds appropriate to the intended purpose.	Dated thresholds that predate results, test reports, release gate record
9(9)	Providers consider whether the system is likely to adversely affect persons under 18 and, as appropriate, other vulnerable groups.	Vulnerable group analysis with conclusion and measures
9(10)	Providers subject to internal risk management requirements under other Union law may make Article 9 part of, or combine it with, those procedures.	Mapping to the existing procedure, for example a medical device or financial services risk process

Building the risk process: steps and artefacts

Article 9 says what the process must do, not how. A workable design borrows from ISO/IEC 23894:2023 (guidance on AI risk management) and ISO 31000 and adds the AI Act's specific objects of harm: health, safety and fundamental rights. See the ISO/IEC 23894 AI Risk Management Guide.

Fix the intended purpose. Every later judgement is made against it. Write down users, affected persons, deployment settings, decisions supported and explicit exclusions. Without this, "reasonably foreseeable misuse" has no boundary.
Set acceptance criteria before analysis. Define how severity and probability are scored for each harm type, and what level of residual risk the organisation will accept. The draft harmonised standard prEN 18228 (AI risk management, CEN-CENELEC JTC 21) requires providers to establish objective criteria for risk acceptability without setting the levels itself.
Identify hazards. Work through the data, the model, the human interface, integration with other systems and the operating environment. Use structured prompts: who is harmed if the output is wrong, biased, unavailable, manipulated or over-trusted.
Analyse misuse. Distinguish reasonably foreseeable misuse (a recruiter using a screening score as a final decision) from malicious misuse (an attacker poisoning training data), and record both.
Estimate and evaluate. Score each risk against the criteria, per hazard and in aggregate, as 9(5) requires both.
Select measures in the 9(5) order. Record for each risk why a design fix was or was not feasible before falling back to controls or deployer information.
Verify by testing. Each measure needs a test that shows it works, against a threshold set in step 2 or in the test plan.
Accept residual risk formally. A named accountable person signs off per hazard and overall, and the residual risks that deployers must know go into the instructions for use.
Feed back from the field. Post-market monitoring, serious incident reports and deployer feedback reopen the register on a defined cycle and on trigger events.

Artefact	Contents	Updated when
Risk management plan	Scope, intended purpose, roles, acceptance criteria, review cycle, link to the QMS	Annually and on change to intended purpose
Hazard and risk register	Hazard, harm, affected group, misuse type, scores, measures, owner, residual risk	Every release and every post-market review
Test plan and thresholds	Metrics, probabilistic thresholds, datasets, subgroups, dates fixed	Before each test cycle
Test reports	Results against thresholds, dated and signed, as Annex IV point 2(g) expects for test logs	Each cycle
Residual risk statement	Per hazard and overall acceptance, signatory, deployer information produced	Each release
Change log	Pre-planned modifications and their risk review, linked to Annex IV point 2(f)	Each change

Testing under Article 9(6) to 9(8)

Testing is where most Article 9 programmes are weakest, because thresholds are often chosen after results are known. The safest pattern is to treat the threshold document as a controlled record with a date and approver, and to store it separately from results.

Metrics: choose metrics that reflect the harm, not just overall accuracy. A credit scoring model needs false negative and false positive rates by relevant subgroup, not only area under the curve. Annex IV point 4 asks providers to explain why the chosen metrics are appropriate.
Probabilistic thresholds: express pass marks with confidence, for example a maximum error rate at a stated confidence level on a test set of stated size, so a lucky run does not pass a weak model.
Coverage: test intended use, foreseeable misuse, edge cases, degraded inputs, and the adversarial cases that Article 15(5) names. See the EU AI Act Article 15 Guide and the AI Red Teaming Guide.
Timing: 9(8) requires testing throughout development as appropriate and in any event before release. Build it into the release gate so nothing ships without a current report.
Real-world testing: 9(7) allows testing in real-world conditions under Article 60, which has its own conditions. Treat it as a separate, approved plan, not as an informal pilot.
Oversight effectiveness: where a risk is mitigated by human oversight, test whether the overseer actually catches the error in time. See the EU AI Act Article 14 Guide.

Where identity fits

Many of the risks an Article 9 register should hold start with access, not with the model. Training data poisoning (MITRE ATLAS AML.T0020), manipulation of a model artefact (AML.T0018) and AI supply chain compromise (AML.T0010) usually need write access to a data store, a model registry or a build pipeline. Those are held by service accounts, pipeline tokens and API keys more often than by people. Record the non-human identities that can change training data, models and inference configuration as hazards in their own right, with least privilege and short-lived credentials as design measures. See the AI Data Poisoning and Backdoors Guide. The LiteLLM PyPI package breach shows how one stolen publishing token can push tampered AI tooling to many downstream users.

Deciding how far to go

The following is NHI Mgmt Group's recommendation, not a requirement of the Act.

Situation	Approach	Trade-off
Provider already under a sectoral risk regime (medical devices, banking)	Use 9(10): extend the existing procedure with AI hazards, fundamental rights and the 9(5) hierarchy	Less duplication, but the existing method may ignore fundamental rights harms
First high-risk system, small provider	One plan, one register, a quarterly review, thresholds in the test plan	Light, but depends on one or two people; document the method so it survives staff change
Portfolio of high-risk systems	Shared method and criteria, per-system registers, a central tool, prEN 18228 tracked for adoption	Consistency across systems, at the cost of tooling and governance overhead
Deployer evaluating a high-risk system	Ask for the residual risk statement, the instructions for use and the test thresholds; run a FRIA where Article 27 requires it	Provider evidence may be summarised; contract for access in advance

On standards: harmonised standards give a presumption of conformity only once their references are published in the Official Journal. As reported by CEN-CENELEC in 2026, prEN 18228 was at public enquiry, so it is a draft and may change. ISO/IEC 23894:2023 is published and usable now as guidance, but it is not a harmonised standard. The NIST AI Risk Management Framework (AI RMF 1.0, January 2023, with Govern, Map, Measure and Manage functions) is a useful method for organisations already working with it, but carries no presumption under EU law.

Implementing Article 9 in phases

Phase 1, inventory and scope (first month): list systems that fall under Article 6, record each intended purpose, name a risk owner for each, and decide whether 9(10) integration applies.
Phase 2, method (months 1 to 3): write the risk management plan, acceptance criteria and scoring scales, and get them approved inside the QMS.
Phase 3, pilot (months 3 to 5): run the full cycle on one system, including tests against pre-set thresholds and a residual risk sign-off. Review where evidence was missing and fix the method.
Phase 4, roll out (months 5 to 9): apply to every high-risk system, connect release gates to test reports, and route post-market monitoring outputs into the registers.
Phase 5, assure (before the application date): internal audit against Article 9 and Annex IV point 5, a mock conformity assessment, and a gap list tracked to closure.

Rollback: if a release fails its thresholds or a new risk is found after release, the plan should define who can stop distribution, revert to the last conforming version and notify deployers, and how the corrective action under Article 20 is recorded.

Detection and measurement

Monitor the inputs that should reopen the register: drift in input data, changes in subgroup performance, deployer complaints, human overrides, security events on data and model assets, and incidents. Useful measures:

Register currency: percentage of high-risk systems whose register was reviewed within the defined cycle.
Threshold discipline: percentage of test reports whose thresholds are dated before the results.
Design-first ratio: share of high and medium risks mitigated by a design measure rather than by deployer information alone.
Field feedback latency: median days from a post-market monitoring finding to a register update.
Open residual risks: number of residual risks above acceptance criteria without a signed decision.
Release gate bypasses: releases shipped without a current test report (target zero).

Framework mapping

Article 9 element	NIST CSF 2.0	NIST SP 800-53 Rev. 5	Other
Risk management system and criteria, 9(1) and 9(5)	GV.RM-01, GV.RM-02, GV.RM-06	PM-9, RA-3	ISO/IEC 23894:2023; ISO/IEC 42001 risk clauses; prEN 18228 (draft)
Risk identification and evaluation, 9(2)(a) and (b)	ID.RA-04, ID.RA-05	RA-3	NIST AI RMF Map and Measure
Post-market feedback, 9(2)(c)	ID.IM-01	RA-3	AI Act Article 72
Design-first measures, 9(5)(a)	GV.RM-01	SA-8	NIST AI RMF Manage
Testing, 9(6) to 9(8)	ID.IM-01	SA-11	Annex IV points 2(g) and 4
Supply chain and pipeline risks	GV.RM-01	PM-30, RA-3(1)	MITRE ATLAS AML.T0010, AML.T0020

Common failure patterns

The release-day register: a risk assessment written for the conformity file and never reopened, which fails the "continuous iterative" test in 9(2).
Warnings instead of fixes: residual risks handed to deployers through the instructions for use when a design change was feasible, reversing the 9(5) order.
Thresholds set after the results: pass marks that move to fit the model, which 9(8) rules out by requiring prior defined metrics.
Safety only, no rights: registers built from product safety templates that never ask about discrimination, privacy or access to services.
No misuse analysis: only intended use is assessed, leaving out the reasonably foreseeable misuse that 9(2)(b) names.
Pipeline access ignored: poisoning and tampering risks scored without looking at who and what can write to data, models and pipelines.

Practitioner checklist

Write the intended purpose and exclusions for each high-risk system before any risk work.
Approve risk acceptance criteria for health, safety and fundamental rights harms inside the QMS.
Build a register that covers intended use, foreseeable misuse and malicious misuse.
Record for each risk why a design measure was or was not feasible.
Fix metrics and probabilistic thresholds, dated and approved, before each test cycle.
Assess effects on persons under 18 and other vulnerable groups, and record the conclusion.
Sign off residual risk per hazard and overall, and carry deployer-relevant residual risks into the instructions for use.
Route post-market monitoring findings into the register with a defined latency target.
List the service accounts and tokens that can change data, models and pipelines, and treat them as hazards.
Track prEN 18228 and adopt it once its reference is published in the Official Journal.

Standards and references

Related NHI Mgmt Group resources: EU AI Act High-Risk AI Systems Guide · EU AI Act Article 10 Data and Data Governance Guide · AI Risk Assessment Guide · EU AI Act Fundamental Rights Impact Assessment. This guide summarises Article 9 of the EU AI Act and is not legal advice.

EU AI Act Article 9 Risk Management System Guide: Paragraph by Paragraph, Testing and Evidence