Art. 9 EU AI Act: the risk management system for high-risk AI

Updated: June 2026

This is an explicit providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name — carrying manufacturer-style duties: design controls, documentation, conformity.Open full entry → obligation under the EU AI Act. It falls on whoever develops or places the high-riskriskIn the EU AI Act's terms, the combination of the probability that a harm occurs and the severity of it if it does. The link between a principle (via the harm that would breach it) and a control (the measure that reduces it). Naming the harm and assessing its risk is required by Art. 9 before any mitigation measure is chosen. See harm, control, residual risk.Open full entry → AI systemAI systemA machine-based system that, for explicit or implicit objectives, infers from input how to generate outputs — predictions, content, recommendations or decisions — that can influence physical or virtual environments. The OECD-style definition followed by the EU AI Act.Open full entry → on the market. Deployers meet a related but lighter set of duties under Art. 26.

Introduction: the obligation that holds the others together

Art. 9 is the first of the technical requirements the EU AI Act places on providers of high-risk AI systems, and it is deliberately first. The risk management system is the framework into which the other obligations fit: the data governancegovernanceThe system through which an organization steers itself: corporate governance, risk management, compliance, lines of accountability, risk appetite, and the operating model. It exists across everything the organization does, before and beyond AI. AI governance is this same system extended for AI. See AI governance, governance design, execution level.Open full entry → of Art. 10, the technical documentationtechnical documentationRecords a provider must compile and keep for a high-risk AI system to demonstrate conformity, covering its design, data, testing, risk management and monitoring.Open full entry → of Art. 11, the logging of Art. 12, the transparencytransparencyOpenness about the fact that AI is used and how it operates in general: disclosures, documentation, notices. Pairs with explainability, which addresses individual outcomes.Open full entry → of Art. 13, the human oversighthuman oversightDesigned-in human ability to monitor, intervene in, override or shut down an AI system — meaningful only when the human has authority, information and time to act.Open full entry → of Art. 14, and the accuracy and robustnessrobustnessA system's ability to perform reliably under realistic conditions including noise, edge cases and adversarial pressure — the engineering core of the safety-and-reliability principle.Open full entry → of Art. 15 are all, in part, risk mitigation measures that the Art. 9 system identifies, justifies, and tracks.

The defining feature of Art. 9 is that it is continuous. The article uses the word "iterative" and requires the process to run "throughout the entire lifecycle" of the system. A provider who conducts a single risk assessment before launch, files it, and never revisits it has not satisfied Art. 9, regardless of how thorough that assessment was. The obligation is to operate a living system, not to produce a document.

What the risk management system must do

Art. 9 sets out a cycle with four recurring steps:

