EU AI Act
Article 9 — Risk management system
Article 9 requires a risk management system that runs continuously across the whole lifecycle of a high-risk AI system, not a document produced once before launch. The provider must identify, estimate and evaluate risks, and must record a judgement that the residual risk is acceptable. That judgement is the obligation most often missing.
§ 1 — Who it binds
Who it binds, and from when
Provider
Every high-risk AI system: under Article 6(2) because it appears in Annex III, or under Article 6(1) because it is a safety component of — or is itself — a product covered by the Union harmonisation legislation in Annex I, where that product must undergo third-party conformity assessment. Both Article 6(1) limbs must hold. The duty sits with the provider, but a deployer that puts its own name on a system, or substantially modifies it, becomes a provider under Article 25(1) and inherits it.
§ 2 — In practice
How the duty actually works
The word that does the work in Article 9 is continuous. The Act describes "a continuous iterative process planned and run throughout the entire lifecycle", which rules out the artefact most organisations actually hold: a risk assessment completed before launch and never reopened. A risk management system is a thing that runs. The evidence that it ran is not the register — it is the second entry in the register, and the third.
The provision people miss is Article 9(5), which requires a judgement that the residual risk is acceptable. That is a decision, not a rating. Ratings are produced by a methodology; decisions are made by a person who can be asked why. In practice this is the single most common gap an assessor finds, because a heat map shaded green looks like an acceptance until you ask whose acceptance it was and on what date.
Article 9 does not stand alone. Risks you identify here must be measured somewhere, and that somewhere is Article 15, which requires the levels of accuracy and the relevant accuracy metrics to be declared in the instructions for use; the robustness and cybersecurity levels the system was tested against reach those same instructions through Article 13(3)(b)(ii). A risk register naming "model degrades on under-represented groups" with no corresponding subgroup performance figure is an identified risk with no measurement behind it. Equally, field data gathered under post-market monitoring has to re-enter this process; monitoring that never changes a risk rating is running alongside the risk management system rather than inside it.
One timing point worth stating plainly, because it is widely misread in both directions: the Digital Omnibus — Regulation (EU) 2026/1744, in force 27 July 2026 — moved the high-risk dates without touching Article 9 itself. The Annex III standalone deadline moved to December 2027 and the Annex I embedded deadline to August 2028, as set out below. But "only the dates changed" is not a safe reading of the instrument as a whole: it amends some forty articles, narrowing what counts as a safety component under the new Article 6(1a) to (1c), deleting Article 10(5), and trimming the registration data required by Annex VIII. What Article 9 itself demands is a judgement rather than a threshold: it sets no number for acceptable residual risk, which is why the evidence below turns on who made the call and on what basis rather than on what score was reached. Our note on building an AI risk profile sets out one way to structure that.
§ 3 — When it applies
When it applies
2 December 2027
Annex III standalone high-risk systems. Moved from 2 August 2026 by the Digital Omnibus — a sixteen-month extension driven by undesignated national authorities and the absence of harmonised standards, not by any relaxation of the Section 2 requirements themselves.
2 August 2028
Annex I embedded high-risk systems — medical devices, machinery, vehicles — where AI Act requirements fold into the existing sectoral conformity assessment. Moved from 2 August 2027.
§ 4 — What discharges it
What the process must produce
The artefacts an assessor asks to see, and what makes each one sufficient rather than merely present.
01
A risk management plan tied to a named system and release
It should name the process owner and the review cadence, and be versioned against the system rather than against the organisation. A plan that cannot be tied to a specific system and a specific release is a corporate policy, and Article 9 does not ask for a policy.
02
A dated residual-risk acceptance decision
Article 9(5) requires a judgement that residual risk is acceptable. A judgement has an author and a date. A risk register with a column shaded green records a rating, not an acceptance, and cannot show who would answer for it.
03
Review records from more than one point in the lifecycle
The Act calls the process "continuous" and "iterative". Two or more review entries across releases, with risks that visibly changed status between them, is what distinguishes a process that ran from an assessment that happened.
04
Traceability from each significant risk to the test that measured it
Each identified risk should reach a mitigation and a test result. Testing that cannot be mapped back to a risk demonstrates diligence but not conformity, and mitigations with no test behind them are intentions.
05
Evidence that post-market data re-entered the process
Article 9 and Article 72 are one loop. Field data that never changes a risk rating is a monitoring function running in parallel to the risk management system rather than inside it — the two artefacts exist, and nothing connects them.
§ 5 — Worked example
Worked example
A bank licenses a credit-scoring model from a vendor and puts it into service under its own brand for consumer lending. It is high-risk under Annex III point 5(b). The vendor supplied validation evidence; the bank’s model risk committee signed the model off before launch. Fourteen months on, the bank has retrained it twice on its own book, both times recorded as routine maintenance.
Whose Article 9 duty is this, and has it been discharged?
The bank’s. Article 9 binds the provider, and under Article 25(1) a deployer that puts its own name on a high-risk system becomes the provider and takes the provider obligations with it — branding it did that on its own. Whether the retrainings did so independently is a separate question: a substantial modification under Article 3(23) is a change not foreseen in the provider’s conformity assessment, and recital 128 puts pre-determined continued learning outside that definition. The bank has never asked, which is itself a finding. The vendor’s file is evidence it may rely on, not a duty it has escaped. As to discharge: the pre-launch validation is an assessment rather than a process; the committee approved a model, which is not the act of accepting a residual risk; and recording retrainings as maintenance means nobody asked whether the risk picture moved when the model did. What is missing is not documentation but sequence.
§ 6 — What a weak answer looks like
What a weak answer looks like
The register mistaken for the system. A spreadsheet of severities and likelihoods is the smallest component of what Article 9 asks for, and it is routinely offered as the whole of it. What it cannot show is that anything was decided: no author against the acceptance, no date on it, and no line connecting a mitigation to a test that established the mitigation works. Organisations that fail here are rarely careless — they have done the thinking and kept no record capable of demonstrating it, which from the outside is indistinguishable from not having thought.
§ 7 — Exposure
Exposure
€15 million or 3% of worldwide annual turnover, whichever is higher
Article 99(4)(a), reached through Article 16(a): a provider must ensure its high-risk system meets the Chapter III Section 2 requirements, and Articles 9 to 15 sit in that section. Neither Article 9 nor Article 15 is itself enumerated in Article 99(4) — the exposure runs through Article 16. Under Article 99(6) an SME pays the lower of the two figures rather than the higher. The 7% ceiling in Article 99(3) applies only to the prohibited practices in Article 5.
§ 8 — Elsewhere
The same requirement elsewhere
Where another instrument addresses the same obligation. These are correspondences, not comparisons — the Council does not rank one framework against another.
ISO/IEC 42001 Clause 6.1 addresses risk as a management-system requirement, planned and reviewed at organisational level. Article 9 addresses it per system, across that system’s lifecycle. An organisation running a conformant AIMS will already hold much of the material Article 9 asks for.
A correspondence indicates that two instruments address the same underlying obligation. It is not a mapping endorsed by either body, not a statement that one satisfies the other, and not a judgement about which is more demanding.
§ 9 — provenance
The provision itself
This page sets out what the instrument requires and what discharges it. The official text is the authority — these go straight to it.
§ 10 — Also read
Also read
Article 27 — fundamental rights impact assessment
How to build an AI risk profile for a deployment
Certification
Assessed on the same standard of evidence
Every Council credential is examined on applied judgement against a published anchor, set out the way the obligations on this page are. The Certified Applied AI Associate, the Council’s flagship, is open to any adult today, its fee waived by a coupon code from the AI-Readiness Check, and the register lists what is open for enrolment.