Handing Your Data to US Providers — CLOUD Act, FISA 702, and the Sovereignty Asymmetry

The data you hand to OpenAI, Google, or a US cloud can be pulled by the US government through a relatively short procedure. When a non-US government tries to obtain the same data through the proper channel, it takes months. The same data, sitting under the same provider — yet how fast it can be reached depends largely on who is reaching, and by which legal route. This asymmetry is a structural fact that follows you whenever you entrust data to a US company, AI or otherwise. This article maps it from both sides: why the US side is fast, and why the non-US side is slow.

As of: 2026-06 / Jurisdictions: US / EU / Japan (the two ends of the asymmetry) / last_updated: 2026-06-19 Revisions: 2026-06-19 initial version.

Scope of this article: the focus is "data you have entrusted to a US provider, and how fast anyone can pull it back out." AI training data and crawlers dealt with defending your published content against AI-training crawlers; this is the opposite layer — government access to the non-public data you handed over (chat history, uploaded files, logs, customer records). The thing you are protecting shifts from "copyright in published content" to "the privacy and sovereignty of entrusted data."

Terms (for first-time readers): minimal definitions of the acronyms used throughout, grouped into US law / international procedure / EU & Japan law.

US-law terms (relevant to §2):

• CLOUD Act◆ (Clarifying Lawful Overseas Use of Data Act, 2018): a US statute. It makes US communication/cloud providers disclose data even when stored outside the US (18 U.S.C. §2713), and creates the "executive agreement" framework under which a foreign government can demand data directly from US providers (18 U.S.C. §2523).
• FISA◆ (Foreign Intelligence Surveillance Act): the US framework for foreign-intelligence collection. Its Section 702 (50 U.S.C. §1881a) is the authority for compelling US companies to hand over communications of non-US persons located outside the US.
• NSL◆ (National Security Letter, 18 U.S.C. §2709): an administrative order by which the FBI can demand subscriber/transactional records without a court order, often accompanied by a gag order barring the recipient from disclosing it.
• EO 12333 (Executive Order 12333): a US executive order governing NSA-style foreign collection, separate from FISA. It was one of the authorities the Schrems II ruling flagged.

International-procedure terms (relevant to §3):

• MLAT◆ (Mutual Legal Assistance Treaty): a treaty for cross-border investigative cooperation. It is the proper route by which a foreign government obtains data from US providers — slow, because it passes through US central authorities (the DOJ) and courts.
• Data sovereignty: the idea of which country's laws and jurisdiction a given piece of data is subject to. The crux of this article is that "where you put it" and "whose law reaches it" do not have to match.

EU & Japan-law terms (relevant to §4–§5):

• Schrems II (Case C-311/18, 2020): a Court of Justice of the EU (CJEU) ruling that struck down the EU-US "Privacy Shield" transfer framework, citing US surveillance (FISA 702 + EO 12333) and the lack of effective redress for EU data subjects.
• DPF (EU-US Data Privacy Framework, 2023): the successor adequacy framework the European Commission adopted in 2023 — itself under CJEU review via the Latombe case (§4).
• APPI Article 28 (Japan): the rule restricting the provision of personal data to a third party located in a foreign country without consent or equivalent safeguards (§5).

§1. The big picture — speed depends on who reaches for the data

Before the details, one table to see who can reach the same data, by which route, and how fast. The point is that when data sits under a US provider's control, the US government's reach is fast and a non-US government's reach is slow — and this asymmetry comes from the design of the law itself.

Throughout, "US provider" means the covered electronic-communication-service / remote-computing-service providers (ECS/RCS) that §2713 binds — most large cloud, email, and messaging services, though not literally every US company (see §2.1).

The top four rows (the US government plus executive-agreement partners) sit on the fast side; the bottom row — most non-US countries — sits on the slow side. This gap is not because the US is uniquely hostile. It is the product of two structures meshing: (1) US law can order US companies to disclose data held abroad, and (2) a foreign state's only proper route to US-held data is a slow inter-state treaty. §2 covers why the US side is fast; §3, why the non-US side is slow.

Why does this matter to you, wherever you are outside the US? Your business AI chat logs, the drawings and contracts you uploaded to the cloud, the customer data accumulating in your SaaS◆ (software used over the network rather than installed locally) — much of it sits under the control of US companies. So independently of where the servers physically are, your data may be within reach of US law. The takeaway is not "never use US services" (rarely realistic) but to understand the premise so you can make sound calls about sensitive data, encryption, and contract terms.

§2. Why the US side is fast — CLOUD Act, FISA 702, NSL

