EU AI Act + CLOUD Act: The Hidden Compliance Gap in AWS and Azure-Hosted AI Systems (2026)

Post #1587 in the sota.io EU Cyber Compliance Series — EU AI Act CLOUD Act Compliance Gap #1/5

You have spent the last three months building your EU AI Act compliance programme. You have documented your risk management system under Art.9. You have structured your training data governance to satisfy Art.10. You have wired up post-market monitoring for Art.72. Your legal team has reviewed your user-facing transparency obligations under Art.13.

Your high-risk AI system is deployed on AWS eu-central-1 (Frankfurt).

You have a compliance gap. It is not visible in any EU AI Act checklist. It does not appear in most regulatory guidance. And it directly undermines the security guarantees that Art.9, Art.10, and Art.72 require you to maintain.

The gap is called the US CLOUD Act.

What the CLOUD Act Is — and Why EU Hosting Doesn't Protect You

The Clarifying Lawful Overseas Use of Data Act (CLOUD Act, 2018) is a US federal law that requires US-based companies — including cloud providers — to disclose stored data to US government authorities when served with a valid US legal order, regardless of where that data is physically stored.

The critical word is "regardless." AWS eu-central-1 is physically in Frankfurt, Germany. But Amazon Web Services is a division of Amazon.com Inc., a US corporation. Under the CLOUD Act, US federal agencies — including the FBI, DEA, and the Departments of Justice — can compel Amazon to produce data stored on Frankfurt servers without going through EU mutual legal assistance procedures, without notifying the German BfDI or EU data protection authorities, and potentially without notifying you, the customer.

The same applies to:

• Microsoft Azure (West Europe, Amsterdam; North Europe, Dublin) — Microsoft Corporation is a US company.
• Google Cloud Platform (europe-west1–6) — Alphabet Inc. is a US Delaware corporation.
• Oracle Cloud Infrastructure (Frankfurt, Amsterdam) — Oracle Corporation, US-incorporated.

EU-hosted ≠ EU-jurisdictioned when the provider is a US company.

This was confirmed in academic research and legal analysis. The European Court of Justice decision in Schrems II (C-311/18, July 2020) invalidated Privacy Shield partly on the basis that US surveillance law — including the CLOUD Act — creates access to EU-resident data without equivalent EU-level protection. The CJEU found that "mere technical measures" (physical EU storage) do not prevent US law from reaching the data.

How the CLOUD Act Creates EU AI Act Gaps

The EU AI Act's technical obligations for high-risk AI systems assume that you control your compliance artefacts — your training data, your risk management documentation, your monitoring logs, your model outputs. The CLOUD Act creates a legal mechanism by which a third party (US government) can access those artefacts without your knowledge. This creates three specific compliance gaps.

Gap 1: Art.10 Training Data Governance

Art.10 of the EU AI Act requires providers of high-risk AI systems to implement data governance and management practices for training, validation, and testing data sets. This includes:

• Documenting data sources, collection practices, and processing operations
• Ensuring training data is free from biases that could create prohibited discrimination
• Implementing appropriate data security measures
• Documenting the characteristics of data sets relevant to the AI system's intended purpose

The implicit assumption in Art.10 compliance is that you control your training data. You know who can access it. You have documented the access controls and security measures protecting it. You can assert in your Annex IV technical documentation that your training data is handled with appropriate safeguards.

If your training data is stored in Amazon S3 eu-central-1 or Azure Blob Storage West Europe, that assertion is incomplete. US authorities could obtain that training data — including any PII or sensitive data used in training — without your knowledge and without the disclosure appearing in your Art.10 data governance documentation.

The practical risk is documentation integrity. When your EU AI Act notified body auditor asks "who has accessed your training data?", you can accurately list your own team, your data processors, and your EU subcontractors. You cannot answer "and the US Department of Justice, which obtained it under a CLOUD Act order that we were not permitted to disclose due to a gag order." That answer makes your Art.10 data governance documentation materially incomplete.

Gap 2: Art.9 Risk Management System

Art.9 requires providers of high-risk AI systems to establish, implement, document, and maintain a risk management system. This system must identify and analyse known and reasonably foreseeable risks, estimate and evaluate risks, and adopt appropriate risk management measures.

