Can I use a US model and stay GDPR-compliant?

Often yes, but never by default, and the detail is where it gets decided. A US-headquartered provider stays reachable under the CLOUD Act even on an EU region, because exposure follows provider control, not data location. To use one lawfully you pin an EU region, sign a data-processing agreement, vet the subprocessor list, and handle lawful basis, retention and transfers yourself. Customer-held encryption keys harden the path further. Where the deploying-models guide answers this at the level of where it runs, this is the jurisdiction-level answer: region and DPA mitigate the exposure, they do not erase it, so for the most sensitive data an EU-native provider or self-hosting is the cleaner path.

What does the EU AI Act require in 2026?

The bulk of the AI Act applies from 2 August 2026, and the duties scale by risk tier. In practice you classify your AI use, ensure AI literacy in your teams (already a duty since early 2025), and for higher-risk uses add documentation, risk management, logging and human oversight. Some high-risk deadlines are under amendment, so treat 2 August 2026 as the broad application date rather than a single fixed cliff for every use, and confirm your tier against the official timeline. This is engineering guidance, not legal advice.

Does an EU region make me compliant?

No. An EU region gives you data residency, which is necessary but not the same as sovereignty or compliance. If the operator is US-headquartered, the CLOUD Act still reaches the data; in June 2025 Microsoft France stated under oath that it could not guarantee a France-hosted offering against US authorities. And a region does nothing for your lawful basis, your DPA or your subprocessor controls. Treat the region as one control among several, not as the finish line.

What are the EU-native model providers?

Mistral, headquartered in Paris, is the strongest by capability: it ships open models under Apache-2.0 and operates a French datacenter for inference under EU jurisdiction. LightOn (Paris) targets private models for sensitive data, on-prem or in a dedicated EU cloud. DeepL (Germany) is API-only and strong on EU-language tasks. The market moves fast, so confirm a provider current jurisdiction and ownership before you rely on it; some European labs have been acquired by non-EU companies.

Is sovereign AI worth the capability tradeoff?

It depends entirely on the data. Climbing the ladder buys jurisdiction control and pays in capability ceiling and operational cost, because the broadest frontier choice still sits with the US labs today. For regulated, personal or sensitive data, that trade is worth it, and is often non-negotiable. For low-stakes, non-sensitive work, paying it is a self-imposed tax for a risk you never had. The discipline is to match the rung to the data: as sovereign as the data requires, and no more.

← Stack

Sovereign AI

For an EU buyer, which jurisdiction governs the data is a first-class axis, not an afterthought.

Overview

Most model-strategy advice ranks capability, then cost, then maybe latency. For a European buyer, and especially a French one, there is a prior axis that often outranks all three: which jurisdiction governs the data, and what EU law requires of you. This is not a compliance footnote, it is a first-class input to the model choice. This page goes deep on that axis. For the deployment mechanics (where a model runs and what it costs), see the deploying-models guide; this page answers which jurisdiction governs the data and what the EU options are.

Two forces shape this axis. First, exposure: the US CLOUD Act lets US authorities compel a US-headquartered provider to produce data it controls, regardless of where that data physically sits, including an EU datacenter. Exposure follows provider control, not data location, so an EU region alone is necessary but not always sufficient. Second, obligation: the bulk of the EU AI Act applies from 2 August 2026, with duties that scale by risk tier (classify your AI use, ensure AI literacy, and for higher-risk uses add documentation, risk management and human oversight). GDPR still applies on top: lawful basis, a data-processing agreement, subprocessors and transfers.

The response is a ladder of increasing sovereignty: a US lab API (US jurisdiction), then a US hyperscaler EU region with a DPA (Bedrock Frankfurt, Vertex Frankfurt, Azure West Europe), then an EU-native provider (Mistral in Paris, with open Apache-2.0 models and a French datacenter, plus LightOn and DeepL), then self-hosting open-weight in your own EU infrastructure. Two honest caveats. Using an EU provider does not by itself make you compliant: you still own lawful processing. And sovereignty is a spectrum and a tradeoff against capability and cost, not a binary EU-good US-bad. The right rung is the one your data and your risk tier actually require. This is informed engineering guidance, not legal advice.

