Zero Data Retention Is AI’s New Safety Battleground

OpenAI says frontier-model safety monitoring no longer has to mean storing customer prompts. Anthropic argues its most capable systems are too dangerous not to retain them. The dispute will shape enterprise AI, privacy, cybersecurity, and who gets access to the frontier.

Current as of August 19, 2026, 2:17 p.m. PDT (21:17 UTC). Policies, model eligibility, and feature limits can change quickly.

The verdict

Zero Data Retention materially reduces the blast radius of an AI-provider breach, subpoena, insider incident, or unwanted secondary use. It does not mean that no data is processed, no metadata exists, no safety signal survives, or no other party stores the interaction. It also transfers evidence, compliance, recovery, and abuse-prevention duties from the model company to its customer.

That transfer is now a frontier-AI safety dispute. On August 19, OpenAI previewed Private Safety Processing, a design intended to correlate related interactions while keeping the underlying content outside OpenAI personnel’s reach. Anthropic has made the opposite near-term choice: prompts and outputs for Claude Mythos 5 and Fable 5, its designated Covered Models, must be retained for at least 30 days on every platform where they are offered.

Neither company has proved the industry’s larger case. OpenAI has announced a preview, not published technical proof. Anthropic has explained its threat model, but it has not publicly shown that 30 days of raw content produces enough added detection to justify the exposure. The useful question is not whether retention is good or bad. It is which party should keep which evidence, for what purpose, under whose keys, for how long, and with what right to inspect it.

The short answer

• ZDR is narrow by design. It normally means covered prompts and outputs are not written to durable provider storage after processing. It does not automatically cover metadata, tools, customer logs, files, caches, safety signals, or legal exceptions.
• OpenAI and Anthropic are making different safety bets. OpenAI says privacy-preserving, cross-request analysis can preserve ZDR. Anthropic says serious misuse of its Covered Models requires a retained 30-day window.
• The same model can have a different data path on another cloud. AWS, Azure, Google Cloud, and a direct model API can apply different storage, review, routing, and verification controls.
• ZDR removes evidence as well as exposure. It reduces breach and discovery risk, but can obstruct incident reconstruction, appeals, debugging, recovery, and mandatory recordkeeping.
• Enterprise buyers should demand a fail-closed control, not a brochure claim. A contract, endpoint matrix, programmatic signal, change-notice duty, and audit evidence matter more than the word “zero.”
• Many regulated deployments need split custody. The model provider retains no content; the customer keeps the minimum governed audit record required for safety, care, finance, or legal duties.

What zero data retention actually means

In plain English, ZDR usually means the AI provider does not keep your prompts or the model’s answers in durable storage once it has processed the request.

The technical definition is conditional: for an identified entity, tier, model, endpoint, region, and configuration, covered content is processed transiently and excluded from durable provider logs and application state, subject to stated exceptions. A text-completion request can have ZDR while a separate service keeps account records, token counts, a policy signal, or a file.

The terms vendors blur together

Term	What it usually means	What it does not guarantee
Zero Data Retention	Covered prompt/output content is not durably retained after processing	No processing, no metadata, no legal exception, or no downstream copy
No training on customer data	Content is excluded from model training by default or contract	Content is not logged, reviewed, or retained
store=false or stateless API	A retrievable response object is not intentionally persisted	Abuse logs and feature-specific stores are also disabled
Modified abuse monitoring or zero operator access	Ordinary human review is restricted	No automated inspection or durable storage
Data residency	Covered data is processed or stored in a chosen region	No retention or no cross-border system metadata
Customer-managed encryption keys	The customer controls decryption authority for a defined store	The data does not exist or cannot leak through another path
Confidential computing	Processing occurs inside a hardware-protected environment, if implemented	ZDR or protection across every tool and endpoint
On-premises, VPC, or self-hosting	The customer controls more of the data path	Safe settings, deletion, or the absence of customer-side logs
Temporary or deleted chat	A UI hides a chat or schedules it for deletion	Immediate backend deletion or an enterprise ZDR commitment

This distinction is not academic. OpenAI says API data is not used to train models unless the customer opts in, yet its default API abuse logs can contain prompts, responses, and classifier outputs for up to 30 days. Fireworks says most open-model inference is ZDR by default, but its Responses API stores conversations for 30 days when store=True, which is the default. A training opt-out is a control over purpose; ZDR is a control over persistence.

The data that can remain outside “zero”

