The US CLOUD Act lets US authorities demand data from a provider under US law if the provider holds, keeps or controls it, whether the servers stand in Virginia or in Frankfurt. The GDPR, by contrast, only allows disclosure to authorities outside the EU on the basis of an international agreement.
If you put contracts, personnel files or customer data into an AI, this conflict is a real line in your risk assessment. It also explains why "EU region" doesn't answer the sovereignty question.
- The CLOUD Act obliges providers under US law to hand over data they hold or control, wherever the servers are.
- The GDPR only recognises such orders under Art. 48 if an international agreement backs them, and in practice the customer carries the conflict in between.
- So don't just ask where your data sits, but who supervises your vendor, who owns it and which state can compel it to disclose.
What is the US CLOUD Act?
The Clarifying Lawful Overseas Use of Data Act has applied since March 2018. It adds a clear rule to the US Stored Communications Act: a provider subject to US law must, on a lawful order, disclose data in its possession, custody or control. Whether the data sits inside or outside the US doesn't matter (18 U.S.C. § 2713).
So the deciding question isn't where the data is, but who has access. That covers US groups and the subsidiaries they control. How far the duty reaches in a given case, for example for companies with US business, is a question for lawyers.
Under certain conditions the provider can challenge an order that conflicts with another country's law. That procedure, however, depends on agreements between the US and the country concerned. And the customer may never learn of an order: US courts can forbid the provider from telling them.
In shortSince 2018, providers under US law must hand over data they control, wherever the servers are, and sometimes without telling you.
CLOUD Act vs GDPR: where is the conflict?
Article 48 of the GDPR covers what happens to such orders: judgments and decisions of a third country's authorities requiring a transfer of personal data are only recognised if they're based on an international agreement, such as a mutual legal assistance treaty. A CLOUD Act order on its own isn't one.
The European Data Protection Board and the European Data Protection Supervisor said as much in a joint response in 2019: disclosure based on the CLOUD Act alone generally can't rely on a legal basis under the GDPR. The provider is caught between two legal systems. If it follows the US order, it may breach the GDPR. If it follows the GDPR, it risks sanctions in the US.
For you as the controller, the risk lands with you. Many data processing agreements with US providers include a clause to review and challenge authority requests and to inform you where allowed. That's good and right. But it only changes how the conflict is fought, not whether it exists.
In shortArt. 48 GDPR only recognises such orders through an agreement. The customer carries the conflict, Data Privacy Framework or not.
Why "EU region" doesn't close the question
An EU data centre answers where the data sits. That's data residency. The CLOUD Act asks who can be compelled to disclose it. That's data sovereignty, and it follows the provider's legal system, not the address of its data centre. The graphic above shows the path: from the US authority via the provider and its EU subsidiary to your data in Frankfurt.
Encryption is often named as the answer. It only helps if the keys are exclusively yours and the provider never sees the data in plain text. With AI that's rarely the case: to answer a question, the system has to read your documents, and it does so in plain text on the operator's machines.
In shortAn EU region answers where data sits, not who must hand it over. Encryption rarely helps with AI.
Which data on an AI platform is affected
AI on your own data, a RAG system, produces more data than a file store. Each of these categories can fall under an order if a provider under US law keeps it:
| Data | What it contains | With a US provider | Self-hosted |
|---|---|---|---|
| Documents and files | contracts, manuals, personnel files | with the provider | on your servers |
| Embeddings | number vectors from your texts, often stored next to the text | with the provider | on your servers |
| Questions and answers | what staff ask, what the AI replies | with the provider | on your servers, storage can be switched off |
| Logs | who asked what, when | with the provider | in your audit log |
| Calls to a language model | question plus matching passages | with the model provider | local, no external call |
The last row is often overlooked. Even if the platform runs in Germany: if it uses a language model from a US provider, the question and passages go there with every answer.
In shortDocuments, embeddings, histories, logs and model calls, with AI, more sits with the provider than with a file store.
Who your AI vendor answers to
Behind every vendor stand three chains, and most questionnaires ask about only one. Supervision: which authority oversees it? In Germany, the Bundesnetzagentur has been the central supervisor for the AI Act since 29 July 2026. Ownership: which company do you sign with, and who owns it? And jurisdiction: which state can compel the vendor to disclose, under which law?
The three chains can point in three directions. A vendor can be supervised in Germany, owned by a group in another country and compellable under a third state's law. Ownership changes fastest: an acquisition between two tenders can shift all three answers.
Ask every vendor these questions, us included:
Every point ticked. Well prepared.
In shortAsk about supervision, ownership and jurisdiction, and what changes after an acquisition.
Three ways to run AI on your data
Whether the CLOUD Act matters to you depends on who runs your AI and which language model it uses. There are three ways:
The three ways compared
Data in the EU, provider under US law.
Data location: a data centre in the EU. Jurisdiction: the provider is subject to US law, so a CLOUD Act order is possible. Safeguards: contracts and the Data Privacy Framework. What you can check is mainly certificates and contracts.
Run by RAGSuite in Germany.
Data location: documents, search index and histories sit in a data centre in Germany, run by RAGSuite. Check: ask us the same six questions. The data centre and sub-processors are listed in our data processing agreement. Note: if you choose a language model from an external provider, the question and passages go to that provider. The questions then apply to them too.
No provider in the data path.
Data location: your servers or a host of your choice, offline if you like. Jurisdiction: there's no provider keeping your data for an authority to address. With a local language model no request leaves your network, and RAGSuite itself sends no data to us.
Many companies decide per project: own servers and a local model for personnel files and client data, RAGSuite Engine for projects that need to start quickly. With the free location check you can test any provider against its facts:
Read more about the difference between location and control on our page Sovereign AI. What runs where in RAGSuite Engine is shown in the Trust Center. And what running it on your own servers looks like is explained in Self-hosted AI.
This is general information, not legal advice. Have your data protection officer or legal counsel assess your specific risk.
In shortUS provider with EU region, RAGSuite Engine or your own servers: decide per project, and check the language model too.
Check your AI vendor with the free location check, or go through the questions with Jürgen.
Frequently asked questions
Does the CLOUD Act apply to data in German data centres?
Yes, if a provider under US law holds, keeps or controls the data. The duty to disclose follows the provider, not the server's location. A data centre in Frankfurt therefore doesn't protect you if a US parent company owns or controls it. What counts is who has access to the data.
Does the EU-US Data Privacy Framework solve the problem?
Only partly. Since July 2023 the framework has allowed transfers to certified US companies, and the EU General Court upheld it in September 2025. The appeal is pending at the Court of Justice. It doesn't remove US authorities' access under the CLOUD Act, and like its predecessors it can fall.
Does encryption protect against the CLOUD Act?
Only if you alone hold the keys and the provider never processes the data in plain text. With AI that's rarely possible, because the system has to read your documents to answer. That processing happens in plain text on the operator's machines, so with the provider whenever the provider runs the platform.
What about providers based in Germany?
What counts is whether the provider or a parent company is subject to US law. If a provider based in Germany isn't owned by a company under US law, the answer usually differs, but not automatically: check the data centre operator, sub-processors and model providers one by one. Ask for the whole chain in writing.
Does a self-hosted AI automatically meet the GDPR?
No. Self-hosting removes the transfer risk and the provider in the data path. You still need a legal basis, a purpose, retention periods, access rights and, where required, a data protection impact assessment. Running on your own servers just makes these points easier to prove. This is general information, not legal advice.
Sources
- 18 U.S.C. § 2713: Required preservation and disclosure: statute text
- US Department of Justice: CLOUD Act resources: mechanism and reach
- DSGVO Art. 48 (EUR-Lex): recognition of third-country orders
- EDPB–EDPS joint response on the US CLOUD Act (2019): European data protection view
- General Court, T-553/23 Latombe v Commission (3 Sep 2025): framework upheld, appeal C-703/25 P pending
- KI-MIG (gesetze-im-internet.de): Bundesnetzagentur as AI supervisor
- Bitkom Cloud Report 2026: 603 companies with 20+ staff
Jürgen advises companies on introducing AI on their own infrastructure and leads RAGSuite at NITSAN. He writes about sovereignty, strategy and costs.