The US government's fast reach rests on three routes with different purposes: the CLOUD Act for criminal investigations, FISA Section 702 for foreign-intelligence collection, and the NSL, an FBI administrative order. Targets and procedures differ, so take them one at a time.

2.1 CLOUD Act — "disclose it even if it's stored abroad"

The core of the CLOUD Act (2018) is that it codified an obligation on US communication/cloud providers to disclose data in response to US legal process (a warrant or subpoena) even when the target data sits on servers outside the US (18 U.S.C. §2713). The text requires a provider to comply "regardless of whether such communication, record, or other information is located within or outside of the United States."

The trigger was the Microsoft Ireland case (United States v. Microsoft Corp.). The FBI sought, by warrant, emails stored on an Irish server in a drug investigation; Microsoft resisted on the ground the data was abroad and prevailed below. While the case was before the Supreme Court, the CLOUD Act was enacted, mooting the dispute, and in 2018 the Supreme Court vacated and remanded as moot. In short, the "store it abroad and the US can't touch it" defence was closed by legislation.

The practical implication is simple. Even if your company places data in a US cloud's Tokyo (or Frankfurt, or Sydney) region, as long as the service is a US electronic-communication-service or remote-computing-service provider (ECS/RCS — the class §2713 binds), it can fall within CLOUD Act reach. Most large cloud, email, messaging and communication services qualify, though it does not extend automatically to every US business — it depends on the nature of the service. Either way, "data-centre location" alone is not the decisive lever for blocking US-government access.

2.2 FISA Section 702 — where non-US persons get more limited protection and redress than US persons

FISA Section 702 (50 U.S.C. §1881a, added by the 2008 FISA Amendments Act) is not a criminal-investigation power but a foreign-intelligence one. The Attorney General and the Director of National Intelligence jointly may compel US companies to provide communications, targeting non-US persons located outside the US.

This route is heavy for non-US users for two reasons. First, no individual court warrant is needed per target (the court approves the program in advance, annually). Second, the Fourth Amendment's warrant protection is essentially framed around US persons, so non-US persons abroad have almost no effective redress. In plain terms, the data of a person living outside the US sits on the under-protected side of Section 702. This is exactly the structure the EU's Schrems II ruling (§4) attacked.

That said, Section 702 is in flux right now. After a short extension of the April-2026 deadline set by the 2024 reauthorization (RISAA), it lapsed on 2026-06-12 (a first) — per reporting. But a lapse does not mean collection stops instantly: certifications the FISA Court approved before the lapse (in March 2026) are said to continue, under the statute's transition provision, until those year-long certifications expire (reportedly around March 2027), and the reauthorization debate continues (as of 2026-06; both the lapse and the continuation rest on reporting/commentary, as the certification documents themselves are non-public). The point of this article is not the life-or-death of Section 702 but the asymmetry — that non-US persons get more limited protection and redress than US persons (targeting and minimization procedures do exist). Whether it is reauthorized or stays lapsed, the underlying issue of foreign-intelligence access to data held by US providers remains (confirm the current status against primary sources).

2.3 NSL — an administrative order, and the "duty of silence"

An NSL (National Security Letter, 18 U.S.C. §2709) lets the FBI demand subscriber and transactional records from a provider without a court order. In many cases the recipient is placed under a gag order barring it from telling the customer or the public that the demand exists (the FBI must certify a specified harm for the non-disclosure to attach). So even if an NSL reaches your subscriber/transactional records, the service provider may be unable to notify you (obtaining the communication content itself requires a separate warrant or FISA authority).

Put together, the US side's access is not just fast but hard for the subject to see. §3 turns to the opposite case — the slow, procedure-heavy non-US route.

§3. Why the non-US side is slow — the MLAT detour, and who is left out

Reverse the roles. When your own country's authorities want to obtain data held by a US company through proper channels, the standard route is an MLAT (mutual legal assistance treaty). The flow is roughly:

1. Your investigators → your country's central authority
2. → the US central authority (DOJ, Office of International Affairs)
3. → a US court issues a warrant where required
4. → the US company discloses the data
5. → it is returned to your side

Crossing borders, multiple authorities and courts, it is inevitably slow. The figure most often cited is about 10 months on average (the US President's Review Group report of 2013 — a general average across all foreign governments' requests, not a current, country-specific number), and some cases run longer. Against the US government's swift domestic process, the difference is an order of magnitude.

What sharpens the asymmetry further is the CLOUD Act's executive agreement mechanism (18 U.S.C. §2523). For a partner country the US has certified as having sufficient privacy protections, that country's investigators can demand data directly from US providers, bypassing the MLAT. That direct route is not open-ended: §2523 confines it to orders aimed at the prevention, detection, investigation, or prosecution of serious crime, including terrorism, that identify a specific person, account, or device — not to general administrative data-gathering. As of 2026-06 the agreements in force are with the United Kingdom (2022) and Australia (2024); Canada and the EU are in negotiation. Most countries — Japan among them — are not on that list (and there is no public sign of Japan being in negotiation). So the majority of the non-US world is doubly disadvantaged: the only proper route to US-held data is the slow MLAT, and they are outside the fast-track agreements.

