GDPR vs CLOUD Act: EU cloud hosting isn't enough

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

Both paths can claim “EU data residency”. Only the right-hand path keeps the model provider under EU legal control — and tells you where the remaining US link is.

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 provider subject to US jurisdiction to produce data in its possession, custody, or control — "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 — and that is not limited to US companies. The US Department of Justice itself states that its jurisdiction "is not limited to U.S. corporations, U.S. headquartered companies, or companies owned by U.S. persons": a foreign provider with enough business in the United States can be served too.

That's the mechanism that matters for procurement decisions: a warrant served on a US company can reach data held by its subsidiaries, including a technically separate EU entity, whenever the company served controls that data — a fact-dependent question, in the Justice Department's own words. 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 protection against access by foreign authorities is only as strong as your provider's corporate jurisdiction, not its physical footprint.

The CLOUD Act also lets the US sign "executive agreements" with other governments (18 U.S.C. § 2523). Only those give a provider a statutory ground to challenge an order that would breach a foreign law: the motion to quash is reserved for "qualifying foreign governments", meaning countries with such an agreement in force (§ 2703(h)). The US has signed agreements with the United Kingdom and Australia; with the EU, negotiations resumed in 2023 and the European Commission still describes them as ongoing.

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 doesn't decide which government can serve a subpoena on your processor. Its closest point of contact with the CLOUD Act is Article 48: a court order from a non-EU country requiring a controller or processor to disclose personal data can only be recognized or enforced if it is based on an international agreement, such as a mutual legal assistance treaty. That doesn't stop a US court from issuing the order; it puts your provider between two conflicting laws. 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 September 2026, still formally in force — the EU General Court dismissed a direct annulment challenge (Latombe v Commission, T-553/23) on 3 September 2025, finding the redress mechanism and the limits on US data collection sufficient on the date the decision was adopted, in July 2023. The challenger has appealed to the Court of Justice of the EU (Case C-703/25 P, lodged in October 2025), which has not ruled yet. If the Court of Justice strikes the framework down, 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 current version, 3.2 (March 2022), added explicit criteria of protection against non-EU law, and they apply to every qualified service: SecNumCloud has had a single level since version 3.1. The provider's registered office and main establishment must be in the EU; non-EU shareholders may hold no more than 24% individually and 39% collectively, with no veto and no power to appoint a board majority; and no non-EU third party, subcontractors included, may have the technical ability to obtain the data. 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. We apply that principle — not the qualification — to decide which models get the sovereign label in our catalog and which are labeled fast access: neither Frontière AI nor the OVHcloud and Scaleway AI services we use are SecNumCloud-qualified.

SecNumCloud is a French qualification. At EU level, the EUCS cloud certification scheme still hasn't been adopted, with sovereignty requirements as the main point of contention, and in June 2026 the European Commission proposed a Cloud and AI Development Act that would introduce a single EU-wide framework for assessing cloud and AI sovereignty — a proposal, not yet law.

Bleu, S3NS, and why 'French cloud' isn't automatically sovereign

Two high-profile French "trusted cloud" offerings show why the question is about control and technical access, not just the address. S3NS, a French company controlled by Thales that runs Google Cloud technology, obtained SecNumCloud 3.2 qualification for its PREMI3NS offer in December 2025: ANSSI's list names the qualified service “Cloud de confiance S3NS” (provider: Thales Cloud Sécurisé), valid from 17 December 2025 to 17 December 2028. Bleu, owned by Orange and Capgemini and built on Microsoft Azure and Microsoft 365 technology, passed the J1 milestone of the same process in November 2025 and was not yet on ANSSI's list of qualified services in September 2026. Both are French-incorporated and operated in France. The debate they sparked is about dependence on a US technology vendor — updates, roadmap, continuity — which is exactly what SecNumCloud's criteria on subcontractors and operating autonomy are meant to test. For S3NS's qualified service, ANSSI has now given its answer; for Bleu, it is still pending.

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.

A data center without the US CLOUD Act: the real options

No data center escapes the CLOUD Act because of its address. What keeps hosting out of its direct reach is the company that operates it, and what that company depends on. Six criteria, mostly taken from ANSSI's SecNumCloud 3.2 framework:

• Operator. Registered office and main establishment in the EU, and no significant business in the US: the US Department of Justice states that its jurisdiction is not limited to US companies.
• Capital and control. SecNumCloud caps non-EU shareholders at 24% each and 39% combined, with no veto and no board majority.
• Subcontractors. No non-EU subcontractor, software vendor included, may be technically able to obtain your data, the logs or the access configuration.
• Administration and support. Run and supervised from the EU; any support given from outside the EU is listed and supervised from the EU.
• Proof, not a badge. SecNumCloud is granted service by service: check the exact service on ANSSI's list.
• Contract. A commitment to refuse any non-EU request that bypasses an international agreement (Article 48 GDPR), and to report any change of control within one month, as SecNumCloud requires.

Frontière AI is in the last row, so here is our chain. Models labeled EU sovereign run at OVHcloud or Scaleway, French companies, in data centers in France. Neither of these AI services is SecNumCloud-qualified, and our gateway runs in the Paris region of Vercel, a US company: prompts transit there without being stored (details). Models labeled fast access (US) run at US companies (Modal, OpenRouter) and remain exposed to the CLOUD Act; the catalog and the API mark them as such, never as 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? An EU-incorporated subsidiary of a US parent can still be reached through that parent when the parent controls the data — and a non-US company with significant business in the United States can be subject to US jurisdiction itself.
• Is the exact service you will use on ANSSI's list of SecNumCloud-qualified services? Qualification is granted service by service: a provider can hold it for some offers and not for others. A self-declared "EU cloud" badge, or a qualification still in progress, is not the same thing.
• Is any part of the stack licensed from a non-EU technology vendor, and can that vendor technically reach the data? A license is not by itself a CLOUD Act hook, but it is a dependency to assess — updates, continuity, technical access — which is why SecNumCloud tests it.
• 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. OpenRouter is usually cheaper than us per token on commodity models; each page compares prices excluding VAT on both sides, since ours include VAT and theirs don't.

FAQ