EU AI Act Art.9 Risk Management System: Integrating with Your QMS

Post #3 in the sota.io EU AI Act Quality Management System Series

Article 17 of the EU AI Act requires every high-risk AI provider to operate a Quality Management System. But the QMS is not self-contained — it references and depends on Article 9, which mandates a risk management system (RMS) as a prerequisite. You cannot satisfy Art.17 without first building the risk management infrastructure Art.9 demands.

This guide explains what Art.9 actually requires, how its four iterative phases translate into engineering tasks, and how the outputs of your RMS flow into the broader QMS your team is building before the August 2, 2026 enforcement deadline.

Why Art.9 Is the Foundation of Your QMS

Article 17(1)(b) explicitly requires your QMS to document "examination, testing, and validation procedures to be carried out before, during, and after the development of the high-risk AI system." Every one of those procedures must trace back to a risk identified and assessed under Art.9.

Without a functioning Art.9 risk management system, your Art.17 QMS has no factual basis. Risk-linked test plans become arbitrary checklists. Conformity assessment under Art.43 fails because examiners will ask: where did your test criteria come from? The answer must be: from our Art.9 risk register.

Art.9(2) states that the risk management system shall consist of a continuous iterative process — not a one-time document. This is a recurring engineering commitment that must be embedded in your development lifecycle.

The Four Iterative Phases

Art.9(2) defines the process in four steps. Here is how each one maps to practical engineering deliverables.

Phase 1: Identify and Analyse Known and Foreseeable Risks

Art.9(2)(a) requires you to "identify and analyse the known and foreseeable risks that the high-risk AI system can pose to health, safety, or fundamental rights."

Critically, Art.9(3) specifies the scope of risks to consider:

• Risks arising from the intended purpose of the system
• Risks arising from reasonably foreseeable misuse, including use contrary to intended purpose
• Risks arising from the interaction of the system with others, including persons and other AI systems

The word "foreseeable" is doing significant work here. You are not only responsible for risks you designed in — you are responsible for risks any reasonable engineering team would anticipate.

Practical deliverable: A risk identification register with at minimum three columns: risk description, trigger scenario (normal use / misuse / combined use), and affected population (user type, vulnerable groups, third parties). For a healthcare decision-support system, this register might include 40–80 initial entries before any prioritisation.

Tooling approach: Many teams run structured risk identification workshops using a modified FMEA (Failure Mode and Effects Analysis) template. For AI-specific risks, supplement standard FMEA with AI-specific failure modes: distributional shift, spurious correlations, adversarial inputs, and feedback loops.

Phase 2: Estimate and Evaluate Risks

Art.9(2)(b) requires estimation and evaluation of risks that may emerge under normal use and reasonably foreseeable misuse.

Estimation involves two dimensions: probability of occurrence and severity of harm. Art.9(4) specifies that when estimating probability and severity, you must consider:

• The degree to which the system may cause harm, especially considering the number of persons affected
• The severity of harm, including reversibility
• The dependency of persons on the outcome of the system
• The potential vulnerability of affected persons, in particular children

This is not a generic safety matrix. The regulation specifically calls out vulnerable populations, which means your risk scoring must apply higher severity weights when the affected users include children, people with disabilities, or people in positions of power asymmetry (immigration applicants, loan applicants, job candidates).

Practical deliverable: A risk matrix with probability (1–5) × severity (1–5) = risk score (1–25), with documented rationale for each rating. Critically, this matrix must be version-controlled alongside your model artefacts — when your model changes, the risk matrix must be re-evaluated.

Risk ID | Description                        | Prob | Severity | Score | Status
--------|-------------------------------------|------|----------|-------|--------
R-001   | False negative in fraud detection   |  3   |    4     |  12   | Mitigated
R-002   | Bias against non-native speakers    |  2   |    5     |  10   | Open
R-003   | Model inversion attack exposing PII |  2   |    4     |   8   | Mitigated

Phase 3: Adopt Risk Management Measures

Art.9(2)(c) requires you to "adopt appropriate risk management measures." Art.9(4) provides a prioritisation hierarchy:

