Residency is not sovereignty. An EU region in a US console does not change who can be ordered to hand over your data.
Picking an EU region in a US provider's console fixes where your data sits, not who can reach it. What the CLOUD Act reaches, why the usual contractual fixes leave the gap open, and the three-part test that separates the two.
In this article 4 sections
- The CLOUD Act reaches providers under US jurisdiction wherever the server physically sits. An EU region in a US console is residency, not sovereignty.
- Sovereignty, if it is to mean anything, needs three things under EU law at once: the provider, the infrastructure, and the people operating it.
- GDPR fines reach 4% of global annual turnover, and the AI Act sets its own ceiling, up to 7% for prohibited practices. The compliance question is not theoretical.
- If your prompts carry regulated data, the fix is structural, not a setting: an EU provider on EU hardware with EU hands on the keyboard.
Every US hyperscaler console has a region dropdown, and picking eu-central feels like a compliance decision. It isn't. The CLOUD Act attaches to the provider, not to the server's postcode: a US-headquartered company operating a Frankfurt data center can be compelled to hand over data held there. Where the data lives and who can be ordered to produce it are two different questions, and the dropdown only answers the first.
What the CLOUD Act reaches
The Clarifying Lawful Overseas Use of Data Act, passed in 2018, lets a US court order a provider subject to US jurisdiction to produce data in its possession, custody or control, regardless of whether that data is stored inside or outside the United States. The test is the provider's legal reach, not the location of the disk. A company incorporated in the US, or operating there, or with a US parent that controls the entity running your EU region, can fall inside that reach.
That is the whole distinction. Residency is a statement about geography: the bytes are on a disk in the EU. Sovereignty is a statement about law: the legal orders that reach those bytes are EU orders, served on an EU entity, executed by people employed under EU law. Residency is easy to buy and easy to show on a map. Sovereignty is a property of the company structure, and no dropdown can grant it.
| RESIDENCY | SOVEREIGNTY |
|---|---|
| Where the disk is. A region picker in a console. | Who can lawfully order the data produced. A question of jurisdiction over the provider. |
| THE DIFFERENCE THE DROPDOWN CANNOT CLOSESatisfied by an EU region at any provider. | Satisfied only when the provider, the hardware and the staff all sit under EU law. |
| A US order to the parent company can still reach the data. | There is no US entity in the chain for a US order to land on. |
Why the standard contractual fixes do not close the gap
The usual answers are paper: standard contractual clauses, a data processing addendum, a transfer framework, a provider promise to challenge foreign requests. Each of those is a contract between you and the provider. None of them binds a US court. When a lawful order arrives, the conflict between the provider's contract with you and its obligation to the court is resolved by the provider's lawyers, on the provider's timeline, with you informed if the order permits it. The clauses can change how a provider responds to a demand. They cannot change whether the demand can be made.
- Standard contractual clauses govern transfers between you and the processor. They say nothing to a court that orders the processor to produce data.
- A "sovereign" offering from a non-EU parent moves the operating entity and the staff, which helps, as long as the parent cannot direct it. Read who owns the entity and who can instruct it.
- Customer-held encryption keys are the strongest paper fix, and they still leave the provider holding the ciphertext, the metadata and the access logs, and still leave the key management under its software.
- Transfer frameworks make the transfer lawful under GDPR. They do not withdraw the foreign jurisdiction that made the question arise.
The three-part test
A structural answer has to pass three questions at once. If any one of them fails, a legal path back to your data can open outside the EU, however the marketing reads.
Is the provider an EU entity, under EU control?
Not an EU subsidiary of a non-EU parent that can instruct it, and not a reseller of a non-EU platform. The company that holds the contract and operates the service should be incorporated in the EU and take no instruction from outside it.
Is the infrastructure physically in the EU and owned or controlled by that entity?
Hardware in an EU datacenter, operated by the provider, with no non-EU platform layer underneath it that has its own access to the machines.
Are the people with access employed under EU law?
Operations staff, support staff, anyone with a key or a credential. If a non-EU parent's staff can reach the systems, the jurisdiction travels with them.
Apply the test to any provider, including us. Euclid Services Ltd has its corporate headquarters in Cyprus; the hardware in our Athens and Amsterdam datacenters is ours and is operated by our own engineers. Ask the same three questions of anyone else and the answers sort providers quickly.
Why AI workloads feel it first
That gap matters most for AI workloads, because prompts are the most candid data a company produces: contracts, patient notes, source code, the questions nobody puts in writing anywhere else. A hosted model receives them in plain text, and a hosted API persists them wherever its operator persists them. A regulated organisation can control what goes into a database field. It cannot control what an employee types into a prompt box, which is exactly why where that box lives is a structural question.
An open-weight model on single-tenant hardware inside an EU provider's datacenter removes the third party from the picture. The model runs on your machine, the prompts stay on your machine, and the only people who can touch that machine are employed under EU law. It is the same answer as the rest of this post: not a setting, a structure.
Straight answers
Isn't an EU region enough for GDPR?+
Residency helps with parts of GDPR, but GDPR was never the only exposure. A provider subject to US jurisdiction can face a lawful US demand for data held in the EU, and that conflict is exactly the gap the region picker cannot close.
What actually qualifies as sovereign?+
Provider incorporated in the EU, hardware physically in the EU, and the people operating it employed under EU law. Remove any one of the three and a legal path back to your data can open outside the EU.
Does this apply to AI API providers too?+
Yes, and more so. With a hosted API your prompts transit and persist with a third party under that party's jurisdiction. Self-hosting an open-weight model on sovereign hardware removes the third party entirely.
Do customer-held encryption keys solve it?+
They narrow it. The provider still holds the ciphertext, the metadata and the access logs, and the key management runs on its software. Keys are a good control on top of a sovereign structure, and a weak substitute for one.
Bring us the model you want to run
Single-tenant GPU hardware in our EU datacenters, run by our own engineers under EU law.
See GPU ServersYou’ve reached the end.
Put the reading to work
What are
you running?
Tell us about the workload, traffic and recovery requirements. Start with the server builder, or talk through the details with an engineer.
Written by the engineers who build and run the infrastructure it describes.Talk to an engineer