Hosting your AI workloads in an EU region does not, by itself, make them exempt from US law. If the company operating that region is American — or is a subsidiary, licensee, or majority-owned affiliate of an American company — a US court order under the CLOUD Act can compel it to hand over data it controls, wherever that data physically sits. GDPR compliance and US jurisdictional reach are two separate questions, and most "sovereign AI" marketing conflates them.
A cloud computing provider's data center location tells you where the servers are, not which government can compel access to what's on them. That second question is decided by corporate jurisdiction — who owns and operates the company running the servers — not geography. An EU region operated by a US-headquartered company is still reachable by a US court order under the CLOUD Act, regardless of where the disks physically sit. If your AI vendor's answer to "are you GDPR compliant" stops at "our servers are in Frankfurt," you haven't gotten an answer to the jurisdiction question at all — and that gap matters most when your European data includes sensitive data or personally identifiable information.
Two infrastructure paths, side by side
US AI provider
- US company
- EU data center
- Potential US jurisdiction
Hosting location ≠ jurisdiction. The CLOUD Act follows the operator's incorporation, not the server's postcode.
Frontière AI EU Sovereign
- EU-controlled infrastructure
- EU jurisdiction
- EU workload
No non-EU capital control anywhere on the serving path: operator (French SASU), cloud (OVHcloud, Scaleway), data (zero retention).
Both paths can claim “EU data residency”. Only the right-hand path keeps the whole chain under EU legal control.
How the CLOUD Act actually reaches EU data
The US Clarifying Lawful Overseas Use of Data Act (CLOUD Act), signed into law in March 2018, amends the Stored Communications Act to let US law enforcement compel a US-based provider to produce data it possesses, custody, or controls — "regardless of whether such communication, record, or other information is located within or outside of the United States." The statute doesn't ask where the server is. It asks whether the entity that can access the data is subject to US legal process.
That's the mechanism that matters for procurement decisions: a subpoena or warrant served on a US company's headquarters obligates that company's global operations, including a subsidiary or a technically-separate EU entity it controls. The location of the data center changes nothing about the legal chain — it changes only where the request has to travel before it's fulfilled. From a security perspective, this means your security measures against unauthorized access by foreign authorities are only as strong as your provider's corporate jurisdiction, not its physical footprint.
What GDPR actually requires
The General Data Protection Regulation (GDPR), formal name Regulation (EU) 2016/679, governs a different problem: it restricts transfers of personal data outside the EU/EEA (Chapter V, Articles 44-50) unless a valid transfer mechanism applies — an adequacy decision, Standard Contractual Clauses, or Binding Corporate Rules. It says nothing directly about which government can serve a subpoena on your processor. A company can be fully GDPR-compliant on paper — proper contracts, EU data residency, a valid transfer mechanism for any residual flows — while still being a US company subject to CLOUD Act process. That is why every model in the Frontière AI catalog carries its jurisdiction rather than a single site-wide compliance badge. The two frameworks answer different questions, and passing one doesn't answer the other.
Why the transatlantic framework keeps collapsing
The EU and US have tried three times to bridge this gap with a formal adequacy framework for transfers to US companies: Safe Harbor (invalidated by the CJEU in 2015, Schrems I), Privacy Shield (invalidated in 2020, Schrems II), and the current EU-US Data Privacy Framework, adopted by the European Commission in 2023. Each time, the challenge has come back to the same structural issue: US surveillance law gives US authorities access to data held by US companies that EU law doesn't consider proportionate or subject to adequate redress.
The Data Privacy Framework is, as of mid-2026, still formally in force — the EU General Court dismissed a direct annulment challenge (Latombe v Commission) in September 2025, finding the framework's independent redress mechanism and US data-collection limits sufficient. But the challenger has appealed to the Court of Justice of the EU (Case C-703/25 P, filed October 2025), with no hearing date set as of writing. If the CJEU rules against it, it would be the third consecutive invalidation of a transatlantic transfer framework in a decade. That pattern is itself the signal: the underlying incompatibility between US surveillance law and EU data protection law hasn't been resolved by any of the three attempts — it's been paused, then challenged, each time.
For a business making a multi-year infrastructure decision, betting on the current framework holding is a bet on a specific pending appeal at Europe's highest court. Choosing infrastructure that isn't subject to the underlying jurisdictional conflict in the first place sidesteps that bet entirely.
The French answer: SecNumCloud and the 'immunity' requirement
France's national cybersecurity agency, ANSSI, runs a cloud qualification called SecNumCloud. Its most recent major revision (v3.2) added an explicit requirement that the highest trust tier be free of non-EU capital or legal control — not just data-residency, but corporate ownership and jurisdictional "immunity" from non-EU law. It's the clearest official articulation of the exact distinction this article is making: hosting location and legal exposure are different axes, and a serious sovereignty standard has to specify both. It is the rule we apply to decide which models get the sovereign label in our catalog, and which are labeled fast access instead.
Bleu, S3NS, and why 'French cloud' isn't automatically sovereign
Two high-profile French "sovereign cloud" projects illustrate why this distinction is contested in practice, not just in theory. Bleu is a joint venture between Orange and Capgemini operating Microsoft Azure technology under license. S3NS is a joint venture between Thales and Google operating Google Cloud technology under license. Both are French-incorporated, French-operated, and marketed as SecNumCloud-track sovereign offerings — and both have drawn sustained criticism precisely because the underlying technology stack is licensed from a US hyperscaler, raising the same "who ultimately controls this" question SecNumCloud's immunity requirement was written to answer. The controversy isn't about where their data centers sit (France) — it's about whether a licensing relationship with a US parent technology vendor reintroduces the exposure the sovereignty requirement was meant to eliminate.
The lesson generalizes beyond these two: a provider's marketing page can say "hosted in the EU," "sovereign," or "GDPR-compliant" while describing only the data-residency axis and leaving the ownership/jurisdiction axis unaddressed — sometimes because it's genuinely fine, sometimes because it isn't, and the page doesn't say which. Ours says which, per model, in the catalog and in the API response itself — and where a model is only reachable through US-controlled infrastructure, it is labeled fast access, never sovereign.
How to actually check a provider
Four questions get you most of the way to a real answer, in roughly the order they're worth asking:
- Who is the ultimate parent company, and where is it headquartered? A EU-incorporated subsidiary of a US parent is still reachable through that parent under the CLOUD Act's corporate-control provisions.
- Does the provider hold — or claim eligibility for — SecNumCloud's highest tier, or an equivalent EU-only qualification? That tier specifically requires the non-EU-control test this article describes; a lower tier or a self-declared "EU cloud" badge doesn't.
- Is any part of the stack licensed from a non-EU technology vendor? As the Bleu/S3NS pattern shows, a licensing dependency can matter even when the operating entity is genuinely EU-incorporated.
- What does the contract say about who responds to a foreign government data request, and under what process? A vendor confident in its own position will have a clear, specific answer here — not a general compliance statement.
None of this is exotic due diligence — it's the same distinction a DPO already applies to any cross-border data flow, just pointed at the infrastructure layer instead of the data-transfer contract. We have run those four questions against two direct competitors in public: Frontière AI vs OpenRouter and Frontière AI vs Together AI — both are US-incorporated, and both are cheaper than us per token.
FAQ
Does hosting in Europe make an AI provider sovereign?
No. Hosting in Europe only addresses data residency. Sovereignty is about who controls the operating company: a US provider can run a compute region in the EU and still be reachable by a US court order under the CLOUD Act. A provider is EU sovereign only when the serving path — operator and cloud — is free of non-EU capital or legal control, the SecNumCloud test.
Does OpenAI in Azure France solve the sovereignty problem?
No. Azure France runs on Microsoft, a US company. Your data may physically sit in France, but the operator remains subject to US legal process, so a US court order can still reach it. It can be a perfectly valid GDPR setup for many workloads — it is just not jurisdictional sovereignty. The same reasoning applies to Anthropic on GCP and to licensed 'sovereign cloud' joint ventures like Bleu or S3NS.
Does GDPR prohibit US AI providers?
No. GDPR does not ban US providers — it restricts transfers of personal data outside the EU/EEA unless a valid mechanism applies (adequacy decision, SCCs, or BCRs). A US provider can be fully GDPR-compliant and still expose your data to US jurisdiction. GDPR compliance and jurisdictional sovereignty are two different questions; you may need answers to both depending on your workload.
What is data residency?
Data residency is where data is physically stored — 'our servers are in France' is a residency claim. It says nothing about who controls the company operating those servers or which law enforcement can compel access. It is the weakest of the three sovereignty layers.
What is data sovereignty?
Data sovereignty means data is subject to the laws of the country where it is stored AND of the entity that controls it — in practice, the second dominates. True data sovereignty requires EU storage plus an operator with no non-EU capital or legal control, so no foreign court order can compel disclosure through the operator.
What is jurisdictional sovereignty?
Jurisdictional sovereignty is the strongest layer: the entire serving path — operating company, cloud provider, and any sub-processor — sits under EU legal jurisdiction, so no non-EU legal process can compel access through any link in the chain. This is what SecNumCloud's highest tier formalizes and what Frontière AI's EU sovereign label certifies per model.
What is the CLOUD Act?
The Clarifying Lawful Overseas Use of Data Act (2018) lets US authorities compel US-based providers to produce data they control, regardless of where it is stored. It applies through corporate control: a US parent's EU subsidiary, or a company licensed to operate US technology, can be reached through it. This is why 'hosted in EU' does not equal 'outside US jurisdiction'.
What does “EU sovereign AI” actually mean?
It should mean: every operator in the serving path is free of non-EU capital or legal control, compute runs in the EU, and data retention is zero or contractually bounded. In practice the term is often used for plain EU data residency. Frontière AI uses it in the strict sense, labels every model per call, and publishes the Sovereignty Score methodology so you can verify instead of trusting the word.
If a provider's servers are physically located in the EU, isn't that enough for GDPR compliance?
It helps with the data-residency question but doesn't resolve jurisdiction. GDPR restricts data transfers outside the EU/EEA; it doesn't determine which government can compel a company to disclose data through domestic legal process. A US-owned company operating EU servers can be fully GDPR-compliant on data transfers while still being reachable under the CLOUD Act as a US legal entity.
Does the CLOUD Act apply to any company with an EU office, or only to fully US-owned ones?
It applies to providers subject to US jurisdiction — typically US-incorporated companies and their subsidiaries or affiliates where the parent retains legal control. A genuinely independent EU company with no US parent, majority ownership, or controlling license relationship isn't reachable through the CLOUD Act in the same way, which is exactly the distinction SecNumCloud's immunity requirement tries to formalize.
Is the EU-US Data Privacy Framework currently valid?
As of mid-2026, yes — the European Commission's 2023 adequacy decision is in force, and the EU General Court upheld it against a direct annulment challenge in September 2025. That ruling has been appealed to the Court of Justice of the EU, with no hearing date set. It's the third such framework in a decade; the previous two (Safe Harbor and Privacy Shield) were both invalidated after being relied upon for years.
Does using a self-hosted or EU-sovereign AI provider mean my company doesn't need a DPO or a GDPR review?
No — infrastructure choice addresses one specific risk (foreign government access to data your processor controls). It doesn't replace the rest of a GDPR compliance program: lawful basis, data minimization, retention limits, data subject rights, and a proper Article 30 record of processing still apply regardless of where or by whom the AI model is hosted.
What is SecNumCloud, exactly?
It's a security and sovereignty qualification for cloud services run by ANSSI, France's national cybersecurity agency. Its highest trust tier requires, among other security controls, that the operating entity be free of non-EU capital or legal control — the explicit 'immunity' criterion this article discusses.
Are Bleu and S3NS non-compliant with GDPR?
That's not the claim here. Both are French-incorporated joint ventures actively pursuing SecNumCloud qualification, and neither is presented in this article as failing GDPR. The point is narrower: their reliance on licensed US hyperscaler technology (Microsoft for Bleu, Google for S3NS) has been the subject of public debate about whether it reintroduces the exact jurisdictional exposure a sovereignty label is meant to rule out — which is precisely the kind of question worth asking of any provider, including these two.
How does Frontière AI handle this distinction?
Frontière AI's catalog labels every model 'EU sovereign' only when it runs on a provider with no non-EU capital or jurisdictional control — currently OVHcloud, Scaleway, and our own self-hosted EU servers. Models available only through non-EU-controlled infrastructure (like Modal) are explicitly labeled 'fast access,' never 'sovereign,' regardless of which region they run in.
Ready to try it?
Create an account and call any model in the catalog in minutes.