Skip to content

Long-form guide / revised 4 Nov 2026

The US CLOUD Act and AI inference

What 18 U.S.C. § 2713 actually reaches, why an EU region does not change the answer, and the controls that shrink what any provider can be compelled to produce.

Short answers

Does an EU region of a US cloud avoid it?
No. Reach turns on control, not server location.
Is an EU-parented provider outside it?
Usually lowest exposure, not automatic. Check US subsidiaries and hosting.
What limits what can be produced?
Zero retention, customer-held keys, pseudonymisation and in-VPC deployment.
23 Mar 2018
CLOUD Act enacted as Division V of the Consolidated Appropriations Act, 2018
Pub. L. 115-141
18 U.S.C. § 2713
providers must disclose data in their possession, custody or control wherever it is stored
Stored Communications Act, as amended
14 days
window for a provider's statutory motion to modify or quash, counted from service of the legal process
18 U.S.C. § 2703(h)(2)
3 Oct 2022
US-UK Data Access Agreement, the first CLOUD Act executive agreement, enters into force
Signed 3 October 2019

01 / Statute

What the CLOUD Act actually is

The Clarifying Lawful Overseas Use of Data Act was signed into US law on 23 March 2018 as Division V of the Consolidated Appropriations Act, 2018. It is short, and it does two separate things. Part one amends the Stored Communications Act (18 U.S.C. § 2701 and following) by adding a new section, 18 U.S.C. § 2713, which settles where a US warrant can reach. Part two, codified at 18 U.S.C. § 2523, lets the US government conclude executive agreements with qualifying foreign governments so that their authorities can serve orders directly on US providers for serious crime investigations.

The Act was written to end a specific lawsuit. In the Microsoft Ireland case, the Second Circuit held in 2016 that a Stored Communications Act warrant could not compel Microsoft to produce email content held in its Dublin data centre. The Supreme Court heard argument on 27 February 2018. Congress passed the CLOUD Act a month later, the government obtained a fresh warrant under the amended statute, and on 17 April 2018 the Supreme Court vacated the judgment and sent the case back for dismissal as moot. The extraterritoriality question was never decided by the Court because the statute answered it.

For a European DPO the practical reading is narrow but important. The CLOUD Act does not create a new surveillance programme and does not lower the evidentiary bar. US authorities still need the same instrument the Stored Communications Act already required under § 2703: a warrant for content, a court order or subpoena for certain records. What changed is the geography. Once a provider is subject to US jurisdiction and the data is within its control, the server's location stops being a defence.

Keep the statutes apart
Schrems II (Case C-311/18, 16 July 2020) turned on US foreign intelligence law: FISA Section 702 and Executive Order 12333. The CLOUD Act is criminal law enforcement access to stored data. Both matter to a transfer impact assessment, but they are different authorities with different procedures, and a mitigation that answers one does not automatically answer the other.

02 / Reach

Section 2713: control, not location

The operative sentence of § 2713 requires a provider of electronic communication service or remote computing service to comply with obligations to preserve, back up or disclose the contents of communications and any record or other information pertaining to a customer or subscriber that is within the provider's possession, custody or control, regardless of whether that communication, record or other information is located within or outside of the United States.

Three phrases carry the weight. First, the provider categories: electronic communication service and remote computing service are Stored Communications Act terms broad enough to cover cloud hosting, managed AI inference APIs and most SaaS that stores customer content. Second, possession, custody or control: a standard borrowed from US discovery practice, where control can mean the legal right or practical ability to obtain the data on demand. Whether a US parent controls records held by its European subsidiary is a fact-specific question, and you should not assume the answer is no simply because the subsidiary is the contracting entity. Third, customer or subscriber records: the section reaches metadata, account and billing records, not just content.

