Where does your data go after you hit delete? Retention, managed enclaves, and cross-border access in AI/cloud

Written: 2026-06-22 / Scope: United States and the EU

日本語版: AI・クラウドに預けたデータはいつ消え、誰が見ることができるか

This is the English edition of a data-sovereignty series. The predecessor, "Putting your data in the hands of US companies," covered the asymmetry in how fast data can be pulled. This article continues into the two layers it deliberately left out: what survives after deletion, and operational access inside managed environments.

A few terms (for readers new to this):

• ZDR (Zero Data Retention): a contractual option not to store inputs/outputs. It is approval-gated and limited in scope.
• Abuse monitoring: retaining and reviewing data for a period to detect misuse — separate from training and from chat history.
• Litigation hold: a duty to preserve data that would normally be deleted, arising when litigation is reasonably anticipated or ordered by a court. It overrides ordinary deletion.
• CLOUD Act◆: a US law that can compel a provider subject to US jurisdiction to disclose data even when it is stored abroad.
• BYOK / CMK (Bring Your Own Key / Customer Managed Key): managing the encryption key on the customer side.
• GDPR◆ (General Data Protection Regulation): the EU regulation governing how personal data of people in the EU is handled.

"Is it safe to put data here?" actually splits into three independent questions. Mixing them produces either false comfort ("it's not used for training, so it's safe") or excess fear ("anything in the cloud is wide open"). We start by separating the three axes.

"Not used for training" is not the whole story — the three-way separation

Evaluate the safety of hosted data along three axes.

On APIs and commercial plans, "not used for training" is increasingly the default — but that is a separate matter from (2) and (3). Even when data is not used for training, it can still be retained, a government can still obtain it through legal channels, and provider operations staff can still see plaintext. We leave axis (1) to the terms-of-service article and dig into (2) and (3).

Two more pairs are easy to conflate. First, "retained" is not "used for training": even providers that promise no training use retain data for a period for operations and abuse monitoring. Second, "deleted" is not "who can see it": deletion is rarely instant physical erasure, and while data is retained it remains within reach of (2) government and (3) provider access.

Deleting isn't erasing — the three layers of retention

Retention is not a single "retention period." Three layers of different character overlap, and you should first identify which layer you actually care about.

