EU AI Act Art.9 RMS Finale: Building Your Documentation Package and Fulfilling Maintenance Obligations

Post #1467 in the sota.io EU AI Act Risk Management Series (RMS-2026 #5/5)

You have identified your risks. You have built controls. You have run your pre-deployment tests. Now you need to prove it — and keep proving it every day your system operates.

This is the fifth and final post in the EU AI Act Art.9 Risk Management System series. Previous posts covered the RMS framework (1/5), risk identification and failure modes (2/5), risk controls and mitigation (3/5), and testing and validation procedures (4/5). This post covers what ties everything together: the documentation package that makes your RMS audit-ready, and the maintenance obligations that continue after your August 2, 2026 go-live.

Why Documentation Is Not an Afterthought

The EU AI Act creates a specific legal category: technical documentation. Under Art.11, providers of high-risk AI systems must draw up technical documentation before placing a system on the market. This documentation must remain up to date throughout the system's lifetime.

The Annex IV of the AI Act specifies exactly what this documentation must contain. Critically, the risk management system — your Art.9 work — is a mandatory component of the Art.11 technical documentation. Market surveillance authorities can request this documentation at any time. If you cannot produce it, or if it is incomplete, you are in non-compliance regardless of what your system actually does.

Three failure modes appear repeatedly in compliance practice:

Work exists but is not captured. Teams run risk assessments in meetings, implement controls in code, and run validation tests in pipelines — but none of it is recorded in a form that could be shown to an auditor. The work happened; the evidence did not.

Documents exist but are not structured for the regulation. Internal wikis, Jira tickets, and Confluence pages may capture the substance of your RMS work without mapping to the Annex IV structure. An auditor cannot efficiently verify compliance from unstructured internal documentation.

Documents were current at launch but are not maintained. Art.9 requires a living system. Documentation that was accurate at August 2026 launch but has not been updated as the AI system evolved fails the ongoing obligation — not just the initial one.

The Four Core RMS Documents

Your Art.9 documentation package must include four functional document types, regardless of how you name or organize them internally.

1. Risk Management Policy

The policy is the governing document that describes your approach. It should cover:

• Scope: which AI systems are within scope of this RMS
• Governance: who owns the RMS, who reviews it, who can authorize changes
• Risk tolerance: what level of residual risk is acceptable before deployment
• Review cadence: how frequently the risk register and controls are reviewed
• Integration: how the RMS connects to your software development lifecycle, incident response, and change management processes

The policy does not need to be long. A clear 3–5 page document that answers these questions is more defensible than a 50-page document that buries the answers in process narrative.

2. Risk Register

The risk register is the operational heart of your Art.9 RMS. Each entry should capture:

• Risk identifier and description
• Affected intended purpose and use case
• Foreseeable misuse scenarios linked to this risk
• Likelihood and severity assessment (with the methodology used)
• Assigned risk controls and their type (technical, procedural, or human oversight)
• Residual risk level after controls
• Owner and review date

The risk register is a living document. It should be versioned. Each version should be dated and linked to the system version it covers.

A minimum viable risk register for a high-risk AI system has at least 15–25 entries. Fewer than ten entries typically indicates that the risk identification process was not thorough enough to meet Art.9 requirements.

3. Testing Log

The testing log documents that your pre-deployment validation procedures were carried out and what they found. Each test run entry should record:

• Test date and system version under test
• Test type (functional, adversarial, bias evaluation, edge case coverage, performance degradation)
• Test environment and dataset characteristics
• Results: pass/fail per test case, accuracy metrics, failure mode instances observed
• Risk controls verified by this test run
• Any anomalies found and how they were addressed

The testing log must be tied to the risk register. An auditor should be able to trace from a risk entry, through the controls designed to address it, to the test cases that validated those controls, and to the test results that show the controls work.

4. Review and Update Record

This document captures your ongoing compliance activity after initial deployment. Each entry should record:

• Review date and triggering event (scheduled review, incident, system change, regulatory update)
• Aspects reviewed (risk register, controls effectiveness, test coverage, documentation currency)
• Changes made and their rationale
• Sign-off by the designated responsible person