Architecture

Read the ladder from the bottom up. The lowest rung is a US lab API: top capability, US jurisdiction. As you climb, data-jurisdiction control rises (EU region with a DPA, then an EU-native provider, then self-hosting in your own EU infrastructure), and the capability ceiling tightens, because the broadest frontier choice still sits with the US labs today. There is no universally correct rung. The right one is the highest your data and risk tier demand, and no higher, so you do not pay a capability or cost penalty the data does not require.

The EU sovereignty ladder: US lab API → US cloud EU region + DPA → EU-native provider → self-host in EU. Jurisdiction control rises as you climb; the capability ceiling tightens.

Key concepts

Data sovereignty: Control over which jurisdiction governs your data: not just where it is stored, but whose courts and law can compel access to it. The core axis this page is about.
Data residency: Where data physically sits (an EU region, a Frankfurt datacenter). Necessary but weaker than sovereignty: residency in the EU does not stop a US-headquartered operator from being reachable under US law.
US CLOUD Act: A 2018 US law that lets US authorities compel a US-headquartered provider to produce data it controls, regardless of where the data is stored, including EU datacenters. Exposure follows provider control, not data location.
EU AI Act: The EU regulation on AI. Obligations scale by risk tier; the bulk applies from 2 August 2026, with documentation, risk management and human oversight for higher-risk uses, on top of GDPR.
GDPR: The EU data-protection regulation. It governs personal data independently of the AI Act: you need a lawful basis, a data-processing agreement with each processor, and control over subprocessors and international transfers.
DPA (data-processing agreement): The contract under GDPR Article 28 between a controller and a processor (the model provider). It sets the purpose, security measures, subprocessors and transfer safeguards. Signing one is part of using any external provider lawfully.
Subprocessor: A third party a provider uses to deliver its service (hosting, logging, support). Each subprocessor is a place your data flows to, so its location and jurisdiction matter as much as the provider you contracted with.
EU-native provider: A model provider headquartered and operating under EU jurisdiction, such as Mistral (Paris), LightOn or DeepL. It removes the US-control exposure, but it does not by itself discharge your GDPR duties as controller.
Sovereign cloud: Infrastructure operated under EU jurisdiction and control, on which you can self-host open-weight models. The top of the ladder: maximal jurisdictional control, in exchange for operating the stack yourself.

When to use

Good fit

When the data is personal or sensitive enough that where it is processed is a hard constraint, not a preference: health, finance, legal, HR, or anything covered by sector rules. Then sovereignty drives the model choice before capability does.
For public-sector and French or EU procurement, where a documented EU data path and a clear jurisdiction story are often an eligibility requirement, not a bonus. The sovereignty rung is part of the bid.
When you must be able to demonstrate, not just assert, where data flows: a named provider, a signed DPA, a known subprocessor list and a pinned region. The EU AI Act and GDPR both reward a path you can document.
When the data does NOT carry a hard residency constraint, the honest fit is to stay low on the ladder: a US lab API or an EU region with a DPA, and spend the saved capability and budget where the work needs it. Sovereignty is a tool for the cases that require it, not a default tax.

Anti-patterns

Treating an EU region as automatic compliance. Pinning Frankfurt on a US-headquartered provider improves residency but does not remove CLOUD Act exposure, and it does nothing for your lawful basis or your DPA. Region is one control, not the whole story.
Assuming an EU-native provider means you are done. Choosing Mistral or LightOn removes the US-control exposure, but you remain the controller: lawful basis, retention, subprocessors and human oversight are still yours to handle.
Buying maximal sovereignty the data does not require. Self-hosting in a sovereign cloud for non-sensitive, low-stakes workloads pays a real capability and cost penalty for a risk you never had. Match the rung to the data.
Confusing data location with data sovereignty in a contract. A clause that promises EU storage but is silent on the operator jurisdiction, subprocessors and government-access handling leaves the real exposure unaddressed.

Code examples

Pin an EU region on a US hyperscaler

import boto3

