EU AI Act Art.9 Risk Management System 2026: Implementing the Documentation in Practice

Post #1407 in the sota.io EU AI Act August 2026 Deadline Sprint Series — EU-AI-ACT-AUGUST-DEADLINE-SPRINT-2026 #2/5

You are in Sprint Week 2. The 9-week countdown to August 2, 2026 has begun (see your sprint plan). This week and next, you need to build the foundation document of your entire EU AI Act compliance stack: the Article 9 Risk Management System.

If you are a provider of high-risk AI — a company that develops, substantially modifies, or places on the EU market an AI system listed in Annex III — Art.9 compliance is not optional. It is the precondition for everything else: Art.10 data governance, Art.11 technical documentation, Art.17 quality management, and ultimately Art.43 conformity assessment all build on top of a functioning Art.9 risk management system.

This post is not a conceptual overview. For that, see Post #1394. This post is about the documentation artifacts you must actually produce, how to structure them, what auditors check during conformity assessment, and common mistakes that cause compliance gaps. By the end, you will have a 20-item checklist to verify your Art.9 documentation is audit-ready before August 2.

What Art.9 Requires (Sprint Essentials)

Art.9 mandates a risk management system — not a one-time risk assessment, but a documented, iterative process that runs across the entire AI system lifecycle. The regulation specifies:

• Continuous process: The RMS must be maintained and updated as the AI system evolves, as new risks are identified, and as real-world deployment generates feedback.
• Identification and analysis: You must identify all known and reasonably foreseeable risks that the AI system may pose across its intended use, foreseeable misuse, and the foreseeable interaction between the AI system and the environment in which it operates.
• Estimation and evaluation: Identified risks must be estimated (likelihood × severity) and evaluated against the benefits the AI system provides.
• Risk control: For each risk that cannot be eliminated at the design level, you must implement technical and organisational measures to reduce risk to acceptable levels.
• Testing against residual risks: The system must be tested to verify that residual risks fall within acceptable thresholds — including tests under real-world conditions where technically feasible.
• Lifecycle maintenance: The RMS must be reviewed and updated in response to post-market monitoring data (Art.72), incident reports (Art.73), and corrective actions (Art.20).

What this means in practice: Art.9 compliance is a living documentation system, not a box you check once. The good news is that you can start lean and build iteratively — the regulation allows proportionate implementation under Art.62 for SMEs and start-ups.

The Four Core RMS Documents

Most technical teams approaching Art.9 for the first time make the same mistake: they produce one large "risk assessment" document and consider Art.9 done. Conformity assessment bodies (CABs) under Art.43 expect to see a system — meaning multiple interlinked documents that together demonstrate continuous lifecycle management.

The four core documents that satisfy Art.9 are:

Document 1: Risk Management Policy

Length: 2–4 pages. Audience: Management + auditors. Purpose: Establishes the governance framework — who is responsible, what the process is, and how it connects to your quality management system (Art.17).

Required sections:

• Scope and applicability: Which AI systems are in scope, which Annex III category applies, intended use definition
• Governance structure: Risk owner(s), sign-off authority, escalation path
• Risk acceptance criteria: How you define "acceptable" vs. "unacceptable" residual risk (e.g. severity × likelihood matrix thresholds)
• Review cadence: When the RMS is reviewed — at minimum after significant design changes, incidents, and annually
• Linkage to other obligations: How Art.9 connects to Art.10 (data quality), Art.11 (technical docs), Art.17 (QMS), Art.20 (corrective actions)

Common mistake: Writing the policy for the AI system as a whole rather than per AI system / deployment scenario. If you operate multiple Annex III AI systems, each needs its own Art.9 documentation.

Document 2: Risk Register + Mitigation Matrix

Length: Varies (typically a spreadsheet or JIRA-tracked table). Audience: Engineering + auditors. Purpose: The operational core of your RMS — a structured inventory of all identified risks with their mitigations.

Required columns (minimum):

What auditors look for: Completeness across risk categories — technical failures, data quality risks, misuse risks, and discriminatory outcomes. If your register only covers technical failures and ignores bias or foreseeable misuse, expect a finding.

