sota.io
2026-06-08·5 min read·sota.io Team

EU AI Act Art.13 Transparency + CLOUD Act: The Audit Trail Compliance Gap in AWS-Hosted AI Systems (2026)

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

EU AI Act Art.13 transparency obligations and CLOUD Act audit trail compliance gap

In the previous post in this series, we established the foundational CLOUD Act compliance problem for EU AI Act providers: if you run a high-risk AI system on AWS, Azure, or GCP, US federal law can compel disclosure of your compliance artefacts — training data, monitoring logs, model weights — without notifying you or your EU supervisory authority.

This post goes deeper on two specific EU AI Act obligations that are structurally undermined by CLOUD Act exposure: Art.12 record-keeping and Art.13 transparency and information to deployers. These are not abstract obligations. They are auditable requirements with direct consequences if your documentation is incomplete or if your audit trail has been accessed by undisclosed parties.

The August 2026 deadline is 55 days away. If your high-risk AI system runs on US hyperscaler infrastructure, read this before your notified body assessment.

Art.12 Record-Keeping: The Log Integrity Problem

Article 12 of the EU AI Act requires providers of high-risk AI systems to ensure that the AI system is capable of automatically recording events ("logs") relevant to identifying situations that may present a risk or lead to significant changes in the system's operation. These logs must:

The implicit assumption in Art.12 compliance is that your log storage is under your exclusive control. You know who can read it. You can assert to your EU AI Act supervisory authority: "This log has not been accessed by unauthorised parties. Its integrity is intact."

If your logs are stored in Amazon CloudWatch, Azure Monitor, or Google Cloud Logging, that assertion is structurally incomplete.

The CLOUD Act Log Access Scenario

A US federal agency — FBI, IRS, or Department of Justice — can serve a CLOUD Act order on AWS, Azure, or Google. The order compels the US company to produce stored data, including application logs. Critically:

  1. The order can be subject to a gag provision that prohibits AWS from notifying you (the customer) that the order was served or that data was produced.
  2. The log content produced to US authorities includes operational data, performance metrics, error rates, bias indicators, and user interaction patterns that your EU AI Act compliance programme treats as confidential and controlled.
  3. Your Art.12 tamper-proof assertion covers unauthorized modification and deletion — but it typically does not cover undisclosed reads. A CLOUD Act-compelled read of your CloudWatch logs does not modify them. It does not delete them. But it means a third party accessed data that your compliance programme treats as confidential.

For your Art.12 compliance documentation to be complete, it needs to acknowledge this risk. Most do not.

What a CLOUD Act-Aware Art.12 Log Architecture Looks Like

If you must use AWS for compute, you can materially reduce the CLOUD Act log exposure problem through architectural choices:

# EU AI Act Art.12 log pipeline with CLOUD Act mitigation
# Pattern: write to CloudWatch (operational), export to EU-only immutable store (compliance)

import boto3
import hashlib
import json
from datetime import datetime