"Known and reasonably foreseeable risks" include legal risks that could affect the AI system's operation, security, and the interests of persons it affects. The CLOUD Act creates a foreseeable legal risk:

• US government could compel access to your model weights, creating IP exposure
• US government could compel access to inference outputs, creating confidentiality breaches affecting your users
• US government could compel access to your incident logs and monitoring data, exposing internal system behaviour before you have disclosed it through Art.73

Most Art.9 risk management systems address: technical failures, bias and discrimination, adversarial attacks, data corruption, and model drift. Almost none document jurisdictional exposure via provider legal compulsion as a risk category.

This is a gap in your risk inventory. The EU AI Act does not enumerate specific risk categories — it requires that your risk assessment be complete and address "all risks" based on the AI system's purpose and context. Legal risks from the provider's national law obligations are within scope.

A complete Art.9 RMS for an AWS-hosted high-risk AI system should include:

# Risk Register — Jurisdictional Exposure
risk_id: JURI-001
risk_category: Legal / Jurisdictional
risk_description: >
  AWS (Amazon Web Services) is subject to US CLOUD Act obligations. 
  US federal authorities may compel AWS to disclose training data, 
  model artefacts, monitoring logs, and inference outputs stored in 
  AWS eu-central-1 without EU data protection authority notification.
risk_likelihood: LOW (requires US federal legal order)
risk_impact: HIGH (training data exposure, monitoring log disclosure, 
  model IP exposure, Annex IV documentation integrity compromise)
residual_risk: MEDIUM
risk_controls:
  - Encryption at rest with customer-managed keys (CMK) stored 
    in EU HSM outside AWS (e.g. AWS KMS with CloudHSM + 
    external key import from EU-only HSM)
  - Zero-knowledge architecture: AWS stores only encrypted blobs, 
    decryption keys never available to AWS
  - Contractual CLOUD Act notification clauses in AWS DPA 
    (note: AWS cannot guarantee notification if subject to gag order)
residual_risk_justification: >
  CMK with external HSM materially reduces CLOUD Act exposure to 
  encrypted-only data access. Residual risk remains due to inference 
  infrastructure (decryption occurs at runtime in AWS compute). 
  Full mitigation requires EU-native infrastructure.

Most organisations do not have this entry in their Art.9 risk register. That is a gap.

Gap 3: Art.72 Post-Market Monitoring

Art.72 requires providers of high-risk AI systems to implement a post-market monitoring system that actively collects and analyses data throughout the AI system's lifetime to identify need for corrective actions. This monitoring data — system performance metrics, anomaly detections, user feedback, accuracy drift indicators — is typically stored in CloudWatch (AWS), Azure Monitor, or Google Cloud Monitoring.

That monitoring data, stored on US cloud infrastructure, is subject to CLOUD Act disclosure. But there is a subtler problem: the integrity of your post-market monitoring programme.

Art.72 requires that your monitoring provides you with timely, reliable information about your AI system's performance. If US authorities can access your monitoring infrastructure — logs, metrics, alert configurations — they have visibility into your system's known vulnerabilities before you have acted on them. If a US authority discovers through your monitoring logs that your AI system has a bias problem or a security vulnerability, and you are compelled to not disclose this under a gag order, you have a legal instrument preventing you from fulfilling your Art.72 obligations.

The risk is not theoretical. The US government has used CLOUD Act orders to obtain cloud data in enterprise investigations, and gag orders preventing customer notification are common.

The Jurisdictional Conflict: GDPR Chapter V vs. CLOUD Act

The EU has addressed this conflict imperfectly. Article 48 of the GDPR prohibits transfers of personal data to non-EU authorities based on foreign court orders unless the transfer is authorised by an EU-US agreement or an EU member state adequacy decision. This means AWS complying with a CLOUD Act order — if it involves personal data — could itself violate GDPR Article 48.

But this creates a conflict of laws that AWS, Microsoft, and Google are forced to navigate on your behalf. In practice, US cloud providers have been known to challenge CLOUD Act orders when they believe GDPR compliance obligations conflict. But the outcome of that challenge is not guaranteed, and you — the EU AI Act provider — are dependent on your US cloud provider's legal strategy for your own compliance programme's integrity.

