The CLOUD Act Problem Nobody Wants to Explain

I’ve had this conversation a dozen times with IT managers and DPOs:

Them: “We’re fine. Our provider stores data in EU data centres.”

Me: “Where’s the company headquartered?”

Them: “…California.”

Me: “Then you’re not fine.”

This is the CLOUD Act problem. And almost nobody explains it clearly because the implications are uncomfortable.

What the CLOUD Act Actually Says

The Clarifying Lawful Overseas Use of Data Act (CLOUD Act) became US law in March 2018. It’s short, so here’s the key part:

A [US-based] provider of electronic communication service or remote computing service shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider’s possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States.

Read that last part again: regardless of whether such information is located within or outside of the United States.

If the company is American, US law enforcement can compel access to your data. It doesn’t matter if the server is in Frankfurt, Dublin, or on the moon.

“But We Have a DPA”

Data Processing Agreements are contracts between you and your provider. They’re important for GDPR compliance. They establish responsibilities, define processing purposes, require breach notification.

What they can’t do: override a US federal warrant.

When Microsoft, Google, or Amazon receives a CLOUD Act request, your DPA is not part of that conversation. The US government doesn’t care what you agreed with your vendor. They care what US law requires.

“But They Promised Zero Retention”

This is the defence I hear most often about AI tools. OpenAI, Anthropic, Google—they all offer zero-retention API options. Your prompts aren’t stored. Nothing to hand over, right?

In theory, yes. If data genuinely doesn’t exist, it can’t be compelled.

In practice, three problems:

1. You’re trusting a promise, not an architecture. Zero retention is a policy. Policies can change. Policies can have exceptions. Policies can be misunderstood. “We don’t retain prompts” might not cover metadata, session logs, or abuse-detection systems.

2. The request might come before the data disappears. Real-time interception exists. If your prompt is being processed right now, it exists right now.

3. You still made a cross-border transfer. Under GDPR, sending personal data to a US-headquartered company—even momentarily—is a transfer to a third country. You need a legal basis for that transfer. The EU-US Data Privacy Framework provides one today, but it’s politically fragile. If Schrems III invalidates it (and many expect this), your “zero retention” setup still broke the law.

The Schrems Cases, Quickly

For context:

Schrems I (2015): Max Schrems, Austrian privacy activist, challenged Facebook’s data transfers to the US. The European Court of Justice invalidated Safe Harbor, the EU-US data transfer agreement at the time.

Schrems II (2020): Schrems challenged the replacement framework, Privacy Shield. The ECJ invalidated that too, citing US surveillance laws as incompatible with EU fundamental rights.

Schrems III (expected): The current framework, the EU-US Data Privacy Framework, is already being challenged. Given the ECJ’s track record, many compliance professionals are planning for its invalidation.

Each time, the core issue is the same: US law allows government access to data in ways that conflict with EU privacy rights. New frameworks keep trying to paper over this. The court keeps saying no.

What “EU Data Residency” Actually Gets You

When a US company offers “EU data residency,” you get:

✅ Data physically stored in EU
✅ Compliance with GDPR’s storage requirements
✅ Potentially faster performance (closer servers)

You don’t get:

❌ Immunity from US legal process
❌ Protection from CLOUD Act requests
❌ True jurisdictional sovereignty

This is why the term “sovereign washing” exists. The marketing says “EU.” The legal reality says “California.”

What Actually Solves This

There are only two architectures that genuinely avoid CLOUD Act exposure:

Option 1: Use EU-headquartered providers

If the company is French, German, Dutch, or any EU member state, US law has no jurisdiction. A warrant served in Virginia means nothing to a company in Paris.

Examples: OVHcloud (France), Scaleway (France), Mistral AI (France), IONOS (Germany), Bunny.net (Slovenia).

The trade-off: smaller ecosystems, sometimes less polished products, fewer integrations.

Option 2: Keep data client-side

If your data never reaches a server—any server—there’s nothing to compel. This is rare in cloud computing, but it’s possible for specific use cases.

Example: browser-based encryption where the server only sees encrypted blobs it cannot decrypt.

The trade-off: limited functionality, no cross-device sync (unless you add EU-only sync infrastructure).

The Uncomfortable Truth

Most European organisations are deeply dependent on US tech. Microsoft 365. Google Workspace. AWS. Azure. Salesforce. The entire productivity stack.

Ripping this out isn’t realistic for most companies. The switching costs are enormous. The alternatives are less mature.

But you can make choices at the margin. New tools, new projects, new AI implementations—these are decision points. When you’re adopting something new, you can ask: does this need to be US-jurisdictional?

For AI tools specifically, the answer is often no. European alternatives exist. EU-endpoint options exist. Client-side architectures exist.

The question is whether you’ll choose them before a regulator asks why you didn’t.

Limbo Chat is built on a simple principle: your AI conversations shouldn’t require trusting US jurisdiction. EU-only processing, browser-side storage, no CLOUD Act exposure. Learn more.