What Art. 9 Requires
Art. 9 AI Act obliges providers of high-risk AI systems to establish, implement, document and maintain a risk management system (Art. 9(1)). The wording in paragraph 2 is decisive: this is not a one-off assessment carried out before placing the system on the market, but a „continuous iterative process“ that is planned, carried out and regularly updated throughout the entire lifecycle of the system. Anyone who treats risk management as a project-closure document, drafted once and then filed away, misses the core of the provision.
The Process in Four Steps
Art. 9(2) sets out four interlinked steps:
- Identification and analysis of known and reasonably foreseeable risks to health, safety or fundamental rights under intended use (point a).
- Estimation and evaluation of risks arising from intended use and from reasonably foreseeable misuse (point b). This includes misuse scenarios that fall outside the intended purpose.
- Evaluation of other possible risks based on data from the post-market monitoring system under Art. 72 (point c). Risk management is thus explicitly linked back to market surveillance after placing on the market.
- Adoption of suitable, targeted measures to address the risks identified under point a (point d).
The limitation in paragraph 3 matters: only risks that can be reasonably mitigated or eliminated through development, design or sufficient technical information are captured. Art. 9 is not a general liability-expansion mechanism — it is tied to what can actually be designed into the system.
Residual Risk, Interactions and Testing
Paragraph 4 requires that interactions between the various requirements of this section (such as data quality, technical documentation, human oversight) be taken into account when choosing measures — risk management is not an isolated module but must be considered together with the other high-risk obligations.
Paragraph 5 sets the target: both the residual risk associated with each hazard and the overall residual risk must be judged acceptable. The order of measures is prescribed: first, elimination or reduction through design and development; then, mitigation and control measures for unavoidable residual risks; finally, information and training for deployers under Art. 13. The realistically expected knowledge and experience of deployers, as well as the likely context of use, must be taken into account — a blanket assumption that „the deployer will use it properly“ does not hold up.
Paragraphs 6 to 8 require testing against predefined metrics and probabilistic thresholds appropriate to the intended purpose, carried out throughout development and, in any event, before placing on the market or putting into service. Testing in real-world conditions under Art. 60 can form part of these testing procedures.
Paragraph 9 additionally requires a specific assessment of whether the system is likely to have an adverse impact on minors or other vulnerable groups — a dedicated check that is often missing from generic risk analyses.
Typical Gaps in Practice
Three recurring patterns stand out. First, risk management is treated as a static document rather than an iterative process with defined update cycles. Second, feedback from post-market monitoring under Art. 72 is missing — risk analyses rely solely on assumptions made during development, not on actual usage data. Third, foreseeable misuse under point b is neglected: only intended use is analysed, not foreseeable deviation from it. Providers who have already built processes under Art. 10 (data), Art. 11 (documentation) or Art. 15 (accuracy, robustness) should check whether these processes actually capture the interactions required under paragraph 4 — duplication of effort or gaps at the interfaces are common.
Paragraph 10 allows existing internal risk management processes under other Union law to be used or combined with the Art. 9 requirements. For organisations with established risk management systems (for example from product safety or financial regulation), this can save effort — provided the combination is documented and covers all paragraphs of Art. 9.
Where This Fits in the Timeline
For high-risk AI systems under Annex III, the deadline for these obligations is now 2 December 2027 — pushed back from the original 2 August 2026. For high-risk systems covered by Annex I product legislation, 2 August 2028 applies. That leaves time to build the risk management system required under Art. 9 — but the postponement is no reason to delay, since an iterative process with testing phases cannot be put together at short notice.
Whether your system falls under the high-risk categories at all, and which deadlines apply in practice, can be clarified with the free risk-check at /einstufung.