EU AI Act Art.9 Risk Management System: Foundations Every High-Risk AI Developer Must Know (2026)

Post #1 in the EU AI Act Art.9 Risk Management System 2026 Series

The EU AI Act's August 2026 deadline is 54 days away. If your product falls under Annex III — biometric identification, credit scoring, education, employment, critical infrastructure, public services, law enforcement, migration, or justice — you need a Risk Management System (RMS) under Art.9. Not a risk register. Not a one-time risk assessment. A continuous, lifecycle-spanning system that runs from design through decommissioning.

Most developers treat Art.9 compliance as a documentation exercise. It is not. The RMS is the load-bearing foundation beneath your conformity assessment, your technical documentation (Art.11), your data governance (Art.10), and your post-market monitoring (Art.72). If the RMS is missing or incomplete, every other compliance artefact rests on sand.

This is the first post in a five-part series that builds a practical, code-adjacent RMS implementation. Post 1 covers foundations — what Art.9 actually requires and how it maps to your existing SDLC. Subsequent posts cover risk identification methodology, testing requirements, continuous monitoring integration, and the documentation package that goes to conformity assessment.

What Art.9 Actually Requires

Art.9 defines the RMS in functional terms. It does not prescribe a specific format, software tool, or methodology. What it does prescribe is:

A continuous and iterative process (Art.9(1)). The RMS is not a gate at the end of development. It runs throughout the entire lifecycle of the high-risk AI system — design, development, testing, deployment, operation, and eventual decommissioning. Every lifecycle decision is, formally, an input to the RMS.

Known and foreseeable risks must be identified and analysed (Art.9(3)). "Known" means risks you have already encountered in testing or deployment. "Foreseeable" means risks a reasonable developer in your position should have anticipated. The regulator will not accept "we didn't know" for risks that are standard in your domain. If you're building a CV-screening tool, foreseeable risks include disparate impact across protected groups. Document them.

Risk estimation and evaluation (Art.9(4)). Each identified risk must be estimated — likelihood and severity — and evaluated against the benefit delivered by the system. This is where most compliance programmes go thin. A risk register with five-by-five probability/impact matrices is not the same as a documented risk-benefit analysis showing why residual risks are acceptable.

Risk mitigation measures must be chosen and implemented (Art.9(4)(b)). Mitigation measures are technical or organisational controls that reduce likelihood, severity, or both. The RMS must document which measures were selected, which were considered but rejected (and why), and the residual risk after each measure is applied.

Residual risks must be disclosed to deployers (Art.9(5)). After all technically and economically feasible mitigation measures have been applied, remaining risks must be communicated to deployers via the instructions for use (Art.13). This creates a direct coupling between RMS outputs and Art.13 documentation.

Testing procedures must verify consistent performance (Art.9(6)). The RMS must include test procedures that evaluate performance across the entire Annex III use-case envelope — not just the happy path. For systems that act on different demographic groups (nearly every Annex III system), this means testing across representative subpopulations.

Fundamental rights risks must be considered (Art.9(2)). The RMS must account for risks to fundamental rights, particularly for systems operating in the Annex III categories that intersect with public services, law enforcement, and biometrics.

The RMS Is Not a Document — It's a Process Artifact

This is the conceptual shift most teams miss. Art.9 requires the RMS to be "established, implemented, documented, and maintained" (Art.9(1)). The documentation is evidence that the process happened — not the process itself.

In practice this means:

The RMS must produce artefacts at each lifecycle stage. A design-time risk analysis is an RMS artefact. A test failure that reveals a new risk is an RMS artefact. A post-deployment monitoring alert that escalates to a risk review is an RMS artefact. Your conformity assessor will look for a chain of artefacts that demonstrates continuous operation, not a PDF produced in the week before submission.

The RMS must have a version history. Because the risk profile of a high-risk AI system changes over its lifetime — new use cases emerge, new vulnerabilities are discovered, the regulatory landscape shifts — the RMS must be versioned. Art.9(1) requires the system to run "throughout the entire lifecycle," which implies it must capture how the risk profile evolved over time.

The RMS must reference the system it governs. Generic risk frameworks do not satisfy Art.9. The RMS must be specific to the high-risk AI system in question, referencing the specific Annex III category, the specific intended purpose, the specific deployment context, and the specific user population.

Mapping Art.9 to Your SDLC

The good news: if your team follows any structured development methodology — agile sprints, waterfall phases, CI/CD pipelines — you already have natural RMS integration points. The question is whether those integration points are documented as RMS activities.

Design phase (Art.9(3)): Risk identification belongs here. Before writing a line of code, the RMS should capture the foreseeable risks of the system's intended purpose. For an employment screening tool, this means foreseeable bias risks. For a credit scoring model, this means foreseeable discrimination risks under Art.9(10) (the insurance and credit-specific provision). For any system processing biometric data, this means foreseeable privacy and accuracy risks.

Design-phase risk identification outputs:

