Article 9, line by line.

The four operative verbs.

One sentence. Four verbs. Each carries its own evidence burden, and a regulator examining a provider under Article 21 can ask for proof of any one of them in isolation.

Established is the act of bringing the risk management system into existence with a defined scope. The provider must be able to point to a date on which the RMS for a given system was first stood up, and to the document of authority that constituted it. Implemented is the operational layer. The procedures named in the document must run in the organisation, with named owners and a defined cadence. Documented is the artefact layer. The RMS exists in writing, the writing is current, and the writing is producible on request. Maintained is the temporal layer. The RMS does not stop at first deployment. It runs across the lifetime of the system.

Article 9(1) does not say the RMS must be perfect. It says it must exist, run, be written down, and keep running. An undocumented risk register held in a senior engineer's head fails the third verb. A documented register that has not been updated since the model went into production fails the fourth.

The four-step process and the lifecycle clause.

The opening clause carries more weight than the four sub-points it introduces. Continuous iterative process planned and run throughout the entire lifecycle rules out the most common compliance pattern in 2025 and 2026: a one-time risk assessment performed before launch, archived in a SharePoint folder, and consulted again only when a regulator asks. The text does not allow for that pattern.

Continuous means the process runs at all times, not at intervals. Iterative means the output of each cycle feeds the next. Planned and run throughout the entire lifecycle means from the moment intended purpose is fixed through to the moment the last instance of the system is withdrawn from service. Regular systematic review and updating implies a defined cadence, defined owners, and defined triggers for off-cadence review.

The four steps then describe the substantive content of each iteration. They are not optional. They are not in priority order. They run in sequence and they run again.

The four steps form a register, an evaluation, a feedback channel, and a treatment plan. Together they constitute the substance of the risk management system. The continuous iterative clause then governs how often each step runs.

The boundary on what risks the article reaches.

Paragraph 3 narrows the scope of paragraph 2. Article 9 is not a duty to manage every conceivable risk a high-risk AI system might raise. It is a duty to manage those that the provider can reasonably reach through one of three levers: development, design, or technical information.

The first two levers are obvious. Build the system differently. Design the input pipeline differently. The third is more subtle. Adequate technical information reaches forward into Article 13 and the instructions for use. Where a risk cannot be eliminated in the artefact, the provider may discharge the Article 9 duty by communicating the risk and the mitigations clearly enough that a competent deployer can manage it. The lever shifts from product to documentation, but the duty remains the provider's.

What paragraph 3 does not do: it does not licence the provider to declare a risk unreachable simply because reaching it is expensive or commercially inconvenient. The standard is reasonably mitigated, which is a proportionality standard that imports cost, technical feasibility, and the severity of the underlying risk. Severity scales the duty. A risk to fundamental rights at the high end of the severity spectrum imports a higher reasonableness threshold than a risk to operational performance at the low end.

The interaction with the rest of Section 2.

Paragraph 4 is the integration clause. This Section is Section 2 of Chapter III, which contains Articles 8 through 15. Those articles run in sequence: requirements (8), risk management (9), data and data governance (10), technical documentation (11), record-keeping (12), transparency and information to deployers (13), human oversight (14), and accuracy, robustness and cybersecurity (15). They are not silos. They are facets of the same compliance posture, and paragraph 4 says the risk management measures must take their interaction into account.

The practical reading: a risk management measure adopted under 9(2)(d) cannot be evaluated only against the specific risk it targets. It must also be evaluated against its effect on the other Section 2 obligations. A measure that improves robustness under Article 15 by aggressive input filtering may degrade transparency under Article 13. A measure that improves human oversight under Article 14 by inserting a manual review step may slow throughput in a way that defeats the intended purpose declared under Article 9(2)(a).

Paragraph 4 does not resolve those tradeoffs. It requires the provider to make them visibly, with the interaction documented and the balance argued. The risk management system must be able to show its work on tradeoffs across the whole of Section 2, not only on the risk it is treating.

Residual risk acceptability and the three measures.

Paragraph 5 sets the substantive test for risk management measures. Two thresholds, two operands.

