Zero Data Retention: What Every AI Provider Actually Promises You

A security questionnaire lands in your inbox three weeks before the deal closes. Question 14 asks whether your AI provider retains customer data, and for how long. You check the provider's trust page, see the words "zero data retention," and answer no.

That answer is usually wrong, and the reason it is wrong has nothing to do with the provider being dishonest.

Zero data retention is not a setting. It is a contract term with a scope, and the scope has holes in it that the marketing page does not describe. I spent a day reading the actual retention documentation for six major providers, and the gap between what founders think ZDR means and what it contractually covers is wide enough to fail an enterprise review.

Verified as of 8 September 2026. Every claim below is sourced to the provider's own documentation, linked inline. Provider terms change without announcement, so check the source before you rely on any of this in a contract.

Retention means four different things, and conflating them is the error

When a questionnaire asks about retention, it is collapsing four separate mechanisms into one word. Every provider treats them differently. Answering for one and assuming it covers the others is how a confident answer becomes a false one.

Training use. Whether your data improves the provider's models. OpenAI states that data sent to the OpenAI API is not used to train or improve OpenAI models unless you opt in. That is the default most founders assume is universal. It is not. Mistral trains on API data by default and requires you to opt out through an admin setting. Cohere does the same, with a Data Controls toggle.

Abuse monitoring retention. Data held so the provider can investigate misuse. This is the one that surprises people, because it survives most ZDR arrangements. OpenAI generates abuse monitoring logs for all API feature usage and retains them for up to 30 days. Anthropic goes further: under its retention documentation, flagged sessions can be held for up to two years regardless of your arrangement, including under ZDR and including under a HIPAA agreement.

Operational and application-state logging. The data a feature needs to function at all. Anthropic publishes the clearest breakdown here, and it is worth reading closely because it shows that ZDR eligibility is decided per feature rather than per account. Batch jobs retain for 29 days. Code execution containers retain for 30. Files API content persists until you delete it. A cache diagnostic keeps a hash fingerprint rather than content.

Sub-processor retention. What the provider's own vendors keep. Both OpenAI and Anthropic publish sub-processor lists. Neither publishes a sub-processor retention period. This is the weakest-documented leg across every provider I checked, and it is the one your customer's security team is least likely to ask about and most likely to care about after an incident.

Nobody offers a zero data retention toggle

The common mental model is that ZDR is a switch in a settings page, the way a training opt-out often is. Across the six providers I checked, no one offers that for the standard API.

What exists instead falls into three tiers.

Sales-gated, available to anyone who asks. OpenAI describes ZDR as subject to prior approval and acceptance of additional requirements. Anthropic enables it per organization, which matters more than it sounds: a second org under the same account does not inherit it. Google's Gemini API takes applications per project and does not publish an approval timeline. Mistral requires a written request with a stated reason, reviewed case by case, and it can be denied.

Enterprise-tier gated. Cohere restricts ZDR to enterprise agreements and frames the request as something that reduces its ability to monitor for abuse, so approval comes with additional commitments from you.

Arbitrated by a third party even after you configure it correctly. This is the tier nobody expects, and AWS Bedrock is the example.

The Bedrock case, where your own setting is not the deciding vote

Bedrock does not express retention in days. It expresses it as one of four modes, ordered from least to most retention: none, default, aws_review, and provider_data_share. You set the mode at the account or project level.

The catch is in the model-level permissions. A model declares which modes it allows. If a model does not list none among its allowed modes, you cannot reach zero retention on that model no matter what your account is set to. For models that mandate aws_review, data is retained up to 30 days for internal human review, and getting an exception requires the model provider to agree, evaluated per account and per model.

Read that sequence again, because it describes a three-party negotiation. You want zero retention. AWS operates the platform. Anthropic, or whichever provider owns the weights, holds a veto. Setting store=false on the request does not override it.

The exclusion that would fail a security review

Anthropic designates some models as Covered Models, currently the Claude Fable and Mythos 5 and 5.1 families. Those models carry a 30-day retention requirement and cannot run under zero data retention at all unless Anthropic expressly authorizes it, even for a customer who already holds an org-wide ZDR arrangement.

Sit with the implication. An engineer on your team switches a model string in a config file, from a model that runs under your ZDR arrangement to one that does not. Nothing in the code review flags it. Nothing in the API response signals it. Your contractual data posture changed on a one-line diff, and the first time anyone notices is the next questionnaire, or the next audit.

Retention is not a property of your vendor relationship. It is a property of the specific model you called, on the specific surface you called it through, using the specific feature you invoked. Three of those can change without a procurement conversation.

Where the providers actually stand

All values checked 8 September 2026 against the sources linked above.

Provider	Trains on API data by default	How you obtain ZDR	The exclusion that matters most
OpenAI	No	Approval plus additional requirements	Safety retention override for severe-risk investigations
Anthropic	No	Sales, enabled per organization	Covered Models cannot run under ZDR at all
Google Gemini API	No on paid tiers. Free tier and AI Studio usage may be human reviewed	Application per project	Search and Maps grounding retain 30 days with no opt-out
Mistral	Yes	Written request with a stated reason, can be denied	Stateful services excluded categorically, including Agents and batch
Cohere	Yes	Enterprise agreement only	Usage metadata is never covered
AWS Bedrock	No	Mode setting, but only for models that permit it	Model provider can require human-review retention regardless

What to ask before you select, not after

The questionnaire arrives too late to change anything. These are the questions worth asking during vendor selection, when the answer can still influence the decision.

Ask which specific models are in scope for the retention arrangement, and whether that scope is stated in the contract or assumed. Anthropic's Covered Models carve-out is the reason this question exists.

Ask which features are excluded. Batch, file storage, code execution, agent frameworks, and caching are commonly outside the arrangement even when the base API is inside it.

Ask what abuse monitoring retains and for how long, separately from everything else. This is the question most likely to produce a number that contradicts the trust page summary.

Ask whether the arrangement covers a second organization or project under the same account. At Anthropic and Google, it does not automatically.

Ask what your provider's sub-processors retain. You will probably not get a satisfying answer. Getting a clear "we do not publish that" in writing is still better than assuming a number that does not exist.

The structural problem

Every provider on this list documents its retention behavior honestly. The documentation is public, detailed, and in several cases genuinely careful. Anthropic's per-feature eligibility table is better disclosure than most enterprise software ships.

The failure is not disclosure. It is that a buyer is asked a yes-or-no question about a mechanism with four independent dimensions, each of which varies by model, by feature, and by surface. The honest answer to "do you retain customer data" is a table, and the questionnaire has a checkbox.

If you are answering that question this quarter, the useful move is to stop answering it at the vendor level. Answer it for the specific model, on the specific surface, with the specific features you actually call. Then write down which of those four retention mechanisms you verified, and which you assumed.

Which of the four did you verify the last time you filled one of these out?