• Identified risk list (structured: risk ID, risk description, risk category, foreseeable scenario)
• Preliminary risk estimation (likelihood × severity before any mitigation)
• Initial mitigation candidates (not yet selected — just identified)

Development phase (Art.9(4)): Risk mitigation measures are chosen and implemented. This is where technical controls — bias detection pipelines, uncertainty quantification, adversarial testing, input validation — are built. Each control must be linked back to the specific risk it addresses in the RMS.

Development-phase outputs:

• Risk mitigation decision log (why each measure was selected or rejected)
• Residual risk estimates after mitigation
• Links between code commits/pull requests and the risks they address

Testing phase (Art.9(6)–(8)): Test procedures that verify the system performs consistently across its intended use envelope, across demographic subgroups, and under foreseeable misuse conditions. Art.9(8) specifically addresses testing data — it must be appropriate for the intended purpose and representative of the populations the system will encounter.

Testing-phase outputs:

• Test plan linked to identified risks
• Subpopulation performance data (the basis for Art.13 accuracy disclosures)
• Bias evaluation results
• Adversarial or misuse test results
• Final residual risk assessment

Deployment/Operations phase (Art.9(1)): The RMS continues. Post-market monitoring (Art.72) feeds back into the RMS. Any serious incident (Art.73) triggers an RMS review. New risks discovered in operation must be assessed, and additional mitigation measures must be considered.

Operations-phase inputs to RMS:

• Monitoring alerts that indicate performance degradation
• User or deployer-reported anomalies
• Regulatory guidance updates that affect risk categorisation
• Art.73 serious incident reports

The Art.9(10) Special Case: Credit Scoring and Insurance

Art.9(10) introduces heightened requirements for high-risk AI systems used for credit scoring, life insurance, and health insurance. For these systems, the RMS must also address the specific prohibition on discrimination based on characteristics that are proxies for protected attributes — including postal codes as proxies for ethnicity, and employment history patterns that correlate with disability.

If your system falls under Annex III point 5(b) (credit scoring) or is a component of insurance risk classification, the RMS must explicitly document:

1. Which input features were considered and which were rejected because they function as protected-attribute proxies
2. The disparate impact analysis performed on the selected feature set
3. The residual discrimination risk after feature selection and debiasing measures

This is above and beyond the general subpopulation testing requirements of Art.9(6)-(8). It requires intent documentation — showing that the feature selection process was informed by discrimination risk analysis, not just that post-hoc performance was evaluated.

RMS Documentation Structure: Minimum Viable Artefact Set

A conformity assessor conducting an Annex VII audit will look for at minimum:

The Annex IV technical documentation requirements (Art.11) incorporate the RMS as a mandatory section. Section 2(c) of Annex IV explicitly requires "a description of the risk management system in accordance with Article 9."

The Infra Question: Where Does the RMS Live?

This is where sota.io's EU-native infrastructure matters for Art.9 compliance. The RMS artefacts — risk registers, mitigation logs, test results, monitoring feedback — are operational compliance documentation. They must be:

• Accessible to conformity assessors without CLOUD Act jurisdiction issues. If your RMS lives in an AWS S3 bucket, a US government subpoena can reach it without your knowledge. If you're a provider under EU AI Act Art.9, you have obligations to protect the integrity of your compliance documentation.
• Immutable for audit purposes. Art.9(1)'s "maintained" requirement implies records cannot be retroactively altered. Use append-only storage with timestamps.
• Available for the 10-year post-last-market-availability period (Art.16(1)(d)). RMS artefacts are part of the technical documentation that must be retained for 10 years after the system is placed on the market or put into service.

EU-native, CLOUD-Act-free infrastructure (Hetzner Germany via sota.io) means your RMS lives in a jurisdiction where Art.9 documentation cannot be unilaterally accessed by a foreign authority — and where your conformity assessor has unambiguous access rights.

What's Coming in Posts 2–5

This series continues with:

• Post 2: Risk identification methodology — how to run structured risk identification sessions for Annex III systems, with concrete templates for employment screening, credit scoring, and biometric identification use cases.
• Post 3: Testing requirements under Art.9(6)–(8) — how to structure test suites that satisfy the RMS testing mandate, including subpopulation testing frameworks.
• Post 4: Continuous risk management — integrating Art.9 with Art.72 post-market monitoring so that monitoring findings automatically feed back into the RMS update cycle.
• Post 5: The complete RMS documentation package — the artefact set that satisfies Annex IV, Art.9, and a notified body audit, with a pre-August-2026 completion checklist.

The August 2026 deadline is 54 days away. If you're building a high-risk AI system and your RMS consists of a risk register someone made in a spreadsheet six months ago, that needs to change.

Related Posts

• EU AI Act Art.9: Risk Management System Documentation and Hosting Requirements — infrastructure angle
• EU AI Act + CRA Dual Compliance: The Complete Developer Checklist — integration checklist
• EU AI Act Post-Market Monitoring: SaaS Developer Checklist — Art.72 integration