The first threshold is relevant residual risk associated with each hazard. Per-hazard, after measures, the residual must be acceptable. The second threshold is overall residual risk. Across the whole system, the total residual must also be acceptable. A provider cannot pass the first test by treating each hazard in isolation while the cumulative effect of those treatments still leaves the system unsafe overall. The two thresholds run together.

The text does not define acceptable. The acceptability judgement is the provider's, made in light of the intended purpose, the protected interests under 9(2)(a), and the reasonableness boundary under 9(3). The conformity assessment under Article 43 then validates that judgement. Where a notified body is engaged, the body examines the residual-risk reasoning. Where self-assessment applies, the provider must be ready to defend the reasoning to a national competent authority.

The three sub-points in 9(5) form a hierarchy. Eliminate or reduce through design comes first. Mitigate and control what cannot be eliminated comes second. Inform and train deployers comes third. The order is statutory. A provider whose primary mitigation is a warning in the user manual, where elimination through design was technically feasible, has inverted the hierarchy and fails the test in 9(5)(a).

Sub-point 9(5)(c) imports Article 13 by reference. The information required pursuant to Article 13 includes the instructions for use, the characteristics of the system, the human-oversight measures under Article 14, and the expected lifetime and maintenance measures. The cross-reference matters: a deficient Article 13 instruction set is not only an Article 13 failure, it is also a 9(5)(c) failure, because the residual-risk argument relies on the deployer being adequately informed.

Testing for the purpose of identifying measures.

Paragraph 6 ties testing to the risk management process. Testing under Article 9 has a defined purpose: identify the most appropriate and targeted measures. It is not testing for its own sake, and it is not the model-evaluation testing that an ML team runs to satisfy itself that a model is good. It is testing scoped to inform the risk register and the measures attached to that register.

The second sentence widens the purpose. Testing must also ensure consistent performance under intended purpose, and compliance with the whole of Section 2. Consistent performance is not statistical accuracy alone. It includes stability across runs, across operating conditions defined in the intended purpose, and across the deployment population the provider has anticipated. A model that performs at 95 percent accuracy on average but degrades sharply for a subpopulation identified in the intended purpose has not been tested for consistent performance.

Testing in real-world conditions under Article 60.

Paragraph 7 is short and operates as a permission, not a mandate. The provider may include real-world testing in the testing procedures, and where it does, Article 60 governs the conditions.

Article 60 sets out a substantial procedural regime: a real-world testing plan filed with the relevant market surveillance authority, informed consent of subjects where applicable, registration in the EU database, statistical safeguards, suspension powers, and time limits. Real-world testing is permitted but it is gated. The default is testing in controlled conditions; real-world testing is the exception requiring justification.

The cross-reference matters operationally. A provider that runs A/B experiments on production users without filing the Article 60 plan is, on most readings, conducting unauthorised real-world testing. The line between routine production rollout and Article 60 testing is whether the deployment is being used to inform the risk management system under 9(6). Where it is, Article 60 attaches.

Testing throughout development against prior defined metrics.

Paragraph 8 carries two distinct rules. The first is temporal. Testing happens throughout development, and at minimum before placing on the market or putting into service. The second is methodological. Testing is against prior defined metrics and probabilistic thresholds appropriate to the intended purpose.

The temporal rule rules out testing only at the gate. A provider that runs the full test suite once, on the eve of conformity assessment, satisfies the second clause but not the first. Testing must occur throughout development, which implies at design milestones, after data changes, after model retraining, and after architectural changes.

The methodological rule is the more demanding of the two. Prior defined means the metrics and thresholds are fixed before the test runs. A provider cannot pick the metric after seeing the result. Probabilistic thresholds imports statistical reasoning into the test design. A pass-fail boundary on a deterministic metric is not enough. The provider must define what level of confidence at what threshold constitutes a pass, and must be able to defend that confidence level as appropriate to the intended purpose.

