Sovereignty & compliance
GDPR vs. the CLOUD Act: why your AI provider's region doesn't guarantee compliance
Published 2026-08-03 · 5 min read
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 data center's 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.
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.
What GDPR actually requires
GDPR (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. 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.
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.
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.
FAQ
FAQ
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 handle this distinction?
Frontière'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.