The review record is the primary evidence that you are meeting the ongoing Art.9 obligation — the requirement that the RMS is iterative and continuously updated.

Structuring Documents for Annex IV Compliance

Annex IV of the EU AI Act specifies the required contents of technical documentation. Section 2 of Annex IV covers the risk management system specifically. Your documentation package must be structured so that an auditor can locate the Annex IV Section 2 elements without difficulty.

The Annex IV Section 2 elements your documentation must address:

2(a): Identification and analysis of known and foreseeable risks. This maps to your risk register. The register must be present and must show identified risks across intended purpose, foreseeable misuse, and reasonably foreseeable conditions.

2(b): Estimation and evaluation of risks that may emerge when the system is used in accordance with its intended purpose. This requires more than listing risks — it requires an assessment of how likely and how severe each risk is. Your risk register entries with likelihood/severity assessments fulfill this.

2(c): Estimation and evaluation of risks that may emerge when the system is subject to reasonably foreseeable misuse. Foreseeable misuse scenarios must be explicitly documented. They are not the same as intended purpose risks. A separate column or section in the risk register for misuse scenarios is the clearest way to satisfy this.

2(d): Adoption of suitable risk management measures in accordance with the provisions of the following sections. This covers your controls documentation and the test log showing controls are validated.

When creating or reorganizing your documentation, map each document section explicitly to the Annex IV reference it satisfies. A simple cross-reference table at the start of your technical documentation package helps auditors and reduces review time.

Maintenance Obligations: What Art.9 Requires After Deployment

Art.9 explicitly states that the risk management system must apply throughout the entire lifecycle of a high-risk AI system. The obligations do not end at deployment. Three categories of ongoing obligation apply.

Scheduled Reviews

Your RMS must be reviewed regularly. The regulation does not specify a mandatory interval — it requires that the interval be appropriate for the risk level and rate of change of the system. For most high-risk AI SaaS applications:

• Annual review is the minimum acceptable baseline
• Quarterly reviews are appropriate for systems that change frequently or operate in high-stakes domains
• Systems with active model retraining should review after each significant model update

Each scheduled review should assess: whether identified risks are still accurate, whether controls remain effective, whether new risks have emerged from operational data, and whether the testing log is current.

Event-Triggered Reviews

Certain events must trigger an immediate or near-term review of relevant RMS elements, even if a scheduled review is not due:

Significant system modification. Any change to the AI model, its training data, its input/output interface, or its integration architecture constitutes a modification that requires assessment of whether existing risks and controls remain applicable.

Operational incident. When the system produces an outcome that matches a documented failure mode, or produces an unexpected output in a high-stakes context, the incident must be analyzed against the risk register. If the failure was not anticipated, the register must be updated.

Post-market monitoring data indicating new risks. Art.9 requires that post-market monitoring data feed back into the RMS. If monitoring data shows that actual system behavior differs from what was modeled in the risk assessment, an update is required.

Regulatory change. Updates to implementing acts, harmonized standards, or guidelines under the AI Act may change what your RMS must address.

Serious Incident Reporting

Under Art.73 of the EU AI Act, providers are required to report serious incidents to national market surveillance authorities. A serious incident is defined as one that results in death or serious injury to persons, damage to health, serious property damage, or other significant societal impacts.

The timelines under Art.73 are specific: 15 days for most serious incidents, 10 days for incidents involving risk to life, and 2 days for incidents involving actual death. These timelines run from the provider becoming aware of the incident.

Your RMS documentation must include an incident response procedure that connects your post-market monitoring to the Art.73 reporting obligation. The procedure should specify who is responsible for making the determination that a reportable incident has occurred, how that determination is escalated, and how incident documentation is prepared.

The Audit-Ready RMS: A Practical Checklist

Before August 2, 2026, your documentation package should be able to satisfy the following verification:

Document completeness:

• Risk Management Policy exists, is dated, and is signed by an accountable person
• Risk Register covers intended purpose risks, foreseeable misuse risks, and environmental/deployment risks
• Testing Log includes results from pre-deployment validation tied to risk controls
• Review and Update Record exists, even if it records only the initial baseline review

