Zero Data Retention, explained

“Zero Data Retention” is one of the most-used and least-precise phrases in enterprise AI procurement. Vendors put it on a slide, buyers write it into a checklist, and everyone assumes it means the same thing. It doesn’t. Before you rely on it, it helps to separate what it can mean, how it is actually delivered in a contract, and where it quietly stops applying.

Three guarantees, often confused

Not trained on. Your data is excluded from model training. This is now common by default on enterprise and API tiers, but “by default” and “guaranteed in contract” are different things, and default settings can change with a future product update unless the exclusion is written into your agreement.

Not retained. Prompts and outputs are not stored after the request completes, or are stored only briefly for abuse monitoring. This is what “Zero Data Retention” should mean, but the window and scope vary by provider, by product tier, and sometimes by data type within the same product.

Not accessible. Even where data is briefly stored, who can see it, under what controls, and in which jurisdiction? A retention window of zero does not answer this question by itself.

What ZDR does and doesn’t cover

ZDR clauses typically govern the prompts and outputs passing through a specific, named product surface, usually an enterprise API or a defined business tier. They do not automatically extend to everything a vendor ships under the same brand. A file uploaded for OCR or run through a code-execution sandbox may pass through a separate subsystem with its own retention behavior. A third-party plugin or connector the model calls out to may retain data under its own, different terms. And a consumer-tier product bundled under the same company name is very often governed by an entirely different agreement, sometimes one not even eligible for ZDR. A contract that guarantees zero retention on the API says nothing about what happens when the same team pastes the same document into the free consumer app because it is faster to open.

How enterprise contracts actually deliver it

ZDR is rarely a self-serve checkbox for meaningful production usage. For most providers it is a term negotiated into an enterprise agreement or an approved business-tier API contract. For some categories of use (certain content types, certain regions), providers require a specific written application or approval before ZDR applies at all. Confirm exactly which product tier the ZDR clause attaches to. It is common for a firm to sign an enterprise agreement covering the chat interface, then route a separate integration through the API under different default terms without anyone noticing the gap until an audit asks about it.

Logging is not the same as retention

Even under a genuine ZDR agreement, some logging almost always continues: infrastructure logs (timestamps, request size, error codes), abuse and safety monitoring, often with a short retention window measured in days and sometimes triggering human review if a policy violation is flagged; and billing or usage metering. None of this is the same as retaining prompt content for reuse or training, but it means “zero” rarely means that literally nothing is ever written down anywhere. Ask specifically what is logged, separately from what is retained; vendors answer these as two different questions because they are two different systems internally.

When ZDR is necessary and when it’s overkill

For work touching regulated data, privileged communication, or anything a firm could not comfortably disclose to a regulator, a contractual zero-retention guarantee should be non-negotiable because the downside of getting it wrong is not symmetrical with the upside of skipping the paperwork. For lower-stakes internal work, such as brainstorming an agenda or drafting a generic outline, insisting on ZDR everywhere can slow procurement without buying meaningful protection, and it can rule out reasonable capabilities, like a provider using aggregate, de-identified signals to improve abuse detection. Match the requirement to the data classification of the task, not a blanket policy applied to every prompt regardless of content. A firm-wide usage policy that names which classification tiers require ZDR, rather than treating every prompt as equally sensitive, is easier to enforce and easier for staff to actually follow.

ZDR is a floor, not a substitute for the rest of governance

Even a fully contracted, verified zero-retention agreement does not answer questions ZDR was never designed to answer: whether the tool should have been given that document in the first place, whether the output was reviewed before it reached a client, or whether the vendor’s security posture is otherwise sound. Treat ZDR as one line item on a broader governance checklist alongside training exclusion, a signed DPA, data residency, and firm-level access controls, not as a single term that, once confirmed, closes the review. See AI without breaking client confidentiality for the fuller checklist ZDR sits inside.

What to require in writing before sending real data

• Is exclusion from training contractual, not just a settings toggle?
• What is the exact retention window, and does ZDR remove it entirely, or only reduce it?
• Where is data processed and stored geographically, and does that satisfy your residency requirements?
• Do logging, abuse-monitoring, or human-review processes create copies, and what is their retention window?
• Does ZDR still apply when using agents, tools, or connectors, or only to direct chat completions?
• What happens to data already sent if you switch plans or cancel?

Data handling is one of the first lenses in a Celadon AI Decision Sprint, and a key input to choosing a provider.