What Is Zero Data Retention (ZDR)?

Zero data retention (ZDR) is an arrangement where an AI provider processes your request and does not keep your prompts and outputs afterward. It is a contract and account setting, not a default for most users.

It answers a narrow question: after I send data to a model API, how long does the provider keep a copy?

What providers keep by default

Defaults vary, so read the current terms. As one example, OpenAI’s enterprise privacy page (updated 8 January 2026) says it does not train on business data by default. It also says it may retain API inputs and outputs for up to 30 days to provide the services and identify abuse, unless it must keep them longer by law. It adds that customers can request ZDR for eligible endpoints if they have a qualifying use case.

OpenAI’s data controls documentation explains the mechanism. Abuse monitoring logs exist for API usage and are kept for up to 30 days by default. Eligible customers can have content excluded from those logs by getting approved for Zero Data Retention or Modified Abuse Monitoring. The same page lists endpoints that are not eligible. Stateful features that store data for you, such as threads, files, vector stores, and batches, appear on that list.

That last point is the catch. ZDR usually covers stateless calls. Any feature that stores data for you, by design, sits outside it.

What ZDR does not mean

Not “the provider never sees your data.” The model still processes it in memory.
Not a blanket guarantee across a vendor’s products. Scope is per endpoint and per agreement.
Not automatic. It is typically approval-gated and tied to a qualifying use case.
Not a replacement for your own controls. Your logs, vector stores, and caches are still yours to secure.
Not necessarily total. Terms may carve out legal holds or abuse-related retention. Read the exceptions.

Why it matters for production agents

Agents move data through many places. A prompt may include customer records pulled by a RAG system. A long context window can carry an entire contract. If the provider retains that text for 30 days, your retention policy has a hole.

Regulation points the same way. The GDPR’s storage limitation principle says personal data should be kept in an identifiable form for no longer than necessary for the purposes of processing. Its data minimisation principle says data should be adequate, relevant, and limited to what is necessary. A provider that retains prompts adds another copy of personal data you must account for. ZDR shrinks that footprint.

The logging tension

There is a trade-off that people miss. ZDR means the provider keeps no copy. But security guidance says you should keep your own. The UK NCSC recommends logging enough to spot suspicious activity, including full model inputs and outputs, tool use, and API calls.

My view: those two are compatible. You choose where the record lives. Keep the logs in your own environment, under your retention schedule and access controls, and let the provider keep nothing. You get investigation ability without a second copy at a third party.

How to check it

Get it in writing. A line in a sales deck is not an agreement.
List every endpoint you use. Check each against the eligible list. Include embeddings, files, batch, and any “assistant” or memory features.
Check subprocessors and cloud wrappers. If you reach a model through a cloud marketplace, the cloud provider’s terms apply too.
Test your own stack. Find where prompts are logged by your gateway, observability tool, or error tracker.
Set a review date. Terms change.

A short example

Say a law-firm team builds a contract-review agent. The model call is stateless, so it qualifies for ZDR. But the first design also used the provider’s file storage and thread features to keep conversation history. Those were outside the ZDR scope. The team moved history into their own database and stopped using provider-side storage. Now the provider keeps no copies, and the team controls retention.

Common mistakes

Assuming “we don’t train on your data” means “we don’t store your data.”
Enabling ZDR for one endpoint and using another that stores.
Forgetting your own logging copies.
Treating ZDR as a compliance finish line.
Not noticing when a vendor adds a stateful feature to an existing workflow.

Questions to ask a provider

Which endpoints and features does ZDR cover, in writing?
What is retained anyway, such as abuse or safety data, and for how long?
Does the agreement apply when we call the model through a cloud marketplace?
Which stateful features are excluded?
How do we verify the setting is active for our organization?
What notice will we get if terms change?

Put the answers in your vendor file. Auditors and customers will ask.

Data sovereignty covers where data lives and who has legal reach over it. Shadow AI is how data reaches providers with no agreement at all. For deployment options, see data sovereignty for AI agents and open source vs commercial LLMs.