What risk management system does Article 9 require?

What makes the process continuous and iterative?

A continuous iterative process is one that does not end at release. It begins during design, is updated during development and testing, continues through deployment, and is revisited when post-market information, incidents, or changes to the system or its context emerge. Iteration means that each round of identification, evaluation and mitigation informs the next round, and that earlier conclusions are reopened when new evidence appears. A provider should record the cadence for review, the triggers for an out-of-cycle review, and the owner for each round. A single risk assessment produced before release, with no review mechanism, does not match the description in Article 9, even if it was thorough at the time it was written.

Which risks must be identified and analysed?

Article 9 requires identification and analysis of known and reasonably foreseeable risks to health, safety and fundamental rights that may be posed when the system is used in accordance with its intended purpose. The analysis must consider the intended purpose, the people affected, the deployment context, and the interaction between the system and human oversight. Risks that are purely speculative, without a plausible pathway, are not the focus, but risks that are foreseeable from the system's design, its data, or its operating environment must be included even where they have not yet occurred. The risk register should name each risk, its source, the affected people, and the evidence relied on, so that a reviewer can see why a risk was included or excluded.

For the broader regulatory framework, see High-risk requirements overview.

How are risks estimated and evaluated?

Estimation and evaluation require judging the severity and probability of each identified risk, under the intended purpose and under reasonably foreseeable misuse. Misuse in this context means use in a way that is not intended but can reasonably be foreseen, not deliberate abuse that no design could anticipate. The evaluation should be proportionate: a risk with severe consequences for affected people needs more rigorous analysis and stronger measures than a low-severity risk, even where probability is low. The provider should record the method used, the assumptions made, and the thresholds applied, and should distinguish between residual risk after measures and the original risk before measures. An evaluation that records only a label, without severity, probability and reasoning, cannot support the measures that follow.

What risk management measures are expected?

Risk management measures must be appropriate and targeted to the risks identified, and must be designed to eliminate or reduce risks as far as technically feasible, including through design and development, and to address residual risks that cannot be eliminated. Measures can include design changes, data controls, testing, human oversight design, deployer information, and post-market monitoring, depending on the risk. Each measure should have an owner, a timetable, and a check that it worked. Where a risk cannot be eliminated, the provider should consider whether the residual risk is acceptable in light of the intended purpose, record that judgement, and ensure that the deployer is given the information needed to manage the residual risk in operation. A measure that is recorded but never implemented, or implemented but never checked, does not meet the article.

How does testing fit into Article 9?

Article 9 requires that the risk management system include testing, where appropriate, against predefined metrics and thresholds, and that testing procedures be suitable for the intended purpose. Testing should be planned before the system is relied on, with metrics and thresholds set in advance, so that results are judged against a standard rather than fitted to the outcome. The testing record should include the procedures used, the data and conditions, the results, and the decisions taken where a threshold was not met. Testing should be repeated when the system, its data, or its deployment context changes in a way that could affect risk. Article 9 also requires explicit consideration of whether access by certain vulnerable groups, including children, creates additional risk, and the testing and measures should reflect that consideration where relevant.

Continue with Testing and validation for high-risk systems.

What does this guide not decide?

This guide does not decide whether a particular risk management system meets Article 9, what level of residual risk is acceptable for a specific system, or whether a testing threshold is appropriate. It does not set a risk method, a metric, or a threshold for any system. Those questions depend on the system's intended purpose, the people affected, the evidence available, and the consolidated legal text as applied to that system. A provider should have its risk management file reviewed by a competent authority or legal adviser where the risk picture is contested, keep the file live through the lifecycle, and record every material change and review.

Frequently asked questions

Continue through this AI Act cluster

• High-risk requirements overview
• Testing and validation for high-risk systems
• Evidence chains for high-risk requirements
• High-risk AI systems
• Provider responsibilities
• What data and data governance does Article 10 require?