The provider must also be subject to US jurisdiction in the first place. A US-headquartered company always is. A European company with a US subsidiary, US offices, or substantial and deliberate US business may be, depending on its contacts with the United States. A European company with no US presence is much harder for a US court to reach directly, which is why parent nationality and corporate structure appear in serious transfer impact assessments.

  • In scope: stored prompts, completions, conversation history, fine-tuning datasets, vector store contents, abuse-monitoring logs, account and billing records.
  • Process required: the ordinary § 2703 instruments (warrant for content; court order or subpoena for specified records).
  • Not changed by § 2713: the need for a US court or prosecutor to obtain that process, or the provider's ability to challenge it.

03 / Challenge

The motion to quash and comity under § 2703(h)

The CLOUD Act added a statutory route for a provider to push back. Under 18 U.S.C. § 2703(h)(2), a provider served with process for content may file a motion to modify or quash where it reasonably believes that the customer is not a US person and does not reside in the United States, and that disclosure would create a material risk of violating the laws of a qualifying foreign government. The motion must be filed within 14 days of service unless the government agrees or the court extends the deadline.

The court then runs a comity analysis. Section 2703(h)(3) lists the factors, including the interests of the United States, the interests of the qualifying foreign government in preventing the disclosure, the likelihood and nature of penalties the provider would face, the location and nationality of the customer and their connection to the United States, the provider's ties to and presence in the United States, the importance of the information to the investigation, and whether the information could be obtained in a timely way by means with less serious consequences.

The catch for European data is the phrase qualifying foreign government. It means a country with a CLOUD Act executive agreement that gives reciprocal rights to US providers. The European Union is not one, and no EU member state is one. For an order touching EU personal data, the statutory motion is therefore generally not available. The Act states that it does not affect common-law comity analysis, so a provider can still argue comity under ordinary US case law, but that is a discretionary, case-by-case argument with no guarantee of success.

What to ask your AI vendor
Do you commit, in the DPA, to challenge orders for EU customer data, to use all available comity arguments, to notify us unless legally prohibited, and to publish a transparency report that separates government requests by jurisdiction of the data subject?

04 / Agreements

Executive agreements: the UK, Australia, and the EU gap

Section 2523 lets the US Attorney General, with the concurrence of the Secretary of State, certify an agreement with a foreign government whose domestic law offers robust substantive and procedural protections for privacy and civil liberties. Orders under such an agreement must relate to serious crime, must not target US persons or persons in the United States, and must be subject to review or oversight by an independent authority in the requesting country. In exchange, the foreign government's authorities can serve orders directly on US providers without going through the slower mutual legal assistance treaty process.

The first agreement was with the United Kingdom. It was signed on 3 October 2019 and entered into force on 3 October 2022. The second, with Australia, was signed in December 2021 and entered into force on 31 January 2024. Both are time-limited and must be renewed.

The European Union opened negotiations on an EU-US agreement on cross-border access to electronic evidence in 2019, paused them, and resumed them in 2023. At the date of this guide's last review, no EU-US agreement has entered into force. In parallel the EU built its own regime: the e-Evidence Regulation (EU) 2023/1543 lets member state authorities issue European Production and Preservation Orders to service providers offering services in the Union, and applies from 18 August 2026. For AI teams, the point is symmetry: lawful access to cloud-held data is now a cross-border problem in both directions, and residency design has to account for which authority can compel which entity.

05 / Corporate structure

EU-parented versus US-parented providers

When a prompt is processed in Frankfurt by a US-parented hyperscaler, the physical location satisfies most residency clauses, but the legal reach analysis is unchanged: the US parent is subject to US jurisdiction, and the question becomes whether it has possession, custody or control of the data. Regional commitments such as EU data boundary programmes are real engineering work and narrow the set of places data goes, but they are commitments about storage and processing location. They do not, and do not claim to, remove the parent from US jurisdiction.

An EU-parented provider with no US subsidiary and no meaningful US operations sits in a different position: a US court would first have to establish jurisdiction over it, and a US order would collide directly with Article 48 GDPR. That is a stronger position, not an absolute one. Check three things before treating an EU provider as outside CLOUD Act reach: whether it has a US subsidiary or US-based staff with access to production systems, whether its own infrastructure runs on a US-parented cloud (which reintroduces the exposure at the sub-processor layer), and whether its model weights or inference stack are operated by a US partner.