A data-flow inventory includes more than the prompt box:

• identity, billing, token-count, rate-limit, model, timestamp, IP, request-ID, and audit data;
• classifier scores, hashes, policy labels, or other derived safety signals;
• RAM and GPU memory, KV caches, ephemeral disks, traces, and crash artifacts;
• files, vector stores, batches, fine-tuning sets, evals, agent memory, stored responses, containers, and generated media;
• web search, remote MCP servers, connectors, cloud drives, code sandboxes, and other subprocessors;
• customer gateways, DLP, observability, local coding-agent histories, and backups;
• support tickets, user feedback, red-team examples, abuse investigations, and material under legal hold; and
• apparent child sexual abuse material that a provider may have to report and preserve.

OpenAI documents encrypted prompt-cache tensors in GPU-local storage for up to 24 hours, roughly ten minutes of disk state for Responses background mode, an hour for some audio state, and third-party rules for MCP traffic. Those details show why buyers must define the boundary.

Why this became a frontier-model fight

Per-request moderation asks whether one interaction crosses a line. Frontier safety increasingly asks whether a sequence does.

A cyber operator can divide reconnaissance, exploit development, credential work, and persistence across many plausible-looking turns. A Best-of-N jailbreak submits hundreds of slight prompt variations and waits for one failure. A biological workflow can distribute precursor selection, protocol refinement, and troubleshooting across sessions. An agent can also drift from its owner’s instruction gradually: no single action looks decisive, but the trajectory does.

Longitudinal monitoring can join those dots. Raw logs are the easiest input for it, and they are also a concentrated collection of source code, patient notes, legal strategy, unreleased products, financial records, and research. That is the core collision: the evidence most useful for detecting a campaign is often the evidence a responsible customer most wants the provider never to possess.

NIST’s March 2026 report on the challenges of monitoring deployed AI systems says post-deployment monitoring is needed to catch unforeseen behavior and real-world consequences, while methods and common terms remain immature. ZDR does not cancel that need. It forces a different answer to where monitoring runs and what survives.

OpenAI’s proposal: correlate risk without exposing content

OpenAI’s Private Safety Processing announcement sketches two architectures.

In the first, customer content stays on infrastructure the customer controls. Automated safety processing evaluates related interactions and returns a narrowly defined risk signal to OpenAI. In the second, still under development, content sits on OpenAI infrastructure encrypted with customer-controlled keys that OpenAI personnel do not possess. If a signal triggers enforcement, the customer investigates with records in its own environment. It can choose to share relevant material to appeal or to support an investigation of verified abuse.

The proposal could give the provider cross-request context without a readable prompt warehouse. It could also improve due process: the customer evaluates an alert before disclosing sensitive details.

The announcement does not identify the cryptographic construction, trusted-computing base, linkage identifiers, signal schema, error rates, cache behavior, key-revocation path, isolation design, or audit mechanism. Nor does it say whether the system replaces OpenAI’s Eyes Off and Safety Retention provisions. Current docs still reserve the right, with written notice, to make models ineligible for ZDR for a customer; Safety Retention can permit storage and review of classifier-flagged content for severe-risk investigations.

Private Safety Processing is in early-customer testing, with rollout and a technical paper planned for September. Until then, its security, unlinkability, operator access, and detection performance remain unproved vendor claims.

There is also an explicit limit on “zero.” OpenAI says images flagged as possible CSAM will continue to be retained for manual review and reporting, including in ZDR deployments. That exception is visible and tied to law. Buyers should demand the same clarity for every exception.

Anthropic’s opposing bet: retain a safety window

Anthropic’s Covered Models policy says prompts and outputs for Claude Mythos 5 and Fable 5 are retained for 30 days everywhere those models appear. Mythos 5 has limited partner access; Fable 5 is broadly available. Prior Claude models can remain in ZDR workspaces.

Anthropic’s case is straightforward. Mythos-class capability raises cyber and biological risk. Best-of-N attempts, espionage, extortion, and coordinated misuse become visible only when classifiers can compare many requests. It therefore requires a window of raw prompts and outputs rather than betting immediately on a less mature privacy-preserving design.

Anthropic says personnel cannot read retained conversations by default. Flagged material can enter a controlled path for a small approved group, with each access logged. Content is deleted after 30 days unless a safety flag or legal duty requires longer. Eligible customers can add managed keys and access-transparency logs. Custody follows the route: Anthropic on its platform, AWS or Google on their clouds, and a separate Azure subscription configuration.