A clarification to avoid a misread: this looks like a story about law-enforcement convenience, but it bites the private sector too — it is the same picture of your own and your customers' data sitting somewhere far from your home jurisdiction's protection and control.

§4. The EU precedent — the bloc that litigated this asymmetry head-on

If you build in or for the EU, this section is the heart of the matter; if you are elsewhere, it is the clearest worked example of what taking the asymmetry seriously looks like.

The turning point was Schrems II (CJEU, Case C-311/18, 16 July 2020). The Court declared the EU-US "Privacy Shield" transfer framework invalid. The authorities it named are exactly the ones in §2: FISA Section 702 (the basis for programmes like PRISM) and EO 12333, against which EU individuals had no effective judicial redress. US surveillance powers plus the thinness of redress for non-US persons fell short of the EU's fundamental-rights standard.

The European Commission then adopted a successor, the EU-US Data Privacy Framework (DPF), with an adequacy decision in July 2023 (adding safeguards such as the new Data Protection Review Court). But it is not final either — it remains under judicial review on appeal. A French member of parliament, Philippe Latombe, sued to annul the DPF; the EU General Court upheld it in September 2025 (dismissing the action — Case T-553/23, 3 September 2025), and the applicant appealed to the CJEU in October 2025 (Case C-703/25 P), which remains pending as of 2026-06. So in the shape "Schrems II → DPF → judicial review again," the EU keeps testing this asymmetry in court.

The lesson for builders outside the EU is not to copy the mechanics (your regime differs). It is the posture. The EU refused to leave "entrusting data to US companies" as an abstract worry and turned it into a concrete, litigated question about the validity of a transfer framework. Few jurisdictions have pressed the point with the same intensity — which is precisely why individual operators and developers benefit from understanding the premise defensively. §5 brings it down to practice.

§5. What you can actually do

"Don't use US services" is unrealistic on most teams, so think in terms of lowering the risk in steps rather than driving it to zero. Two angles.

For IT / legal teams (work through procurement, contracts, and policy):

• Triage your data. Don't treat everything at the same sensitivity. Separate especially sensitive data (identifiers, health, financials) from the rest, and the more sensitive it is, the more you restrict what goes into US SaaS.
• Read the contract / DPA (data processing agreement). Confirm data location (region), sub-processors, and the provider's stance on government-disclosure requests and transparency reports. But remember from §2.1 that region pinning alone does not block the CLOUD Act.
• Handle the transfer law. Under the GDPR, a transfer to the US runs on a mechanism (the DPF for certified importers, or Standard Contractual Clauses plus a transfer impact assessment that must account for US surveillance law). Under Japan's APPI Article 28, where consent is the basis for the cross-border provision, give the data subject the required information about the destination country's regime; other transfer bases and exceptions may apply. Note that, per Japan's regulator (the Personal Information Protection Commission, PPC), a cloud provider that does not handle the personal data (storage-only, no access) falls outside Article 28, so applicability depends on the service's design and contract.

For indie / solo developers (entrust less, encrypt what you must):

• Minimise. First ask whether you can avoid putting customer-sensitive data into US AI / cloud at all (this is the most effective move).
• Hold your own keys. Client-side encryption, or schemes where you manage the keys (BYOK — bring your own key), bring you closer to a state where even a forced disclosure yields unreadable content.

Now the honest limits of encryption. It is not a cure-all. (1) Anything that runs inference or full-text search has to touch plaintext somewhere, and protection drops at that moment. (2) Encrypting the body still leaves metadata — who talked to whom and when — which can itself be sensitive. (3) "Encryption at rest" where the provider holds the keys still lets the provider decrypt and disclose on a government demand. So encryption only means something combined with data minimisation, contract review, and self-managed keys. Settle the final architecture and product choices with a specialist against your own requirements and risk tolerance.

§D. Summary — a data-sovereignty checklist (by role)

A role-based checklist to close. You don't need all of it — use it as a map for "where does US law reach the data I've entrusted, and how far can I protect it myself."

