If you train or serve models in 2026, the country where your GPU is plugged in is not a footnote anymore. It changes who can lawfully read the data, what you owe regulators, how fast users see results, and what you pay to move bytes. This piece is the practical version of that conversation, written for teams that already operate inside the EU and have to make a real call.
What "EU-based" actually controls
When a vendor says "EU region", three concrete things are supposed to change.
First, jurisdiction. A GPU node in Frankfurt or Madrid sits inside the GDPR enforcement perimeter. A US-controlled provider can legally serve EU customers, but extraterritorial requests (CLOUD Act, FISA 702) reach back through the corporate parent. Providers headquartered in the EU do not have that reach-through.
Second, latency. Most EU traffic stays on regional peering. Same-region inference cuts roughly 60–120 ms compared with shipping requests to us-east-1. For chat or any interactive tool, that is the difference between "responsive" and "noticeable lag".
Third, egress economics. Hyperscalers charge $0.05–$0.12 per GB to leave their network. A 2 TB monthly fine-tune dataset costs €100–€240 just to move once. EU GPU specialists usually price egress at zero or close to it, because egress is not their moat.
What GDPR actually requires (and what it doesn't)
The common misconception is "if it's not in the EU, it's illegal". That is not what the regulation says. GDPR allows international transfers when the destination has an adequacy decision, or you have Standard Contractual Clauses (SCCs) plus a Transfer Impact Assessment, or you rely on a derogation.
In practice, SCCs work. But post-Schrems II, you have to document that the destination's surveillance laws don't undermine the protections, and the EU's own data protection authorities increasingly disagree about which jurisdictions clear that bar. Hosting inside the EU just removes the question. That is the operational appeal: not that other arrangements are illegal, but that EU-only is the only setup with zero compliance footnotes.
Where latency actually shows up
Two scenarios are worth thinking about.
User-facing inference. A request from Madrid to a model in Madrid is roughly 5 ms RTT. The same request to Virginia is around 95 ms RTT, plus the TLS handshake, plus the model's actual compute time. For streaming responses, the user perceives first-token latency that is dominated by RTT, not GPU. Putting the GPU near the user is the cheapest latency improvement available.
Multi-step pipelines. RAG systems that hit a vector DB, then a reranker, then a generator amplify every hop. If the storage and the GPU live in the same region, you avoid paying that cross-region penalty three times.
The egress trap
Bandwidth is the biggest hidden cost in cloud GPU. A typical training run involves:
- Downloading the dataset (free or close to it, depending on source).
- Running the GPU (the line item you actually planned for).
- Uploading checkpoints to object storage.
- Pulling those checkpoints later for inference.
Hyperscalers price the upload-to-object-storage step at $0 if you stay in the same region. Anything that crosses regions or leaves the cloud entirely is billed by the GB. Once you start shipping to another vendor for inference, or pulling checkpoints to your laptop, the egress line on your invoice can rival the GPU line.
EU GPU specialists tend to bundle bandwidth in one of two ways. Either egress is free (you only pay compute), or transfers between EU regions are not metered. For workloads that move data, that simplification matters more than the headline €/h.
Compliance does not stop at residency
Hosting inside the EU is necessary, not sufficient. The questions you should be asking on top of that:
Subprocessors. Where do they sit, and which jurisdictions do they invoke?
Encryption at rest. Are volumes encrypted by default, with keys managed in the EU?
Logging and access. Who at the provider can see your workload, and from where?
DPA quality. Is there a real Data Processing Agreement, or a copy-pasted template that flips you into a controller-controller relationship by accident?
A "EU region" label without those answers is a marketing claim, not a compliance posture.
When non-EU still makes sense
There are workloads where the EU-only constraint costs more than it earns.
Pre-training new foundation models. You probably need every H100 you can find. If a US provider has them and an EU provider doesn't, the lawful path through SCCs is the right call.
Public, non-personal data. If you're rendering animation or running scientific simulations on synthetic inputs, GDPR does not apply. Pick on price and SLA.
Multi-region serving. A SaaS with users on three continents should not pin everything to one EU region. Use the EU as the primary and replicate elsewhere where user volume justifies it.
The framing here is not "EU good, US bad". It's matching the data residency posture to the data.
What we ship
Clodei runs entirely in the EU. The default region is EU-West. We do not bill egress. The DPA on our website is a real DPA, signed without negotiation cycles. If your workload is EU-personal-data, that is the simplest answer on the table. If it isn't, we still tend to be cheaper per hour than the hyperscalers, but the strongest reason to land here is the regulatory simplicity.