1. Eliminate or reduce risks as far as possible through adequate design and development
2. Where appropriate, implement adequate mitigation and control measures for risks that cannot be eliminated
3. Provide information required by Art.13 (transparency obligations) with respect to residual risks

This hierarchy matters for legal compliance: you cannot mitigate a risk that is eliminable through redesign. A model that produces discriminatory outputs due to a specific input feature should have that feature removed if removal is technically feasible — mitigation-only is only appropriate if elimination is not feasible.

Practical deliverable: For each identified risk, document: the chosen treatment (eliminate / mitigate / accept), the specific technical or organisational measure applied, the residual risk level after treatment, and the owner responsible for the measure.

Integration with Art.14 (Human oversight): For risks that cannot be fully mitigated technically, Art.9(6) explicitly requires consideration of whether the risk can be addressed through human oversight measures. This creates a direct data flow from your Art.9 risk register to your Art.14 human oversight design — each residual risk above a threshold should trigger a corresponding oversight control.

Phase 4: Test Residual Risks

Art.9(7) requires that the overall residual risk associated with each hazard is determined to be acceptable. Testing is how you produce the evidence that residual risks remain below your acceptance threshold.

Art.9(8) is particularly demanding for self-learning systems: if your AI system continues to learn after initial deployment, risk management measures must ensure that prior learning does not adversely affect the system's compliance with the Regulation. This means you need post-deployment risk monitoring as an ongoing obligation, not a one-time pre-launch test.

Practical deliverable: A test plan that maps each risk in your register to one or more test cases, specifying: test method (statistical evaluation, red-team exercise, third-party audit), acceptance criterion (pass/fail threshold), test frequency (pre-deployment, quarterly, on-drift-detection), and evidence storage location.

Risk Management for Children: The Enhanced Obligation

Art.9(4)(b) calls out the "potential vulnerability of the persons concerned, in particular because they are children" as a factor in severity estimation. This is not an abstract principle — it has practical consequences.

If your high-risk AI system is used in educational contexts, child welfare systems, or any setting where the affected population may include minors, you must apply enhanced severity multipliers in your risk matrix. A risk rated severity 3 for adults may require severity 5 for children, changing a medium-priority risk to a critical one that demands elimination rather than mitigation.

Connecting Art.9 Outputs to Your Art.17 QMS

The risk management system and the QMS are not parallel tracks — the RMS produces outputs that the QMS consumes. Here are the primary data flows:

Versioning requirement: Each time you make a significant change to your model — new training data, architecture change, deployment to a new use case — your Art.9 risk management cycle must restart from Phase 1. The QMS must document the trigger conditions for re-evaluation and how the updated risk register flows into updated test procedures.

Infrastructure Checklist for August 2, 2026

Before August 2, your Art.9 + Art.17 integration must satisfy the following:

• Risk identification register exists and covers intended purpose, misuse, and combined-use scenarios
• Risk matrix with probability × severity scoring is version-controlled alongside model artefacts
• Each risk has a documented treatment decision (eliminate / mitigate / accept) with technical owner
• Residual risks above acceptance threshold feed directly into Art.14 human oversight design
• Test plan links each risk to at least one test case with acceptance criterion
• Post-deployment re-evaluation triggers are defined and documented in the QMS
• Children or other vulnerable populations identified and flagged for enhanced severity weighting
• QMS document control ensures updated risk matrices are reflected in technical documentation

What Comes Next in This Series

Post 1 covered the eight mandatory elements of the Art.17 QMS. Post 2 covers the Art.11 technical documentation infrastructure that stores your QMS outputs. This post (Post 3) covers the Art.9 risk management foundation that feeds the QMS. Post 4 will cover Art.72 post-market monitoring — the obligation that keeps your QMS alive after deployment. Post 5 will provide a complete audit readiness checklist for the August 2026 enforcement deadline.

Building on sota.io means your compliance infrastructure runs on EU-native compute from day one — no CLOUD Act exposure for your risk registers, model artefacts, or audit logs. Every artefact your Art.9 and Art.17 system generates stays in EU jurisdiction.