EU AI Act Risk Management System: How to Build One Under Article 9

Article 9 of Regulation (EU) 2024/1689 is the obligation most providers underestimate. It is not a one-time risk assessment you complete before launch. It is a continuous, iterative process that runs across the entire lifecycle of your high-risk AI system — from initial design through post-market surveillance — and it must be documented, maintained, and ready for inspection.

If your system falls under Annex III or Article 6(1), you need a functioning Article 9 risk management system in place before you go to market. Under the Digital Omnibus agreed in May 2026, the compliance date for stand-alone Annex III systems is 2 December 2027; for high-risk AI embedded in regulated products under Annex I, it is 2 August 2028. Non-compliance under Article 99(4) carries fines up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher.

What Article 9 Actually Requires

Article 9 defines the risk management system as a continuous, iterative process — the regulation's own phrase — covering the full lifecycle. It has four operational components that must work together.

Identify and analyse risks. You must identify all known and reasonably foreseeable risks to health, safety, and fundamental rights that could arise from the system's intended use and from foreseeable misuse. This is broader than most compliance teams expect. Foreseeable misuse means uses you do not endorse but could reasonably anticipate — a recruitment-screening tool used to weed out candidates over 50, or a credit-scoring model applied to populations outside its validated training distribution.

Evaluate and mitigate. Once identified, risks must be evaluated by severity and likelihood, then addressed through a mitigation hierarchy: eliminate the risk through design changes first; reduce it through technical or organisational controls if elimination is not feasible; manage residual risk through monitoring, human oversight (Article 14), and user information. Residual risks that cannot be eliminated must be assessed as acceptable — and that judgment must be documented.

Test against predefined metrics. Article 9 requires testing at appropriate stages of development and before market placement, against predefined metrics and probability thresholds. Generic "we ran a test" language does not satisfy this. You need documented pass/fail criteria established before testing begins.

Monitor post-market and loop back. Article 72 requires providers to actively collect and review post-market data from deployed systems. Findings from post-market monitoring feed back into the Article 9 risk management process — emerging failure modes identified in production must update the risk register, trigger re-evaluation, and (where necessary) corrective action. This is what makes the system iterative rather than static.

Special Attention: Vulnerable Groups

Article 9 calls out a specific obligation that many implementation guides miss: special attention must be paid to risks arising to persons who may be particularly vulnerable, including children. If your system is used in education, employment, or access to essential services, assess whether any part of the population it affects is in a structurally weaker position — minors, people with disabilities, people in economically precarious situations. Document that assessment explicitly.

The Mitigation Hierarchy in Practice

The hierarchy matters because it shapes your documentation. Competent authorities reviewing your technical file will look for evidence that you considered elimination before reaching for a monitoring fix. A system that simply routes everything through a human reviewer has not eliminated or reduced the underlying risk — it has managed residual risk, which is the last resort, not the first.

For a credit-scoring system at a regional lender (Annex III, point 5(b)), elimination might mean removing a proxy variable — postcode, for instance — that correlates with protected characteristics. Reduction might mean retraining on a more representative dataset and introducing fairness constraints. Residual-risk management then covers the human review procedure for borderline decisions and the alert threshold that triggers a bias audit.

How Article 9 Connects to the Rest of the High-Risk Obligation Stack

Article 9 does not stand alone. It is the spine that connects to every other high-risk requirement:

• Article 10 (data governance): The quality and representativeness of your training, validation, and testing data directly determines the risk profile of your system. A data governance failure is a risk management failure.
• Article 11 (technical documentation): The risk management system and its outputs — risk register, mitigation decisions, test results — must be included in the Annex IV technical documentation file.
• Article 14 (human oversight): Human oversight measures are a primary residual-risk control. Article 9 mitigation planning and Article 14 oversight design should be developed together.
• Article 15 (accuracy, robustness, cybersecurity): Your Article 9 risk analysis must include failure-mode analysis covering accuracy degradation, adversarial inputs, and cybersecurity vulnerabilities. Article 15 performance requirements set the floor your testing must clear.
• Article 17 (quality management system): The QMS under Article 17 provides the organisational framework within which the Article 9 risk management system operates. They are designed to complement each other, not duplicate.
• Article 72 (post-market monitoring): Post-market data is not just a reporting obligation — it is an input into the Article 9 review cycle.

Article 9 vs. Voluntary Frameworks: ISO 31000, NIST AI RMF, ISO/IEC 42001

You may already operate under ISO 31000 (generic risk management), the NIST AI Risk Management Framework, or ISO/IEC 42001 (AI management systems). These are valuable — and the EU AI Act does not prohibit their use. But they do not substitute for Article 9 compliance.

The distinction is legal obligation versus best practice. ISO 31000 and NIST AI RMF are voluntary; Article 9 is mandatory for high-risk AI providers. ISO/IEC 42001 is closer — it specifically addresses AI management systems — but it is a certification standard, not a legal requirement, and its scope differs from Article 9's. Alignment with these frameworks can support your Article 9 work and may help demonstrate due diligence, but your technical documentation must reference Article 9 explicitly and show how each mandatory component has been addressed.

Building a Risk Register: Practical Steps

