EU AI Act Art.9 Risk Management System: Why Your RMS Documentation Storage Is a Compliance Variable

Post #3 in the EU AI Act Infrastructure Compliance Series

EU AI Act Article 9 requires providers of high-risk AI systems to establish, implement, document, and maintain a risk management system (RMS) throughout the product lifecycle. The standard compliance checklist covers the process: identify risks, estimate probability, adopt mitigations, test against benchmarks, communicate residual risks to deployers.

What almost no compliance guide addresses is the infrastructure question: where does your RMS documentation physically live? If the answer is AWS S3, Azure Blob Storage, or Google Cloud Storage, you have a CLOUD Act exposure problem that Art.9 compliance alone cannot solve.

What Art.9 Actually Requires

Article 9 of the EU AI Act establishes the risk management system as a continuous, iterative process running from initial development through post-deployment monitoring. The core documentation obligations include:

Art.9(2) — Risk identification and analysis: Providers must identify and analyze known and reasonably foreseeable risks associated with the high-risk AI system when used as intended and under conditions of reasonably foreseeable misuse.

Art.9(3) — Risk estimation and evaluation: Where a risk cannot be eliminated, it must be estimated and evaluated. This produces documented risk scores, probability assessments, and severity classifications — all of which must be recorded.

Art.9(4) — Risk management measures: Appropriate risk management measures adopted in accordance with Art.9(5) must be documented. This includes test results, validation outcomes, and benchmark comparisons.

Art.9(7) — Residual risk communication: Providers must communicate residual risks to deployers via the instructions of use. The source documentation backing those communications must be maintainable and auditable.

The phrase "established, implemented, documented, and maintained" in Art.9(1) is not procedural boilerplate. It creates a documentation trail. That trail lives in files, databases, and version-controlled repositories — somewhere on infrastructure you control (or think you control).

The Infrastructure Problem No One Is Talking About

If your RMS documentation is stored on AWS S3 (Amazon Inc., US parent), the US government can compel Amazon to produce it via CLOUD Act §2 without notifying you or EU regulatory authorities. The same applies to Azure Blob Storage (Microsoft) and Google Cloud Storage (Alphabet).

This creates three compliance risks that Art.9 alone cannot address:

1. NCA Inspection Integrity (Art.74)

Article 74 grants EU national competent authorities (NCAs) the right to access your AI system's technical documentation, including the risk management system records, during market surveillance. When an NCA requests your Art.9 documentation, you are representing that the risk register accurately reflects your current, uncompromised assessments.

If US authorities have accessed your RMS documentation through a sealed CLOUD Act production order — which, by definition, you may not know about — you are potentially handing the NCA documentation that has been reviewed, copied, or acted upon by a third party without your knowledge. The NCA has no way to verify the chain of custody. You may not either.

2. Continuous Integrity Obligation (Art.9(1))

Art.9 requires the risk management system to be a "continuous iterative process throughout the entire lifecycle." The word "maintained" implies that your risk documentation must remain accurate and uncompromised over time.

A sealed CLOUD Act subpoena targeting your risk register would not give you notice to correct or update the documentation. Your Art.9(1) continuous maintenance obligation and the US government's ability to access your risk documentation without disclosure are structurally incompatible.

3. Residual Risk Communication Chain (Art.9(7))

Deployers of your high-risk AI system rely on the residual risk disclosures you provide. Those disclosures are backed by your RMS documentation. If your risk documentation has been subject to a sealed production order, the deployers' ability to independently verify your residual risk assessments is compromised before they even begin.

In a post-August 2026 enforcement environment, where deployers have their own Art.26 obligations and face Art.99 penalties for non-compliance, the integrity of your Art.9(7) residual risk disclosures is not an academic question.

What Art.9 Read With Art.11 and Art.74 Implies About Infrastructure

Article 11 requires technical documentation to include the risk management system elements. Annex IV specifies what that documentation must contain, including descriptions of risk management measures and test results. Article 74 gives NCAs authority to inspect this documentation on demand.

Together, these three articles create an implicit infrastructure requirement: your RMS documentation must be accessible to EU regulatory authorities via an uninterrupted, EU-jurisdiction chain of custody. The EU AI Act does not grant US district courts the right to access EU market surveillance records. But CLOUD Act §2 grants US courts exactly that right over any US-parent provider — regardless of where the data center is located.

A German AWS data center is not outside CLOUD Act reach. Amazon Germany GmbH operates infrastructure for Amazon Web Services Inc. When a US court issues a CLOUD Act order to Amazon Web Services Inc., the legal obligation falls on the US parent, not the German subsidiary.

EU-Native Storage for RMS Documentation: What to Move