Tool recommendation for sprints: Notion or Confluence table for documentation-first teams; Linear or JIRA Epic with custom fields for engineering-first teams. Export to PDF for submission.

Document 3: Testing Protocol and Results Log

Length: Varies. Audience: Engineering + CAB. Purpose: Evidence that risk control measures were validated through testing before deployment and continue to be validated post-market.

Required structure:

• Test plan header: AI system version tested, test date, test environment, tester
• Test cases linked to Risk Register: Each test case should reference at least one Risk ID from Document 2
• Test conditions: Input data, edge cases, adversarial inputs where relevant
• Pass/fail criteria: What outcome constitutes acceptable residual risk
• Results: Actual outcomes, failure rates, confidence intervals where applicable
• Residual risk conclusion: The test result supports / does not support acceptance of the residual risk
• Sign-off: Tester + risk owner signatures (or equivalent Git commit trail)

For ML models specifically: Include accuracy metrics (overall + disaggregated by demographic subgroup if applicable), false positive and false negative rates, performance on edge cases, and out-of-distribution behaviour. Art.15 (accuracy, robustness, cybersecurity) feeds directly into this document.

Common mistake: Using internal performance metrics (e.g., F1 score on held-out test set) as the sole evidence of risk control. CABs expect to see testing under conditions representative of the intended use environment, not just benchmark datasets.

Document 4: Review Calendar and Evidence Trail

Length: Short (1 page + linked records). Audience: Management + auditors. Purpose: Demonstrates that the RMS is "iterative" as required — that reviews actually happen and that the system responds to new information.

Required content:

• Review schedule: When the RMS is reviewed, who is responsible
• Review triggers: List of events that trigger an unscheduled review (significant change, serious incident per Art.73, field feedback above threshold)
• Evidence of reviews completed: Date, reviewer, summary of findings, what changed in the Risk Register or Policy as a result
• Change log: Version history of all three documents above

Practical tip: Even for your first August 2026 submission, Document 4 should show at least one completed review cycle — the review that approved the initial RMS. Sign off a review meeting with a dated record before submission.

Integrating the RMS into Your Development Workflow

The Art.9 documentation does not live in isolation — it must be wired into your engineering processes to be credible as a "continuous iterative process." Here is how to connect the four documents to your existing tools:

GitHub / GitLab

• Create a /docs/compliance/rms/ directory in your main repository
• Store the Risk Register as a structured YAML or JSON file — version-controlled changes are automatically an audit trail
• Link Test Log entries to Pull Requests: add a RMS: R-042 mitigated label on PRs that address a specific risk
• Tag releases with compliance attestation — a release note confirming which Risk IDs were re-tested before this version shipped

Jira / Linear

• Create an Epic: "Art.9 RMS — AI System X v1.0"
• Each risk in the register becomes a Story with a custom field for Risk ID, severity, control status
• Testing tasks link back to Risk Stories
• Sprint reviews include an RMS review checklist item for the iteration

Confluence / Notion

• Master RMS document with embedded risk register table
• Use "Last Edited" metadata as your review trail
• Create a template page for each AI system — consistent structure across your portfolio
• Lock the published version and create a new draft for each update cycle

Common Mistakes That Fail Conformity Assessment

Based on the guidance published by EU notified bodies preparing for Art.43 assessments, these are the most common Art.9 gaps:

1. Static risk assessments presented as "RMS" A one-time document created before launch with no update mechanism is not an Art.9 risk management system. CABs will ask for evidence of at least one completed review cycle and a forward-looking review schedule.

2. Risk registers that only cover technical failures Art.9 requires identification of risks "associated with the use of high-risk AI systems." This explicitly includes foreseeable misuse, discriminatory outcomes, and impacts on vulnerable groups. A register that only covers model degradation and API failure will fail.

3. No link between testing results and risk acceptance Testing must be connected to specific risk control decisions. "We tested the model and it achieved 94% accuracy" is insufficient. The test must demonstrate that a specific residual risk (e.g., R-042: false positive rate causes denial of service benefit to protected group) falls below the acceptance threshold.

