What Is the CLOUD Act?

By Weapp · Updated

The CLOUD Act is a US law that gives US authorities the right to compel data from US companies regardless of where the data is physically stored – even in the EU. Since all four major AI providers are ultimately subject to US jurisdiction, EU storage doesn't neutralize the law. The risk is mitigated with technical supplementary measures, not wishful thinking.

Many people assume the question of US data access is settled as soon as a service stores data in the EU. The CLOUD Act is why that’s not true. The law ties access to the company’s jurisdiction, not to where the servers stand – and that changes how you need to think about AI providers.

What the Law Does

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act) is a US law that gives US authorities the legal right to compel data from US companies – regardless of where the data is physically stored. If the data sits in a European data center but is controlled by a US company, the request still reaches it.

This is the core of the problem for AI buyers: all four major AI providers in the usual lineup are ultimately subject to US jurisdiction. The fact that a service is operated in the EU or billed through a European subsidiary doesn’t change the parent company’s domicile. Jurisdiction follows the company.

It’s also worth distinguishing the CLOUD Act from the transfer question in GDPR itself. A transfer to a third country requires a lawful mechanism – Standard Contractual Clauses or an adequacy decision. The CLOUD Act is a different problem: even when the mechanism is in place and the data sits in the EU, the company controlling it can be compelled to hand it over to US authorities. The mechanism addresses the legality of sending data; the CLOUD Act is about who can access it afterward. That’s why the two questions have to be handled separately in a review.

The Documented Testimony

The question isn’t hypothetical. During 2025, Microsoft France confirmed under oath before the French Senate that the company can’t guarantee protection against a US request for data. That’s an unusually clear confirmation coming from one of the largest providers itself.

At the same time, according to the information available, it has never happened that a European customer’s data was actually obtained that way. That makes the risk a legal possibility rather than an event that’s occurred – but a possibility a supervisory authority or auditor may well require you to address.

Why EU Storage Isn’t Enough

The conclusion is uncomfortable but important: EU storage reduces exposure but doesn’t neutralize the CLOUD Act. Storage and jurisdiction are two separate questions. You can have all your data in Frankfurt and still have a provider that can be lawfully compelled to hand it over.

A concrete scenario: a company chooses the EU region for its AI service, checks the box for “data in the EU,” and considers the third-country question settled. During the review, it’s pointed out that the provider’s US parent company can be subject to a CLOUD Act request – and that the EU region doesn’t address that. What remains is to show what supplementary measures are in place.

Mitigation Under the EDPB

The European Data Protection Board’s Recommendations 01/2020 point the way: technical and organizational supplementary measures on top of the transfer mechanism. In an AI context, that generally comes down to three things:

  • Customer-controlled encryption (KMS/CMEK) where the provider doesn’t hold the key, so that any data handed over is unreadable.
  • Data minimization – send as little personal data to the service as possible.
  • EU inference and other measures that limit where and how the processing happens.

The residual risk that remains is disclosed openly in a data protection impact assessment (DPIA), instead of being wished away. The whole point of the EDPB’s model is that the risk should be managed and documented, not denied.

Of the three, customer-controlled encryption is often the heaviest-weight measure. The idea is simple: if you hold the keys yourself, in a key management service the provider can’t reach, then any data that does get handed over is unreadable without your involvement. A request that lands on the provider then yields encrypted blocks, not readable personal data. It rarely eliminates the risk entirely – keys have to be used somewhere for data to be processed – but it shifts control to you and is a central building block of a defensible architecture. For a Swedish organization that needs to be able to stand behind its choice before the Swedish Authority for Privacy Protection (IMY), that’s the difference between having a well-thought-out measure to point to and standing there with nothing but a promise of EU storage.

If you’d like to see how the CLOUD Act connects to residency, transfer mechanisms, and retention across a full AI project, there’s more on our AI page. Need help building an architecture that holds up to a review? Get in touch and we’ll take a look at your setup.

Frequently asked questions

Does the CLOUD Act make EU storage pointless?

No, but it isn't enough on its own. EU storage reduces exposure and is often a requirement in itself, but it doesn't remove US jurisdiction. Under the CLOUD Act, a US company can be ordered to hand over data it controls, even if the servers sit in Europe. Storage and jurisdiction are two different questions.

Which providers fall under the CLOUD Act?

Every company subject to US jurisdiction, which includes all four major AI providers in the usual lineup. The fact that a service is operated in the EU or billed by a European subsidiary doesn't change the parent company's US domicile. Jurisdiction follows the company, not the data center.

Have US authorities actually obtained EU data under the law?

According to the information available, that hasn't happened to a European customer's data so far. At the same time, Microsoft France confirmed under oath before the French Senate in 2025 that it can't guarantee protection against a US request. The risk is therefore legally real even where it hasn't materialized in practice.

How do you mitigate the CLOUD Act risk?

With technical and organizational supplementary measures under the EDPB's Recommendations 01/2020. As a rule, that means customer-controlled encryption (KMS/CMEK) where the provider doesn't hold the key, data minimization, and EU inference. The residual risk is then disclosed openly in a DPIA instead of being assumed away.

Does customer-controlled encryption protect against the CLOUD Act?

It's the most common technical measure. If you hold the encryption keys yourself (CMEK/KMS), the provider can only hand over encrypted data that's unreadable without your key. It rarely eliminates the risk entirely, but it shifts control to you and is a central part of a defensible architecture under the EDPB.