The solution is not complex architecturally. It requires identifying which parts of your Art.9 documentation trail are on US-parent infrastructure and moving them to EU-native providers.

Risk register: Your documented risk identification, probability scores, severity assessments, and mitigation status should live in EU-native object storage with versioning enabled. Hetzner Object Storage, Scaleway Object Storage, and OVHcloud Object Storage are all outside CLOUD Act jurisdiction (no US parent). Enable versioning so every risk register update is traceable — this supports the Art.9(1) continuous maintenance audit trail.

Test and validation logs: Art.9(5) testing results against product standards (EN ISO/IEC 42001, harmonized standards) should be stored in EU-native block storage with WORM (write-once-read-many) settings where possible. Immutability makes your test record tamper-evident for NCA inspection.

Residual risk documentation: The internal documentation backing your Art.9(7) deployer risk communications should be version-controlled in EU-native git infrastructure — Gitea or Forgejo on EU-hosted servers — rather than GitHub (Microsoft, US parent) or GitLab SaaS (US entity).

Mitigation measure audit trail: Every change to your risk mitigation register should have a timestamped, authored audit entry stored on EU-native infrastructure.

Practical RMS Infrastructure Architecture

For high-risk AI providers targeting the August 2, 2026 deadline:

EU AI Act Art.9 — Infrastructure Architecture

[Risk Register]
  → EU-native object storage (Hetzner / Scaleway / OVHcloud)
  → S3-compatible API, versioning enabled
  → Access logs: WORM-protected

[Test & Validation Records (Art.9(5))]
  → EU-native block storage
  → Immutable retention: 10 years (Art.11 + Art.18)
  → Hash verification on write

[RMS Documentation (Art.11 / Annex IV)]
  → EU-native git repository (Gitea / Forgejo)
  → Signed commits (author, timestamp, content hash)
  → Branch protection: no force-push on main

[Residual Risk Disclosures (Art.9(7))]
  → EU-native document store
  → Versioned, auditable, NCA-accessible on request

[Access Control]
  → IAM: EU-resident identity provider
  → No US-parent SSO (no Okta if US legal entity, no Azure AD)

The Difference Between EU-Datacenter and EU-Parent

This distinction matters more for Art.9 compliance than for most other compliance frameworks.

EU-datacenter, US-parent (e.g., AWS Frankfurt Region): CLOUD Act jurisdiction applies. US courts can compel the US parent to produce your RMS documentation. NCA inspection integrity cannot be guaranteed.

EU-native, EU-parent (e.g., Hetzner Object Storage, Scaleway, OVHcloud): CLOUD Act does not apply. Your RMS documentation is accessible only to parties with EU-jurisdiction legal authority — the EU courts, your NCAs, and you.

sota.io deploys on Hetzner Germany, has no US parent, and is not subject to CLOUD Act reach. That infrastructure characteristic becomes a compliance feature when the documentation you are protecting is your Art.9 risk management system.

10-Point RMS Infrastructure Compliance Checklist

Before August 2, 2026:

1. Map where Art.9 documentation lives — risk register, test logs, mitigation records, residual risk disclosures
2. Identify US-parent cloud dependencies — AWS S3, Azure Blob, GCP, GitHub, GitLab SaaS
3. Migrate risk register to EU-native object storage with versioning and access logging
4. Enable WORM on Art.9(5) test result storage — immutability protects test integrity
5. Move RMS git history to EU-native git hosting — Gitea/Forgejo on EU-sovereign infra
6. Verify CI/CD pipelines don't write RMS artifacts to US-parent cloud as build outputs
7. Archive Art.9(7) residual risk disclosures on EU-native document storage
8. Confirm NCA access path — document how your NCAs can access RMS documentation via EU-jurisdiction data access procedures
9. Test access log integrity — verify that your RMS access logs are tamper-evident
10. Add infrastructure provider to Art.11 technical documentation — list where each documentation type is stored

Series Context

This post is part of the EU AI Act Infrastructure Compliance series examining the infrastructure decisions that EU AI Act obligations implicitly require:

1. Art.12 & Art.19 Record-Keeping: Log Storage Jurisdiction & CLOUD Act Exposure
2. Art.10 Training Data Governance: EU Jurisdiction Requirements
3. Art.9 Risk Management System: Documentation Hosting & CLOUD Act (this post)
4. Art.74 Market Surveillance Cooperation: Infrastructure Requirements (coming)
5. EU AI Act Infrastructure Compliance: Complete Checklist Finale (coming)

The August 2, 2026 deadline for full EU AI Act enforcement is 55 days away. Article 9 compliance is not just a process obligation — it is an infrastructure obligation. Where your risk documentation lives determines whether your NCA inspections are clean.