1. Identify and analyse the known and reasonably foreseeable risks the system can pose to health, safety, and fundamental rights when used for its intended purpose.
2. Estimate and evaluate the risks that may emerge when the system is used as intended and under conditions of reasonably foreseeable misuse.
3. Evaluate other risks that arise from the analysis of post-market monitoringpost-market monitoringProvider-side duty to systematically collect and act on experience from systems in use — the product-regulation half of continuous monitoring.Open full entry → data (the feedback loopfeedback loopA dynamic where a system's own outputs influence its future training data, amplifying initial patterns — e.g. investigating only flagged claims, then learning from those investigations.Open full entry → from Art. 72).
4. Adopt appropriate and targeted risk management measures to address the identified risks.

The measures must reduce each risk so far as is technically feasible, through the design and build of the system itself, through mitigation and controlcontrolThe concrete, testable measure that reduces a specific risk, and through that risk protects the principle behind it. Also called a risk management measure, risk response, or risk treatment. Always traceable to the risk it addresses: under EU AI Act Art. 9 every control must map back to a specific risk, and controls recorded separately from their risks is a recognized compliance failure. It works in one of three types: preventive, detective, or corrective. See risk, control types, evidence.Open full entry → measures where the risk cannot be eliminated, and through the information and training provided to deployers. Residual risks that remain after mitigation must be judged acceptable and communicated to the deployerdeployerAn organization using an AI system under its own authority in its activities — carrying operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry →.

The relationship to the other technical articles

Art. 9 does not operate in isolation. It is the orchestrating process, and the other articles are where its measures are implemented:

• A data quality risk identified under Art. 9 is mitigated through the Art. 10 data governance measures.
• A risk of insufficient traceability is mitigated through the Art. 12 logging capability.
• A risk that a deployer misunderstands the system is mitigated through the Art. 13 instructions for use.
• A risk that the system acts without meaningful human control is mitigated through the Art. 14 human oversight design.
• A risk of inaccurate or non-robust performance is mitigated through the Art. 15 measures.

This is why Art. 9 is the backbone: a finding in the risk management system flows out into a concrete measure in one of the other articles, and the evidenceevidenceThe concrete proof that a control is designed, implemented, and working: a test report, an audit trail, an impact assessment, a monitoring log. Each link in the governance chain produces an artifact, and together they are what an organization hands to its own board, a regulator, a customer, or an affected person to show, not say, that a system is governed. Its absence is itself the failure: a risk register without test results, or a mitigation claimed without validation, is a governance gap, not a paperwork one. The closing link of the governance chain. See control, governance.Open full entry → that the measure works flows back in through testing and monitoring.

Why it matters

For a provider, the risk management system is the document a conformity assessmentconformity assessmentThe pre-market process demonstrating a high-risk AI system meets the EU AI Act's requirements, leading to CE marking and registration.Open full entry → examines first, because it demonstrates whether the provider's compliance is systematic or improvised. A coherent Art. 9 system, with each identified risk traced to a mitigation measure and a piece of evidence, signals a system under control. A pile of separate assessments with no connecting process signals the opposite.

For a deployer, Art. 9 matters indirectly but materially: the residual risks the provider judged acceptable, and the conditions under which the system is safe to use, are communicated through the instructions for use. A deployer who operates the system outside those conditions inherits the risk that the provider's Art. 9 system explicitly excluded.

Governing the risk management system

The practical challenge is keeping the system alive after launch, when the pressure to move on to the next release is strongest. The controls below treat the risk management system as a process with a heartbeat, not a deliverable with a deadline.

The core artefact is a risk registerrisk registerThe living record of an AI system's identified risks, ratings, responses, owners and review dates — kept current from design through retirement.Open full entry → that, for each identified risk, records the description, the affected rights or safety dimension, the severity and likelihood, the mitigation measure, the article under which that measure sits, the evidence that the measure works, and the residual riskresidual riskThe risk that remains after controls have reduced it. No control reduces a risk to zero, and not every control is worth its cost, so a deliberate judgment is made: whether the cost of further control is justified by the reduction it would buy, and whether the remaining risk is acceptable against the organization's risk appetite. This is a design-level judgment, where execution reports back up and governance accepts the residual risk, calls for more control, or declines the use case. EU AI Act Art. 9(5) requires it to be judged acceptable per hazard and overall. See risk, control, risk appetite.Open full entry → after mitigation. This register is updated on a defined cadence and on trigger events: a system change, a new intended use, a post-market monitoring signal, or a serious incidentserious incidentAn AI incident causing (or nearly causing) death, serious harm to health, property, fundamental rights or infrastructure — triggering regulatory reporting duties for high-risk systems.Open full entry →.

The feedback loop is what makes the system iterative. Post-market monitoring data under Art. 72 and serious incident reports under Art. 73 feed back into the register, where they either confirm that a risk was correctly judged or reveal that it was underestimated. Each incident closes with the register updated so the next iteration of the system carries the lesson forward.

Compliance checklist

1. Is there a documented risk management system that covers the full lifecycle of each high-risk system, not a single pre-deployment assessment?
2. Does the risk register trace each identified risk to a specific mitigation measure and the article under which it sits?
3. Is there evidence that each mitigation measure was tested and works?
4. Are residual risks documented, judged acceptable, and communicated to deployers through the instructions for use?
5. Is the register updated on a defined cadence and on trigger events (system change, new use, monitoring signal, incident)?
6. Does post-market monitoring and incident data feed back into the register?