EU AI Act Infrastructure Compliance: The Complete EU-Sovereign Hosting Checklist for High-Risk AI Providers (2026)

Post #1596 in the sota.io EU Compliance Series — EU AI Act Infrastructure Compliance Finale

The EU AI Act's August 2, 2026 deadline for high-risk AI providers is 55 days away. Five articles — Art.9, Art.10, Art.12, Art.19, and Art.74 — each impose direct infrastructure obligations that cannot be met with documentation alone. They require your logs, your training data, your risk management records, and your model artefacts to live in a jurisdiction where EU authorities can reach them without US CLOUD Act interference.

This finale synthesizes the complete EU AI Act Infrastructure Compliance series into a single, actionable 30-point checklist. Use it as your pre-August audit framework.

Why Infrastructure Is a Compliance Variable

Most EU AI Act compliance guides treat infrastructure as background. The actual text disagrees.

Art.12 requires automatically generated logs to be retained "to the extent that it is reasonably within the provider's control." Art.19 requires providers to maintain those logs "for the period appropriate to the intended purpose of the high-risk AI system, for a minimum of 6 months." Art.10 requires that training data used for high-risk AI systems involving personal data is processed under EU data protection rules — which means the processing infrastructure must be EU-jurisdictional. Art.74 grants national competent authorities (NCAs) the right to "access the source code of the high-risk AI system" and to "carry out announced and unannounced on-site inspections."

None of these obligations are satisfied by a Statement of Applicability in a Word document. They require infrastructure decisions that determine whether EU regulators can actually exercise their rights.

The CLOUD Act Problem

Every checklist item in this guide flows from one structural tension: the US CLOUD Act and the EU AI Act impose contradictory jurisdiction over the same data.

The CLOUD Act (18 U.S.C. § 2523) requires US-headquartered cloud providers to disclose stored data to US law enforcement, even when that data is stored in EU datacenters. AWS Frankfurt, Azure Netherlands, and GCP Belgium are all subject to CLOUD Act demands because their parent corporations — Amazon, Microsoft, and Google — are US entities.

The EU AI Act assumes that NCAs have effective access to AI system records on EU terms. When logs, training data, and risk management artefacts reside on infrastructure subject to CLOUD Act, NCAs face a dual-jurisdiction conflict:

1. The EU NCA requests access under Art.74 EU AI Act powers.
2. A US federal agency may separately compel disclosure under the CLOUD Act, potentially overriding EU data protection objections.

This is not theoretical. The CLOUD Act has been invoked against data stored in EU jurisdictions. For high-risk AI providers, it creates a compliance gap that cannot be closed by contractual means alone — only by hosting on infrastructure outside US-parent jurisdiction.

The 30-Point EU AI Act Infrastructure Compliance Checklist

Section A: Log Storage and Record-Keeping (Art.12 + Art.19)

From the series post: EU AI Act Art.12/19 Record-Keeping and Log Storage: The CLOUD Act Exposure Developers Miss

1. Log storage jurisdiction is EU-sovereign Your inference logs, input/output records, and confidence scores are stored on infrastructure without US-parent ownership. AWS, Azure, and GCP do not qualify.

2. Log retention period meets the 6-month minimum Art.19 requires minimum 6-month retention for automatically generated logs. Your storage configuration enforces this, not just your runbook.

3. Log access is technically restricted to EU entities IAM policies, network egress rules, or EU-sovereign key management (e.g., Hetzner KMS, OVHcloud Bring-Your-Own-Key) prevent extraterritorial access without explicit EU legal process.

4. Log integrity is cryptographically verifiable NCA inspectors need assurance that logs have not been altered. Hash-chain or append-only log structures with verifiable integrity are in place.

5. Log formats are NCA-readable without proprietary tooling Logs are stored in structured, open formats (JSON Lines, CSV, structured syslog) that an NCA inspector can read without licensing your ML framework.

6. Log retention extends to post-market monitoring data (Art.72) Art.72 post-market monitoring data — anomaly counts, performance drift metrics, feedback loop records — is co-located with Art.12/19 logs in the same EU-sovereign environment.

7. Log deletion workflows comply with GDPR Art.17 without breaking Art.19 When end users exercise the right to erasure, your deletion pipeline removes personal data from logs without destroying the structural log records required under Art.19.

Section B: Training Data Governance (Art.10)

From the series post: EU AI Act Art.10 Training Data Governance: EU Jurisdiction Requirements for Personal Data in AI Training

