Your GPU Server Is in Frankfurt. Your Data Isn't Safe.

You’ve done everything right. You rented a dedicated GPU server in a Frankfurt data center. You downloaded an open-weight model — Llama, Mistral, whatever — and you’re running inference locally. Your prompts never leave the building. Your data stays in Germany.

Except it doesn’t. Not legally.

If the company you’re renting that server from is American — or has a US parent company — then US law enforcement can compel them to hand over your data. It doesn’t matter that the server is in Frankfurt. It doesn’t matter that you’re running your own software on it. The CLOUD Act follows the provider, not the server.

The CLOUD Act follows the provider, not the server. If your GPU host is American, your Frankfurt data center changes nothing.

The jurisdiction trap

Here’s the core problem: data sovereignty isn’t data residency. Where your data physically sits is one question. Who has legal authority over it is a completely different one.

The Clarifying Lawful Overseas Use of Data Act — the CLOUD Act, signed into US law on March 23, 2018 — gives US authorities the power to compel any US-controlled company to produce data in its possession, custody, or control. The law explicitly states that this obligation exists “regardless of whether such communication, record, or other information is located within or outside of the United States.”

That’s not ambiguous. If you rent a GPU server from a US company operating in Frankfurt, Amsterdam, or Helsinki, the US government can issue a warrant to that company for your data. The company is legally required to comply — even if doing so would violate GDPR. We’ve written about this legal collision before, and it remains unresolved.

What “access” actually means for GPU rentals

“But I’m running my own model on dedicated hardware,” you might say. “The hosting company doesn’t see my data.”

They don’t need to see it to access it. Here’s what the hosting company controls, even on a “dedicated” server:

The hypervisor. If you’re on a virtual machine (most GPU rentals are), the host controls the hypervisor — the software layer beneath your operating system. It can snapshot your entire VM, including whatever’s in GPU memory at that moment.

The network. Your traffic passes through their switches, their firewalls, their monitoring. Even encrypted traffic reveals metadata — when you’re running inference, how much data moves, what endpoints you connect to.

The firmware. BMC/IPMI management interfaces give the host out-of-band access to your server. They can reboot it, mount virtual media, access the console — all without your knowledge or consent.

The physical hardware. Your prompts exist in GPU VRAM during inference. Your model weights sit in system memory. On bare metal, the provider can physically access the machine. On shared infrastructure, they control the memory allocation layer.

The short version: running a private LLM on rented US-company hardware is like keeping a diary in a locked drawer in a rented apartment. The lock is yours. The apartment isn’t.

Running a private LLM on rented US-company hardware is like keeping a diary in a locked drawer in a rented apartment. The lock is yours. The apartment is not.

FISA 702 makes it worse

The CLOUD Act isn’t the only law that reaches into EU data centers. FISA Section 702 — originally designed for foreign intelligence surveillance — was reauthorized and expanded in April 2024 through the Reforming Intelligence and Securing America Act.

The expansion broadened the definition of “electronic communications service provider” to include any entity with “access to equipment that is being or may be used to transmit or store wire or electronic communications.” A GPU hosting company that rents you a server with network connectivity fits that definition precisely.

Under FISA 702, surveillance requests come with a gag order. The provider can’t tell you they’ve been compelled to provide access. Unlike the CLOUD Act (which involves a warrant and some due process), FISA 702 orders are approved by a secret court — the Foreign Intelligence Surveillance Court — and the target is never notified.

So not only can US authorities access your data on a US-company GPU server in Frankfurt — they can do it without you ever knowing.

The private LLM illusion

This matters especially for AI workloads. When you send a prompt to a locally-running LLM, the prompt exists in plaintext in GPU memory during inference. The model’s attention mechanism processes your query token by token, and at each step, your data is in VRAM — unencrypted, because encryption would make computation impossible.

If the hosting provider controls the hypervisor or has physical access to the machine, they can — in theory and in practice — capture that data. A VM memory snapshot catches everything: your prompt, the model’s intermediate states, and the generated response.