4. Disproportionate documentation for the risk level Going too far is also a problem. Art.62 explicitly allows proportionate approaches for SMEs. An exhaustive 200-page RMS for a low-risk Annex III system creates more compliance debt than it eliminates. Calibrate documentation depth to actual risk level.

5. Missing sign-off and governance evidence Who approved this risk as acceptable? Who reviewed the RMS in March? Without audit trail evidence — even simple Git commits, meeting notes, or email threads — claims of continuous management cannot be verified.

6. No connection to Art.17 QMS Your Art.9 RMS and your Art.17 Quality Management System are separate but linked obligations. The QMS is the management system that governs how you develop and maintain your AI; the RMS is the product-level risk process. CABs expect to see explicit linkage — your QMS procedures should reference the RMS, and vice versa.

The Minimum Viable RMS for August 2026

If you are an SME with one high-risk AI system and limited bandwidth, this is your sprint target for weeks 2–3:

Week 2 deliverables (by day 10 of sprint):

• Document 1 (Risk Management Policy) — draft version, 2 pages, signed by CTO/risk owner
• Document 2 (Risk Register) — first pass covering all obvious risk categories, minimum 10 risks documented
• Review meeting scheduled and recorded (establishes "iterative process" evidence)

Week 3 deliverables (by day 17 of sprint):

• Document 2 enriched — all risk categories covered including misuse and discriminatory outcome risks
• Document 3 (Testing Log) — test cases linked to top 5 highest-severity risks, results documented
• Document 4 (Review Calendar) — 12-month schedule established, first review recorded

Sprint Week 4 check: Before moving to Art.10 data governance, run the 20-item checklist below.

The August 2026 Art.9 Documentation Checklist

Use this before submitting for conformity assessment or completing your self-declaration of conformity.

Policy and Governance

• Risk Management Policy document exists and is dated
• Scope clearly defines which AI system(s) and which Annex III category
• Risk owner and sign-off authority named
• Risk acceptance criteria (likelihood × severity thresholds) documented
• Review triggers and review cadence defined

Risk Register

• All known and reasonably foreseeable risks identified
• Technical failure risks included
• Data quality risks included (especially if training data involves personal data)
• Foreseeable misuse scenarios included
• Discriminatory outcome risks addressed for applicable systems
• Each risk has inherent and residual scores
• All high-residual-risk entries have documented mitigation measures

Testing Log

• Testing protocol exists for each high/medium residual risk
• Test conditions reflect intended use environment (not just benchmark)
• Results documented with pass/fail against defined acceptance criteria
• Disaggregated performance metrics included where discriminatory risk applies
• Testing log version-controlled and linked to product releases

Evidence and Maintenance

• At least one completed review cycle documented (date, reviewer, findings)
• Change log showing document version history
• Explicit linkage to Art.11 technical documentation package
• Explicit linkage to Art.17 QMS procedures
• Post-market monitoring feedback loop defined (how field data updates the register)

What Comes Next in the Sprint

Art.9 is your foundation. The remaining posts in this sprint series build on it:

• Post #1408 (Sprint Week 4): Art.50 Transparency obligations — chatbot disclosures, AI-generated content labelling, and the technical implementation for August 2026
• Post #1409 (Sprint Week 5–6): Art.73 incident reporting — integrating your monitoring stack with the EU reporting obligation
• Post #1410 (Sprint Week 7–9): The August 2026 compliance finale — complete developer checklist before enforcement begins

For a full Art.9 provider deep-dive beyond the sprint context, see Post #1394. For deployer Art.9 obligations, see Post #1384.

Host Your Compliance Docs on EU Infrastructure

Your Art.9 documentation — risk registers, testing logs, review records — is sensitive compliance material. It should be hosted where it cannot be subject to US CLOUD Act production orders. sota.io is EU-native managed PaaS on Hetzner Germany: no US parent, no CLOUD Act exposure, GDPR-100%. Deploy your compliance tooling and internal documentation systems on infrastructure that matches your compliance posture. Git-push deploy from €9/month.

Sprint checkpoint: You have completed Week 2–3 objectives. Your Art.9 RMS is documented, version-controlled, and audit-ready. Move to Post #1408 for Sprint Week 4: Art.50 transparency obligations.