Annex IV cross-reference:

• A cross-reference table maps each Annex IV Section 2 element to the document that fulfills it
• The cross-reference covers all four Annex IV Section 2 requirements (a) through (d)

Traceability:

• Each risk register entry references the controls that address it
• Each control references the test cases that validated it
• Each test case references the test results in the Testing Log

Maintenance readiness:

• A review schedule is documented and assigned to a responsible owner
• Event-triggered review criteria are defined (system modification, incident, monitoring anomaly)
• An incident escalation procedure exists with Art.73 timelines documented
• Post-market monitoring data has a defined path back into the risk register

Document control:

• All documents are versioned and dated
• A retention policy is in place (the regulation does not specify duration, but five years aligns with other EU compliance frameworks)
• Documents are stored in a location accessible for regulatory audit without advance processing time

Common Gaps Found in RMS Documentation Reviews

Based on patterns in early compliance preparation across the EU SaaS market, five gaps appear most frequently.

No connection between risk register and test log. The two documents exist independently, making it impossible to verify that the testing actually addressed identified risks. Fix: add a cross-reference column to the risk register that lists the test IDs that validate each control.

Test log captures pass/fail but not what failed. Compliance requires understanding of failure modes observed during testing, not just pass/fail ratios. Fix: add a failure instance capture field to each test log entry, even if it records "none observed."

Post-market monitoring is described but not connected to RMS. Many providers document that they monitor their systems but do not specify how monitoring findings trigger risk register updates. Fix: add a formal feedback loop step to the RMS policy that names the person responsible for reviewing monitoring data against the risk register.

Review record has never been updated. The initial documentation dates from pre-launch but shows no subsequent review entries. Fix: schedule the first post-launch review within 90 days and enter it in the record, even if it finds no changes required.

Technical documentation is stored in a format not accessible for audit. Scattered Notion pages, Jira tickets, and Confluence spaces that require internal system access cannot be produced quickly for a market surveillance authority. Fix: export a consolidated PDF or archive of the current RMS documentation quarterly, stored with access credentials that survive individual team member departures.

Connecting to the Broader Compliance Architecture

The Art.9 RMS does not stand alone. At minimum, it connects to three other compliance obligations:

Art.11 technical documentation contains the RMS. The technical documentation is the package submitted with conformity assessment; the RMS is a required component of it.

Art.12 record-keeping requires that high-risk AI systems be capable of automatically logging events that affect safety and functionality. The records produced by Art.12 logging are an input to the Art.9 post-market monitoring obligation and to incident review.

Art.14 human oversight obligations require that deployers have the capability to understand and interpret the outputs of the system and intervene when necessary. Your RMS should document how human oversight is integrated into the risk controls — particularly for risks where the primary control is human review rather than automated mitigation.

From Documentation to Compliance

The EU AI Act's August 2, 2026 deadline applies to placing high-risk AI systems on the EU market. If you are a provider of a high-risk AI system, you cannot legally place or make available that system in the EU market after that date without a complete Art.9 RMS — including documentation that meets the Annex IV requirements.

What this series has covered:

1. The Art.9 RMS framework: what it is and why it applies to high-risk AI SaaS
2. Risk identification: systematically mapping failure modes and foreseeable misuse
3. Risk controls: selecting and implementing technical, procedural, and human oversight measures
4. Testing and validation: pre-deployment procedures that verify controls work
5. Documentation package and maintenance: structuring evidence for audit and meeting ongoing obligations

The final step is the one that requires consistent effort: maintaining the RMS after launch. The providers who will pass market surveillance reviews in 2027 and beyond are not those who built the best documentation in June 2026 — they are the ones who kept it current.

This completes the EU-AI-ACT-RMS-2026 five-part series on Art.9 Risk Management System compliance. The related EU-AI-ACT-CICD-COMPLIANCE-TESTING-2026 series continues with automated compliance pipelines that connect directly to the RMS documentation workflow covered here.