• Operational retention: conversation history and app state kept to deliver the service. Often controllable by user deletion or plan settings.
• Abuse / safety-classification retention: kept to detect misuse and enforce policy, independently of user deletion or training opt-out. For example, OpenAI's API default is 30 days; Anthropic retains inputs and outputs for up to 2 years and trust-and-safety classification scores for up to 7 years when a session is flagged; Google's Gemini Apps (consumer) retains human-reviewed data for up to 3 years (all per the providers' official pages as of 2026-06).
• Legal hold: a court order or preservation duty that overrides ordinary deletion and keeps data far longer. The user cannot control this layer.

Between "I deleted it" and "it is gone" there are stages. When you delete, data is removed from history and the account immediately — but that is "no longer visible," not physical erasure. Permanent backend deletion lags: OpenAI states ChatGPT data is "permanently removed within 30 days," and Anthropic "within 30 days from back-end systems." For Google's and Microsoft's consumer services, the physical-erasure lag is not stated as a number in their official pages. So "30 days" is a baseline figure that lengthens once the abuse and legal layers apply.

ZDR (Zero Data Retention) looks like a way to avoid retention, but it is not a cure-all. It is approval-gated, limited to certain endpoints and plans, and some retention survives it: CSAM-detection holds, safety retention for certain new models, and user-safety classifier scores can persist even under ZDR.

The strongest override is a litigation hold. In the reported New York Times v. OpenAI matter, a court asked OpenAI to preserve even "deleted" ChatGPT chats and API content that would normally be auto-deleted within 30 days; Free, Plus, Pro, Team and API without ZDR were in scope, while Enterprise, Edu, and API under a ZDR amendment were out of scope (OpenAI has stated this preservation obligation ended on 2025-09-26). The takeaway is that higher-tier plans were less exposed to retention override — but you cannot generalize this to "ZDR or Enterprise is always exempt."

Managed enclaves don't make the provider blind — what BYOK/CMK protects

Managed enclaves such as Amazon Bedrock, Azure OpenAI Service, and Google Vertex AI all state contractually that customer input is not used to train models. Each, however, carries a reservation — "except with permission or instruction" — which belongs to axis (1). This section is about axes (2) and (3): while data is retained and operated on under "no training," can the provider or a government reach it?

This is where BYOK / CMK (customer-managed keys) matters — but the key's protection has limits. What BYOK/CMK reliably protects is mainly data at rest; revoke the key and even the provider can no longer decrypt it. But plaintext processed at inference time (an LLM cannot run inference on ciphertext, so the input has to be restored to plaintext), the decrypt permission the provider holds to run the service, and abuse-monitoring logs can fall outside the key's reach. Google explicitly documents that in-memory data at the endpoint and abuse-monitoring logs are not covered by customer-managed keys (CMEK). For Bedrock and Azure OpenAI, plaintext visibility at inference time is not explicitly stated in the official pages, so this point cannot be confirmed (we treat it as unverified).

In other words, unless the customer holds the key in fully separated custody (for example via an external key manager), encryption is not a decisive block against provider or government access. Conversely, if the customer holds the key externally, the provider has room to argue it "cannot technically disclose" the data — but that is a technical argument, separate from whether the data still sits within its legal possession, custody, or control, and it does not extend to processing that requires plaintext, such as abuse monitoring.

US reach follows the provider's jurisdiction, not the region

"Put it in a Frankfurt or Tokyo region and the US government can't touch it" and "anything in a US cloud is wide open" are both oversimplifications. The mechanics and basic definitions of the CLOUD Act, FISA 702, and NSLs are in the predecessor article; here we only fix the determining factor.

The first factor is not where the data sits but whether the provider is subject to US jurisdiction. The US Department of Justice has stated there is "no exception for data that a company controls but chooses to store abroad," and that disclosure cannot be compelled unless the US "has personal jurisdiction over the company." The major US providers are US entities, so they are subject to personal jurisdiction. Data stored in an EU or Tokyo region therefore can still fall within the reach of the CLOUD Act when it is within the provider's possession, custody, or control.

But "can fall within reach" is not "will always be obtained." Each channel has constraints: obtaining content requires a warrant (probable cause), NSLs cannot reach content, and FISA 702 targets "persons reasonably believed to be located outside the United States" who are non-US persons. (FISA 702's statutory authority lapsed on June 12, 2026 after Congress failed to agree on reauthorization; however, surveillance is reported to continue under FISA Court certifications already in effect — by most accounts through around March 2027 — and reauthorization remains in flux. Confirm the current status when you make a decision.) Region choice moves the at-rest location, but it does not change the provider's jurisdiction or the cross-border processing that some deployment modes allow.

This reach also applies to data that survives deletion and to managed enclaves. Abuse-monitoring logs that remain after a user deletes are a region where the provider holds plaintext, and they therefore sit on the path of government access (whether they are actually obtained depends on whether the content is communications content or transactional records, and on warrant requirements). Real numbers exist: Microsoft's Law Enforcement Requests Report for the second half of 2025 states that, of 190 enterprise-related requests, 45 required content disclosure, of which 31 were to US law enforcement, and 3 disclosed data of non-US enterprise customers stored outside the US to US law enforcement. Content disclosure for offshore-stored enterprise data does happen — and the same jurisdictional reach applies to enclave deployments, since the provider remains under US jurisdiction.

The EU view: storage limitation, the right to erasure, and Schrems II

In the EU, the abuse-retention layer sits in tension with GDPR principles. Article 5(1)(e) (storage limitation) says personal data must not be kept in identifiable form longer than necessary for the purpose; the long retention of the abuse layer (up to two years, classification scores up to seven) invites the question of whether it exceeds "necessary." Article 17 (the right to erasure) lets data subjects request deletion on certain grounds.

A precise distinction matters here. Article 17(3)(e) — that erasure does not apply where processing is necessary for "the establishment, exercise or defence of legal claims" — is a defence against an erasure request, not an independent basis that legitimizes retention. Abuse-monitoring retention may invoke 17(3)(e) against an erasure request, but the lawfulness of the retention itself still has to pass the Article 6 lawful basis plus the purpose-limitation, storage-limitation, and proportionality tests, and is confined to what is necessary. So "we keep it for safety" is not an unlimited free pass; a provider's "retain for up to N years" is best read as a ceiling that proportionality can cut down.

Schrems II (CJEU C-311/18) casts a long shadow. It held that EU data subjects lacked effective redress against US government access, finding FISA 702 and EO 12333 not limited to what is strictly necessary. Since then the picture has shifted: Executive Order 14086 (2022) created the Data Protection Review Court (DPRC) as a redress mechanism, and the European Commission's 2023 adequacy decision (Implementing Decision (EU) 2023/1795) found US protections "essentially equivalent." The EU General Court upheld that decision in September 2025 (Latombe v Commission, T-553/23), though an appeal to the Court of Justice is pending and the framework's durability is contested — it rests on an executive order rather than a statute, and the 2025 disabling of the US oversight board (PCLOB) has been flagged as a concern. So the redress question is no longer "none" but "a mechanism exists whose adequacy is still being litigated." The EDPB's guidance (Recommendations 01/2020, Use Case 6) adds that where plaintext is technically required and the data importer holds the key, transit and at-rest encryption together are not a sufficient supplementary measure. Sovereign-cloud schemes exist — AWS European Sovereign Cloud, Azure's EU Data Boundary, Google's Assured Workloads — but their existence does not mean "the CLOUD Act no longer applies." Azure's EU Data Boundary itself lists eight categories of exception where transfers outside the EU continue, and a US parent remains subject to US jurisdiction. Whether a sovereign configuration definitively removes CLOUD Act reach is not something this article could confirm from primary sources, and it remains an open question.

Summary

"Is it safe to host this data?" gets clearer once you split it into three questions — training, government, and provider access. Not using data for training is neither not retaining it nor making it invisible. Even after deletion, the abuse-monitoring and legal-hold layers remain, and that surviving data is exactly what government access can reach. An enclave's key management mostly protects data at rest, not plaintext at inference or monitoring logs, and region choice moves the storage location without changing the provider's jurisdiction. In the EU, "retain for safety" must still pass storage-limitation and proportionality, and while a post-Schrems II redress mechanism now exists (the DPRC under EO 14086, underpinning the 2023 adequacy decision), its adequacy is still being litigated and politically contested. The point is not zero risk; it is choosing plan, keys, region, and contract type so that each axis is reduced as far as it can be. Confirm specifics with primary sources and a specialist.

Here is a checklist you can copy and reuse.

[Before you host data]
□ Inventory whether the data includes personal data, and map which axis (training / government / provider) you most need to block
□ Choose plan (consumer / API / Enterprise) and whether ZDR is needed, accounting for abuse-retention and litigation-hold override
□ For an enclave, understand what BYOK/CMK protects (at rest) and its limits (inference-time plaintext, monitoring logs), then decide the key model (own KMS / external key manager)
□ Share internally that region choice moves the storage location, not the provider's jurisdiction

[After you host data]
□ Assume abuse/safety retention survives user deletion; confirm the retention ceilings in the contract / DPA
□ For EU personal data, check storage limitation and the right to erasure against the abuse-retention (necessary and time-limited)

[When a disclosure or government request arrives]
□ Treat government access as a "may reach" zone determined by the provider's jurisdiction; separate the channels and consult counsel
□ Confirm with the vendor which plans and isolation a litigation hold can override

References

• OpenAI: Your data (developers.openai.com, as of 2026-06)
• Anthropic: Privacy and data retention (privacy.claude.com, as of 2026-06)
• Google: Gemini Apps Activity / Vertex AI data governance (support.google.com, cloud.google.com, as of 2026-06)
• AWS Bedrock: Security and privacy / Azure OpenAI: Data privacy (as of 2026-06)
• US DOJ: CLOUD Act White Paper, 18 USC 2713 / 2703 / 2709 (justice.gov/d9/pages/attachments/2019/04/10/doj_cloud_act_white_paper_2019_04_10.pdf)
• Microsoft: Law Enforcement Requests Report, H2 2025 (microsoft.com/en-us/corporate-responsibility/reports/government-requests/customer-data)
• CRS R48592: FISA Section 702 and RISAA 2024 (congress.gov/crs-product/R48592)
• EUR-Lex: GDPR Art.5 / Art.17; CJEU C-311/18 (Schrems II, curia.europa.eu); EDPB Recommendations 01/2020
• EU-US Data Privacy Framework: Commission Implementing Decision (EU) 2023/1795; US Executive Order 14086 (DPRC); Latombe v Commission T-553/23 (EU General Court, 2025; appeal to the Court of Justice pending)
• Azure: EU Data Boundary (learn.microsoft.com)
• Predecessor: Putting your data in the hands of US companies (/blog/us-data-access-sovereignty-for-builders-en)