8. Training datasets involving EU personal data are processed on EU-sovereign infrastructure Art.10(5) requires that training data involving personal data of natural persons is subject to appropriate data governance. Processing on CLOUD-Act-exposed infrastructure creates GDPR Art.44 transfer compliance risk.

9. Training data lineage documentation is stored in EU jurisdiction The Art.10(2) requirement for documented data collection provenance, pre-processing steps, and bias assessments applies to documentation stored alongside — or linked to — the training data. Both must be EU-accessible.

10. Data versioning and dataset access logs are retained NCA auditors verifying Art.10 compliance will ask for dataset versions used in specific model releases. Git-LFS or versioned object storage in EU jurisdiction with access logs satisfies this requirement.

11. Third-party training data licences are verifiable Art.10 requires providers to demonstrate lawful use of training data. Licence records for third-party datasets are stored in EU-accessible systems, not in US-vendor licence portals as the sole record.

12. Bias evaluation and testing artefacts are retained Art.10(4) requires that appropriate bias detection and mitigation measures were taken. The artefacts — evaluation datasets, bias metrics, mitigation decisions — are stored in EU-sovereign infrastructure for NCA access.

13. Training data pipelines do not transit US infrastructure Data flowing from EU source systems through a US-parent ETL pipeline to an EU storage target may have been transiently accessible to CLOUD Act demands. Pipelines are EU-sovereign end-to-end.

Section C: Risk Management System (Art.9)

From the series post: EU AI Act Art.9 Risk Management System: Where You Store Your Validations Determines Your Compliance Posture

14. Risk Management System (RMS) documentation is stored in EU-sovereign infrastructure Art.9 requires establishing, implementing, documenting, and maintaining an RMS throughout the system lifecycle. The documentation — risk identification records, evaluation results, residual risk assessments — must be accessible to NCAs.

15. RMS version history is retained and linked to model versions When the RMS is updated to address a newly identified risk, the version history is retained. NCAs need to verify that risk management kept pace with model changes.

16. Residual risk acceptance records include explicit sign-off Art.9(9) requires that residual risks communicated to users are documented. Acceptance records with named decision-makers and dates are stored in EU-accessible systems.

17. RMS integrations with CI/CD pipelines produce EU-stored artefacts Automated risk checks run in your CI/CD pipeline (e.g., fairness tests, adversarial robustness checks) produce artefacts stored in EU-sovereign infrastructure, not US-cloud-hosted CI artefacts.

18. Human oversight evaluation records are retained (Art.14) Art.14 requires that high-risk AI systems enable effective human oversight. The records of oversight evaluations — who reviewed which outputs, when, with what result — are stored in EU-accessible systems.

19. RMS covers the complete system boundary, including third-party components Art.9 applies to the entire high-risk AI system, including third-party APIs, pre-trained models, and data pipelines. Your RMS documentation maps these dependencies and their risk status.

Section D: Technical Documentation and Conformity (Art.11 + Art.43)

20. Technical documentation (Annex IV) is stored in EU-accessible systems The 11-category Annex IV technical documentation package — including system description, design choices, test results, and post-market monitoring plans — is stored where NCAs can access it under Art.74.

21. Conformity assessment records reference EU-stored evidence Whether self-assessed (Art.43(1)) or third-party assessed (Art.43(2)), the conformity evidence pack references EU-sovereign artefacts, not artefacts whose access depends on a US-parent cloud provider's cooperation.

22. CE marking documentation chain is complete and EU-accessible The EU Declaration of Conformity, the technical documentation reference, and the notified body certificate (if applicable) form a chain where each document is traceable to EU-stored underlying evidence.

23. Model card and system card are version-controlled and accessible NCAs reviewing transparency disclosures under Art.13 will cross-reference model cards with technical documentation. Version-controlled model cards in EU-accessible repositories satisfy this requirement.

Section E: NCA Market Surveillance Access (Art.74)

From the series post: EU AI Act Art.74 Market Surveillance: Why Your Infrastructure Hosting Jurisdiction Determines NCA Access

24. Source code access can be provided to NCAs without triggering CLOUD Act Art.74 grants NCAs the right to access source code. If your code repository is hosted on GitHub (Microsoft, US), GitLab.com (US), or Bitbucket (Atlassian, US), providing NCA access may trigger conflicting US legal obligations. Self-hosted Gitea on EU infrastructure eliminates this conflict.

