On 2 August 2026 the obligations for high-risk AI systems under Annex III become applicable. Of all the requirements in Chapter III, Art. 9 — the risk management system is the one most projects stumble on in practice. Not because it is exotic, but because it is continuous and has to be properly documented.
What Art. 9 requires
Art. 9(1) requires a risk management system to be “established, implemented, documented and maintained” — four verbs that together amount to considerably more than a document. Art. 9(2) turns this into a continuous iterative process across the entire lifecycle, requiring regular systematic review and updating. It has four core steps:
- Identify and analyse risks — the known and reasonably foreseeable risks the system can pose to health, safety or fundamental rights when used as intended.
- Estimate foreseeable misuse — explicitly including reasonably foreseeable misuse, not just the happy path.
- Evaluate field data — risks emerging from post-market monitoring. Art. 9 points to the system under Art. 72 AI Act for this.
- Adopt targeted measures to address the risks identified.
Art. 9(3) draws an important boundary: only risks that can be reasonably mitigated through development, design or the provision of adequate technical information are in scope. Art. 9 does not ask you to solve every conceivable harm — but it does cover everything within the provider’s control.
The hierarchy of measures
Less well known, but relevant in an audit: Art. 9(5) prescribes an order. The residual risk — both per hazard and overall — must be judged acceptable, and the route there is tiered:
- Eliminate or reduce through adequate design and development, as far as technically feasible.
- Appropriate mitigation and control measures for risks that cannot be eliminated.
- Information under Art. 13 AI Act and, where needed, training for deployers.
Skipping tier 1 and solving everything with a warning in the manual misses the hierarchy. The technical knowledge, experience and education that can be expected of the deployer must be taken into account — as must the context the system will be used in.
Testing is not optional
The part most often overlooked sits in Art. 9(6)–(8): high-risk systems must be tested in order to identify the appropriate measures at all. Specifically:
- at any appropriate point during development — and in any event before being placed on the market or put into service;
- against prior-defined metrics and probabilistic thresholds appropriate to the intended purpose;
- optionally as testing in real-world conditions under Art. 60 AI Act.
“Prior-defined” is the decisive phrase. An evaluation whose thresholds were set after the result is not evidence — it is a narrative.
Five gaps we keep seeing
1. The document without a process. A risk analysis exists as a PDF, but nobody updates it. Art. 9(2) explicitly requires regular systematic review. A frozen document does not discharge the duty.
2. Model risks only, no fundamental rights. Many analyses come out of the ML team and list accuracy, drift and robustness. But Art. 9(2) explicitly names fundamental rights too — discrimination, privacy intrusions, effects on affected persons.
3. Misuse is excluded. “That is not how the system is meant to be used” is not risk treatment. Reasonably foreseeable misuse belongs in the analysis.
4. Vulnerable groups are missing. Art. 9(9) requires providers to consider whether the system is likely to have an adverse impact on persons under 18 or other vulnerable groups. In education, hiring or credit contexts that is not a footnote.
5. No link to the other articles. Risk management does not stand alone: it feeds the technical documentation (Art. 11 AI Act, Annex IV), justifies the human oversight measures (Art. 14 AI Act) and sets the targets for accuracy and robustness (Art. 15 AI Act). Treat Art. 9 in isolation and you produce contradictions between documents — exactly what surfaces in an audit.
If you already run risk management
Art. 9(10) is the good news for regulated sectors: if you are already subject to internal risk management requirements under other Union law, the aspects of Art. 9 may form part of those procedures or be combined with them. For financial entities already working on DORA that means: no second, parallel system — but do evidence that the Art. 9 points are genuinely covered within it.
What this means before the deadline
For the time that remains, sequence is everything:
- Classify first. Only high-risk systems need Art. 9 in full depth. The free risk check settles that in under two minutes.
- Then name the gap honestly. Not “we have that”, but: is there a documented, recurring process with owners, dates and prior-defined test metrics?
- Then draw the cross-references. Risk management, technical documentation and oversight measures must tell the same story.
If you want to know how far your documents actually carry: KomplAI checks your documents and source code against the relevant rules and backs every citation against the official EUR-Lex texts — including an action plan. More in the obligations guide from August 2026 and the roadmap.