The same logic applies to the gateway in the middle. YTT SECUNET PRIVATE LIMITED is incorporated in India, not the United States, but we do not treat that as immunity: the CLOUD Act reaches any provider subject to US jurisdiction, which can include a foreign company with enough US contacts, and Indian law gives Indian authorities their own access powers under section 69 of the Information Technology Act, 2000. That is why the data path is designed so that YTT Secunet holds nothing worth compelling: prompts and completions stream through memory and are never written to disk, residency receipts contain hashes rather than content, the EU control plane runs on EU-headquartered infrastructure, and Sovereign Dedicated deployments run inside the customer's own VPC with signing keys in the customer's HSM.

  • US-parented provider, EU region: residency satisfied; CLOUD Act reach depends on control, which the parent will usually have.
  • EU-parented provider with a US subsidiary or US hosting: indirect exposure; examine the structure and the sub-processor chain.
  • EU-parented provider, EU hosting, no US presence: lowest exposure; still document the analysis in your TIA.
  • Self-hosted model in your own EU VPC: exposure follows your own corporate structure and your cloud provider's.

Exposure by provider structure

Provider structureChapter V transferCLOUD Act reachWhat to do
US-parented provider, EU regionNone if inference, support access and sub-processors stay in the EEALikely: the US parent will usually have control of the dataZero retention, customer-held keys, pseudonymise before inference; record residual risk in the TIA
EU-parented provider with a US subsidiary or US hostingDepends on the sub-processor chainIndirect: turns on structure and who can access productionMap the group structure and every sub-processor; require Article 48 commitments in the DPA
EU-parented provider, EU hosting, no US presenceNoneLowest: a US court must first establish jurisdictionDocument the analysis in the TIA; re-check on any change of control
Self-hosted model in your own EU VPCNoneFollows your own corporate structure and your cloud provider'sApply the same custodian inventory to your own logs, retrieval stores and tooling

Endpoint-level ratings for 44 in-region services are in the Sovereign AI Index.

06 / AI prompts

Prompts in transit versus prompts at rest

Section 2713 compels disclosure of what a provider holds. For AI inference that distinction is unusually useful, because a well-designed inference path can hold almost nothing. A prompt that is decrypted in memory, used to generate a completion, and discarded within seconds is not a stored record that can later be produced. The same prompt written to an application log, kept for 30 days in a provider's abuse-monitoring store, saved as conversation history, or embedded into a vector database is a record within someone's possession, custody or control.

Zero retention is therefore the single most effective control against CLOUD Act production orders for content. It is not a complete answer, and a TIA should say so. A preservation request under 18 U.S.C. § 2703(f) can require a provider to freeze records it already holds for 90 days, renewable for another 90, so short retention windows still matter. Prospective, real-time collection is governed by other US statutes, such as the Wiretap Act, the pen register statute and, for foreign intelligence, FISA, and zero retention does not neutralise those. And metadata survives zero retention: account records, API keys, billing records, IP addresses and request timestamps are all records pertaining to a customer.

The engineering conclusion is to treat every hop as a potential custodian and ask, for each one, what it writes down. In a typical LLM feature the hops are the client application, the API gateway, the model provider, any retrieval system, and observability tooling. Most stored prompt content in real deployments sits in the last two, not with the model provider.

Article 32 angle
Even where no Chapter V transfer occurs, the risk of third-country access to data processed in the EU belongs in your Article 32 security assessment and your DPIA. Minimising what each hop retains is the measure that serves both.

07 / European view

What the EDPB has said

On 12 July 2019 the EDPB and the EDPS sent a joint response to the European Parliament's LIBE Committee assessing the CLOUD Act against the GDPR. Their reading of Article 48 GDPR is the anchor: a judgment of a third-country court or a decision of a third-country authority requiring a controller or processor to transfer or disclose personal data may only be recognised or enforced if it is based on an international agreement, such as a mutual legal assistance treaty, in force between the requesting country and the Union or a member state. Absent such an agreement, a CLOUD Act order does not by itself make a disclosure lawful. The two bodies saw only narrow, case-by-case room under the Article 49 derogations and called for a negotiated EU-US agreement with strong fundamental rights safeguards.

