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.
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.
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.
| Provider structure | Chapter V transfer | CLOUD Act reach | What to do |
|---|---|---|---|
| US-parented provider, EU region | None if inference, support access and sub-processors stay in the EEA | Likely: the US parent will usually have control of the data | Zero retention, customer-held keys, pseudonymise before inference; record residual risk in the TIA |
| EU-parented provider with a US subsidiary or US hosting | Depends on the sub-processor chain | Indirect: turns on structure and who can access production | Map the group structure and every sub-processor; require Article 48 commitments in the DPA |
| EU-parented provider, EU hosting, no US presence | None | Lowest: a US court must first establish jurisdiction | Document the analysis in the TIA; re-check on any change of control |
| Self-hosted model in your own EU VPC | None | Follows your own corporate structure and your cloud provider's | Apply 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.
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.
- 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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