EU AI Act Article 9: Risk Management System for High-Risk AI
Article 9 EU AI Act requires a continuous risk management system for high-risk AI. Covers the 4 mandatory steps, residual-risk test, and Dec 2027 deadline.
Article 9 of Regulation (EU) 2024/1689 — the EU AI Act — requires every provider of a high-risk AI system to establish, implement, document and maintain a risk management system (RMS). The obligation does not end at launch. Article 9 explicitly frames the RMS as a continuous, iterative process run throughout the entire lifecycle of the system, subject to regular systematic review. That framing matters: a risk file assembled once and filed away does not satisfy Article 9.
Under the Digital Omnibus agreed in May 2026, the Article 9 deadline for stand-alone high-risk AI systems (Annex III) is 2 December 2027. For high-risk AI embedded in products covered by EU product-safety law (Annex I), the deadline is 2 August 2028. Non-compliance exposes providers to fines of €15 million or 3% of total worldwide annual turnover, whichever is higher (Article 99).
This guide explains what the Article 9 RMS must contain, the four mandatory risk-management steps, how the RMS connects to the broader high-risk obligation stack, and how to build one in practice.
What Article 9 Actually Requires
The continuous-process obligation
Article 9(1) describes the RMS as a set of measures established, implemented, documented and maintained that forms a continuous, iterative process run throughout the entire lifecycle of a high-risk AI system, requiring regular systematic review and update. The word "iterative" is deliberate. Risks that were acceptable at training time can become unacceptable once the system is deployed at scale, encounters edge cases, or operates in a context the provider did not fully anticipate.
This is a structural distinction from a one-time conformity audit. Your RMS must be a living management process — not a document.
The four mandatory steps
Article 9(2) sets out the required steps in order:
Step 1 — Identify and analyse known and reasonably foreseeable risks. You must examine risks to health, safety and fundamental rights arising from the system when used for its intended purpose. "Reasonably foreseeable" extends the analysis beyond the happy path: you must consider how the system could be misused, how users might misunderstand its outputs, and what happens when it fails silently rather than loudly.
Step 2 — Estimate and evaluate risks that may emerge under intended use and under reasonably foreseeable misuse. This is distinct from step 1. Identification asks what can go wrong; estimation asks how likely and how severe. A model that mis-classifies a job application at a 0.5% error rate looks different when it processes 500,000 applications per year. Both the probability and the magnitude of harm must be assessed — including risks that materialise only under conditions the deployer creates.
Step 3 — Evaluate risks in light of post-market monitoring data (Article 72). Once the system is live, monitoring data feeds back into the RMS. Article 9(2)(c) explicitly requires that post-market monitoring results be considered in risk evaluation. This creates a closed loop: deployment generates evidence, evidence updates the risk picture, the updated risk picture drives further mitigation or restriction.
Step 4 — Adopt appropriate, targeted risk-management measures. Article 9(4) specifies the priority order. Eliminate or reduce risks through design and development choices as far as possible. Where elimination is not possible, mitigate and control residual risks, including through adequate information to deployers under Article 13 and through training measures. Residual risk — both for each individual hazard and in aggregate — must be judged acceptable before the system is placed on the market or put into service.
The residual-risk acceptability test
The Act does not define "acceptable" in a formula. In practice, the provider must document a reasoned judgment: given the system's intended purpose, its context of use, the availability of alternative approaches, and the state of the art in risk reduction, is the remaining risk proportionate to the benefit? That judgment must be recorded in the technical documentation (Article 11, Annex IV) and be defensible to a market surveillance authority.
Vulnerable persons and persons under 18
Article 9(9) singles out one category explicitly: where the system may interact with or affect persons under 18, or other groups considered vulnerable due to age, disability, or other personal circumstances, the provider must give special attention to their situation in the risk assessment. This is not a soft aspiration. A recruitment tool used at university career fairs, or a credit-scoring model that affects young adults seeking their first loan, must address this population directly in the RMS.
Testing against prior-defined metrics
Article 9(7) requires testing to ensure the risk management measures are effective. Tests must be performed against prior-defined metrics and probabilistic thresholds appropriate to the intended purpose. Testing may take place throughout development; it must happen at the latest before placing the system on the market or putting it into service. A provider that first tests the system after deployment is already out of compliance.
How Article 9 Fits the Broader High-Risk Stack
Article 9 is the procedural backbone; the other high-risk articles supply the substance it must address. Understanding the connections prevents the common error of treating each article as a separate silo.
Article 10 (data and data governance): Data quality, representativeness, and bias — the subjects of Article 10 — are inputs to the Article 9 risk identification and estimation steps. A training dataset that underrepresents a protected group is itself a risk that must appear in the RMS and be mitigated.
Article 11 (technical documentation, Annex IV): The RMS and its findings must be recorded in the technical documentation file. Annex IV, Section 2 specifically lists the risk management system description as a required element of that file.
Article 13 (transparency and information to deployers): Where a risk cannot be eliminated by design, Article 9(4) permits mitigation through information. The instructions for use that providers must supply under Article 13 are one of the recognised mitigation channels — but only after design-level risk reduction has been exhausted.
Article 14 (human oversight): Human oversight is itself a risk mitigation measure. If a system's residual risk in a given scenario can only be rendered acceptable by requiring a human to review outputs before a decision is taken, then the human oversight design requirement under Article 14 is directly driven by the Article 9 analysis.
Article 15 (accuracy, robustness, cybersecurity): Article 9's step 2 (risk estimation) must cover the risks addressed in Article 15: accuracy degradation, adversarial inputs, and cybersecurity vulnerabilities. The Article 15 requirements set the performance floor; Article 9 is the process through which you verify the floor has been met.
Article 17 (quality management system, QMS): Article 9 does not stand alone within the provider's obligations. Article 17 requires providers to embed the RMS within a broader quality management system covering processes across the whole organisation. The QMS is the container; the RMS for each high-risk system is one of its components.
Article 72 (post-market monitoring): Post-market monitoring is not a separate compliance track — it feeds Article 9 directly, as step 3 above. Monitoring data that reveals performance drift, new failure modes, or unexpected use patterns must trigger a review of the risk assessment and, if warranted, new mitigation measures.
Voluntary frameworks: what they are and are not
ISO 31000 (risk management principles), NIST AI RMF (AI risk management framework), and ISO/IEC 42001 (AI management systems) are useful reference architectures for structuring an RMS. Confir cross-maps its controls to ISO/IEC 42001 and NIST AI RMF. However, none of these frameworks is a substitute for an Article 9 RMS. Compliance with ISO/IEC 42001 does not certify EU AI Act compliance. The frameworks can accelerate your build and improve its quality, but the Article 9 obligation is defined by the Regulation and must be fulfilled on its own terms.
Article 6(3): Not Every Annex III System Is Automatically High-Risk
Before investing in an Article 9 RMS, confirm that your system actually triggers the obligation. Article 6(3) provides that a system falling within an Annex III area is not high-risk if it does not pose a significant risk of harm to health, safety or fundamental rights. The Act gives four examples: the system performs a narrow procedural task; it improves the result of a previously completed human activity; it detects decision-making patterns without influencing or replacing individual human assessment; and it performs a preparatory task to assess a person's status. Exception: any system that profiles natural persons is always high-risk regardless of these filters.
Providers claiming the Article 6(3) exemption must document that assessment and register it in the EU database under Article 49. The exemption is not a loophole to avoid the RMS — it is a narrowly scoped filter for genuinely low-consequence applications within an Annex III category.
Worked Example: Article 9 RMS for a CV-Screening Tool
Consider a 45-person HR-tech company that has built a CV-screening system. The system ranks job applicants for client companies in sectors including retail management and logistics. It falls squarely within Annex III, Section 4 (employment and worker management). The company is the provider under Article 16. Here is how Article 9 applies.
Lifecycle scope. The RMS begins at product design, not at launch. The company documents it during development, updates it before each major release, and maintains it through the product's commercial life.
Step 1 — Identify risks. The company identifies: (a) the system may produce discriminatory rankings correlated with gender or ethnicity because of patterns in historical training data; (b) it may disadvantage candidates with non-standard CVs (career breaks, non-EU education systems); (c) deployers may rely on rankings without reviewing underlying justification; (d) candidates who are shortlisted or rejected receive no explanation, limiting their ability to seek redress.
Step 2 — Estimate and evaluate. The company models the probability and magnitude of each risk. Risk (a) affects fundamental rights and could affect thousands of applicants annually across the company's customer base — high probability, high severity. Risk (b) is lower probability but affects groups already underrepresented in the labour market. Both are classified as requiring active mitigation before launch. The company explicitly models reasonably foreseeable misuse: a deployer that turns off the recommended human review step and uses rankings as final decisions, not shortlists.
Step 3 — Post-market monitoring loop. Once deployed, the company collects aggregated outcome data from clients (opt-in, anonymised): shortlist rates by demographic proxy, recruiter override rates, and application-stage complaints. This data feeds the quarterly RMS review.
Step 4 — Risk measures. Design changes: the ranking algorithm is retrained on a debiased dataset, and the system is restructured to produce shortlists rather than ranked scores (reducing the perceived authority of the output). Residual controls: the instructions for use under Article 13 prohibit using the system as the sole determinant of rejection; deployers must confirm human review before any candidate is eliminated. Vulnerable-persons note: the company flags that the system is sometimes used in graduate recruitment programmes targeting persons under 25. The RMS addresses this population's risk profile separately — in particular the risk that the model performs less well on non-traditional graduate pathways.
Residual risk judgment. After mitigation, the company documents that residual risk is acceptable given: the shortlist function rather than binary rejection, the mandatory human review instruction, the active monitoring loop, and the achievable accuracy rates across demographic groups. This judgment is recorded in the Annex IV technical documentation.
How to Build an Article 9 RMS: A Practical Sequence
The following sequence applies to a provider building an RMS from scratch for a stand-alone Annex III system. The deadline is 2 December 2027; realistically, a documented and tested RMS for a medium-complexity system takes four to six months to build properly.
1. Confirm scope. Determine whether the system is high-risk under Article 6 and Annex III, and whether the Article 6(3) filter applies. Document the reasoning. If you are a deployer — not a provider — review the provider's RMS and assess what additional context-specific risks your deployment introduces; deployers carry their own Article 9 obligations within their operational scope.
2. Assign ownership. Designate a named individual (or a small committee in larger organisations) responsible for the RMS. Under Article 17, this fits within the quality management system. Ensure the role has authority to delay a launch if residual risks are not yet acceptable.
3. Map the lifecycle. Identify every stage at which new risks can emerge: design, data collection, training, validation, deployment, operation, update, and decommissioning. The RMS must address each stage, even if the measures at some stages are simply monitoring and review.
4. Conduct systematic risk identification. For each lifecycle stage, identify risks to health, safety and fundamental rights — including reasonably foreseeable misuse. Use structured techniques (failure mode analysis, scenario modelling) rather than ad hoc brainstorming. Give explicit attention to vulnerable groups and persons under 18 where relevant.
5. Estimate probability and severity. For each identified risk, record an estimate of likelihood and impact. This does not require actuarial precision — it requires reasoned, documented judgments that will hold up to scrutiny. Note where data is unavailable and how you have handled the uncertainty.
6. Design risk measures in priority order. Start with design and development changes to eliminate risks. Document what was considered and why certain changes were not feasible. Then define residual controls, documentation to deployers, and training measures. Every mitigation measure should be traceable to the risk it addresses.
7. Define test metrics and thresholds. Before testing begins, write down what success looks like: accuracy rates, performance parity across demographic groups, robustness to specified input perturbations, response to attempted adversarial inputs. Article 9(7) requires testing against prior-defined metrics. Do not define metrics after you have seen the results.
8. Test and validate. Run the tests. Record results against the prior-defined thresholds. Document failures and the corrective actions taken. If thresholds are not met, return to step 6 before proceeding.
9. Make the residual-risk acceptability judgment. For each hazard and in aggregate: document the reasoning that leads to the conclusion that residual risk is acceptable. This is the formal gate before market placement.
10. Record everything in the technical documentation. Annex IV, Section 2 requires the RMS description and findings to be recorded. This is the document a market surveillance authority will inspect.
11. Establish the monitoring and review cycle. Before launch, define the cadence and method for post-market monitoring (Article 72), the trigger conditions for an ad hoc RMS review (new failure mode, significant performance drift, regulatory guidance, incident report), and the process for updating the RMS when a review reveals new risks.
12. Maintain throughout the lifecycle. The RMS is not closed when the product ships. Every substantive update to the system — new training data, changed intended purpose, new deployment context — triggers a proportionate RMS review.
Article 9 and the Conformity Assessment (Article 43)
The RMS is a prerequisite for the Article 43 conformity assessment — the formal process by which a provider demonstrates, before market placement, that the high-risk system meets all requirements. A provider cannot complete the Annex IV technical documentation required for conformity assessment without a functioning RMS, because the documentation must include the RMS description, findings, and residual-risk judgment.
For most Annex III systems, conformity assessment takes the form of an internal review under Module A (the provider assesses its own system against the requirements). For biometric identification systems and certain other categories, a third-party notified body must be involved. Either way, the RMS file is a central exhibit.
How Confir Helps
Building an Article 9 RMS is primarily a judgment exercise, not a software problem. But structuring the exercise — and ensuring nothing is missed — is where tooling adds value.
Confir's AIGM compliance area (Governance & Post-Market Monitoring) maps directly to Article 9 and Article 72. When you register a high-risk AI system and work through Confir's assessment, the AIGM area generates a rule-based risk register that maps identified risks to specific Articles, tracks mitigation measures against each risk, and flags outstanding residual-risk items. Because the engine is deterministic and rule-based — not an LLM — the same system inputs produce the same structured output every time, which is exactly what an audit-defensible compliance record requires.
Confir also generates the Article 11 / Annex IV technical documentation pack, incorporating the RMS findings, and the Article 27 FRIA for deployers who need one. Starting from €600/year, no consultants required.
Penalties and the Compliance Timeline
The fine ceiling for non-compliance with Article 9 (and the other high-risk obligations) is €15 million or 3% of total worldwide annual turnover, whichever is higher (Article 99). For companies and start-ups, the fine is capped at whichever figure is lower — a proportionality provision in Article 99(6) that reduces, but does not eliminate, exposure for smaller providers.
The compliance deadlines under the Digital Omnibus:
- 2 December 2027 — stand-alone high-risk AI systems (Annex III: recruitment, credit, biometrics, law enforcement, etc.)
- 2 August 2028 — high-risk AI systems that are safety components of products covered by Annex I product safety law
Eighteen months looks comfortable from a distance. It is not, once you account for the time needed to complete data governance documentation, run Article 9 tests against prior-defined thresholds, draft the Annex IV technical file, and run the conformity assessment. The providers who will struggle in late 2027 are the ones who treat the deadline as the start date.
Frequently Asked Questions
Q: Who must comply with Article 9 — the provider or the deployer? Both carry obligations, but the structure differs. The provider (Article 16) builds and maintains the RMS across the full lifecycle, from development through post-market monitoring. The deployer (Article 26) is responsible for the risks that arise specifically from its deployment context — in particular, risks that the provider could not anticipate without knowing how and where the system would be used. A deployer who realises it is operating the system in a way that creates new risks must address them, including by informing the provider.
Q: Does Article 9 apply before a system is placed on the market? Yes. The RMS must be established and documented before market placement. Article 9's process begins at product design. The conformity assessment under Article 43, for which the RMS is a prerequisite, must also be completed before the system is placed on the market or put into service.
Q: What counts as acceptable residual risk under Article 9? The Act does not supply a formula. The provider must document a reasoned judgment that — given the intended purpose, the deployment context, the state of the art in risk reduction, and the available mitigation measures — the remaining risk is proportionate to the benefit and does not exceed what a reasonable person would find tolerable in that application. Market surveillance authorities will assess whether that judgment is defensible, not whether it was reached by any particular method.
Q: How does Article 9 interact with ISO/IEC 42001? ISO/IEC 42001 is an AI management system standard. It provides useful structural guidance for building a risk management process, and alignment with it can accelerate an Article 9 RMS build. But ISO/IEC 42001 certification does not equal EU AI Act compliance. The RMS under Article 9 has specific statutory requirements — in particular the four steps in Article 9(2), the residual-risk acceptability judgment, and the post-market monitoring loop — that must be met on their own terms.
Q: Does the Article 9 RMS need to address cybersecurity risks? Yes. Article 15 requires high-risk AI systems to be resilient against attempts by unauthorised third parties to alter their behaviour, exploit their vulnerabilities, or manipulate their outputs. The risks addressed in Article 15 — including adversarial attacks and data poisoning — must be identified, estimated, and mitigated through the Article 9 process. A risk assessment that covers only accuracy and bias but ignores adversarial robustness is incomplete.
Q: What happens to the RMS if the system is substantially modified? Article 3(23) defines a substantial modification as a change that affects compliance or performance in a material way — retraining on new data, changing the model architecture, expanding the intended purpose, or deploying in a new context. A substantial modification triggers a proportionate review of the entire RMS, updated testing against prior-defined metrics, and, if the conformity assessment was based on the previous version, a new or updated conformity assessment under Article 43.
Q: What is the relationship between Article 9 and the Fundamental Rights Impact Assessment (FRIA) under Article 27? The FRIA under Article 27 is a separate obligation, imposed on certain deployers (those operating high-risk AI in domains such as employment, law enforcement, migration, education and essential services). It draws on the provider's risk management findings — particularly the risk identification and mitigation work — but it is distinct: the FRIA focuses specifically on fundamental rights impacts in the deployer's operational context, and must be prepared by the deployer independently of the provider's RMS.
Related guides
- risk classification levels
- EU AI Act Explained Simply: 2026 Compliance Guide
- AI Risk Management Software for EU AI Act Complian
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. 7-day free trial.
Start free trial →