The CLOUD Act and European Source Code
Last updated: 2026-07-224 min read
The US CLOUD Act amended US law so covered providers must preserve or disclose covered communications and records in their possession, custody, or control regardless of location. That sentence is not a universal jurisdiction rule. Provider and service scope, data flow, control, encryption, EU-law conflicts, and residual risk all require a fact-specific assessment. This is not legal advice.
Contents
The mechanism, without the mythology
Legal status and sources checked: July 22, 2026. This article describes the legal landscape for orientation - it is not legal advice; the assessment for your setup belongs to your counsel.
The relevant statutory text is narrower than the slogan. Under 18 U.S.C. §2713, an electronic communication service or remote computing service must meet Chapter 121 obligations for covered customer or subscriber communications and records in its possession, custody, or control, regardless of location. Whether a company, service, repository, or request falls within that rule is a legal question. This page makes no claim about request prevalence and no categorical conclusion for source code.
Where AI coding tools enter the picture
Every cloud AI coding service adds a provider that holds or processes parts of your code - prompts, context, sometimes a full index, as mapped in what AI tools actually read. For jurisdiction analysis that means the question is not just “where is our git remote?” but “which providers, under which law, can access code through the AI toolchain?” The BSI/ANSSI data-flow lens applies unchanged - the toolchain is part of the sovereignty surface.
Since September 2025 the EU Data Act applies. Article 32 addresses adequate technical, organizational, and legal measures by data processing services where third-country access to non-personal data held in the Union would conflict with Union or member-state law. That is a separate EU obligation with its own scope and conditions, not an automatic answer to provider jurisdiction or a guarantee against lawful access.
The three architectural answers
| Architecture | What it changes | Honest limits |
|---|---|---|
| EU-jurisdiction providers | Changes provider, service, contract, and control facts | Ownership, affiliates, lawful process, and actual control still require review |
| Customer-held encryption keys | Can reduce provider access to plaintext in selected data states | Keys, metadata, endpoints, runtime plaintext, and compelled changes remain in the threat model |
| Local processing | Can remove a remote service from a particular processing step | Does not remove endpoint, transfer, operator, supplier, or jurisdiction risk elsewhere |
The middle row carries the AI-specific nuance: customer-held keys protect data at rest and in transit, but a cloud model that should reason about your code needs it decrypted at the provider. For AI-assisted work on the most sensitive code, the realistic strict option is the third row - the setup economics are covered in local LLM code review and the general architecture in local AI code review.
What this does not justify
Neither a provider’s headquarters nor a data-center region settles the full analysis. Do not infer immunity from local-first, on-premises, self-hosted, or customer-key architecture; do not infer certain access from a US link either. Map legal jurisdiction, provider and service control, data location and flow, encryption states, lawful-process scenarios, and residual risk. Counsel then applies the law to those facts.
Where Reality Graph fits
Reality Graph can be operated local-first and can record which files, services, and checks participated in a run; its own account of what is transmitted, and to where names the exceptions rather than claiming there are none. That can support a documented data-flow and control assessment; it does not determine jurisdiction, prevent lawful access, or make an architecture CLOUD Act-proof. Its evidence reports preserve task-relative evidence, not a legal conclusion. The legal weighing and any business approval stay with counsel and the operator.
This analysis gives you
- The provider-control mechanism, stated precisely
- The statutory provider, service, data, control, and location boundaries
- The Data Act's role since September 2025, described
- Three architectures matched to code sensitivity
It does not give you
- Legal advice or a risk verdict for your setup
- A reason to ban US providers wholesale
- A claim that any architecture is 'CLOUD Act proof'
- A substitute for classifying your own repositories
If these boundaries fit how your team wants to ship:
FAQ
- What legal risks does cloud-based code processing carry for EU companies?
- Separate legal jurisdiction, the covered provider and service, the data flow, provider possession, custody, or control, and contractual confidentiality. 18 U.S.C. §2713 addresses covered communications and records held by an electronic communication or remote computing service; it is not a categorical rule for every provider or every source-code workload. Applicability and conflicts with EU law require fact-specific legal advice.
- Does an EU data center protect against the CLOUD Act?
- Location is one fact, not a complete answer. Section 2713 says covered providers must comply for covered data in their possession, custody, or control regardless of where that data is located. Provider identity, service scope, corporate and contractual control, the requested data, and conflicts with EU law still matter. Counsel should assess those facts together.
- Does this article establish how often source code is requested?
- No. It does not claim incident prevalence, and the absence of a case found in a public search would not prove that a request never occurred. The useful exercise is narrower: map the service, data, control path, lawful-process scenario, and residual risk, then have counsel assess applicability.
- Is source code even covered by GDPR here?
- It depends on the content and context. Repositories can include identifiers, logs, fixtures, tickets, credentials, or other information that changes the analysis. Trade-secret and contractual duties may also apply. Classification must follow the actual data, not the filename, and this page is not legal advice.
- What did the EU Data Act change?
- Regulation (EU) 2023/2854 has applied since 12 September 2025. Article 32 requires providers of data processing services to take adequate technical, organizational, and legal measures against third-country governmental access to non-personal data held in the Union where access would conflict with Union or member-state law. Its scope and exceptions matter; it does not decide a CLOUD Act question by itself.
- What are the architectural answers?
- Provider selection, customer-controlled encryption, and local processing can change the provider relationship, readable data states, and data flow. None guarantees immunity from lawful access. Ownership, service design, keys, metadata, endpoints, transfers, and operational access leave different residual risks, so the architecture must be documented and assessed on its facts.
Keep reading
Sources
- 18 U.S.C. §2713 - covered providers, covered records, possession/custody/control, and location rule (US Code, current text checked 22 July 2026)
- Regulation (EU) 2023/2854, Article 32 - international governmental access to non-personal data; applies since 12 September 2025 (EUR-Lex)
- EDPB-EDPS joint response on the CLOUD Act and EU personal-data framework (12 July 2019; legal assessment, not a ruling)
- BSI/ANSSI - recommendations on AI coding assistants: data flows to providers (2024, German)