class Art12AuditLogger:
    """
    Dual-write audit logger: CloudWatch for operations, EU-only store for Art.12 compliance logs.
    Art.12 compliance logs must be in EU-jurisdictioned storage (CLOUD Act does not reach).
    Operational CloudWatch logs are CLOUD Act-exposed; compliance logs are not.
    """

    def __init__(self, system_id: str, eu_storage_endpoint: str):
        self.system_id = system_id
        self.cw = boto3.client('logs', region_name='eu-central-1')
        # EU-native storage endpoint — must be non-US cloud (Hetzner Object Storage,
        # OVHcloud, Scaleway Object Storage, IONOS S3-compatible)
        self.eu_endpoint = eu_storage_endpoint

    def log_ai_event(self, event_type: str, details: dict, risk_level: str = "low"):
        """
        Writes events to both CloudWatch (operational) and EU-native store (Art.12 compliance).
        Only the EU-native store is referenced in your Annex IV technical documentation.
        """
        log_entry = {
            "timestamp": datetime.utcnow().isoformat(),
            "system_id": self.system_id,
            "event_type": event_type,
            "risk_level": risk_level,
            "details": details,
        }
        # Integrity hash (SHA-256 chain over previous entry hash)
        log_entry["integrity_hash"] = hashlib.sha256(
            json.dumps(log_entry, sort_keys=True).encode()
        ).hexdigest()

        # Write 1: CloudWatch (operational — CLOUD Act exposed, do not reference in Art.12 docs)
        self._write_cloudwatch(log_entry)

        # Write 2: EU-native immutable store (Art.12 compliance — outside CLOUD Act jurisdiction)
        self._write_eu_compliance_store(log_entry)

    def _write_cloudwatch(self, entry: dict):
        # Standard CloudWatch log write — used only for operational monitoring
        try:
            self.cw.put_log_events(
                logGroupName=f"/ai-system/{self.system_id}",
                logStreamName="operational",
                logEvents=[{"timestamp": int(datetime.utcnow().timestamp() * 1000),
                            "message": json.dumps(entry)}]
            )
        except Exception:
            pass  # CloudWatch failure does not affect Art.12 compliance log

    def _write_eu_compliance_store(self, entry: dict):
        # Write to EU-native S3-compatible storage
        # This store's Art.12 compliance status: EU-jurisdictioned (no CLOUD Act exposure)
        import requests
        requests.put(
            f"{self.eu_endpoint}/compliance-logs/{self.system_id}/{entry['timestamp']}.json",
            json=entry,
            headers={"Content-Type": "application/json",
                     "x-amz-server-side-encryption": "AES256"}
        )

The key principle: your Annex IV technical documentation and Art.12 compliance log references should point to EU-native storage (Hetzner Object Storage, OVHcloud Swift, Scaleway S3-compatible), not to CloudWatch or Azure Monitor. The operational logs on US infrastructure remain for engineering purposes; the compliance artefacts live in EU-jurisdictioned storage.

Art.13 Transparency: The Information-to-Deployers Gap

Article 13 requires that high-risk AI systems be designed and developed to ensure that their operation is sufficiently transparent to enable deployers to interpret the system's output and use it appropriately. The provider must accompany the AI system with instructions for use that include:

This last requirement is where CLOUD Act creates a transparency gap that is genuinely difficult to close without infrastructure changes.

The Undisclosed Third-Party Access Problem

Art.13 compliance requires you to give deployers a complete picture of who can affect the AI system's operation and under what circumstances the system's outputs or performance may be influenced by external factors.

If your AI system is deployed on AWS eu-central-1:

  1. A deployer relying on your Art.13 documentation trusts that the list of parties who can access or affect the AI system is complete. Your documentation names your team, your subprocessors, your data processors under GDPR Art.28 agreements.

  2. What it does not name — because you do not control whether it happens and cannot publicly acknowledge it after the fact if subject to a gag order — is the US federal government's potential access under CLOUD Act.

  3. The AI system's inference outputs on AWS can potentially be accessed by US authorities. If your AI system processes sensitive personal data — medical decisions, creditworthiness assessments, benefits eligibility — and inference outputs are logged to CloudWatch, those outputs are subject to CLOUD Act.

  4. Your Art.13 transparency documentation implicitly promises deployers that access to the AI system's operational data is controlled, auditable, and within the scope of your GDPR compliance framework. The CLOUD Act creates a pathway that is outside that framework.

This is not a theoretical risk for compliance documentation purposes. The EU AI Act's notified body assessment process includes reviewing your Art.13 documentation for completeness. An assessor familiar with CLOUD Act implications could legitimately flag: "Your documentation does not address jurisdictional exposure through your cloud provider's US legal obligations."

Art.14 Human Oversight: The Oversight Mechanism Integrity Gap