25. NCA inspection response time meets the Art.16(e) notification obligation Art.16(e) requires providers to respond to NCA requests. Your incident response plan includes a defined SLA for NCA inspection requests that does not depend on US-parent cloud provider cooperation.

26. Infrastructure topology documentation is maintained for NCA disclosure Art.74 NCAs may request information about your infrastructure architecture to assess the completeness of their access. A current infrastructure diagram — cloud regions, data flows, storage locations, third-party dependencies — is maintained and can be disclosed.

27. Post-market monitoring reports are prepared for NCA submission (Art.72) Art.72(1) requires providers to proactively document post-market monitoring results. The monitoring reports — performance metrics, incident summaries, corrective actions — are formatted for NCA submission and stored in EU-accessible systems.

28. EU AI Database registration is complete (Art.71 + Annex VIII) High-risk AI systems must be registered in the EU AI Database before being placed on the market. Registration entries reference the EU-sovereign infrastructure where compliance evidence is stored.

29. Third-party processor agreements include NCA access provisions If any component of your high-risk AI system processes data via a third party, the data processing agreement includes explicit provisions allowing EU NCA access for Art.74 inspections.

30. Incident reporting infrastructure supports Art.73 notification timelines Art.73 requires notification of serious incidents to NCAs within defined timeframes. Your incident detection and reporting infrastructure — monitoring, alerting, notification pipelines — runs on EU-sovereign infrastructure so that NCA notifications are not dependent on US-parent systems.

Infrastructure Scoring Matrix

Use this matrix to assess your current compliance posture before the August 2, 2026 deadline.

The EU-Sovereign Infrastructure Stack for High-Risk AI

For providers building new infrastructure or migrating before the August 2026 deadline, this stack eliminates CLOUD Act exposure across all 30 checklist items:

Compute: Hetzner Cloud (Germany), Scaleway (France), OVHcloud (France), IONOS Cloud (Germany)
Object Storage: Hetzner Object Storage (S3-compatible), Scaleway Object Storage, OVHcloud S3
Container Registry: Self-hosted Harbor on EU compute, or OVHcloud Managed Registry
Source Control: Self-hosted Gitea or Forgejo on EU compute, or Codeberg (Germany, non-profit)
CI/CD: Woodpecker CI, Forgejo Actions, or Drone CI on EU compute
PaaS (deploy any language, EU-sovereign): sota.io — git-push deploy, Hetzner Germany, no US parent, no CLOUD Act exposure

Series Summary: What the Five Posts Established

This series addressed five EU AI Act articles that each impose distinct infrastructure obligations:

Art.12/19 (Log Storage): Automatically generated logs must be stored in EU-sovereign infrastructure for minimum 6 months. CLOUD Act creates dual-jurisdiction risk for logs on US-parent infrastructure.

Art.10 (Training Data): Personal data in AI training must be processed under EU data protection rules — which requires EU-jurisdictional processing infrastructure, not just EU-region storage on US-parent cloud.

Art.9 (Risk Management System): RMS documentation, version history, and evaluation artefacts must be accessible to NCAs. US-parent cloud storage creates access barriers via CLOUD Act.

Art.74 (NCA Market Surveillance): NCAs have the right to access source code, documentation, and infrastructure. Cooperative access — without CLOUD Act interference — requires EU-sovereign hosting.

Finale (This post): The 30-point checklist synthesizes all five articles into a single pre-August audit framework.

Conclusion

The EU AI Act's infrastructure requirements are not aspirational. They are legal obligations with enforcement teeth: NCAs can impose fines of up to €30 million or 6% of global annual turnover for non-compliance by high-risk AI providers. The five articles covered in this series — Art.9, Art.10, Art.12, Art.19, and Art.74 — together require that your AI system's compliance evidence lives in a jurisdiction where EU authorities can reach it.

With 55 days to the August 2, 2026 deadline, the infrastructure question is not "should we migrate?" but "how fast can we migrate?"

For EU developers building or migrating high-risk AI infrastructure, sota.io provides git-push deployment on Hetzner Germany — EU-sovereign, no US parent, no CLOUD Act exposure — from €9/month. The compliance infrastructure decision is one deploy away.

This post is the fifth and final entry in the EU AI Act Infrastructure Compliance 2026 series. Previous entries: Art.12/19 Log Storage · Art.10 Training Data · Art.9 Risk Management System · Art.74 NCA Access