The policy is not self-validating. Anthropic has not publicly quantified the detection gained, false-positive burden, incidents missed by per-request classifiers, or performance of customer-side alternatives. A 30-day repository also creates a target and may exclude customers whose rules forbid provider-side copies.

The sharpest reading is not that one company cares about privacy and the other about safety. OpenAI is wagering that the two can be separated technically. Anthropic is wagering that today’s safer operational choice is controlled retention. Both benefit commercially from their answer, and both need independent evidence.

How the major providers compare

The following tables deliberately separate product surfaces. They summarize published terms, not an audit of provider systems.

Defaults and ZDR routes

Provider and surface	Default prompt/output handling	ZDR route	Scope and training treatment
OpenAI API	Abuse logs may retain content for up to 30 days; some features add application state	Prior-approved ZDR at organization or project level	API content is not used for training unless opted in; only eligible endpoints receive the full control
Anthropic Covered Models	Mythos 5 and Fable 5 content retained at least 30 days	Not available for these models	Policy follows the model across direct and cloud routes; other Claude models can keep existing ZDR settings
Anthropic API, other eligible models	Standard commercial retention depends on product and agreement	Eligible organizations can configure ZDR workspaces	Anthropic does not train on commercial inputs/outputs by default; stateful features can step outside ZDR
SpaceXAI/xAI API	Encrypted inputs/outputs stored 30 days for audit	Team-wide, self-service where available	No API training without permission; every response exposes an x-zero-data-retention header
Google Cloud Gemini Enterprise Agent Platform	Feature-dependent; request logging is off by default, but abuse or product stores can apply	A configuration outcome across logging, caching, interactions, and grounding	No training without permission; Search and Maps grounding create separate retention boundaries
Microsoft Foundry model inference	Automated abuse review; flagged samples may be stored for human review	Eligible customers can request modified abuse monitoring	Data is hosted by Microsoft, not sent to the model developer; not described by Microsoft as universal ZDR
Amazon Bedrock	default follows model policy; AWS may retain for safety	Eligible configurations can use retention mode none	store=false alone is not ZDR; model policy can require another mode or block the request
Cohere SaaS	Prompts and generations normally deleted after 30 days, with safety/legal exceptions	Approved enterprise ZDR	ZDR removes prompt/generation logs, not usage data; private and partner deployments can keep content outside Cohere
Mistral API	API data is not used for training; retention control depends on plan/configuration	Approved Scale-plan ZDR for listed stateless endpoints	Labs models and stateful products are excluded
Fireworks AI	Open-model prompts/outputs exist only in volatile memory by default	Default for most services	Metadata remains; Responses API stores 30 days when its default store=True is not changed
Self-hosted Meta Llama	Determined by the deployer’s stack	Customer can keep inference inside its own environment	Open weights are not a retention policy; a hosted Llama endpoint follows the host’s rules

Exclusions, review, and verification

Provider and surface	Main exclusions or review conditions	Best verification signal	Most important caveat
OpenAI API	Conversations, ChatKit threads, Assistants, vector stores, files, fine-tuning, evals, batches, and video are not ZDR-eligible; CSAM images can be retained	Organization/project control plus endpoint allowlist	store=false does not cover every store; Eyes Off and Safety Retention can change eligibility with notice
Anthropic Covered Models	Automated review; restricted human review of flags; safety/legal holds can extend retention	Covered Models list and workspace/cloud configuration	Mandatory retention applies to two named models, not all Claude services
Anthropic API, other models	Batches, managed agents, code execution, files, and connectors have separate terms	Workspace retention setting and feature matrix	A ZDR workspace may still let a user call a non-ZDR feature
SpaceXAI/xAI API	Stateful Responses, Files, Collections, Batch, deferred results, hosted media, and voice history unavailable	Response header and team badge	ZDR is team-wide; administrative logs remain; customer must preserve legal records
Google Cloud	Some advanced-model addenda, abuse logging, stored Interactions, session resumption, Search, and Maps	Config review, store=false, and approved abuse-log exception	“ZDR” requires several settings; in-memory derived cache can last up to 24 hours unless disabled
Microsoft Foundry	Stateful Responses, Assistants, files, and other stored features persist; automated classification continues	Verify ContentLogging: false	Modified monitoring reduces human access but does not eliminate automated inspection
Amazon Bedrock	Current OpenAI frontier traffic can have classifier-flagged samples retained; Fable 5/Mythos 5 require provider sharing	IAM/SCP enforcement of none where eligible	The same model’s direct API and Bedrock route can behave differently
Cohere	Safety flags and legal duties affect default retention; ZDR requires approval and commitments	Contract and ZDR approval; Model Vault configuration	Usage metadata survives; private deployment shifts all controls to the customer
Mistral	Agents, batches, conversations, libraries, files, Vibe Work, and Chat excluded	Admin privacy status plus endpoint blocklist	ZDR and training opt-out are separate controls
Fireworks	Responses conversation state persists when store=True; opt-in services may log content	Request setting plus service allowlist	A provider-wide headline has an endpoint-level exception
Self-hosted Llama	Customer logs, backups, traces, tools, and incident stores	Infrastructure audit, not a Meta badge	The customer inherits deletion, security, abuse, and reporting work