The EDPB developed this into Guidelines 02/2024 on Article 48 GDPR, adopted in final form in June 2025. The core message: Article 48 is not itself a ground for transfer. A controller or processor that receives a request from a third-country authority needs both a legal basis for the processing under Article 6 and a transfer ground under Chapter V before it discloses anything.

For transfer impact assessments, the relevant document is EDPB Recommendations 01/2020 on supplementary measures, version 2.0, adopted on 18 June 2021. Its use cases matter for AI. Where data is stored encrypted and the keys stay under the exporter's control in the EEA, technical measures can be effective. Where a cloud provider or other processor needs the data in the clear to provide the service, and the destination country's access powers go beyond what is necessary and proportionate, the EDPB said it could not identify technical measures that would be effective. LLM inference is the clearest example of processing in the clear: the model must read the prompt. That is why the location and corporate reach of the inference endpoint matter more for AI than for encrypted storage.

08 / Adequacy

Where the EU-US Data Privacy Framework fits

The European Commission adopted its adequacy decision for the EU-US Data Privacy Framework on 10 July 2023. It rests on Executive Order 14086 of 7 October 2022, which introduced necessity and proportionality limits on US signals intelligence and a two-layer redress mechanism ending in the Data Protection Review Court. Transfers to US organisations that have self-certified to the framework with the US Department of Commerce can rely on that decision without SCCs or a separate TIA for the US legal regime.

The framework has survived its first challenge. On 3 September 2025 the EU General Court dismissed the annulment action brought by Philippe Latombe (Case T-553/23). An appeal to the Court of Justice was lodged on 31 October 2025 (Case C-703/25 P) and was pending at the date of this guide's last review. Prudent programmes keep a fallback: SCCs and a TIA on file for critical AI suppliers, so that an adverse ruling does not halt inference overnight.

Two clarifications prevent common mistakes. First, the Data Privacy Framework answers whether a transfer to a certified US recipient is lawful under Chapter V; it does not change whether data held by a US provider can be compelled under the CLOUD Act. Second, it only helps when the specific recipient is certified and the processing is within the scope of its certification. A provider's EU regional deployment, an EU-parented provider, or a self-hosted runtime may avoid the transfer question altogether, which is a more durable position than relying on an adequacy decision that remains under judicial review.

09 / Controls

Technical mitigations that hold up in an audit

No single control removes CLOUD Act exposure for data processed by a provider subject to US jurisdiction. A layered design reduces what can be compelled to almost nothing and produces the evidence a supervisory authority will ask for. The checklist below is the order in which we see regulated teams implement it; each step is independently useful.

  1. 01

    Inventory every custodian of prompt data

    List each hop that can store a prompt, completion or embedding: application logs, API gateway, model provider abuse monitoring, retrieval stores, evaluation datasets, observability and support tooling. Record the legal entity, its parent, and the retention period for each.
  2. 02

    Enforce zero retention at each hop

    Disable prompt logging in your own stack, obtain zero data retention terms from model providers where available, and write the commitment into the DPA. Keep only hashes and policy decisions in audit logs.
  3. 03

    Hold the keys for anything that must be stored

    Encrypt conversation history, receipts and configuration with customer-managed keys in an HSM under EEA control, so a provider ordered to produce data can only produce ciphertext.
  4. 04

    Route sensitive classes to EU-parented or self-hosted endpoints

    Classify requests by data sensitivity and send special category data, regulated financial data and public sector workloads to EU-parented providers or self-hosted runtimes in your own VPC, with failover restricted to the same jurisdiction.
  5. 05

    Pseudonymise before inference

    Replace direct identifiers such as names, national ID numbers and IBANs with tokens in the request path, and keep the mapping table in a vault in the origin jurisdiction, separate from the inference provider, as Article 4(5) GDPR requires for pseudonymisation.
  6. 06

    Minimise customer metadata

    Use pseudonymous tenant and user identifiers in API calls, shorten retention of IP addresses and request logs, and avoid sending account-level personal data to inference providers.
  7. 07

    Prepare an Article 48 response playbook

    Define who reviews a third-country request, how the processor must challenge and notify, when the DPO is consulted, and how requests are recorded. Require the same commitments from every processor in the chain.
  8. 08

    Document the analysis and keep the evidence

    Record the reasoning in your TIA and DPIA, and attach per-request evidence: residency receipts showing the resolved endpoint, region and zero-retention flag, plus the policy pack version that made the decision.