A risk register is the working document of your Article 9 system. It does not need to be elaborate, but it needs to be real — not a template copied from a consultant's deliverable and never reviewed.

A defensible Article 9 risk register typically captures:

1. System description and intended use — including the specific Annex III category and the Article 6(3) filter assessment if you claimed an exemption.
2. Risk inventory — each known and foreseeable risk, identified by source (training data quality, model architecture, deployment context, foreseeable misuse).
3. Risk evaluation — severity (reversibility, scale, nature of harm) and likelihood, assessed against the system's intended population including vulnerable groups.
4. Mitigation measures — for each risk: design elimination applied (or documented reason it was not feasible), technical/organisational controls in place, residual risk level after mitigation.
5. Residual risk acceptability judgment — documented basis for concluding the residual risk is acceptable in light of the system's intended benefit.
6. Test results against predefined thresholds — summary of testing outcomes linked to the risk they address.
7. Post-market review trigger points — what data will be collected, at what frequency, and what thresholds trigger re-evaluation.
8. Review log — dates and outcomes of periodic reviews, including changes made following post-market data.

For a 40-person HR-tech company shipping an applicant-ranking system under Annex III point 4(a), a credible risk register might run to 15–20 entries covering bias risks, misuse scenarios (ranking disabled candidates lower via inference from employment gaps), adversarial manipulation of CV formatting, and data-drift risk as hiring practices shift post-deployment.

How Confir Helps

Article 9 sits inside Confir's AIGM (Governance & Post-Market Monitoring) compliance area. The AIGM area structures your risk management process — risk register, mitigation tracking, post-market review triggers — through a rule-based assessment that maps your system's characteristics to the specific Article 9 obligations that apply. The same rule-based engine that classified your system under Articles 5 and 6 generates the risk register framework you need to populate and maintain. No hallucination, no interpretation gaps — the same intake, the same structured output, every time.

Confir also generates the Article 11 / Annex IV technical documentation pack, which incorporates the risk management section alongside your data governance and human oversight documentation. From €600/year.

Frequently Asked Questions

What is the difference between an Article 9 risk management system and a standard risk assessment?

A standard risk assessment is a point-in-time exercise — you assess risks before launch, document them, and move on. Article 9 requires a risk management system: a continuous process with governance structures, review cycles, and a feedback loop from post-market monitoring under Article 72. The post-market data you collect must actively update your risk register and, where necessary, trigger corrective action. A static assessment does not satisfy the obligation.

Does Article 9 apply to deployers, or only providers?

Article 9 applies to providers — organisations that develop and place a high-risk AI system on the market under their own name or trademark. Deployers (organisations using a third-party high-risk AI system) are governed primarily by Article 26, which requires following the provider's instructions, ensuring human oversight, monitoring the system in use, and informing the provider and relevant market surveillance authorities of serious incidents under Article 26. If you both develop and internally deploy your own system, you carry both sets of obligations.

What counts as a "foreseeable misuse" that Article 9 requires you to assess?

Foreseeable misuse is use that is not intended by the provider but that can reasonably be anticipated given the system's deployment context. For a recruitment-screening system, a foreseeable misuse is a hiring manager using the system's ranking as the sole basis for rejection, bypassing the human oversight measures in the instructions for use. You must identify these scenarios, assess the associated risks, and put controls in place — typically in the instructions for use and the human oversight design under Article 14.

How often must the Article 9 risk management system be reviewed?

The regulation does not prescribe a fixed review interval. It requires the process to be iterative and continuous — meaning review is triggered by events, not just by a calendar. Post-market monitoring data (Article 72), serious incidents (Article 73), changes to the system's intended use, or evidence of performance drift all constitute triggers. In practice, most providers establish a minimum annual review cycle, with event-triggered reviews in addition.

How does Article 9 interact with the Article 6(3) exemption filter?

Article 6(3) allows a provider to self-assess that their Annex III system does not pose a significant risk — because it performs a narrow procedural task, improves a previously completed human activity, detects decision patterns without influencing human assessment, or does preparatory work. If the exemption applies, Article 9 does not. But the exemption is not self-executing: you must document the self-assessment and register the system under Article 49. Note also that any system that profiles natural persons is always high-risk — Article 6(3) does not apply.

What is the penalty for failing to maintain an Article 9 risk management system?

Failure to comply with Article 9 is a breach of the high-risk provider obligations under Article 16. Under Article 99(4), the maximum fine is €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. For companies that are SMEs or start-ups, Article 99(6) caps the fine at the lower of the percentage or the fixed amount — a proportionality protection worth knowing, though it is not an exemption from the obligation itself.

Does alignment with ISO/IEC 42001 satisfy Article 9?

Partial alignment, not full satisfaction. ISO/IEC 42001 (AI management systems) covers similar ground and is a credible demonstration of organisational due diligence. But it is a voluntary certification standard, not a legal instrument. Your technical documentation must show explicit Article 9 compliance — risk inventory, evaluation, mitigation hierarchy, predefined test thresholds, post-market review loop — regardless of what certifications you hold. An ISO/IEC 42001 certificate does not replace an Article 9 risk register.

Related guides

• Article 8 high-risk compliance requirements
• risk classification framework overview
• Article 6 classification decision tree
• Article 9 full implementation guide
• Annex III medical imaging systems