Stateful convenience conflicts with narrow ZDR: history, files, batches, agents, and hosted media need somewhere to live. Cloud custody also matters as much as model authorship. Programmatic proof remains rare; SpaceXAI’s response header is the clearest public example.

The technical data path: where copies appear

1. Assembly: an application or coding agent gathers the prompt, files, retrieved passages, credentials, and tool state. Over-collection can happen before the model call.
2. Customer controls: an API gateway, DLP filter, proxy, telemetry SDK, or local session history may copy the request. Provider-side ZDR does not delete those copies.
3. Service edge: TLS terminates; authentication, rate limiting, routing, and policy classifiers process the request. Administrative and usage metadata can remain.
4. Inference: accelerators hold tokens and KV state in volatile memory. Prompt caching or async work may introduce short-lived state.
5. Safety: a system evaluates one request or correlates a sequence. The correlator may see raw content, customer-held content, ciphertext in a protected environment, or only derived signals.
6. Tools: web search, remote MCP, connectors, code execution, storage, and media systems open new contractual boundaries.
7. Return: the output reaches the customer, where product logs or regulated records may preserve it.
8. Destruction: covered provider content is destroyed according to the actual control, while allowed metadata, signals, and exception records remain.

Four designs can all be sold near the same idea. A provider can avoid durable prompt storage entirely. A customer can retain context and run provider-supplied safety analysis over it. A provider can hold ciphertext that only the customer can unlock. Or a cloud can retain readable content for a short safety window with restricted human access. The privacy-versus-observability relationship is therefore not a straight line.

What ZDR changes

Product design and cost

ZDR often disables history, stored responses, batches, files, retrieval, and delayed jobs. The customer carries conversation state, increasing engineering work and sometimes tokens. Restricted caches can raise latency and cost. A vanished request cannot be debugged after a complaint.

These are consequences of state ownership. A sound product keeps memory in a customer-controlled store, gives prompts and audit facts separate schedules, and sends minimum context. A weak one enables ZDR while gateways, analytics, support, or remote tools keep copies.

Safety, security, and incident response

Retention supplies evidence for campaign detection, appeals, regressions, and incident reconstruction, including patterns no single customer can see. This is Anthropic’s strongest argument.

Non-retention removes a high-value target. A compromised provider, insider, litigant, or government cannot extract a prompt repository that never existed. It also limits competitive intelligence. This is OpenAI’s strongest argument.

One breach can expose many innocent customers; one missed campaign can harm outsiders. Better designs combine minimization, customer-controlled context, narrow signals, prospective escalation, and published performance evidence.

Model evaluation and access

Production traces reveal failures, regressions, and attacks. ZDR removes that evidence unless customers share selected examples, which improves consent but biases the sample.

Security researchers, drug developers, lawyers, and evaluators may refuse proprietary tasks without ZDR. A provider that stores less may see fewer incidents yet receive more realistic workloads.

Competition and a two-tier frontier

Mandatory retention can steer buyers to another lab, cloud route, older model, or self-hosted weights. It can create two tiers: customers accepting a safety window get the strongest model, while stricter buyers accept less capability. Meanwhile, ZDR approval can leave consumers with weaker privacy.

Consumer temporary chat is not the answer. It usually changes history and training behavior and schedules deletion; it is not a negotiated API control. ZDR remains largely an enterprise privilege.

The strongest risks and controversies

Retention turns safety infrastructure into a target