[IT / legal teams]
□ 1. Inventoried which sensitive data goes into your US AI / SaaS / cloud
□ 2. Understood that pinning a domestic region still leaves CLOUD Act reach
□ 3. Checked data location / sub-processors / government-request stance / transparency reports in the contract / DPA
□ 4. Handled the transfer mechanism (GDPR SCCs + transfer impact assessment, or DPF; APPI Art. 28 where relevant)
□ 5. Set a sensitivity-tiered policy for what may enter US SaaS
□ 6. Shared the asymmetry (no fast-track agreement, slow MLAT) with stakeholders

[Indie / solo developers]
□ 1. Considered a design that simply doesn't entrust sensitive customer data to US AI / cloud
□ 2. Practised data minimisation when you must entrust it
□ 3. Considered client-side encryption / self-managed keys (BYOK)
□ 4. Built with the limits of encryption (plaintext at inference, metadata, provider-held keys) in mind

The axis is simple: "whose law reaches it" matters more than "where you put it." Data entrusted to US companies can be within the US government's reach even when stored domestically, while your side's route to claw it back is structurally slow. That is not a reason to stop using these services — it is the premise for restricting what you feed in by sensitivity and widening what you can protect with encryption and contracts. The EU's sustained litigation since Schrems II (§4) shows the value of turning a vague unease into concrete decisions.

For protecting your published site content from AI-training crawlers (robots.txt / noai / CDN), see AI training data and crawlers; for opting out of training on the use side of AI services, see Reading the terms before you use an AI service. This article stayed on government access to entrusted data.

References

Sources are primary where possible. Because the law and litigation here are in flux, everything reflects confirmation as of the writing date (June 2026). Items relying on secondary sources are marked (secondary).

US law & government documents (primary)

• Congress.gov S.2383 (CLOUD Act text) (primary)
• U.S. DOJ "CLOUD Act Resources" (primary)
• Cornell LII 18 U.S.C. §2713 (CLOUD Act disclosure obligation) (primary)
• Cornell LII 50 U.S.C. §1881a (FISA Section 702) (primary)
• Cornell LII 18 U.S.C. §2709 (National Security Letter) (primary)
• Congress.gov CRS R48592 (FISA 702 & the 2024 RISAA reauthorization) (primary, Congressional Research Service)
• Congress.gov Japan-US MLAT, Treaty Doc. 108-12 (primary)
• U.S. DOJ "CLOUD Act Agreement Between the Governments of the U.S. and Australia" (in force 2024-01-31) (primary; UK in force 2022-10-03 per CSIS below)

EU (primary)

• EUR-Lex 62018CJ0311 (Case C-311/18 Schrems II, CJEU Grand Chamber judgment 2020-07-16, Privacy Shield invalidated) (primary, judgment)
• EUR-Lex Commission Implementing Decision (EU) 2023/1795 (EU-US Data Privacy Framework adequacy) (primary)
• EUR-Lex 62023TJ0553 (Case T-553/23 Latombe v Commission, General Court judgment 2025-09-03, DPF upheld) (primary, judgment)
• EUR-Lex C-703/25 P (Latombe's appeal to the CJEU, 2025-10-31, OJ C_202506610) (primary, pending)

Background & commentary (secondary)

• Lawfare "Supreme Court Rules US v. Microsoft Moot" (Microsoft Ireland) (secondary)
• Brennan Center "Section 702 of FISA, Explained" (secondary)
• EFF "Victory! 702 has Expired!" (2026-06-12 lapse) (secondary)
• CDT "MLAT Reform: A Straw Man Proposal" (source of the ~10-month figure) (secondary; underlying source is the 2013 President's Review Group report)
• Congress.gov CRS R45173 "Cross-Border Data Sharing Under the CLOUD Act" (CRS analysis; the MLAT delay, the CLOUD Act, and the executive-agreement framework)
• CSIS "Untapping the Full Potential of CLOUD Act Agreements" (secondary; executive agreements / MLAT comparison)
• Norton Rose Fulbright "Schrems II landmark ruling" (secondary; C-311/18)
• Hunton "EU's General Court Confirms Adequacy of EU-US DPF" (Latombe, 2025-09) (secondary)

Status and dates here shift month to month. The FISA 702 reauthorization/lapse and the Latombe CJEU appeal are especially likely to move after the confirmation date (2026-06).

AI-assistance transparency: the author drafted this from points known in practice, using Claude (Anthropic) for research, structuring, and condensation, then confirmed the substance against primary sources (statutes, government documents, treaties, court/parliamentary records). Because the law and litigation here are in flux, statutes, effective dates, and the scope of rulings reflect confirmation as of June 2026; items relying on secondary sources are marked (secondary).

About the author

Over 20 years in electrical and software development (from control engineering) at a major electronics manufacturer, plus about 10 years of independent development. I write from the basics that "become a risk if you don't know them," across hardware and software, enterprise and individual, and intend to cover practical AI use over time. More at About this blog.