This isn’t theoretical paranoia. It’s the architectural reality that the European Data Protection Board’s guidance addresses when it requires “supplementary measures” for data transfers. The EDPB specifically states that contractual commitments alone aren’t sufficient — the protection must be architectural. The US provider must never have access to unencrypted data or encryption keys.

For GPU inference workloads, that’s nearly impossible to achieve on someone else’s hardware. The data must be unencrypted in GPU memory to be processed. If the provider controls the hardware, they control the data.

Who actually has access?

Let’s be concrete about who can reach your “private” LLM running on a US-company GPU in the EU:

The hosting company’s infrastructure team. They maintain the hypervisor, firmware, and physical hardware. They have root-equivalent access to everything running on their machines.

US law enforcement (via CLOUD Act warrant). With a valid warrant, the hosting company must produce data in its custody or control. Your VM, your model outputs, your logs.

US intelligence agencies (via FISA 702). With a FISC order, the hosting company must provide access to communications data. The definition is broad enough to include your inference traffic.

The hosting company’s government (for EU-headquartered subsidiaries). If the US company operates through an EU subsidiary, that subsidiary is subject to both EU law and — through the parent company relationship — US law. The Schrems II decision found this arrangement fundamentally incompatible with EU data protection.

Who doesn’t have access? You — if a gag order accompanies the request.

Under FISA 702, surveillance comes with a gag order. Your provider cannot tell you they have been compelled to hand over access.

What actually protects you

The uncomfortable truth is that renting GPU hardware from a US company and calling it “self-hosted” doesn’t provide sovereignty. Here’s what does:

An EU-owned provider with no US parent company. Scaleway (France), OVHcloud (France), Hetzner (Germany) — these are EU-headquartered, EU-owned companies not subject to US jurisdiction. The CLOUD Act can’t reach them because there’s no US entity in the chain to compel.

Customer-controlled encryption for data at rest. Your encryption keys should be generated on your devices and never shared with the provider. This way, even if the provider’s hardware is physically seized, your stored data is unreadable.

Runtime isolation for data in use. This is the hard part. Some providers offer confidential computing — hardware enclaves (AMD SEV-SNP, Intel TDX) that encrypt data even while it’s being processed. The hosting provider can’t read memory inside the enclave, even with hypervisor access. This technology is still maturing for GPU workloads, but it’s the direction the industry is moving.

No contractual workarounds — architectural guarantees. The EDPB is clear: a contract that says “we won’t share your data” doesn’t protect you if the provider is legally compelled to break that contract. The protection must be technical, not legal.

What to do now

1. Check your GPU provider’s parent company. Not just the entity you’re contracting with — follow the ownership chain. If a US company is anywhere in the corporate hierarchy, the CLOUD Act applies.

2. Read your contract’s law enforcement clause. Every hosting contract has one. Look for language about “lawful requests,” “court orders,” or “legal obligations.” If it references compliance with US law, that’s your answer.

3. Ask your provider about hypervisor access. Can they snapshot your VM? Do they have IPMI/BMC access to bare metal? If the answer is yes, they can access your data during inference.

4. Evaluate EU-native GPU providers. Scaleway, OVHcloud, and Hetzner all offer GPU instances. They’re more expensive than some US alternatives, but they’re not subject to US jurisdiction. We’ve covered the full landscape.

5. If you must use a US provider, encrypt at rest with your own keys. This doesn’t protect data during inference, but it protects stored research outputs, model fine-tuning data, and logs.

6. Ask about confidential computing support. AMD SEV-SNP and Intel TDX provide hardware-level memory encryption. Not all providers support it, and GPU workloads are still catching up, but it’s the strongest technical mitigation available.

7. Don’t confuse “runs on my server” with “sovereign.” Self-hosting on rented hardware gives you operational control — you choose the model, the config, the data pipeline. But it doesn’t give you jurisdictional sovereignty unless the underlying provider is outside US legal reach.

8. Consider your risk profile honestly. If you’re running general-purpose research on public information, the jurisdictional risk may be acceptable. If you’re processing client-privileged legal research, medical records, or competitive intelligence, it probably isn’t. Match your infrastructure to your data sensitivity — our classification guide can help.