Thirty days of prompts can include credentials, patient histories, legal strategy, merger plans, vulnerability reports, sources, and research. Centralizing them raises breach, insider, cross-tenant, subpoena, discovery, and accidental-exposure risk. Safety data can also drift into product, benchmarking, enforcement, or training uses unless forbidden.

A clinician, lawyer, whistleblower, dissident, or security researcher may avoid a model because a reviewer could see a false-positive flag.

Non-retention can become anti-forensics

A malicious operator can use ZDR to frustrate correlation and leave no provider evidence. Customers may also fail to keep records, then request a vanished response. Appeals suffer when a provider suspends access on a narrow signal without explanatory content.

ZDR customers need risk-tiered logs, abuse detection, incident procedures, and lawful reporting. Records can be redacted, encrypted, access-controlled, and short-lived, but they still need an owner.

“Zero” is hard to verify

Clients cannot see deletion across caches, replicas, traces, crash dumps, support copies, and subprocessors. A vendor can avoid readable prompt logs while keeping linked scores or encrypted state. The label must declare covered bytes and drift detection.

Buyers need machine-readable signals, independent testing, change logs, scoped audits, and a common data taxonomy. A response attestation still needs technical evidence and contractual remedy.

Safety evidence is thin

Anthropic has published a coherent reason for retention. OpenAI has published a coherent alternative. Neither has released the comparative measurement buyers need: detection rate by threat type, false-positive and false-negative rates, amount of raw content required, time-to-detection, reviewer exposure, customer appeal outcomes, and performance under deliberate evasion.

Metrics can be aggregated, delayed, or independently audited without exposing every defense. Without them, buyers choose between institutional claims.

Provider power and due process

Providers define prohibited behavior, design classifiers, receive signals, and control access. False positives can interrupt legitimate cyber, biology, journalism, or civil-society work. Both designs need notice, bounded emergency suspension, customer logs, appeals, and access records.

Legal and compliance collisions

This section is general information, not legal advice. Role, jurisdiction, contract, and use case can change the result.

The GDPR is often flattened into “delete more.” Article 5 requires purpose limitation, minimization, and storage limitation, while erasure has exceptions for legal obligations and claims. ZDR can support minimization, but indiscriminate deletion can frustrate another duty. The official text demands a purpose and schedule, not universal zero.

The EU AI Act can require logs. Article 12 requires high-risk systems to support event recording; Articles 19 and 26 require providers and deployers to keep logs under their control for at least six months unless other law differs. This can coexist with provider-side ZDR when the deployer keeps the governed record. The role-specific text makes custody decisive.

HIPAA does not certify a model because it has ZDR. HHS says a cloud provider handling ePHI is generally a business associate even without the decryption key. A covered entity still needs a BAA, eligible services, risk analysis, safeguards, availability, and lifecycle terms. HHS guidance makes ZDR one control in a larger arrangement.

Financial rules likewise require specified books and communications. FINRA and SEC rules determine scope. A support answer may be ephemeral; regulated advice may be a required record. The usual answer is a supervised customer archive, not an ungoverned provider log.

Litigation can override ordinary deletion. In May 2025, a federal magistrate judge ordered OpenAI to preserve output logs that otherwise would have been deleted in the New York Times copyright litigation. The forward-looking obligation ended on September 26, 2025, but OpenAI says a limited historical April–September set remains under legal hold. The court’s preservation order and OpenAI’s dated update also show a practical distinction: documented ZDR API data was excluded because it had not been stored.

Apparent CSAM is the clearest statutory exception. Under 18 U.S.C. § 2258A, a covered provider that obtains actual knowledge of specified apparent violations has reporting duties, and submitted content is preserved for one year. The law does not impose a general duty to scan every user, but a ZDR claim that ignores known flagged images would be incomplete.

Privilege, trade secrets, export controls, government contracts, localization, and law-enforcement process add constraints. Ask which party retains which record, for what purpose and period, in what region, under whose keys and access rules.

Four cases that expose the trade

1. OpenAI versus Anthropic, 2026

OpenAI proposes customer-controlled or customer-keyed context that emits a narrow safety signal. Anthropic requires a readable 30-day safety window for two named frontier models, with controlled human review. OpenAI’s design reduces provider custody but is not yet technically published. Anthropic’s design is operational and documented but increases exposure. The next decisive evidence is comparative: can the private design match campaign detection without handing raw content to the provider?

2. The New York Times preservation order

