Art. 9: Risk management system under the EU AI Act
Art. 9 requires the provider of a high-risk AI system to establish, implement, document and maintain a risk management system. The system is a continuous iterative process across the entire lifecycle. It identifies and evaluates risks under the intended purpose and under foreseeable misuse, then adopts targeted measures. Art. 9(8) requires testing against prior defined metrics and probabilistic thresholds. In this mapping, six elements are testable, eleven are documentation and six are process. Regulation (EU) 2026/1744 moved the Annex III application dateDeferred and left the content of Art. 9 unchanged.
Art. 9(3) limits the scope to risks that design, development or adequate technical information can reasonably mitigate or eliminate. Art. 9(4) requires the measures to account for their interaction with the requirements of Art. 10 to Art. 15, and Art. 17(1)(g) places the whole system inside the quality management system under Art. 17.
What the text requires and how each element is verified
Requires
Testable
Documentation
Process
Art. 9(1)The provider establishes, implements, documents and maintains a risk management system in relation to the high-risk AI system.
Art. 9(2)The risk management system is a continuous iterative process. The provider plans and runs it through the entire lifecycle of the high-risk AI system. The provider reviews and updates it regularly and systematically. The system has the four steps in points (a) to (d).
Art. 9(2)(a)The provider identifies and analyses the known and the reasonably foreseeable risks that the high-risk AI system can pose to health, safety or fundamental rights when the system is used in accordance with its intended purpose.
Art. 9(2)(b)The provider estimates and evaluates the risks that may emerge when the high-risk AI system is used in accordance with its intended purpose and under conditions of reasonably foreseeable misuse.
Art. 9(2)(c)The provider evaluates other risks that may arise, based on the analysis of data from the post-market monitoring system under Art. 72.
Art. 9(2)(d)The provider adopts appropriate and targeted risk management measures to address the risks identified under point (a).
Art. 9(3)The risks in this Article are only the risks that the provider can reasonably mitigate or eliminate through the development or design of the high-risk AI system, or through the provision of adequate technical information.
Art. 9(4)The risk management measures under Art. 9(2)(d) give due consideration to the effects and the possible interaction that result from the combined application of the requirements in Section 2 of Chapter III. The aim is to minimise risks more effectively and to achieve an appropriate balance in the measures that fulfil those requirements.
Art. 9(5)The risk management measures under Art. 9(2)(d) are such that the relevant residual risk of each hazard and the overall residual risk of the high-risk AI system are judged to be acceptable. The provider makes sure of points (a) to (c) when it identifies the most appropriate risk management measures. The provider gives due consideration to the technical knowledge, experience, education and training expected of the deployer, and to the presumable context in which the system is intended to be used.
Art. 9(5)(a)The provider eliminates or reduces the risks identified and evaluated under Art. 9(2), as far as technically feasible, through adequate design and development of the high-risk AI system.
Art. 9(5)(b)Where appropriate, the provider implements adequate mitigation and control measures for the risks that cannot be eliminated.
Art. 9(5)(c)The provider gives the information required under Art. 13 and, where appropriate, training to deployers.
Art. 9(6)The provider tests the high-risk AI system to identify the most appropriate and targeted risk management measures. Testing makes sure that the system performs consistently for its intended purpose and that it meets the requirements in Section 2 of Chapter III.
Art. 9(7)Testing procedures may include testing in real-world conditions in accordance with Art. 60.
Art. 9(8)The provider tests the high-risk AI system, as appropriate, at any time during the development process, and in any event before it places the system on the market or puts it into service. The provider carries out the testing against prior defined metrics and probabilistic thresholds that are appropriate to the intended purpose of the system.
Art. 9(9)When the provider implements the risk management system under Art. 9(1) to 9(7), the provider gives consideration to whether, in view of its intended purpose, the high-risk AI system is likely to have an adverse impact on persons under the age of 18 and, as appropriate, on other vulnerable groups.
Art. 9(10)A provider that is subject to requirements on internal risk management processes under other relevant provisions of Union law may make the aspects in Art. 9(1) to 9(9) part of, or combine them with, the risk management procedures established under that other law.
The system performs consistently for its intended purpose across the operating conditions recorded in the risk management file, with a result per condition (Art. 9(6)).
Each test in the risk management file runs against a prior defined metric and probabilistic threshold, and the result either meets the threshold or does not (Art. 9(8)).
The residual risk of each hazard after the adopted measures is measured and compared with the acceptance criterion recorded for that hazard, and the overall residual risk is compared with the overall criterion (Art. 9(5)).
Each technical risk management measure adopted under Art. 9(2)(d), such as an input check, a filter, a fallback or a guardrail, activates on the hazard scenarios it addresses and produces the recorded effect (Art. 9(5)(a) and 9(5)(b)).
The system's behaviour under each reasonably foreseeable misuse condition recorded under Art. 9(2)(b) is observed and recorded against the expected behaviour.
Where the Art. 9(9) consideration identifies a likely adverse impact on persons under the age of 18 or other vulnerable groups, the test set contains cases that represent those groups and the results are reported for them.
The risk management system is documented in a risk management file that records the risks identified, the estimation and evaluation method, the measures adopted and the residual risk judgement (Art. 9(1) and 9(5)).
Each hazard is recorded with the intended purpose and the reasonably foreseeable misuse conditions under which it was identified and evaluated (Art. 9(2)(a) and 9(2)(b)).
For each risk, the file states whether design, development or adequate technical information can reasonably mitigate or eliminate it, which fixes the scope of Art. 9 for that risk (Art. 9(3)).
The interaction analysis records how the measures taken under Art. 10 to Art. 15 affect each other and the balance the provider chose (Art. 9(4)).
The acceptance criterion for the residual risk of each hazard and for the overall residual risk is stated before testing, with its rationale (Art. 9(5)).
The Art. 13 information and any deployer training are described together with the technical knowledge, experience, education and training expected of the deployer and the presumable context of use (Art. 9(5)(c)).
Where testing in real-world conditions takes place, the plan and the conditions under Art. 60 are documented (Art. 9(7)).
The prior defined metrics and probabilistic thresholds are recorded before the test runs, with the reason each is appropriate to the intended purpose (Art. 9(8)).
Test records identify the system version tested and show that a full test run took place before placing on the market or putting into service (Art. 9(8)).
The consideration of adverse impact on persons under the age of 18 and other vulnerable groups is recorded with its outcome (Art. 9(9)).
Where the provider combines Art. 9 with a risk management procedure under other Union law, a mapping shows where each aspect of Art. 9(1) to 9(9) is covered (Art. 9(10)).
The risk management system is established, implemented and maintained as a continuous iterative process that is planned and run through the entire lifecycle of the system (Art. 9(1) and 9(2)).
The risk management system is reviewed and updated regularly and systematically, with a defined trigger and a record of each review (Art. 9(2)).
Data from the post-market monitoring system under Art. 72 is analysed and other risks that arise are evaluated in the risk management cycle (Art. 9(2)(c)).
Risk management measures are adopted for the identified risks in the order of Art. 9(5): elimination or reduction by design and development, then mitigation and control measures, then information and training for deployers (Art. 9(2)(d) and 9(5)).
Testing takes place at any time during the development process as appropriate, and is repeated before placing on the market or putting into service (Art. 9(8)).
A provider subject to internal risk management requirements under other Union law may run the Art. 9 aspects inside that procedure (Art. 9(10)).
Metrics and where thresholds come from
Threshold sources, in order of precedence
A harmonised standard cited in the Official Journal (none as of the anchor date)
A JTC 21 draft standard (prEN), with its stage
An ISO/IEC standard or technical report, with its stage
A Commission guideline or code of practice, with its date from the standards data
NIST AI RMF or a sector framework
The state of the art, which the provider justifies and documents
Art. 9 sets no numeric threshold. Art. 9(8) requires testing against prior defined metrics and probabilistic thresholds and leaves the values to the provider, with the single condition that they are appropriate to the intended purpose. Art. 9(5) requires that residual risk is judged to be acceptable and gives no acceptance level. No harmonised standard for Art. 9 is cited in the Official Journal, so the hierarchy level in use today is the JTC 21 draft prEN 18228, under enquiry, supported by ISO/IEC 23894:2023 and NIST AI RMF 1.0 at the next levels, and then the state of the art. None of these documents publishes a numeric acceptance level for residual risk. The provider sets each metric, threshold and acceptance criterion, justifies it against the context of use and documents the justification. The acceptance-criteria step of PR-17-QMS records the residual risk criteria and their rationale; the threshold-declaration step of PR-15-ROB records each test metric, its threshold and the reason it fits the intended purpose.
Metric sources and their stage
Source and stage
Title
What it provides here
Verified on
prEN 18228Enquiry
AI risk management, requirements and guidance
requirements for the Art. 9(2) steps of risk identification, estimation, evaluation and mitigation, and the records that show the cycle ran across the lifecycle; under enquiry, not cited in the Official Journal
published guidance that applies ISO 31000 risk management to AI, with AI-specific risk sources and a lifecycle mapping usable as the reference process for the Art. 9(2) cycle and the Art. 9(5) residual risk judgement
Map, Measure and Manage functions usable as a structure for the hazard register, the Art. 9(8) metric selection rationale and the residual risk decision record
Each protocol is versioned; its page states the derivation from the standards above. PR-17-QMS v1.0 covers the risk management cycle, its review records and the residual risk acceptance criteria. PR-15-ROB v1.0 covers the tests against the declared metrics and thresholds for each residual risk that is an accuracy, robustness or cybersecurity failure.
PR-15-ROB v1.0Robustness and adversarial testing protocolv1.0
What an assessor asks for
Risk management file (Art. 9(1))
Hazard register with intended purpose and reasonably foreseeable misuse conditions (Art. 9(2)(a) and (b))
Residual risk acceptance record per hazard and overall (Art. 9(5))
Prior defined metrics and probabilistic thresholds declaration (Art. 9(8))
Risk-driven test report (PR-15-ROB output)
Risk management system review record (PR-17-QMS output)
Post-market monitoring data analysis record (Art. 9(2)(c))
Vulnerable groups impact consideration record (Art. 9(9))
Common findings
The hazard register lists risks without a residual risk value or an acceptance criterion per hazard.
Metrics and thresholds are set after the test results are known, so the prior definition required by Art. 9(8) cannot be shown.
Risk management measures are described in the file without a test that shows their effect on the risk they address.
Reasonably foreseeable misuse is stated as one general sentence with no scenario list and no test case.
The risk management system exists as a single document from the design phase with no review record after release.
Post-market monitoring data is collected but is not fed back into the risk evaluation.
Questions
+−What does AI Act Article 9 require of a provider?
Art. 9(1) requires a risk management system that is established, implemented, documented and maintained for the high-risk AI system. Art. 9(2) defines it as a continuous iterative process across the entire lifecycle with four steps: identification and analysis of risks, estimation and evaluation of risks, evaluation of post-market monitoring data, and adoption of risk management measures. Art. 9(5) requires that the residual risk of each hazard and the overall residual risk are judged to be acceptable. Art. 9(6) to 9(8) require testing against prior defined metrics and probabilistic thresholds, in any event before placing on the market or putting into service. Art. 9(9) requires consideration of adverse impact on persons under the age of 18 and other vulnerable groups.
+−What is the EU AI Act Article 9 risk management system?
The risk management system under Art. 9 is a process with a documented output, not a single document. Art. 9(2) requires that it runs through the entire lifecycle of the high-risk AI system with regular systematic review and updating. Art. 9(3) limits its scope to risks that design, development or adequate technical information can reasonably mitigate or eliminate. Art. 9(4) requires that the measures take account of how the requirements of Art. 10 to Art. 15 interact. Art. 9(5) requires that the residual risk of each hazard and of the system as a whole is judged to be acceptable. prEN 18228 is the JTC 21 draft standard that specifies requirements for this system; it is under enquiry and not cited in the Official Journal.
+−Is there a guide to the AI Act risk management system under Article 9?
This page restates each paragraph of Art. 9 and splits every element into a testable, a documentation or a process item. The Act gives no numeric threshold for Art. 9, so the metric sources table names the documents that supply the structure and their stage. ISO/IEC 23894:2023 is the published guidance that applies ISO 31000 risk management to AI. NIST AI RMF 1.0 supplies the Map, Measure and Manage functions as a structure for the evidence. prEN 18228 is the JTC 21 draft for Art. 9 and is under enquiry. No harmonised standard for Art. 9 is cited in the Official Journal as of the verified-on date shown on this page.
+−How do AI Act Art. 9 and Art. 15 relate to each other?
Art. 9 defines the risk management process and Art. 15 defines the accuracy, robustness and cybersecurity requirements that the system meets. Art. 9(6) requires testing that shows the system meets the requirements of Section 2 of Chapter III, which includes Art. 15. Art. 9(8) requires that the testing runs against prior defined metrics and probabilistic thresholds. The accuracy metrics declared in the instructions for use under Art. 13(3)(b)(ii) are the usual source of those metrics for an accuracy hazard. A residual risk that is an accuracy, robustness or cybersecurity failure is tested under PR-15-ROB and the result is recorded in the Art. 9 risk management file.
+−Is an AI Act risk management system a document or a process?
Art. 9(1) requires both, because the system is established, implemented, documented and maintained. The process part is the continuous iterative cycle in Art. 9(2) with regular systematic review and updating. The document part is the risk management file that records the hazards, the measures, the residual risk judgement and the test results. Under Art. 17(1)(g), the risk management system referred to in Art. 9 is also a component of the quality management system. Under Art. 9(10), a provider already subject to internal risk management requirements under other Union law may combine the Art. 9 aspects with that procedure.
How we test this
We test the technical risk management measures and the residual risk of each hazard against the metrics and thresholds recorded in the risk management file before the test runs, and we verify that the file shows a full test run on the version placed on the market. Every service is bounded by the scope statement: the residual risk acceptance judgement under Art. 9(5) remains with the provider.
We do not perform conformity assessments where a notified body is required.
We do not issue CE marking or the EU Declaration of Conformity.
We are not a notified body.
We do not give legal opinions on classification or liability.
We test against requirements, prepare evidence, and structure documentation; compliance decisions remain with the provider or deployer, their notified body, and their counsel.