Risk Management System Requirements for High-Risk AI (Article 9)

10 min read · updated August 11, 2026

Article 9 is the first substantive obligation on a high-risk system and it is the one everything else hangs from. Read closely it is more prescriptive than its reputation: it specifies the steps, the order of mitigations, and the point at which testing must have happened.

What Article 9 actually obliges

Article 9(1) of Regulation (EU) 2024/1689 requires that a risk management system be established, implemented, documented and maintained in relation to high-risk AI systems. Four verbs, and “documented” is the one that determines what an auditor sees. Article 9(2) then describes it as a continuous iterative process planned and run throughout the entire lifecycle of the system, requiring regular systematic review and updating.

The obligation is on the provider. A one-off assessment signed before release does not satisfy it, because the article says lifecycle and says review and updating. Nor does an undocumented process, however diligent, because the evidence is the deliverable.

Not legal advice. Whether a given system is high-risk at all is decided by Article 6 and Annexes I and III, and that classification question is logically prior to everything on this page. Get it advised before building a compliance programme on either answer.

The four steps of the process

Article 9(2) lists them, and the distinctions between them are not rhetorical.

(a) Identification and analysis of the known and reasonably foreseeable risks the system can pose to health, safety or fundamental rights when used in accordance with its intended purpose. Fundamental rights sit alongside health and safety as a first-class risk category, which is what distinguishes this from a conventional product safety analysis.
(b) Estimation and evaluation of the risks that may emerge when the system is used in accordance with its intended purpose and under conditions of reasonably foreseeable misuse. Article 3(13) defines reasonably foreseeable misuse as use in a way not in accordance with the intended purpose but which may result from reasonably foreseeable human behaviour or interaction with other systems.
(c) Evaluation of other risks possibly arising, based on the analysis of data gathered from the post-market monitoring system under Article 72. This is the step that makes the process a loop rather than a line, and it is why the post-market monitoring plan is an input to risk management rather than a separate exercise.
(d) Adoption of appropriate and targeted risk management measures designed to address the risks identified under (a).

Article 9(3) sets a boundary that is easy to miss and useful to have in writing: the risks referred to are only those which may be reasonably mitigated or eliminated through the development or design of the system, or through the provision of adequate technical information. Risks arising purely from how a deployer chooses to use the system, and which no design change or instruction could address, are not the provider’s to eliminate under Article 9 — they belong to the deployer’s obligations in Article 26.

The mitigation hierarchy

Article 9(4) is the most operationally specific paragraph in the article and the one most often reduced to “take appropriate measures”. It requires that in identifying the most appropriate risk management measures, the following is ensured, in this order:

Elimination or reduction of identified and evaluated risks as far as technically feasible through adequate design and development of the system.
Mitigation and control measures where appropriate, addressing risks that cannot be eliminated.
Information and training — provision of the information required under Article 13 and, where appropriate, training to deployers.

This is a familiar structure from product safety law and it has a real consequence: warning the deployer is the last resort, not the first. A risk file whose mitigation for a known failure mode is a line in the instructions for use has to be able to show that design mitigation was not technically feasible. Documenting the rejected design options is therefore part of the evidence, not an optional extra.

Article 9(4) also requires that residual risk — for each individual hazard and overall — be judged acceptable, and that measures give due consideration to the effects and possible interaction resulting from the combined application of the Section 2 requirements, taking into account the generally acknowledged state of the art. Article 9(5) adds that risk elimination or reduction must take due account of the technical knowledge, experience, education and training to be expected of the deployer and the presumable context of use.

Testing, metrics and thresholds

Article 9(6) requires that high-risk systems be tested for the purpose of identifying the most appropriate and targeted risk management measures — testing is an input to the risk decision, not a final check. Article 9(7) then sets two conditions: testing may be performed at any point during development but in any event before placing on the market or putting into service, and it must be done against prior defined metrics and probabilistic thresholds appropriate to the intended purpose.

“Prior defined” is the demanding word. A threshold chosen after seeing the results does not satisfy it, and a file whose only evidence is a final evaluation report cannot demonstrate that it did. The practical implication is that the acceptance criteria have to be written down, dated, and retained before the run that tests against them.

Article 9(8) adds a specific consideration: providers must give consideration to whether, in view of its intended purpose, the system is likely to have an adverse impact on persons under the age of 18 and, as appropriate, on other vulnerable groups. That is a required section in the file, not a general sentiment.

What the risk file has to contain

Assembling the paragraphs above, a file capable of being shown to a notified body or a market surveillance authority contains at minimum:

A statement of intended purpose, and of reasonably foreseeable misuse, each specific enough to bound the analysis.
A hazard register covering health, safety and fundamental rights, with the analysis under 9(2)(a) and the estimation under 9(2)(b).
An explicit assessment of impact on persons under 18 and other vulnerable groups, per 9(8).
For each hazard, the mitigation decision traced through the 9(4) hierarchy, including why design elimination was or was not technically feasible.
Predefined metrics and probabilistic thresholds, dated before the corresponding test runs, with the test logs and reports — Annex IV point 2(g) requires those dated and signed by the responsible persons.
A residual risk judgment per hazard and overall, with the reasoning for acceptability.
The feed from post-market monitoring under Article 72, and the record of review and update cycles.

Annex IV point 5 requires a detailed description of the risk management system in the technical documentation, so this file is not free-standing — it is a component of the Article 11 pack. See what Annex IV requires. Article 9(9) allows providers already subject to internal risk management requirements under other Union law to combine these aspects with those procedures, which matters for regulated financial firms in particular.

When this applies

These dates were amended in 2026 and the original ones are still circulating, so both are given here. As adopted, Article 113 set the general application date of the Regulation at 2 August 2026, with Article 6(1) and its corresponding obligations from 2 August 2027 for systems that are safety components of products covered by the Annex I harmonisation legislation.

Those two dates have moved. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It postpones the application of the high-risk obligations — Article 9 among them — from 2 August 2026 to 2 December 2027 for stand-alone high-risk systems under Annex III, and from 2 August 2027 to 2 August 2028 for high-risk systems embedded in products regulated under Annex I. The transparency obligations were not postponed and applied from 2 August 2026.

So a provider of an Annex III system that planned against 2 August 2026 now has until 2 December 2027, and this is the first substantive amendment to the AI Act since its adoption in June 2024. Article 111 separately adds transitional rules, including a later deadline for high-risk systems intended to be used by public authorities that were already placed on the market.

Regulation (EU) 2026/1744 is in force, not a proposal, and it changed more than the dates given above — this page states only the timing changes and does not attempt to describe any amendment it made to the substance of the obligations. Read the amended Article 9 and Article 113 in the consolidated text of the AI Act on EUR-Lex rather than relying on any account of Article 9 written before 24 July 2026, this one included. A postponed deadline is also not a reduced one: nothing in the amendment relieves a provider who places a high-risk system on the market of the Article 9 obligations, and the evidence Article 9(7) requires — predefined metrics and thresholds recorded before the test runs — is the part that cannot be produced retrospectively when the date arrives.

The related quality management obligation, which is where this process gets its organisational home, is Article 17, and the data side is Article 10.