The 2025 order briefly made deletion promises collide with civil discovery. It did not turn all historical OpenAI data into an accessible Times archive; OpenAI said it segregated preserved material under legal controls. It also did not affect ChatGPT Enterprise, Edu, or qualifying ZDR endpoints as described by OpenAI. The episode’s lesson is narrower and more durable: a deletion schedule is subject to legal process, but a provider cannot preserve content it never collected.

3. Grok Build and over-collection

SpaceX acquired xAI on February 2, 2026; current enterprise terms identify SpaceXAI LLC, so this article uses SpaceXAI/xAI on first reference. In July, researcher cereblab’s wire-level analysis of Grok Build 0.2.93 found that the consumer coding agent uploaded entire tracked Git repositories and history through a storage channel, including files it had been told not to read. One 12 GB test captured 5.10 GiB of storage traffic versus about 192 KB of model traffic. The researcher proved transmission and accepted storage, not training, employee access, or retention for enterprise ZDR customers.

Uploads stopped after a server-side flag change. SpaceXAI said ZDR teams never had trace or code retained; Elon Musk said prior uploads would be deleted. Reporting documented the response, but public evidence does not establish user count or verify deletion. Current docs expose a per-response ZDR header and say ZDR inference content is not persisted while local history remains in ~/.grok/.

The case separates three questions that privacy marketing often merges: what left the device, how long it remained, and whether it trained a model.

4. A hospital needs less provider data and more internal evidence

Consider a clinical summarizer processing PHI. The hospital may choose a BAA-covered, ZDR-eligible stateless endpoint so the model provider keeps no note. Inside its own environment, it may still need the source record, final clinician-approved summary, model/version, access audit, and correction history. It should avoid storing every intermediate prompt if that serves no care or audit purpose.

ZDR places the durable record with the organization holding the clinical context, duty, and patient relationship. The same split custody can suit legal, finance, defense, and pharmaceutical work after fact-specific review.

How to evaluate an AI vendor’s ZDR claim

1. Identify the legal entity, product, model, endpoint, region, and cloud route.
2. Obtain the contract, DPA or BAA, retention amendment, subprocessor list, and incident-notification terms.
3. Map prompts, outputs, files, caches, agent state, tools, support data, and customer telemetry.
4. Confirm whether ZDR is default, opt-in, approved, paid, revocable, or unavailable on selected models.
5. Test the runtime signal where one exists and fail closed when ZDR is inactive.
6. Block incompatible endpoints and unapproved model upgrades with IAM or an API gateway.
7. Define the customer record needed for safety, audit, debugging, recovery, and appeals.
8. Redact secrets and personal data before inference; ZDR is not a substitute for minimization.
9. Sandbox tool-using agents and isolate credentials, egress, repositories, and production systems.
10. Validate configuration and deletion controls with audit evidence, not marketing language.
11. Write incident-response, suspension, appeal, and legal-hold procedures before an event.
12. Recheck the policy after every provider, model, endpoint, feature, or routing change.

Questions to send the vendor

1. Which exact data classes are covered, and which metadata or derived signals survive?
2. Is any content written to disk, cache, trace, crash report, backup, or support system?
3. What are the maximum lifetimes for RAM, KV caches, ephemeral disks, and encrypted state?
4. Which models, endpoints, regions, tools, and media types are excluded?
5. Is ZDR enforced by organization, project, workspace, team, key, model, or request?
6. Can we verify it in every response and make a mismatch fail closed?
7. Who can access content, under which trigger, and is that access tamper-evidently logged?
8. Can you revoke ZDR or make a model ineligible? What notice and migration period apply?
9. What legal, CSAM, sanctions, abuse, or severe-risk exceptions override normal handling?
10. Are safety signals linkable to our organization, account, person, or prior requests?
11. What happens to files, batches, agents, stored responses, containers, search, and MCP data?
12. Which subprocessors receive content, and do our controls follow it?
13. How do you test deletion and include the control in independent assurance reports?
14. How will you notify us before policy, routing, model, or feature behavior changes?
15. What evidence can support an appeal or incident when you no longer hold the content?

Scenario guide

