Dev.to AI 🤖 Ai 👁 0 📖 6 min read

Ne plus être en infraction avec les lois UE sur la protection des données privées, face aux privilèges et abus de l’IA américaine (US CLOUD ACT)

Aussi publié en français : https://blog.localai.hex7.com/ne-plus-etre-en-infraction-ue-donnees/ En bref. Transmettre des données à un fournisseur américain ne cesse pas d'être un transfert international parce que ce fou

Aussi publié en français : https://blog.localai.hex7.com/ne-plus-etre-en-infraction-ue-donnees/

En bref. Transmettre des données à un fournisseur américain ne cesse pas d'être un transfert international parce que ce fournisseur héberge une partie de ses serveurs dans le cloud européen : 18 U.S.C. § 2713 lui impose de « conserver, sauvegarder ou produire » les communications et enregistrement en sa possession, sa garde ou son contrôle, que ces données soient ou non stockées dans l'UE. Après Schrems II, il revient au client de le vérifier lui-même : clauses contractuelles, évaluation de l'impact du transfert, puis mesures complémentaires s'il faut en adopter. Un modèle exécuté localement, lui, ne déclenche pas cette chaîne d'obligations : la donnée ne franchit pas la frontière, donc il n'y a pas de transfert à encadrer.

That French paragraph is the short version of this article. It is also a paraphrase of what our own site says: "US providers can compel disclosure of data stored in the EU via FISA 702 or the CLOUD Act — the recurring reason US clouds fail European privacy law. A local system avoids that trap." Below I want to do two things: state exactly what the obligation is, and where a locally-run model genuinely ends it (and where it does not).

What the obligation actually is

Article 44 GDPR is a condition, not a principle: a transfer of personal data to a third country may take place only if the conditions of Chapter V are met. For the EU–US case there are two live routes. The first is an adequacy decision — the Commission Implementing Decision (EU) 2023/1795, which covers transfers to organisations certified under the Data Privacy Framework and which the Commission must "continuously monitor", with a duty to "suspend, amend or repeal" it if necessary (Art. 3(1), (5)). The second is appropriate safeguards: standard contractual clauses plus, after Schrems II (C-311/18), a transfer impact assessment and, where needed, supplementary measures that actually prevent the level of protection being essentially equivalent to EU law. The EDPB's Recommendations 01/2020 set out the roadmap — know the transfer, find the tool, assess the law and practice in the destination, adopt supplementary measures if required, then keep the assessment under periodic review — and they say plainly that adopting one of those measures is not automatically sufficient.

So a European organisation using a US-hosted AI service is not "safe because it signed the SCCs". It is on the hook for assessing whether that vendor's government access powers defeat the protection it is meant to deliver, and for documenting that assessment in a way its supervisory authority can audit.

The CLOUD Act trap, in the statute's own words

18 U.S.C. § 2713, added by the CLOUD Act in March 2018, is one sentence and it is deliberately broad:

"A provider of electronic communication service or remote computing service shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider's possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States."

That phrase is the trap. An EU-region datacentre operated by a US-controlled provider does not end the exposure: the provider's control over the data is what matters, not the rack's location. Vendor marketing promises — "data stays in the EU" — are contractual, not jurisdictional; they shift who may be compelled to produce what, but they do not remove the compulsion. And compulsion is broad: § 2713 covers records "pertaining to a customer or subscriber", which is exactly the surface an AI provider sits on when it holds your prompts, files, embeddings and outputs in its storage.

The reason this keeps failing for US clouds is the pair of surveillance powers Schrems II examined: FISA § 702 and Executive Order 12333 bulk collection. The CJEU's first two answers — Schrems I (C-362/14, Safe Harbour) and Schrems II (C-311/18, Privacy Shield) — struck the adequacy bases precisely because those powers lacked the equivalent protection EU law requires, including sufficiently independent oversight.

Why the ground keeps moving under the DPF

The current framework is fragile in public ways, which is why relying on a single mechanism is the wrong compliance strategy.

  • The courts have only ever tested the past. In Latombe v Commission (T-553/23) the General Court dismissed the challenge on 3 September 2025 and upheld the adequacy decision in full — but its review was expressly limited to the factual and legal position as it stood when the Commission adopted the decision in 2023, and it did not assess whether the safeguards work in practice. It also left admissibility (standing) undecided rather than settling it, which is how challenges get revived later.
  • US institutional independence is now in question. On 29 June 2026 the US Supreme Court decided Trump v. Slaughter, holding that the FTC's for-cause removal protections are unconstitutional and that commissioners are removable by the President at will; in doing so it overruled Humphrey's Executor (1935). European privacy lawyers' argument writes itself: the 2023 adequacy decision leaned on the FTC being "an independent authority" (Recital 60), and if that independence is gone, the basis for the finding weakens. Skadden's assessment — that there is "at minimum, a reasonable possibility" the CJEU strikes the decision down when asked — is the practical advice; Max Schrems has already announced an intention to litigate after that ruling.
  • The Commission itself must keep watching. Art. 3 of that decision requires continuous monitoring and amendment or repeal if needed. That duty was exercised in the first periodic review, whose report (COM(2024) 451) and the EDPB's own report on that review are now part of the public record on both sides.

None of that means transfers are unlawful today. It means a compliance posture built solely on DPF certification is one judgment away from being unsupported, which is why most serious organisations run SCCs alongside it as a "belt and braces" fallback — and keep transfer impact assessments and data maps up to date.

What local inference genuinely changes

If the model runs on hardware you control, in a jurisdiction you sit in, no Chapter V transfer occurs for what stays there: there is no exporter-to-importer leg to assess, so no adequacy to rely on, no SCCs to execute, no TIA to write and no supplementary measures to defend. The provider never acquires "possession, custody, or control" of your prompts in the § 2713 sense, because there is no provider holding them. That is the whole argument for local models, and it is also why an air-gapped deployment audits so easily: as our own privacy page puts it in Spanish, "the audit boundary is your building: no cloud subprocessers in the perimeter, no third-party transfer of medical or employee data — HIPAA guarantees and ISO/SOC 2 controls get demonstrated on your premises, not in the vendor's documentation."

It also changes what you can say to a regulator. You stop defending an argument about whether a foreign oversight body is independent enough, and start describing a fact within your own infrastructure: where the weights live, which machine they run on, who can read the logs.

Sources

📰 Read the original article on Dev.to AI

Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.

Share 𝕏 Twitter ✈ Telegram ↗ Reddit 🟧 HN
← News 🤖 Ai 🏠 Home