The Commission has not, as of May 2026, published a definitive metric catalogue for any high-risk system class. The harmonised standards under Article 40, currently being developed under CEN-CENELEC mandate M/593, are expected to fill that gap. Pending those, providers are reaching for ISO/IEC 23894:2023 procedural guidance and the substantive metrics implied by Article 15: accuracy, robustness, and cybersecurity. The defensible posture in 2026 is to document the metric, document why the threshold was chosen, document when the threshold was set, and ensure all three precede the test run.

Minors and other vulnerable groups.

Paragraph 9 is a consideration duty rather than a substantive prohibition. The provider must consider whether the system is likely to have an adverse impact on persons under 18, and on other vulnerable groups as appropriate. The output of that consideration then feeds the risk management measures under 9(2)(d) and the residual-risk acceptability test under 9(5).

The age-18 line is fixed by the article. Other vulnerable groups is open-ended. Recital 56 and related recitals identify persons in vulnerable positions due to socioeconomic situation, disability, or membership in groups historically subject to discrimination as candidates. The judgement is the provider's, made in light of the intended purpose and the deployment context.

Two things to note about the scope. First, paragraph 9 reaches systems that are not specifically designed for minors. The test is not whether the system is targeted at children but whether it is likely to have an adverse impact on them. A general-population recruitment screening system that may be used to evaluate apprenticeship candidates falls inside the consideration. Second, paragraph 9 interacts with the prohibitions in Article 5(1)(b), which prohibits AI systems that exploit vulnerabilities of a specific group due to their age. Article 9(9) does not displace Article 5; it operates alongside it for systems that are not prohibited but raise the consideration.

Combining the RMS with existing risk procedures.

Paragraph 10 permits integration. Providers already running risk management procedures under other Union law, including the Capital Requirements Regulation for credit institutions, the Medical Device Regulation for medical devices, Solvency II for insurance undertakings, and the Digital Operational Resilience Act for financial entities, may incorporate the Article 9 obligations into those existing procedures rather than running a parallel regime.

The permission is not a presumption of conformity. The provider does not satisfy Article 9 by pointing to a CRR risk function. The provider satisfies Article 9 by showing that the integrated procedure substantively covers the four-step process under 9(2), the residual-risk acceptability test under 9(5), the testing regime under 9(6) to (8), and the consideration duty under 9(9). Where the existing procedure does not cover an Article 9 aspect, the provider must extend the procedure to cover it.

Paragraph 10 also distinguishes Article 9 from Article 17. Article 17 governs the quality management system as an organisational regime, and Article 17(1)(g) names the risk management system as a required component. A provider integrating Article 9 with a CRR risk function under paragraph 10 still has to integrate that combined function into the Article 17 QMS. The integration permitted by 9(10) is at the procedural level. The integration required by 17(1)(g) is at the organisational level.

The articles that plug into Article 9.

Article 9 does not stand alone. The risk management system is the procedural layer through which the substantive obligations of the high-risk regime reach the production system. The cross-references are explicit in the text and operationally consequential.

The shape of the web matters. Articles 10 to 15 supply the substance the risk management system must address. Article 17 supplies the organisational wrapper. Articles 60, 72 and 73 supply the inputs that keep the system iterating. Article 11 captures the static record of the lot for conformity assessment. Article 9 is the verb at the centre.

Where Warrant maps Article 9.

Warrant produces an evidence package per agent execution trace. The fields below show where each Article 9 clause attaches to the evidence record, so a regulator examining a Warrant package under Article 21 can step from clause to clause without leaving the document.

Questions a compliance officer asks first.

Read the source directly.

• Regulation (EU) 2024/1689 · EUR-Lex CELEX:32024R1689
• Article 9 risk management system · annotated text
• Article 17 quality management system
• Article 72 post-market monitoring system
• Article 60 testing of high-risk AI systems in real-world conditions
• ISO/IEC 23894:2023 · Information technology, Artificial intelligence, Guidance on risk management
• Per-obligation Warrant evidence field mapping

Authored by Warrant Compliance, the regulatory-analysis function at Warrant. [email protected]. Editorial commentary on regulatory text. Not legal advice. The verbatim quotations of Article 9 reflect the official English-language text of Regulation (EU) 2024/1689 as published in the Official Journal of the European Union on 12 July 2024.