The EU-US Data Privacy Framework (DPF, adopted July 2023) created a new transfer mechanism following Schrems II, but it covers commercial data transfers, not US government access. The DPF does not prevent CLOUD Act orders from reaching EU-stored data on US-operated infrastructure.

Quantifying the Exposure: What Data Is Actually at Risk

For a typical high-risk AI system deployed on AWS, the CLOUD Act-accessible data includes:

This is not a small surface area. For most high-risk AI deployments, the majority of compliance-critical data — training data, models, monitoring logs — lives in this exposure zone.

What EU AI Act Compliance Requires as Mitigation

The EU AI Act does not prohibit using AWS. It does not name US cloud providers as excluded infrastructure. But the combination of Art.9 (risk management), Art.10 (data governance), Art.12 (record-keeping), and Art.72 (post-market monitoring) creates obligations that are harder to satisfy when your infrastructure provider is subject to a foreign law that can compel access to your compliance artefacts.

Here are the mitigation approaches, from partial to complete:

Approach 1: Customer-Managed Keys with External HSM (Partial)

Store encryption keys in a Hardware Security Module (HSM) outside AWS and use key import to give AWS only encrypted access. Under this architecture, a CLOUD Act order to AWS retrieves only ciphertext that AWS cannot decrypt without your cooperation.

Limitation: This works for stored data. It does not protect data that is decrypted at runtime in AWS compute for inference. Your model weights and training data are decrypted during training and inference runs, at which point they are accessible to the hypervisor layer.

Art.9 impact: Reduces risk from HIGH to MEDIUM for stored artefacts.

# boto3 example: CMK with external key material (not AWS-generated)
import boto3

kms = boto3.client('kms', region_name='eu-central-1')

# Create CMK with EXTERNAL origin — key material imported from EU HSM
key = kms.create_key(
    Description='Training data CMK — EU HSM-backed, CLOUD Act mitigation',
    KeyUsage='ENCRYPT_DECRYPT',
    Origin='EXTERNAL',  # Key material imported from EU HSM, never stored in AWS
    Tags=[
        {'TagKey': 'compliance', 'TagValue': 'eu-ai-act-art10'},
        {'TagKey': 'cloud-act-risk', 'TagValue': 'mitigated-ciphertext-only'},
    ]
)

Approach 2: Confidential Computing (Partial)

AWS Nitro Enclaves and Azure Confidential Computing provide isolated execution environments where even the cloud provider cannot access plaintext data during computation. Intel SGX and AMD SEV-SNP hardware attestation can verify enclave integrity.

Limitation: Confidential computing adds significant operational complexity. Attestation procedures must be documented in your Art.9 RMS. Enclave attestation reports are themselves stored in AWS infrastructure and subject to CLOUD Act.

Art.9 impact: Reduces inference-time exposure. Does not fully address stored data or monitoring infrastructure.

Approach 3: EU-Native Infrastructure (Complete)

Deploy on infrastructure operated by EU-incorporated companies not subject to the CLOUD Act. This eliminates the jurisdictional gap entirely.

EU-native managed PaaS providers such as sota.io (Hetzner Germany, German GmbH), Scaleway (French SAS), OVHcloud (French SA), IONOS (German SE), and Exoscale (Swiss SA) are not subject to US CLOUD Act obligations. A German authority or EU court order is required for any compelled disclosure, subject to GDPR Art.48 and EU judicial oversight.

Under this architecture, your Art.9 risk register entry for jurisdictional exposure becomes:

risk_id: JURI-001
risk_status: MITIGATED
mitigation: >
  Deployed on sota.io (Hetzner Germany infrastructure, 
  GmbH incorporated Germany). Provider is not a US company 
  and not subject to US CLOUD Act. Any compelled disclosure 
  would require German/EU legal authority, subject to GDPR 
  Art.48 and EU fundamental rights protections.
residual_risk: NEGLIGIBLE

Closing the Gap Before August 2026

With 55 days until the EU AI Act August 2, 2026 deadline for high-risk AI providers, the practical question is: what must you do now?

Minimum actions before August 2, 2026:

1. Update your Art.9 risk register to include JURI-001 (jurisdictional exposure). Even if you remain on AWS, you must document the risk.

2. Update your Annex IV technical documentation to describe your cloud provider's CLOUD Act status and your mitigations (CMK, confidential computing, contractual protections).

