EU-Sovereign GPUs: Is the Premium Worth It for Training, or Only for Inference?

Most EU teams I talk to are paying the sovereignty premium in the wrong place.

They sign a pricey sovereign contract for the training run, where the data was already curated and could have been anonymized, and then pipe every production prompt, log line and vector embedding into a US-region backend that nobody wrote down in the transfer assessment. The money goes where it feels reassuring, not where the risk actually lives.

So when someone forwards me a sovereign GPU quote and asks "is this worth it?", my honest answer has three parts. Training a model is "processing" under GDPR, so residency does apply to it. But the economic case for a sovereign premium is strongest at inference. And for training specifically, whether you should pay depends almost entirely on what is in the corpus.

Key Points:

• Data residency is not an inference-only concern. Training a model on personal data is "processing" under GDPR Article 4(2), so the international-transfer rules in Chapter V (Articles 44 to 49) apply to a training run exactly as they apply to a live prediction.
• For training, pay the premium when the corpus is regulated. Health records, financial data in DORA scope, public-sector contracts with sovereignty clauses, or customer transcripts under a DPA that limits sub-processors all justify it. Public, licensed, synthetic or genuinely anonymized data does not.
• The surprise in the 2026 price data: EU-native clouds often undercut US hyperscalers. Scaleway and OVHcloud publish H100 rates below AWS and Azure US on-demand list prices. The real premium shows up at the sovereign-controlled tier and in the lead time for the newest accelerators, not in the base hourly rate.
• Inference is where residency compounds. Every request manufactures new personal data (the prompt, the retrieved context, the output, the log line, the eval trace, the feedback label) and it never stops. A training run touches one curatable dataset once.
• The architecture most EU teams land on is split. Sanitize in the EU, train on whatever capacity is cheapest and actually available, store weights in an EU artifact store, then run inference and every request-derived artifact in an EU region inside your own cloud account. Qovery deploys and operates that application layer inside your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster, so EU residency becomes a region choice rather than a migration.

Is data residency only a concern at inference time?

No. Training is "processing" under GDPR Article 4(2), so residency and international-transfer rules apply to a training run exactly as they apply to a live prediction. What changes between the two phases is the shape of the risk, not the legal status.

Training and fine-tuning work on bulk historical data in a batch job of finite duration, over an input set you can list and audit. Inference runs on live prompts, user context and retrieval, continuously and without a defined end. One is a fixed dataset you curate once. The other is an unbounded stream.

Article 4(2) defines processing as "any operation" performed on personal data: collection, storage, use, structuring, the lot. The obligation attaches to the operation, not to a stage of the model lifecycle. Chapter V then governs any transfer of that data outside the EU. Nothing in either text carves out "but only once the model is serving users."

Two assumptions push teams into treating training as exempt. First, the dataset feels internal, already collected, so moving it to a GPU somewhere abroad feels like an internal operation rather than a transfer. It is a transfer. Second, the output feels like "just weights," not personal data, so the run feels consequence-free. Whether that holds is a real question, and I come back to it below.

Where residency genuinely binds at inference: prompts, RAG retrieval and embeddings, model outputs, request logs, eval traces, human feedback data, caches and backups. Every one of those is new personal data created in production.

The rule of thumb I give people: if you serve EU users, inference almost always needs EU residency; training needs it only when the corpus itself is regulated. This is how engineering teams and their counsel tend to reason about it, not legal advice, so confirm the specifics with your DPO before you sign anything.

What does "EU-sovereign GPU capacity" actually mean, and what does it not guarantee?

EU-sovereign GPU capacity means compute physically located in the EU and, in its strongest form, operated by a legal entity outside the reach of foreign extraterritorial law. Most offerings sold as "sovereign" deliver only the location half. That is why I keep coming back to three tiers, because the word "sovereign" on a sales deck can mean any of them.

Tier 1 is an EU region of a US hyperscaler (eu-west-1, europe-west4, West Europe). Your data sits at rest in the EU, which handles data residency, but the operator is still a US-controlled company.