Scenario	Provider-side ZDR likely desirable?	Customer-side record still needed	Largest residual risk
Public support bot	Often, but not always necessary	Ticket, consent, final answer, escalation and abuse events	Users submit secrets; third-party CRM stores the exchange
Proprietary coding assistant	Strongly desirable	Approved repository access, actions, diffs, model/version, security alerts	Agent or local telemetry collects more code than expected
Clinical summarization with PHI	Usually desirable under a suitable BAA and eligible configuration	Source chart, clinician-approved result, access and correction history	ZDR is mistaken for complete HIPAA compliance
Law-firm document analysis	Strongly desirable	Matter-controlled work product, access, final cited output	Privilege waiver, tool leakage, or provider review of a false flag
Financial fraud investigation	Mixed	Case evidence, approvals, communications, model/version, decision trail	ZDR deletes records a regulator or litigant later requires
Frontier cyber or bio research	Depends on governance maturity	Experiment plan, approvals, isolated logs, alerts, review and appeal evidence	Provider blind spot under ZDR or exposure of legitimate sensitive research under retention

No row is a compliance conclusion. A public bot with no personal data may value debugging over ZDR; a security lab may need both strict provider non-retention and deep customer-side monitoring.

What happens next

OpenAI’s promised September paper is the immediate test. It should define the threat model, protected or cryptographic design, linkage, keys, signals, failure behavior, insider resistance, isolation, audits, and measured safety performance. It should also map Eyes Off, Safety Retention, caching, cloud routes, and legal exceptions.

Anthropic should publish detection lift and privacy cost: which threats require raw content, how often context changes an outcome, how many flags reach people, and how alternatives perform. All providers should publish versioned endpoint matrices and machine-readable state.

Regulators need not mandate one storage design. They can require truthful scope, change notice, evidence, redress, security, and role-specific records. Standards can define content, state, cache, signal, and metadata separately.

The practical end state is likely layered. Raw content stays with the customer; the provider receives bounded safety evidence; a customer-keyed store supports approved longitudinal analysis; targeted retention begins only after a declared trigger; and each party keeps the minimum record for its own duty. That design still has risks. It is more credible than pretending privacy and observability share one slider.

FAQ

What is zero data retention in AI?

Zero Data Retention generally means an AI provider processes covered prompts and outputs without writing them to durable storage after the request. The word “covered” matters: the promise may apply only to certain enterprise accounts, models, endpoints, and configurations. Usage metadata, derived safety signals, customer logs, third-party tools, or legally preserved material can remain. Buyers should read the endpoint matrix and contract, not infer scope from the label.

Is ZDR the same as “your data is not used for training”?

No. A no-training policy limits one use of data; it does not say whether prompts are logged, retained for abuse review, inspected after a flag, or stored as application state. OpenAI, Anthropic, SpaceXAI, Cohere, and Mistral all document settings where commercial data is not used for training but may still be retained. ZDR concerns persistence, while training opt-out concerns purpose. A customer may need both.

Does OpenAI offer ZDR for ChatGPT or only eligible API customers?

OpenAI’s documented ZDR control is for eligible, approved API organizations and projects, with endpoint limits. ChatGPT Enterprise and Edu have administrative retention controls, but those should not be described as the same API ZDR program without an applicable agreement. Consumer Temporary Chat does not appear in history or train models and is scheduled for deletion, but it is not equivalent to an enterprise ZDR amendment.

Why does Anthropic retain data for some frontier models?

Anthropic says Claude Mythos 5 and Fable 5 create elevated cyber, biological, and agentic risks whose misuse may appear only across many requests. It therefore requires at least 30 days of prompts and outputs for those Covered Models on every platform. Other Claude models can remain under existing ZDR settings. Anthropic has published its reasoning and access controls, but not enough comparative metrics to prove that raw 30-day retention is the least intrusive effective design.

Does ZDR mean data never leaves my device or network?

No. A cloud API must receive the prompt to run inference. ZDR normally governs what the provider keeps after processing, not whether data crosses the network. A local agent may also send files to tools, search providers, MCP servers, or observability systems. If data must never leave a controlled network, assess on-premises or isolated private deployment and audit the entire path, including updates, telemetry, and support channels.

Can an AI provider detect abuse without storing prompts?

It can detect some abuse synchronously with per-request classifiers and retain narrow signals rather than raw content. Cross-request detection is harder. OpenAI says its Private Safety Processing can analyze related interactions while content remains customer-controlled or customer-keyed, but the system is only in early testing and its technical paper is pending. Whether it matches raw-log detection across serious threat classes remains an open empirical question.

Does ZDR automatically make an AI service HIPAA- or GDPR-compliant?