3. Review your Art.10 data governance documentation to include a note on which training/validation/testing data is stored on CLOUD Act-accessible infrastructure and what access controls are in place.

4. Review your Art.72 post-market monitoring architecture to assess whether monitoring data includes any data categories where CLOUD Act disclosure would constitute an Art.73 incident or materially compromise your monitoring integrity.

5. Evaluate your risk tolerance: If your AI system processes sensitive personal data (medical, biometric, financial, criminal justice) — which is common for Annex III high-risk categories — the CLOUD Act residual risk should be rated HIGH, not MEDIUM. Consider whether migration to EU-native infrastructure is required before August 2026 to achieve acceptable residual risk.

25-Item Checklist: CLOUD Act Risk Assessment for EU AI Act Compliance

Art.9 Risk Management
[ ] 1. JURI-001 CLOUD Act risk documented in risk register
[ ] 2. Risk rated (HIGH/MEDIUM/LOW) based on data sensitivity
[ ] 3. Residual risk controls documented
[ ] 4. CMK external HSM implemented (if remaining on US cloud)
[ ] 5. Confidential computing assessed for inference workloads
[ ] 6. CLOUD Act risk reviewed with legal counsel

Art.10 Data Governance
[ ] 7. Training data storage locations documented (including region + provider nationality)
[ ] 8. CLOUD Act-accessible training data identified by category
[ ] 9. Encryption at rest with CMK verified for all training data
[ ] 10. Data processor agreements include CLOUD Act notification obligations
[ ] 11. AWS/Azure/GCP DPA reviewed for CLOUD Act conflict clauses
[ ] 12. Contingency plan documented if CLOUD Act order received

Art.12 Record-Keeping
[ ] 13. Inference logs retention policy documented
[ ] 14. Monitoring logs storage location documented (with CLOUD Act status)
[ ] 15. Audit trails for data access include cloud provider access events
[ ] 16. Log access control review completed

Art.72 Post-Market Monitoring
[ ] 17. Monitoring infrastructure CLOUD Act status documented
[ ] 18. Monitoring data classified by sensitivity
[ ] 19. Alert for US legal process (subpoena/CLOUD Act order) defined
[ ] 20. Monitoring integrity can be maintained if AWS/Azure/GCP notified

Art.73 Incident Assessment
[ ] 21. Assessed whether CLOUD Act disclosure qualifies as Art.73 serious incident
[ ] 22. Incident response procedure includes US legal order as trigger
[ ] 23. Customer notification procedure defined for CLOUD Act disclosures

Infrastructure Review
[ ] 24. EU-native infrastructure alternatives evaluated
[ ] 25. Migration timeline documented if EU-native required for acceptable residual risk

Next in This Series

Post #2 of 5 — EU AI Act Training Data Under Two Laws: CLOUD Act vs. Art.10 Governance The specific interaction between CLOUD Act production orders and EU AI Act Art.10 training data governance requirements — including whether CLOUD Act training data access constitutes an Art.10 security breach requiring notification.

Post #3 of 5 — EU AI Act Incident Reporting + CLOUD Act: When Art.73 Meets US Data Disclosure

Post #4 of 5 — GPAI Model Weights and CLOUD Act: Why Open Model Releases Need EU-Native Storage

Post #5 of 5 — CLOUD Act-Free AI Compliance Stack: Complete Architecture on EU-Native Infrastructure

Summary

The CLOUD Act creates a compliance gap for EU AI Act high-risk AI providers that deploy on AWS, Azure, or GCP. The gap manifests in Art.9 risk management (incomplete risk inventory), Art.10 data governance (incomplete access control documentation), and Art.72 post-market monitoring (monitoring data integrity). The gap cannot be fully closed by technical controls while remaining on US cloud infrastructure — customer-managed keys and confidential computing reduce but do not eliminate exposure.

With the August 2, 2026 EU AI Act deadline 55 days away, high-risk AI providers on US cloud should document this risk explicitly, update their Annex IV technical documentation to reflect it, and evaluate whether EU-native infrastructure migration is required for their risk profile.

EU-native managed PaaS infrastructure — operating under German/French/EU law without CLOUD Act obligations — closes the gap entirely.