Risk Management System: AI Act Definition
A risk management system under EU AI Act Article 9 is the continuous process to identify, estimate, evaluate and mitigate high-risk AI risk. Definition inside.
A risk management system under the EU AI Act is a continuous, iterative process — not a document — that the provider of a high-risk AI system must establish, implement, document and maintain across the system's entire lifecycle to identify, estimate, evaluate and mitigate the reasonably foreseeable risks it poses to health, safety and fundamental rights (Article 9(1) to (2), Regulation (EU) 2024/1689).
The protected interests are fixed by statute: health, safety and fundamental rights. The obligation sits on the provider, not the deployer, and it attaches only to systems classified as high-risk AI systems under Article 6 and Annex III. This entry defines the term and the iterative loop; for the full statutory walk-through see Article 9 of the EU AI Act.
The iterative loop: identify, estimate, evaluate, mitigate
The four steps under Article 9(2)
Article 9(2) sets out the recurring steps the system must run:
- (a) identify and analyse the known and the reasonably foreseeable risks the system can pose to health, safety or fundamental rights;
- (b) estimate and evaluate the risks that may emerge when the system is used in accordance with its intended purpose, and under conditions of reasonably foreseeable misuse;
- (c) evaluate other risks possibly arising from the analysis of post-market monitoring data gathered under Article 72;
- (d) adopt appropriate and targeted risk-management measures designed to address the risks identified.
Reasonably foreseeable misuse is an explicit input, not an afterthought — you cannot scope the analysis to intended purpose alone.
Why it is continuous, not one-off
The loop runs across the whole lifecycle — design, development, deployment and post-market — and is systematically reviewed and updated (Article 9(2)). Field data and monitoring evidence feed back in, so the system never "finishes". Each Article 9(2) step has a trigger and produces a working artefact:
| Article 9(2) step | Trigger | Output artefact |
|---|---|---|
| (a) Identify and analyse risks | New system, design change, new use context | Risk register / hazard log |
| (b) Estimate and evaluate (intended use + foreseeable misuse) | Risk identified | Scored risk assessment |
| (c) Evaluate post-market data | Article 72 monitoring signal | Updated risk evaluation |
| (d) Adopt risk-management measures | Unacceptable residual risk | Design changes, controls, user instructions |
Residual-risk acceptability and the role of testing
Judging residual risk
Mitigation measures must be such that the relevant residual risk for each identified hazard, and the overall residual risk of the system, are judged acceptable (Article 9(5)). Residual risk is what remains after measures have been applied.
Article 9(5) prescribes a hierarchy of measures, in order:
- eliminate or reduce risks by design as far as technically feasible;
- where a risk cannot be eliminated, apply adequate mitigation and control measures;
- provide information and, where appropriate, training to deployers.
You work down this hierarchy; you do not jump to user instructions for a hazard that could have been designed out.
Testing to verify measures work
Testing is the verification mechanism. High-risk systems are tested to identify the most appropriate and targeted risk-management measures, and to ensure the system performs consistently for its intended purpose against previously defined metrics and probabilistic thresholds (Article 9(6) to (8)). The performance criteria the testing checks against come from accuracy, robustness and cybersecurity (Article 15).
One specific duty: when implementing the risk management system, the provider must give consideration to whether the high-risk AI system is likely to adversely impact persons under 18 or, as appropriate, other vulnerable groups (Article 9(9)).
How it differs from the QMS and the FRIA
Risk management system vs quality management system
The risk management system is one named component inside a broader framework. The provider must put in place a quality management system under Article 17, and Article 17(1)(g) explicitly lists the Article 9 risk management system as part of it. Treat the quality management system as the overarching governance umbrella — documentation, change control, accountability — and the risk management system as the specific, continuous risk loop operating inside it.
Risk management system vs the FRIA
The fundamental rights impact assessment (FRIA) under Article 27 is a separate obligation, owned by certain deployers of high-risk systems, not by the provider. It assesses the fundamental-rights effects of deploying a system in a given context, before use. Different owner, different question, different trigger.
| Instrument | Legal basis | Who | What it is |
|---|---|---|---|
| Risk management system | Article 9 | Provider | Continuous lifecycle risk process |
| Quality management system | Article 17 | Provider | Overarching governance umbrella |
| FRIA | Article 27 | Certain deployers | Fundamental-rights assessment before deployment |
Keeping these three apart is what stops a compliance programme from duplicating effort or leaving a gap.
How Confir helps
Confir structures the Article 9 loop so the four steps, the residual-risk hierarchy and the Article 17 linkage are tracked as one connected workflow rather than scattered documents. Its rule-based, deterministic engine maps each identified risk to its mitigation measures and surfaces where post-market data should re-open an assessment — the same logic every time, no model inference, no hallucination. Because the reasoning is reproducible, the output suits the evidentiary demands of Article 9: you can show authorities the documented basis for every residual-risk judgement and re-run it when the system changes.
Frequently asked questions
What is a risk management system under the EU AI Act?
It is a continuous, iterative process that the provider of a high-risk AI system must establish, implement, document and maintain across the system's entire lifecycle. Under Article 9 of Regulation (EU) 2024/1689, it identifies, estimates, evaluates and mitigates the reasonably foreseeable risks the system poses to health, safety and fundamental rights. It is a living process rather than a one-off document, reviewed and updated systematically as the system and its monitoring data evolve.
Is the risk management system the same as the quality management system?
No. The risk management system under Article 9 is one named component inside the broader quality management system that the provider must put in place under Article 17. Article 17(1)(g) explicitly lists the Article 9 process as part of the quality management system. Think of the quality management system as the overarching governance umbrella covering documentation, change control and accountability, while the risk management system is the specific, continuous risk loop operating within it.
What does 'residual risk' mean in Article 9?
Residual risk is the risk that remains after mitigation measures have been applied. Article 9(5) requires that, for each identified hazard and for the system overall, this remaining risk be judged acceptable. Providers work through a hierarchy: eliminate or reduce risks by design where feasible, apply control measures for risks that cannot be removed, and supply information and training to deployers. Testing under Article 9(6) to (8) verifies the chosen measures actually achieve an acceptable level.
How is the risk management system different from a FRIA?
They have different owners and purposes. The risk management system (Article 9) is a provider obligation: a continuous, lifecycle-wide process covering health, safety and fundamental-rights risks of a high-risk system. The fundamental rights impact assessment, or FRIA (Article 27), is a separate obligation on certain deployers, focused specifically on the fundamental-rights effects of deploying that system in a given context. One is run by the provider across the lifecycle; the other is run by the deployer before use.
Who has to maintain a risk management system?
The provider of a high-risk AI system — a system classified as high-risk under Article 6 and the categories in Annex III. The obligation sits with whoever places the system on the market or puts it into service under their own name or trademark. Note that under Article 25 a deployer, distributor or importer can become a provider (for example by substantially modifying a system or rebranding it), at which point the Article 9 risk management obligation transfers to them.
Related terms
- Article 9 of the EU AI Act — the full statutory mechanics of the risk management system.
- quality management system — the Article 17 governance umbrella the Article 9 process sits inside.
- high-risk AI system — the Article 6 and Annex III classification that triggers the obligation.
- accuracy, robustness and cybersecurity (Article 15) — the performance criteria that risk-management testing verifies.
- AI risk management — how the risk loop fits the wider compliance programme.
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 14-day free trial.
Start free trial →