# Claude via AWS Bedrock, pinned to an EU region (Frankfurt).
# Residency is in the EU; the operator is still US-headquartered,
# so a DPA and lawful-basis handling remain your responsibility.
client = boto3.client("bedrock-runtime", region_name="eu-central-1")
# ... invoke_model(...) against an EU endpoint
# Region is necessary, not sufficient: it does not remove CLOUD Act reach.

Rung 2 of the ladder: EU residency on a US operator. Pin the region, sign the DPA, and document the path. It mitigates exposure, it does not erase it.

Call an EU-native provider

from mistralai import Mistral

# Mistral (mistral.ai) is operated under EU jurisdiction. Using it
# removes the US-control exposure of rung 1 and rung 2.
client = Mistral(api_key="...")
resp = client.chat.complete(
    model="mistral-large-latest",
    messages=[{"role": "user", "content": "Resume ce dossier."}],
)
print(resp.choices[0].message.content)
# EU jurisdiction, but you are still the controller: DPA, basis, retention.

Rung 3: an EU-headquartered operator removes the US-control exposure. It does not discharge your GDPR duties as controller, which travel with you regardless of the rung.

Comparison

vs Deploying models

How this relates: the deployment mechanics

That guide answers where a model runs and what it costs across the lab API / managed / self-hosted spectrum. This page is the deep dive on one axis it only touches: which jurisdiction governs the data. Read deploying-models for the mechanics and the economics, then use this page to place yourself on the sovereignty ladder.

vs Choosing a model

How this relates: the first non-negotiable filter

The selection process starts by eliminating candidates on non-negotiables before anything else. For an EU buyer, sovereignty is usually the first of those filters: it removes whole rungs from contention before capability or cost is even discussed. This page is the deep dive on that first filter; choosing-a-model is the full process around it.

Resources

FAQ

Can I use a US model and stay GDPR-compliant?: Often yes, but never by default, and the detail is where it gets decided. A US-headquartered provider stays reachable under the CLOUD Act even on an EU region, because exposure follows provider control, not data location. To use one lawfully you pin an EU region, sign a data-processing agreement, vet the subprocessor list, and handle lawful basis, retention and transfers yourself. Customer-held encryption keys harden the path further. Where the deploying-models guide answers this at the level of where it runs, this is the jurisdiction-level answer: region and DPA mitigate the exposure, they do not erase it, so for the most sensitive data an EU-native provider or self-hosting is the cleaner path.
What does the EU AI Act require in 2026?: The bulk of the AI Act applies from 2 August 2026, and the duties scale by risk tier. In practice you classify your AI use, ensure AI literacy in your teams (already a duty since early 2025), and for higher-risk uses add documentation, risk management, logging and human oversight. Some high-risk deadlines are under amendment, so treat 2 August 2026 as the broad application date rather than a single fixed cliff for every use, and confirm your tier against the official timeline. This is engineering guidance, not legal advice.
Does an EU region make me compliant?: No. An EU region gives you data residency, which is necessary but not the same as sovereignty or compliance. If the operator is US-headquartered, the CLOUD Act still reaches the data; in June 2025 Microsoft France stated under oath that it could not guarantee a France-hosted offering against US authorities. And a region does nothing for your lawful basis, your DPA or your subprocessor controls. Treat the region as one control among several, not as the finish line.
What are the EU-native model providers?: Mistral, headquartered in Paris, is the strongest by capability: it ships open models under Apache-2.0 and operates a French datacenter for inference under EU jurisdiction. LightOn (Paris) targets private models for sensitive data, on-prem or in a dedicated EU cloud. DeepL (Germany) is API-only and strong on EU-language tasks. The market moves fast, so confirm a provider current jurisdiction and ownership before you rely on it; some European labs have been acquired by non-EU companies.
Is sovereign AI worth the capability tradeoff?: It depends entirely on the data. Climbing the ladder buys jurisdiction control and pays in capability ceiling and operational cost, because the broadest frontier choice still sits with the US labs today. For regulated, personal or sensitive data, that trade is worth it, and is often non-negotiable. For low-stakes, non-sensitive work, paying it is a self-imposed tax for a risk you never had. The discipline is to match the rung to the data: as sovereign as the data requires, and no more.