10 / Boundaries

What YTT Secunet does, and what it does not

YTT Secunet routes each inference request to an endpoint that satisfies the policy pack for the tenant's jurisdiction and data class, masks or pseudonymises identifiers in the request path, and returns a signed residency receipt that records the resolved endpoint, provider region, facility and zero-retention flag. Those are the technical measures this guide describes, enforced per request and evidenced per request.

YTT Secunet does not make a US-parented provider immune from the CLOUD Act, and nothing on this page should be read that way. It does not host foundation models itself, does not give legal advice, and does not replace your DPIA or transfer impact assessment. YTT SECUNET PRIVATE LIMITED is an Indian company, and that is not an exemption; our answer is architectural: zero prompt retention so there is nothing stored to disclose, customer-held keys, an EU control plane on EU-headquartered infrastructure, and a Sovereign Dedicated option that runs entirely inside your own environment.

What the gateway does per request

  • Routes to an endpoint the tenant's policy pack allows
  • Masks or pseudonymises identifiers in the request path
  • Streams prompts and completions in memory only
  • Returns a signed receipt with endpoint, region, facility and ZDR flag

What it does not do

  • Make a US-parented provider immune from the CLOUD Act
  • Host foundation models itself
  • Give legal advice
  • Replace your DPIA or transfer impact assessment

CLOUD Act and AI: frequently asked questions

Does processing in an EU region of a US cloud provider avoid the CLOUD Act?

No. Regional processing satisfies location requirements, but 18 U.S.C. § 2713 turns on whether a provider subject to US jurisdiction has possession, custody or control of the data, not where the server is. Regional deployments reduce transfer questions under Chapter V; they do not remove the parent company from US jurisdiction.

Is an EU-parented AI provider completely outside the CLOUD Act?

Not automatically. Exposure is lowest when the provider has no US subsidiary, no US-based staff with production access, and does not run on a US-parented cloud. Each of those links can reintroduce indirect exposure, so document the corporate and sub-processor structure in your TIA.

Can a provider refuse a CLOUD Act order for EU data?

It can challenge it. The statutory motion to quash under § 2703(h)(2) is only available where the foreign country is a qualifying foreign government with an executive agreement, which no EU member state currently is. Common-law comity arguments remain available, and good DPAs require providers to use them and to notify customers unless prohibited.

If prompts are never stored, is there anything to disclose?

Stored content cannot be produced if it does not exist, which is why zero retention is the strongest single control. Metadata such as account, billing and IP records may still exist, preservation requests can freeze records already held, and real-time collection falls under other US statutes. Minimise all three.

Does the EU-US Data Privacy Framework solve the CLOUD Act problem?

It answers a different question. The framework makes transfers to certified US organisations lawful under Chapter V; it does not change US authorities' ability to compel data from a US provider. It was upheld by the General Court on 3 September 2025, and an appeal to the Court of Justice is pending.

Is YTT Secunet itself subject to the CLOUD Act?

Possibly. YTT SECUNET PRIVATE LIMITED is incorporated in India, but a foreign provider with enough US contacts can receive US process, so we design on the assumption that it could, and the same design answers requests under Indian law. Prompts and completions are never written to disk, receipts contain hashes rather than content, and Sovereign Dedicated runs in your own VPC with your own signing keys, so there is no stored prompt content for YTT Secunet to produce.

Sovereign route ready

Stop risking 4% global turnover GDPR fines on AI inference.

Deploy sovereign, cryptographically proven AI routing in 15 minutes.