What is Zero Data Retention?

The moment a business starts sending real work through a language model, one question arrives before any other: where does the prompt go? For a people business the question has teeth, because prompts are rarely abstract. They carry candidate CVs, client emails, performance notes, the ordinary personal data of the trade. Zero data retention is the strongest common answer a model provider can give, and it is a genuinely strong one. It is also narrower than the comfort it produces, and the gap between the two is where trouble lives.

What the promise actually covers

Under a zero data retention arrangement, the provider processes your request, returns the response, and stores neither. Nothing persists on the provider’s side once the request is served. That matters because the alternative is quietly significant: a provider that retains prompts becomes a long-term holder of whatever your people paste into the tool, and under GDPR that shapes your processor relationships, your transfer analysis and your breach exposure. ZDR collapses the provider’s copy of your data down to the lifetime of the request itself. It is usually a negotiated or enterprise-tier commitment rather than the consumer default, which is the first thing to check: the promise on the pricing page is not always the promise on your tier. (This entry is a practical explainer, not legal advice.)

What it does not cover

Three gaps recur. First, the provider’s operational edges: some agreements carve out time-limited logs, abuse monitoring or safety review, and a carve-out that allows human review of flagged content is materially different from a system nobody ever sees. Read the carve-outs, not the headline. Second, training: not storing your data and not learning from it are separate commitments, and each needs its own sentence in the contract. Third, and largest, the application layer. The product that calls the model, whether built or bought, typically stores the prompt, the output, the conversation history and the source documents behind them, and none of that is touched by the provider’s promise. Zero data retention is a promise about the model provider’s memory, not your system’s: the application layer keeps whatever it was built to keep. The application layer is where data minimisation and your own retention schedule do the real work.

The questions to ask a vendor

• Does zero data retention apply to our tier and our contract, or to a different one?
• What exactly does it cover: prompts, outputs, embeddings, uploaded files, fine-tuned artefacts?
• What sits outside it: operational logs, abuse monitoring, safety review, and for how long?
• Is our data used to train or improve any model, and where is that written down?
• Who actually serves the model? A subprocessor chain can sit behind the product brand, and each link needs the same answers.
• What does the application itself store: prompts, outputs, source documents, conversation history? For how long, and how is it deleted?

The last question is the one most vendor conversations never reach, and it is usually where most of the data lives. The answers belong in the contract and the data processing agreement, not in a reassuring email.

One concrete example

Clearly illustrative, with no customer implied. A recruitment firm pilots an assistant that summarises candidate CVs. The vendor’s site says “we never store your data”, and the claim turns out to be true of exactly one layer: the model provider behind the product offers zero data retention on its API. Probed, the picture widens. The assistant itself stores every uploaded CV and every summary in its own database by default, and the provider agreement carves out a time-limited abuse-monitoring log. The firm does not walk away; it configures the application to keep summaries only while the vacancy is open, gets the no-training commitment in writing, and records in its processing documentation which layer holds what. The promise was real. It just covered one layer of three, and the firm now knows which.

Zero data retention and decision intelligence

Choosing an AI vendor is a decision about where your data will live, and decision intelligence would treat the vendor’s claims the way it treats any evidence: graded, not just collected. On the evidence hierarchy, a marketing page is a stated claim, a signed contract clause is stronger, and a configuration you have verified in your own tenant is stronger still; a retention decision that rests on the first should not feel like one that rests on the last. Control over the model relationship is also why bring your own AI exists as a pattern: ONX lets a client bring their own model key, so the retention terms that govern the model are terms the client has already chosen and negotiated, rather than an extra relationship taken on trust.