"Our data stays in the EU" is not an answer to a CLOUD Act question. Residency describes where bytes sit. The CLOUD Act is about who can be compelled to hand them over, and that turns on corporate control, not geography. Designing for the second question produces a different architecture than designing for the first.
What the CLOUD Act actually does
The US Clarifying Lawful Overseas Use of Data Act (2018) confirms that a US-based provider must produce data in its possession, custody, or control in response to lawful US process — regardless of where that data is physically stored. The reach follows the corporate entity, not the data centre.
Two consequences follow, and both are commonly missed:
- An EU region operated by a US-headquartered provider remains within reach, because the parent has control.
- An EU subsidiary of a US parent is generally treated as within that control, so incorporation in Dublin or Frankfurt does not by itself resolve the question.
This sits in tension with GDPR Article 48, which says a third-country judgment or order is only recognisable through a mutual legal assistance treaty or similar instrument. A provider caught between the two faces conflicting obligations, and your DPIA has to say something honest about that.
The question your DPO will actually ask
Not "where is it stored". The useful question is: if a US authority served process tomorrow, what could be produced in readable form, and by whom?
Answering that requires tracing four things through your system. Most AI architectures fail on the second and third.
1. Where data rests
Object storage, databases, backups, snapshots. Usually well documented, usually the only thing documented.
2. Where data is processed in the clear
This is the gap. Inference requires plaintext. A prompt containing personal data is decrypted in the provider's memory at the moment the model runs, whatever the storage region says. Vector embeddings derived from personal data are themselves personal data, and are frequently overlooked in the mapping.
3. Who holds the keys
Encryption only helps if the party subject to compulsion cannot decrypt. Provider-managed keys mean the provider can produce plaintext. Customer-managed keys inside the provider's KMS are better but not decisive — the provider still operates the KMS. Keys held outside the provider's control are the only configuration that materially changes the answer.
4. Who operates the plane
Support access, break-glass procedures, and telemetry pipelines routinely cross borders even when the workload does not. So do logs, and logs of AI systems tend to contain prompts.
Four patterns, honestly rated
| Pattern | CLOUD Act exposure | Practical cost |
|---|---|---|
| US hyperscaler, EU region, provider-managed keys | High — control test met, provider holds plaintext | Lowest |
| US hyperscaler, EU region, customer-managed keys in provider KMS | Moderate — reduces casual access, provider still operates KMS | Low |
| US hyperscaler + external key management and confidential computing | Lower — plaintext window narrowed, not eliminated | Moderate |
| EU-incorporated provider, or self-hosted open-weight models in EU infrastructure | Lowest — no US corporate control to compel | Highest, and model choice narrows |
The honest position is that the first three reduce exposure without removing it. Anyone claiming a US hyperscaler configuration eliminates CLOUD Act reach is selling something. The right choice depends on the sensitivity of the specific data flow, which is why the architecture should differ per flow rather than being decided once for the whole estate.
Designing the flow, not the region
The practical technique is to classify by flow and apply the cheapest sufficient control to each.
Keep sensitive data out of the prompt
The most reliable protection is not sending the data at all. Tokenise or pseudonymise identifiers before they reach the model and re-hydrate on return, inside your own boundary. A model that never sees a name cannot have that name compelled from it.
Split the pipeline by sensitivity
Retrieval, ranking, and orchestration can run on EU-controlled infrastructure while a frontier model handles only the generalised, de-identified portion of the task. This hybrid is usually where cost and risk balance out.
Hold keys where the provider cannot reach them
External key management with your own HSM changes the compulsion analysis meaningfully: the provider can be ordered to produce ciphertext it cannot read. Combine with confidential computing to narrow the plaintext window during processing.
Treat logs and embeddings as regulated data
Prompt logs, traces, and vector stores derived from personal data inherit its classification. Apply the same residency, retention, and key rules. Default retention on observability tooling is frequently the widest hole in an otherwise careful design.
The evidence pack
A review goes badly when the architecture is sound but undocumented. Prepare these before you are asked:
- Data flow diagram annotated with processing location, controlling legal entity, and key custody at each hop — including inference, logging, and backup.
- Transfer impact assessment naming the specific third-country laws in scope and the supplementary measures applied, per the Schrems II reasoning.
- Sub-processor register with the corporate parent of each entry, not just its trading name. The parent is what determines reach.
- Key custody statement — who can decrypt, under what process, with what logging.
- Provider transparency reports and the contractual commitment to challenge and notify where legally permitted.
- Retention and deletion evidence covering prompts, traces, embeddings and backups.
The EU-US Data Privacy Framework, adequate since July 2023, changes the lawful-transfer analysis. It does not remove CLOUD Act reach, and its durability has been questioned in litigation, so a design that depends entirely on it carries a policy risk as well as a legal one.
Common questions
Does an EU region solve this?
No. Region determines storage location; the CLOUD Act follows corporate control. An EU region reduces GDPR transfer complexity and latency, and is worth having, but it is not an answer to the compulsion question.
Is customer-managed encryption enough?
It helps, and it is worth doing. If the keys live in the provider's own KMS, the provider still operates the system that performs decryption. Only key custody genuinely outside the provider's control changes the analysis materially.
Are embeddings personal data?
Treat them as such when derived from personal data. They are not anonymous — inversion research has repeatedly recovered substantial source content from embeddings. Vector stores belong inside your regulated perimeter.
Do we have to self-host to be safe?
Rarely. Most organisations get most of the benefit by classifying flows and routing only the genuinely sensitive minority to EU-controlled infrastructure. Blanket self-hosting is expensive and usually solves a problem you only have on a fraction of your traffic.
The short version
Design per flow, not per region. Assume plaintext is reachable wherever a US-controlled entity performs inference. Reduce what you send, hold keys where the provider cannot reach them, treat logs and embeddings as in-scope, and write the whole thing down before review. A CLOUD Act review is survivable — but it is survived on documented architecture, not on a residency claim.