Auditing Whether You Actually Need Zero Data Retention

Zero data retention gets adopted the way encryption at rest gets adopted: it sounds like the responsible default, so nobody has to argue for it. That is the problem. It is a narrow control with a real price, and it is frequently bought instead of the control that was needed.

The position

Make zero data retention a hard requirement in exactly two situations: when a specific clause you can point to — in a customer contract, a sectoral rule, or a binding internal policy — requires it, or when the data genuinely cannot be reduced before it leaves your systems and the consequence of vendor-side persistence is unacceptable. Otherwise treat it as a preference: something you would like, that you will pay a bounded amount for, and that does not by itself veto a provider or block a migration.

The reason to be firm about this is that a requirement and a preference behave differently under pressure. A requirement is a constraint on the solution space — it removes providers, removes features, removes regions, and it does so before anyone has weighed what it removes. A preference gets traded against other things. Most teams have written down a requirement when they meant a preference, and the cost of that shows up months later as a capability they cannot use and cannot remember agreeing to give up.

The one risk it actually controls

Be precise about the threat model. Zero data retention reduces the window in which content you sent exists on somebody else’s infrastructure. That is worth something against a small set of scenarios: a breach at the provider exposing stored content, an insider at the provider reading it, a legal process served on the provider, and the risk that stored content is later used for a purpose you did not agree to.

Note what is not on that list. It does nothing about the content existing in transit or in the model’s context at inference time. It does nothing about your own logs, which are usually the larger exposure by volume and by number of people with access. It does nothing about a prompt injection reading data out of your retrieval index. And it does nothing about the far more common incident shape, which is your own application returning one customer’s data to another.

It is also worth being clear that no major privacy regime names zero data retention as a requirement. Processing by a processor under a written agreement, with defined purposes and defined retention, is the normal lawful arrangement. Zero retention is one way to reduce risk within that arrangement; it is a choice, not a compliance floor. Sectoral rules and your own customers’ contracts are the places where something stricter can genuinely be mandated, and those are citable — which is exactly the test.

The substitution error

The failure this page exists to name: a team adopts zero data retention and keeps sending raw personal data in prompts. The reasoning is that the provider no longer keeps it, so the exposure is closed. It is not. The data still left the building, still traversed a third party’s infrastructure, still appeared in memory on machines you do not control, and still — depending on the clause’s carve-outs — may be retained under an abuse-monitoring or legal-hold exception at precisely the moment something goes wrong.

The control that addresses “this data should not leave” is not to leave it. Redaction, tokenisation, field-level minimisation and simply not putting the customer record in the prompt are the controls that change what crosses the boundary. Retention terms change what happens on the far side of a boundary the data has already crossed. They are defence in depth behind minimisation, not a replacement for it, and a team that has one and not the other has bought the outer layer. What providers do and do not redact for you is the practical follow-on.

What it costs, in things you will miss

A requirement should be priced, and this one has four bills that arrive at different times.

• Debuggability. The provider cannot see what you sent, so “can you look at request X” has no answer, and every support interaction becomes a reproduction exercise using content you have to construct.
• Features. Anything stateful — stored conversations, server-side file indexes, batch pipelines, caching — is where carve-outs cluster. Losing caching in particular can move your unit cost by a large multiple on prompt-heavy workloads, and that cost is discovered after the decision, not during it.
• Provider and region choice. The stricter the term, the smaller the set of providers, models and regions that can serve you, and a small set is a routing constraint. Fewer viable destinations means a worse answer when your primary is degraded.
• Time. Negotiated terms take procurement cycles. Making one a launch blocker converts an engineering schedule into a legal one.

None of these argue against it. They argue that it should be traded deliberately, and that the trade is invisible if the requirement was never examined.

Five questions that settle it

1. What actually leaves? Take a week of real prompts — or a sample if the volume is large — and classify the fields present. Not what the design says goes in the prompt; what is in the prompt. Teams routinely find whole customer objects being serialised because it was easier than picking fields.
2. Can it be reduced? For each category, decide whether the model needs the value, a redacted placeholder, or nothing. If most of it can be reduced, the retention question shrinks to the residue, and the residue is usually small enough to argue about concretely.
3. Which clause requires it? Name the document, the section, and who is on the other side. “Our enterprise customers expect it” is a sales position, which is a legitimate reason to want it and a poor reason to call it a requirement. If no document says it, it is a preference.
4. Is it retention you care about, or training use? These are different terms and one is far cheaper to obtain. Read what you already have before negotiating for something stronger — the anatomy of the clause separates them.
5. What does it disable, in money? Estimate the cost with and without the features the term excludes, using your own traffic mix and your own current prices. A number makes the conversation different: “this term costs us this much per month” is a decision, “it feels safer” is not.

Do that audit and one of two things happens. Either you emerge with a citable requirement and a priced trade, which is a defensible position in front of anybody. Or you find you are protecting data that should not have been in the prompt, and the real work is upstream — in minimisation and in what you keep in your own logs, which is where most of the copies live anyway.