No. HIPAA can require a BAA, eligible services, risk analysis, safeguards, access, availability, and breach procedures. GDPR requires a lawful basis, transparency, minimization, security, rights handling, processor terms, and purpose-bound retention. ZDR may reduce stored content and exposure, but it does not settle every duty. Some deployments must retain a customer-controlled record. Obtain use-case-specific legal and security review.

What AI features usually stop working under ZDR?

Features that depend on server-side state are the usual casualties: stored conversation history, response retrieval, files, vector stores, agents, batches, delayed jobs, long-lived caches, hosted media, and some code-execution workflows. Providers differ. Some block the feature; others allow it while warning that its data falls outside ZDR. A safe deployment uses an allowlist and fails closed instead of trusting every new feature to inherit the setting.

Is self-hosting an open-weight model safer than using a ZDR API?

It can reduce third-party custody and keep inference inside a controlled environment. It can also be less safe if the deployer misconfigures logs, backups, access, egress, model servers, or tools. Open weights do not create a retention policy. The customer becomes responsible for security updates, abuse controls, incident response, deletion, and legal reporting. Compare actual architectures and operational maturity, not “open” against “closed” as labels.

How can a company verify that ZDR is really enabled?

Start with a signed contract and current endpoint matrix. Add a runtime check where supported, such as SpaceXAI’s x-zero-data-retention response header, and reject mismatches. Pin models and endpoints through IAM or a gateway. Review console settings, cloud policy, subprocessors, caches, and stateful features. Ask for independent assurance evidence and notification before changes. No client check alone proves deletion across every backend copy.

Can a court order override an AI company’s deletion policy?

Yes. A valid litigation hold, subpoena, or statutory duty can require a provider to preserve material it possesses despite its ordinary schedule. The 2025 New York Times preservation order temporarily required OpenAI to keep output logs that otherwise would have been deleted. The forward-looking order later ended. Genuine ZDR changes the practical result: content never durably collected cannot be recovered, which is why customers must preserve records they are legally required to keep.

What metadata can remain even when prompts and outputs are not retained?

Providers may keep account and organization IDs, timestamps, IP addresses, request IDs, model versions, token counts, latency, billing records, rate-limit events, administrative actions, and classifier or policy signals. The exact list and linkability vary. Metadata can still reveal sensitive patterns, especially when tied to a person or project. Ask what survives, how long, for what purpose, who can access it, and whether it can be joined to other records.

Methodology and limitations

Kingy.ai reviewed current official product documentation, contracts and policy pages from OpenAI, Anthropic, SpaceXAI/xAI, Google Cloud, Microsoft, AWS, Cohere, Mistral, Fireworks, and Meta; primary EU and U.S. legal sources; NIST and HHS guidance; the 2025 preservation order; the original Grok Build researcher’s evidence; and independent reporting. Research closed August 19, 2026, at 2:17 p.m. PDT.

We did not inspect provider infrastructure, execute enterprise contracts, interview vendors, or reproduce the Grok Build test. Vendor architecture and deletion statements are attributed claims unless backed by public technical evidence. OpenAI’s Private Safety Processing is a preview, not a generally deployed or independently validated system. Policies can change after publication.

Primary source list

• OpenAI: Offering Zero Data Retention for frontier models
• OpenAI API: Data controls
• Anthropic: Covered Model retention practices
• Anthropic: API and data retention
• SpaceXAI: API Security and ZDR
• Google Cloud: Zero Data Retention
• Microsoft Foundry: Data privacy
• AWS Bedrock: Data retention
• Cohere: Enterprise Data Commitments
• Mistral: Zero Data Retention
• Fireworks: Zero Data Retention
• EU GDPR, EU AI Act, and 18 U.S.C. § 2258A

Final verdict

Organizations handling source code, health data, legal work, defense information, financial records, sensitive research, or vulnerable users should demand provider-side ZDR when they can own the missing safety and audit functions. Organizations facing mandatory records, weak internal monitoring, high abuse exposure, or difficult incident reconstruction may need controlled retention instead, ideally under their own keys and governance.

Neither choice fixes over-collection before inference, unsafe tools, excessive customer logs, bad access controls, false safety flags, or unclear legal duties. ZDR should be treated as a verifiable system property and a contractual allocation of responsibility, not a binary privacy badge. Buyers should demand exact data definitions, endpoint and model matrices, runtime proof, change notice, scoped exceptions, access logs, deletion evidence, published safety metrics, and independent audits. “Zero” deserves engineering evidence equal to the confidence of the word.