Article 14 requires that high-risk AI systems be designed and developed to enable effective human oversight throughout their operational lifetime. This includes technical measures that:

The oversight infrastructure — dashboards, alert systems, intervention controls — is typically deployed on the same cloud platform as the AI system. If the AI system runs on AWS, the oversight tools run on AWS.

CLOUD Act Exposure of Your Oversight Infrastructure

Consider a high-risk AI system for credit scoring deployed on AWS:

Human oversight infrastructure:
- Dashboard: React app on AWS Amplify (eu-central-1)
- Alert system: CloudWatch Alarms → SNS → Lambda
- Intervention controls: API Gateway → Lambda (triggers model pause)
- Audit trail of oversight interventions: DynamoDB table (eu-central-1)
- Override logs: "Human reviewer X overrode AI decision Y at timestamp Z": CloudWatch Logs

Every component of this oversight architecture is US-cloud-hosted. A CLOUD Act order can compel production of:

  1. The oversight audit trail — who reviewed which AI decisions and what they decided
  2. The intervention history — when humans paused or overrode the AI system
  3. The alert configuration — what conditions trigger human review (revealing your AI system's known failure modes)
  4. The dashboard query logs — which decisions have been reviewed most frequently (revealing which outputs the human reviewers consider highest-risk)

From an Art.14 compliance perspective, the human oversight mechanism is not just a technical capability — it is also a data source about the AI system's known weaknesses and the deployer's internal risk assessments. If US authorities access that data without your knowledge, your Art.14 oversight infrastructure has become an intelligence source about your AI compliance programme's private risk assessments.

The Annex IV Documentation Completeness Problem

This is where Art.12 and Art.13 concerns converge at audit time. Annex IV of the EU AI Act specifies the technical documentation that high-risk AI system providers must maintain and present to conformity assessment bodies (notified bodies or internal assessors under Annex VI).

Annex IV documentation must include, among other things:

For AWS-hosted systems, Annex IV documentation currently fails to address CLOUD Act exposure in:

Annex IV SectionGap
Section 3 (Monitoring)Log storage on CloudWatch — CLOUD Act-exposed. Documentation does not disclose that US authorities can compel log access.
Section 3 (Access controls)Lists internal access controls. Does not list CLOUD Act as a legal mechanism through which the provider's cloud vendor (AWS) can be compelled to provide access.
Section 2 (Operational infrastructure)Lists AWS eu-central-1 as compliant EU-hosted infrastructure. Does not note that AWS's US corporate status means CLOUD Act applies.
Section 1 (Third parties)Lists data processors and subcontractors. Does not list US federal government as a potential data recipient under CLOUD Act (because providers cannot guarantee when/whether CLOUD Act orders occur).

A technically complete Annex IV for an AWS-hosted high-risk AI system would need to address this gap explicitly. Either by:

  1. Documenting the residual CLOUD Act risk with mitigating controls (encryption, EU-only key management)
  2. Or by migrating compliance artefacts to EU-native infrastructure that is genuinely outside CLOUD Act jurisdiction

Practical Remediation: A Tiered Approach for August 2026

Given the August 2026 deadline, most organisations cannot rebuild their entire AI infrastructure on EU-native cloud before then. A tiered approach prioritises the highest-risk compliance gaps first.

Tier 1: Compliance Artefact Migration (Do Before August 2026)

Move EU AI Act compliance documentation to EU-native storage. This is the fastest, lowest-disruption fix.

What to move:

Where to move it:

Implementation timeline: 2-3 days for a mid-sized AI system. Write compliance artefacts to EU-native storage as primary, keep AWS as operational mirror.

Tier 2: Oversight Infrastructure Isolation (Do Before Q4 2026)

Move human oversight tooling (dashboards, alert infrastructure, intervention controls) to EU-native infrastructure. This closes the Art.14 gap.

Why this is Tier 2 (not immediate): The oversight infrastructure is more tightly coupled to the AI inference system than the compliance documentation. Migrating it requires careful re-architecting to avoid breaking the oversight capability itself.

Approach:

Tier 3: Full Inference Migration (Multi-Year Roadmap)

Moving inference workloads from AWS eu-central-1 to EU-native GPU cloud is a substantial engineering project but provides full CLOUD Act closure. EU-native compute options for AI inference:

For organisations needing managed infrastructure without the operational overhead of bare-metal GPU management, EU-native PaaS platforms that are not subject to CLOUD Act provide the cleanest compliance path.

Updating Your Art.13 Documentation: A Disclosure Template

If your organisation is deploying on AWS/Azure/GCP and cannot migrate before August 2026, your Art.13 transparency documentation should explicitly acknowledge the CLOUD Act risk rather than leave an undisclosed gap. Here is a template section for your Art.13 instructions for use:

## 8. Third-Party Legal Access to AI System Data

This AI system is operated on [AWS eu-central-1 / Azure West Europe / GCP europe-west1].
The infrastructure provider ([Amazon Web Services / Microsoft Azure / Google Cloud Platform])
is a US-incorporated company subject to the US CLOUD Act (18 U.S.C. §2713).

Under the CLOUD Act, US federal authorities may compel [AWS/Azure/GCP] to produce data
stored on EU-located servers without notifying the data controller or the relevant EU
supervisory authority, subject to applicable confidentiality requirements.

This means that the following categories of AI system data may, in principle, be subject
to undisclosed access by US federal authorities:

- Art.12 operational audit logs (if stored on [AWS CloudWatch / Azure Monitor / GCP Cloud Logging])
- Art.14 human oversight intervention records (if stored on [AWS DynamoDB / Azure Cosmos DB])
- Model inference outputs and user interaction logs

Deployers should be aware of this residual jurisdictional exposure when:
1. Assessing the suitability of this AI system for processing sensitive personal data
2. Evaluating their own GDPR Art.28 processor obligations
3. Considering whether additional data localisation measures are required

Current mitigating controls: [describe your specific controls, e.g. CMK encryption,
EU-native compliance artefact storage, log segmentation between operational/compliance]

This disclosure is uncomfortable to write. But it is more defensible than an Art.13 documentation gap that your notified body assessor discovers independently.

Developer Checklist: Art.12 + Art.13 CLOUD Act Gap Assessment

Use this checklist to audit your AWS/Azure/GCP-hosted high-risk AI system before August 2026.

Art.12 Record-Keeping

Art.13 Transparency Documentation

Art.14 Human Oversight

Infrastructure Assessment

What's Next in This Series

This series is working through the EU AI Act + CLOUD Act compliance gap systematically:

Summary

The EU AI Act's Art.12 and Art.13 obligations assume that you control your AI system's documentation and audit trail. The US CLOUD Act breaks that assumption for any high-risk AI system deployed on AWS, Azure, or GCP.

The practical consequence is a structural gap in your Annex IV technical documentation and your Art.13 transparency disclosures — not because you have done anything wrong, but because US cloud infrastructure introduces a legal access pathway that your compliance programme's standard access control documentation cannot account for.

The fastest fix — migrating compliance artefacts (logs, Annex IV docs, risk registers) to EU-native storage — can be completed in 2-3 days and closes the most acute Art.12 gap before August 2026. The complete fix — migrating inference and oversight infrastructure to EU-native cloud — is a longer-term project but provides full jurisdictional clarity.

EU-native infrastructure (Hetzner, Scaleway, OVHcloud, or EU-native PaaS like sota.io) is the cleanest path: when your cloud provider is incorporated in Germany, France, or another EU member state, the CLOUD Act does not apply, and your Art.12/Art.13 compliance documentation is complete by construction.

August 2026 is 55 days away. The documentation gap audit should happen now.

EU-Native Hosting

Ready to move to EU-sovereign infrastructure?

sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.

Join the waitlistView pricing