Tier 2 is a sovereign-controlled offering. The AWS European Sovereign Cloud reached general availability on 15 January 2026, backed by a €7.8 billion investment, with its first region in Brandenburg, Germany, operated by EU-incorporated entities staffed exclusively by EU-resident personnel. Google Cloud Sovereign Cloud offers software controls plus partner-operated clouds such as S3NS in France (majority-owned by Thales) with external key management the customer holds. Microsoft Cloud for Sovereignty adds customer-held keys, confidential compute and tamper-evident access logging. (One common mix-up worth clearing: "Delos Cloud" is an SAP-operated, Azure-based sovereign cloud for the German public sector, not a Google offering.)

Tier 3 is an EU-headquartered operator such as Scaleway, OVHcloud, IONOS, Exoscale or Nebius, plus the EuroHPC public systems (LUMI, Leonardo, JUPITER, MareNostrum 5). Here the operator itself is European by incorporation and jurisdiction.

What sovereignty does not buy you is just as important:

• No GDPR exemption. Sovereign compute still processes personal data under the same rules.
• No guarantee of GPU availability. Sovereign and scarce are unrelated properties.
• No substitute for a DPA, encryption, key management and access controls. Those are still your job.

The legal backdrop in two sentences, no drama: the concern with a US-controlled operator is a lawful access request served under US extraterritorial law (the CLOUD Act), served on a company that can be compelled regardless of where the server sits. Transfers to US-operated providers currently rely on the EU-US Data Privacy Framework adequacy decision, which remains in force in 2026 after the General Court upheld it in September 2025, though an appeal to the Court of Justice is pending.

A few obligations get conflated with residency but are separate regimes: the EU Data Act (applicable since 12 September 2025, covering cloud switching and egress fees), the AI Act (general-purpose AI model obligations apply from 2 August 2025), NIS2 and DORA. Keep them in separate boxes or the decision gets muddy.

And sovereignty of the artifact store counts too. Checkpoints, weights, training logs and dataset snapshots all live somewhere, and a sovereign GPU feeding a US bucket defeats the point.

How big is the EU-sovereign GPU premium in 2026?

Here is the finding that surprised me when I pulled the numbers: there is no single "EU premium." EU-headquartered discount clouds frequently undercut US hyperscaler on-demand list prices. The premium is real, but it sits at the sovereign-controlled tier and in the lead time for the newest accelerators, not in the base H100 rate.

All prices below are published on-demand rates captured in October 2026. Provider pricing pages are the source of truth and these move, so check the live page before you budget.

• Scaleway lists H100 PCIe around €2.73 per GPU-hour and L40S around €1.47.
• OVHcloud lists H100 around €2.80 per GPU-hour from its Gravelines region.
• Nebius (headquartered in Amsterdam) lists HGX H100 at $4.50 and H200 at $5.40 per GPU-hour, following a price change effective 1 October 2026.
• IONOS offers H200 only, from about $3.26 per GPU-hour, which is the cheapest H200 on this list.

Against those, the US baselines: Lambda lists H100 SXM at $3.99 per GPU-hour on its 8-GPU config, CoreWeave lists HGX H100 at $6.16 and H200 at $6.31, and AWS p5 (8x H100) works out to roughly $6.88 per GPU-hour in us-east-1 with p5en (H200) around $7.91. The three hyperscalers publish GPU prices only through JavaScript calculators (AWS, Google, Azure), and I could not confirm a distinct EU-region figure for any of them, so I am not going to invent one. Azure's ND H100 v5 lands near $12.29 per GPU-hour in a US region, Google's A3 (H100) near $10.98.

The hourly rate is often not the biggest number anyway. Watch these multipliers:

