Article 9 requires a continuous, iterative risk management system for high-risk AI across the whole lifecycle. In practice: identify risks to health, safety and fundamental rights, estimate them for intended use and foreseeable misuse, use post-market data to find more, then adopt measures until residual risk is acceptable. Test against defined metrics before release.
The four steps
- Identify and analyse known and reasonably foreseeable risks to health, safety or fundamental rights, given intended purpose and context.
- Estimate and evaluate risks from intended use and from reasonably foreseeable misuse, including misuse that comes from human behaviour or interaction with other systems.
- Evaluate further risks using data from post-market monitoring.
- Adopt targeted risk management measures.
Only risks that can reasonably be reduced or removed through design, development or adequate technical information are in scope.
Choosing measures
The order of preference in the article is: remove or reduce risk through design and development where technically feasible, mitigate what remains, and give information and training to deployers. Measures should be balanced so they work together. The residual risk of each hazard and the overall residual risk must be judged acceptable.
Providers should also consider likely adverse impacts on people under 18 and other vulnerable groups.
Testing
Systems must be tested against predefined metrics and probabilistic thresholds appropriate to the intended purpose, during development and before market placement. Write the thresholds before you see results. Otherwise they drift to whatever the model achieved.
A usable risk record
For each risk keep:
- Description and affected group.
- Cause: data, model, interface, misuse or interaction.
- Likelihood and severity rating with rationale.
- Control and owner.
- Residual risk and who accepted it.
- Test evidence.
- Review date and trigger.
Misuse is part of the job
Foreseeable misuse is explicitly included. If users can paste anything into the tool, someone will. If outputs are easy to over-trust, they will be. Threat model the human workflow, not only the model. Security failure modes, such as the attacks listed in Article 15, belong on the register too.
Keep it continuous
Treat the register as a living document linked to change management. A new data source, model version or customer use case should trigger a review. Post-market findings feed step three. See the posts on the quality management system and documentation and monitoring.
Providers already under other EU risk rules may combine the elements with those procedures.
For a small team, start with a one hour workshop per system: list who is affected, how it could go wrong, and what would tell you early. Capture the output in the register, assign owners, then schedule the first review. A rough register that is maintained beats a perfect one that is not.
Quick check
Is risk management a one time exercise?
No. The article calls it continuous and iterative, with regular review across the lifecycle.
Does it cover misuse?
Yes, reasonably foreseeable misuse must be estimated and evaluated.
Sources
- AI Act Article 9, risk management system (an unofficial reader; confirm wording against the Official Journal)
Last reviewed: 19 October 2026.