Module 2 — The Risk Management System (Art. 9)

Module 2 of the AI Act Provider certification: Art. 9 as a continuous iterative process — identification, estimation, evaluation, mitigation, residual risk, testing, and the vulnerable-groups question.

Article 9 is the spine of Chapter III. Every other requirement either feeds it or is justified by it: data governance addresses risks you identified, the technical documentation records them, human oversight mitigates them, and post-market monitoring watches for the ones you missed.

It is also the requirement most often satisfied on paper and not in fact, because the artefact — a risk assessment — looks the same whether or not a process produced it.

What Art. 9 actually establishes

Art. 9(1) requires a risk management system to be established, implemented, documented and maintained in relation to high-risk AI systems.

Art. 9(2) defines it as a continuous iterative process planned and run throughout the entire lifecycle, requiring regular systematic review and updating, and comprising four steps:

1. Identification and analysis of the known and the reasonably foreseeable risks the system can pose to health, safety or fundamental rights when used in accordance with its intended purpose.
2. 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.
3. Evaluation of other risks possibly arising, based on the analysis of data gathered from the post-market monitoring system.
4. Adoption of appropriate and targeted risk management measures designed to address the risks identified.

Read step 3 again. The risk management system takes an input from post-market monitoring, which does not exist until the system is on the market. That is what makes Art. 9 unclosable: it is a loop, and Art. 72 is the return path.

Reasonably foreseeable misuse

Art. 3 defines misuse as use of an AI system in a way that is not in accordance with its intended purpose, but which may result from reasonably foreseeable human behaviour or interaction with other systems.

This is where most risk assessments are thin. The intended-purpose analysis is usually competent because it mirrors the product specification. The misuse analysis requires imagining users behaving as users do:

• A screening tool built to rank candidates, used to reject them automatically because the volume made review impractical.
• A summarisation system built for internal briefings, used to generate customer-facing text.
• A triage model built as decision support, used as a decision because the humans learned to trust it.
• A system evaluated on one population, deployed on another because a new market opened.

Note that most of these are also the deployer's Art. 26(1) failure. That does not discharge you: reasonably foreseeable misuse is a provider obligation precisely because the provider is better placed to anticipate it and to design against it.

Measures, in the order the Regulation puts them

Art. 9(5) sets an order, and it is not a menu:

1. Eliminate or reduce risks as far as technically feasible through adequate design and development of the system.
2. Where appropriate, implement adequate mitigation and control measures for risks that cannot be eliminated.
3. Provide information required under Art. 13 and, where appropriate, training to deployers.

Design first. A risk that could have been engineered out but was instead pushed into the instructions for use has not been managed in the way Art. 9 contemplates. This is the provision behind a common review finding: a control that exists only as a warning in the documentation.

The third step is also the bridge to the deployer track. Your Art. 13 instructions are a risk control, not marketing collateral. When a deployer's oversight fails because your instructions did not explain what the system cannot do, that is an Art. 9 and Art. 13 defect in your product.

Residual risk, and judging it

Art. 9(5) requires that residual risks — those remaining after measures — be judged acceptable. The Regulation does not tell you what acceptable means, which is deliberate and unhelpful in equal measure.

What survives review is a residual risk statement that: names the risk, states what was done, states what remains, states who judged it acceptable and on what basis, and states the conditions under which that judgement would change. The last element is what connects it to post-market monitoring: if you cannot say what would make you revisit the judgement, you have not made one.

Testing (Art. 9(6)-(8))

High-risk systems must be tested to identify the most appropriate risk management measures, ensuring they perform consistently for their intended purpose and comply with the Chapter III requirements. Testing is against prior defined metrics and probabilistic thresholds appropriate to the intended purpose — so you must define the metric and the threshold before the test, not after seeing the results.

Testing may be carried out at any point during development and in any event before placing on the market or putting into service. Real-world testing outside a sandbox is governed separately by Art. 60 and its own conditions.

Vulnerable groups (Art. 9(9))

The risk management system must give consideration to whether the high-risk system is likely to have an adverse impact on persons under the age of 18 and, as appropriate, other vulnerable groups.

This is a specific, checkable requirement and it is frequently absent from otherwise competent assessments. If minors can be affected by your system — education, employment of young people, essential services, content systems — the assessment must say so and address it.

Interaction with existing risk management

Art. 9(10) recognises that providers already subject to internal risk management under other Union law may integrate these requirements into, or combine them with, those existing procedures.

That is permission to extend a working system, not to point at one. A financial entity's operational risk framework can host the AI Act risk management system, provided the four steps, the misuse analysis, the testing regime and the vulnerable-groups consideration are genuinely present and traceable within it.

What the file looks like

Per system: the risk register with intended-purpose and misuse branches; the measures against each risk, marked design / mitigation / information; the test plan with metrics and thresholds defined in advance, and the results; the residual risk statement with its named owner and revisit conditions; the vulnerable-groups consideration; and a review log with dates showing the loop turning.

That review log is the artefact that distinguishes a process from a document. Without dated iterations, Art. 9(2) is unevidenced regardless of how good the assessment is.

Check yourself

1. Our risk assessment is thorough and was signed off before launch. — Art. 9(2) requires a continuous iterative process with regular systematic review. One assessment, however good, is not a risk management system.
2. Users are misusing the system contrary to our documentation. — Reasonably foreseeable misuse is squarely within Art. 9(2)(b), and the deployer's breach does not discharge your obligation to have anticipated it.
3. We addressed the risk with a warning in the instructions for use. — Art. 9(5) puts design first. Information to deployers is the third step, not the first.
4. Where does post-market data enter the risk management system? — At step three of Art. 9(2), which is why the process cannot be closed out at launch.

Previous: Module 1 — Are you a provider, and by which route? Next: Module 3 — Data and data governance (Art. 10) →