• Egress charges on moving checkpoints and datasets out.
• Checkpoint and dataset storage for the duration.
• Committed-use or reserved discounts, which change the comparison entirely at scale.
• Interconnect and networking for multi-node runs (and note Scaleway's cheap H100 is PCIe, not the SXM fabric you want for large multi-node training).
• Queue time. Idle ML engineers waiting on capacity are a real line item.

That last point is where the genuine EU premium hides. NVIDIA's CEO said on the Q3 FY2026 earnings call that cloud GPUs are "sold out." Scarcity of the newest accelerators in EU regions can mean weeks of lead time, which on a project timeline usually dominates a per-hour difference of a dollar or two. I have not found an independent primary source cleanly comparing EU-versus-US lead times, so treat vendor blog numbers on that with caution, but the direction is not controversial.

Here is a worked example so there is a concrete figure to anchor on: a 1,000 GPU-hour fine-tune, roughly 8x H100 for about five days.

The EuroHPC systems are the genuinely cheap outlier for research-style workloads. JUPITER is Europe's first exascale machine, built on around 24,000 NVIDIA GH200 superchips, and there is an industrial access track. The tradeoff is real: you get capacity through peer-reviewed allocation calls, not an on-demand console, with scheduling queues and no managed application stack. Great for a bounded research run, wrong tool for a product on a deadline.

When is the EU-sovereign premium worth it for training AI models?

Pay the premium for training when the corpus itself contains personal, regulated or contractually restricted data. Skip it when the corpus is public, licensed, synthetic or genuinely anonymized. That single test resolves most cases in under a minute.

Clear "pay the premium" cases:

• Health and patient data.
• Public-sector contracts with explicit sovereignty clauses.
• Financial records in DORA scope.
• Customer support transcripts.
• Anything under a DPA that restricts sub-processors or transfer destinations.

Clear "do not pay" cases:

• Public web corpora.
• Licensed open datasets.
• Synthetic data.
• Fully anonymized or aggregated data.
• Continued pretraining of open-weight models on non-personal text.

The grey zone is pseudonymization. Under GDPR Recital 26, pseudonymized data that could be re-attributed to a person using additional information is still personal data. Only genuinely anonymized data falls out of scope, and the bar is high: the EDPB's draft Guidelines 01/2025 on pseudonymisation (adopted for public consultation in January 2025) reaffirm that pseudonymized data remains personal data. Stripping names is not anonymization.

There is also a procurement reality worth saying out loud: sometimes the premium buys a deal, not compliance. If a public-sector tender or a large enterprise RFP demands sovereign training as a hard requirement, the ROI question is answered by the revenue on the contract, not by GDPR. That is a legitimate reason to pay. Just name it for what it is.

The pragmatic middle path, which a lot of teams run: do the sanitization and anonymization pipeline inside the EU, then train on cheaper non-EU capacity. It works until it does not, and it breaks in three specific places: residual re-identification risk in "anonymized" data, contractual clauses that name permitted regions regardless of anonymization, and memorization of rare or unique records during training.

A six-question checklist to run against your own corpus:

1. Does it contain data about identifiable people?
2. If yes, is it genuinely anonymized to the EDPB bar, or only pseudonymized?
3. Is any of it in a regulated category (health, finance, public sector)?
4. Does a DPA or contract restrict where it can be processed or who can sub-process it?
5. Could rare records be memorized and later extracted from the model?
6. Does a customer or tender require sovereign training as a written condition?

Any "yes" to 1-and-not-2, or to 3, 4 or 6, and the premium is doing real work. All clear, and it is buying you comfort, not protection.

Are model weights personal data, and does that change where you can train?

It depends on the facts, and that is the official position rather than a dodge. The EDPB's Opinion 28/2024, adopted 17 December 2024, says an AI model trained on personal data is not automatically anonymous and must be assessed case by case. So treat "the weights are just numbers" as an assumption you have to defend, not a default you get for free.

The Opinion rejects an all-or-nothing view. To call a model anonymous, you have to show that both the likelihood of extracting the training personal data from the model (for example through model-inversion attacks) and the likelihood of obtaining it from the model's outputs are insignificant, judged against all means reasonably likely to be used.

Weights are most likely to carry personal data in a few situations: small fine-tunes on customer records, memorization of rare or unique examples, and embeddings or vector indexes derived directly from personal data.

The practical consequence is the part teams miss. If the weights may themselves be personal data, then the artifact store, the checkpoint bucket and the model registry inherit residency constraints too, not just the GPU that produced them. The sovereign question follows the weights wherever they are stored.

Mitigations teams actually use: differential privacy and deduplication during training, extraction testing before release, and documenting the assessment in the records of processing so you can show your reasoning. National supervisory authorities differ in emphasis here (the Hamburg DPA, for instance, has published its own discussion paper taking a somewhat different line on LLMs and personal data), which is one more reason to write down your assessment rather than rely on a general belief that weights are safe.

Why is inference the part EU teams underestimate?

Inference is where residency obligations compound, because every single request manufactures new personal data: the prompt, the retrieved context, the output, the log line, the eval trace and the feedback label. Training is one dataset you can curate. Inference is a stream you cannot.

Start by listing what inference generates and where each piece lands by default. The prompt and output flow through your app. The log line goes to your observability backend, which is very often a US-region SaaS that nobody added to the transfer assessment. The eval traces and feedback labels accumulate in yet another tool. APM, caches and backups each have their own home.

RAG makes this sharper. A vector index is a derivative of your customer data, so it inherits the same residency constraints as the source, including any embeddings held by a third-party vector service. Moving the GPU to the EU while the index sits elsewhere solves nothing.

Third-party model APIs are a transfer too. Calling a US-hosted LLM API from an EU-hosted app is an international transfer of whatever is in that prompt. The mitigations exist and are worth naming: Azure OpenAI EU data zones (processing kept in Sweden and Germany), Amazon Bedrock in EU regions such as Frankfurt and Paris, Mistral hosted in the EU by default, or self-hosted open-weight models on EU GPUs.

There is a second, non-legal reason to keep inference in-EU that happens to point the same way: latency. Round-trip time between an EU region and US-East is roughly 90 ms (CloudPing tracks this live), which you pay on every call and every retrieval hop. Convenient that residency and user experience agree for once.

A copy-paste residency checklist, because this is where things slip. All of these need the same region discipline as the GPU:

• Prompt logs
• Feedback and labeling data
• Observability and APM
• Caches
• Backups
• Support tooling
• CI artifacts
• Eval datasets

And the cost angle that ties it together: inference spend overtakes training spend as soon as a product has real traffic. AWS puts it bluntly on its Inf1 page, stating that inference can account for up to 90% of ML infrastructure cost, and McKinsey projects inference overtaking training as the dominant AI workload. So a sovereign premium applied to inference is the bigger recurring bill. Which is exactly why the architecture question matters more than the training quote in your inbox.

What split architecture do most EU AI teams actually end up with?

The common landing zone is split: sanitize in the EU, train wherever capacity is available and affordable, then keep inference, weights and every request-derived artifact in an EU region inside your own cloud account.

The reference flow is five steps:

1. An EU sanitization and anonymization pipeline on the raw data.
2. Training on the best-available capacity, EU or not, chosen per the corpus test above.
3. Weights in an EU artifact store.
4. Inference services in an EU region.
5. Logs and the vector store in that same EU region.

The paper trail auditors ask for is short and worth preparing in advance: records of processing under Article 30, a transfer impact assessment, an up-to-date sub-processor list, and the anonymization assessment for the corpus.

Running inside your own cloud account (BYOC) matters here for reasons that are about control, not branding. The GPUs, the data and the audit logs stay under your own contracts with your chosen provider. The cloud bill and any committed-use discounts stay in your name. And you do not add a SaaS vendor that becomes a new sub-processor holding your data, which is one more line on the transfer assessment and one more entity in scope.

This is where Qovery fits, and I want to be precise about what it does and does not do. Qovery deploys and operates your applications and the Kubernetes clusters around them inside your own AWS, GCP, Azure or Scaleway account, or on your existing Kubernetes cluster. Moving inference to an EU region becomes a region choice rather than a migration. The capabilities are concrete: git-push deployments, preview environments per pull request, environment auto-stop for non-production, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services.

Qovery does not sell GPUs or sovereign capacity. You bring the capacity from whichever provider you chose; Qovery runs the application layer and the cluster lifecycle on top of it. In practice that often means one EU cluster serving inference and a separate environment elsewhere for training infrastructure, with the same deployment workflow and the same RBAC model across both.

How do I stand up an EU-region inference environment with Qovery from Claude Code or Cursor?

Install the Qovery Agent Skills once, then ask your coding agent in plain language to deploy into an EU region of your own cloud account. Here are the exact commands, in order.

Install the Agent Skills once, for every compatible agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI):

curl -fsSL https://skill.qovery.com/install.sh | bash

For a project-scoped install instead of a global one:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the MCP Server for Claude Code. It uses OAuth and is read-only by default:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Enable write access only when you explicitly want it, which also requires enabling write access in the Qovery Console:

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

What ships: qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview and qovery-terraform. The skills handle deployment; the MCP Server operates what already exists.

After install, ask in plain language. For example: "deploy this inference API to my Scaleway Paris region with Qovery," or "create a preview environment in eu-west-3." The agent proposes a plan and you approve each action before it runs. Full walkthroughs are in the AI agent quickstart and the Claude Code integration page.