What Is Zero Data Retention, and Does Your Document Pipeline Actually Have It?

Zero data retention, usually shortened to ZDR, means the provider does not store your inputs or outputs at rest once the API response has been returned. Anthropic words it as not storing "customer prompts or responses at rest after the API response is returned". It is an account-level contractual arrangement rather than a per-request flag, and on most vendors a human has to approve it.

That definition is the easy part, and it is where almost every explanation of ZDR stops. The part that decides whether your document pipeline is actually covered is the scope, and the scope has a hole in it shaped exactly like a document pipeline.

ZDR is written for stateless inference

The arrangement assumes a particular shape of request: you send a prompt, the model returns an answer, nothing needs to persist. That describes a chatbot well. It describes document processing poorly, because a document pipeline usually uploads a file, references it, sometimes queues it in a batch, and each of those steps is a different endpoint governed by a different policy.

Anthropic's feature eligibility table makes the boundary unusually explicit. PDF support through the Messages API is ZDR eligible, with the note that eligibility "applies to PDFs sent inline through the Messages API, not through the Files API". The Files API row is marked "No", with the reason given as "files retained until explicitly deleted". Same document, same vendor, same account, two different retention outcomes, decided entirely by how the bytes reached the model.

Mistral draws the same line in a single sentence: ZDR "does not apply to stateful APIs or products, including agents, batch processing files, conversations, libraries, /v1/files, Vibe Work, and Chat". Notably, the "/v1/ocr" endpoint is on Mistral's supported list, which is genuinely useful and worth knowing. The file store sitting next to it is not. OpenAI's version of the same boundary is that assistants, threads and conversations are ineligible and retain data until deleted.

The question people mean to ask

Here is how this goes wrong in practice, and it is nobody's fault in particular. A security reviewer asks "does this vendor offer zero data retention". The honest answer is yes. The question they meant was "is our document pipeline running under zero data retention", and the honest answer to that one can be no, because the pipeline uploads before it reads.

Anthropic is refreshingly direct about the consequence. Using a feature marked "No" is not blocked, and the documentation says that "using one is a choice to step outside your ZDR arrangement for that specific data". Nothing errors. Nothing warns you. The arrangement simply does not apply to that call, and you find out when someone reads the table.

Where the vendor supports it, the practical fix is to send the document inline in the request body rather than uploading it first. On Anthropic that keeps a PDF inside both the ZDR and the HIPAA arrangement. It costs you the ability to reference the same file across many calls and it puts the whole document inside your request size limit, so it works for a ten page invoice and not for a four hundred page loan file. Where inlining is not viable, the upload needs its own entry in your risk register rather than an assumption.

The discount that costs you the arrangement

There is a second trap, and this one has a price tag. Batch processing is the standard way to cut the bill on a large document job: Mistral and Anthropic both discount batch by 50 percent, and OpenAI's batch tier roughly halves the rate too.

Batch is also excluded from ZDR. Anthropic marks it "No" with the reason "29-day retention; async storage required", which is inherent rather than a policy choice, since an asynchronous job has to be stored somewhere while it waits its turn. Mistral names batch processing files in its exclusion list. So the cheapest way to run a large extraction job is also the way that steps outside the zero retention arrangement, and the two facts are almost never presented together because pricing pages and trust pages are written by different teams inside the same company.

Price the job both ways before you commit. If the discount is worth more than the retention exposure for that document type, take it deliberately. If it is not, run the volume synchronously and put the real number in the business case rather than the batch number. Either answer is defensible; discovering the trade-off after the security review is the expensive outcome.

Some models cannot run under ZDR at all

Anthropic designates Claude Fable 5 and Claude Mythos 5 as Covered Models and states that they "require 30-day data retention; ZDR is therefore not available for either model". A ZDR organization that calls one gets a 400 error saying the organization or workspace "must have data retention enabled". There is a documented middle path: you can enable 30-day retention on a single workspace, unlocking those models there while every other workspace stays at zero.

The reason this belongs in a document processing discussion is upgrade risk. A model choice is not usually treated as a compliance decision, so a team that signed a ZDR arrangement in January and moved to a newer model in June can break its own arrangement without anyone filing a change request. Neither Mistral nor OpenAI publishes an equivalent model-level carve-out today, which is worth confirming in your own contract rather than assuming it holds.

Zero is not literally zero

Every ZDR arrangement in this market carries a legal and safety ceiling. Anthropic states that even with ZDR or HIPAA arrangements in place it may retain data where required by law or where content has been flagged by automated trust and safety systems, and that in that case it "may retain inputs and outputs for up to 2 years". OpenAI states that image and file inputs are scanned for CSAM content and may be retained "even if Zero Data Retention" is enabled.

This is not a reason to skip ZDR. It is a reason to write the ceiling into your risk register instead of a zero, because a control described to an auditor as absolute and then found to have a two year exception is a worse outcome than one described accurately from the start.

How the three vendors compare

Worth noting on the last row: not training on your data and not retaining your data are separate commitments, and vendors are much more forthcoming about the first. OpenAI states that API data "is not used to train or improve OpenAI models (unless you explicitly opt in)", a default in force since March 2023, while still retaining abuse monitoring logs for up to 30 days without ZDR. Both statements are true at once. The full comparison, with every quote and its source, is on zero data retention OCR.

What to ask before the security review

Trace the real call path rather than the marketing one, and ask which endpoint your document actually touches. Ask by model name, not just by vendor. Ask whether the arrangement survives the way you intend to run volume. Ask who has to approve it and how long that takes, because two of these three gate ZDR behind a human and that conversation should start before you write the integration. Ask what is retained regardless. And check whether it extends to a second account, because Anthropic states plainly that enablement "does not automatically extend to other organizations under the same account", so a sandbox organization and a production one are two arrangements.

Underneath all of it is a question that is really about your own systems rather than the vendor's: do you know where document data goes after extraction, and which downstream tables it lands in? Teams that have mapped the lineage of their data end to end answer a ZDR questionnaire in an afternoon. Teams that have not spend weeks discovering that the extracted fields were copied into three warehouses nobody listed, at which point the retention policy on the OCR endpoint was never the binding constraint.

All quotes here were read off the vendors' own documentation in July 2026. These policies change, so re-read the source before you rely on any of it contractually.