Zero Data Retention: What It Actually Means

“Zero data retention” is a claim about a system, and systems have more than one place to put a byte. Before you can judge the claim you need the map of places, because the claim is almost always about some of them rather than all of them.

What follows is engineering guidance, not legal advice. It is how to interrogate a retention claim technically; whether the result satisfies an obligation you are under is a question for whoever advises you on that obligation.

Where a copy can exist

Draw the request path before you read anybody’s terms. A prompt leaving your process passes through more hands than the two on the invoice:

  your app
     |  (1) your own logs, traces, error reports
     v
  your gateway / SDK layer
     |  (2) request logging, retry buffers, APM spans
     v
  edge / CDN / WAF in front of the API
     |  (3) access logs, request body sampling on error
     v
  provider API front door
     |  (4) abuse + safety classification pipeline
     v
  inference cluster
     |  (5) KV cache, batch buffers, crash dumps
     v
  provider storage
        (6) durable request/response records, backups

Six places. Point 1 and point 2 are yours, and in practice they are where most incidents actually start — a prompt containing a customer record is far more likely to end up in your own error tracker than in a provider’s training set. A retention claim from a vendor says nothing about them.

What ZDR usually covers

When a provider offers zero retention, the commitment is normally about point 6 and sometimes point 4: request and response content is not written to durable storage, and is not fed into pipelines that persist it. That is a real and valuable commitment. It is also narrower than the phrase sounds.

Point 5 is almost never covered explicitly and almost never needs to be: content necessarily exists in memory while the model is running, and “zero retention” has never meant otherwise. The question worth asking about point 5 is not whether the data is there but what happens on a crash — whether core dumps are captured, where they go, and how long they live. That is a real retention surface with a real answer, and it is rarely in the marketing page.

Metadata is the other systematic gap. Token counts, model name, timestamps, latency, account id and error codes are retained by essentially everyone, because billing and abuse prevention require it. Metadata is generally not the content — but if your prompts are per named individual and the metadata carries an identifier you control, the pattern of requests can itself be personal data. Decide that question deliberately rather than assuming it away.

The exceptions that are always there

• Legal hold. Every retention commitment yields to a binding legal order. This is not a loophole; a vendor that promised otherwise would be promising something it cannot deliver.
• Abuse investigation. Content flagged by a safety classifier commonly leaves the zero-retention path so a human can look at it. Ask specifically whether flagged content is exempt from the retention commitment, because this is the exception most likely to apply to you without your knowing.
• Backups and replication lag. If content is never written durably there is nothing to back up — but if zero retention is implemented as scheduled deletion rather than as non-persistence, backups are the difference between the two. Ask which implementation it is. “Deleted within 24 hours” and “never written” are different products.
• Sub-processors. A retention commitment binds the party making it. If that party forwards your request onward, the onward party is operating under its own terms unless the contract says otherwise.

Six questions that settle it

Send these, in writing, to a vendor rather than reading a page about it. The answers are short and the shape of the reply is itself informative.

• Is zero retention implemented as non-persistence, or as deletion on a timer? If a timer, what is the interval and does it apply to backups?
• Does content flagged by safety or abuse classification leave the zero-retention path? If so, what is retained and for how long?
• Which fields are retained regardless — and can we have the field list rather than the word “metadata”?
• Is zero retention account-wide, per-key, or per-request? If per-request, what happens on a request that omits the flag?
• Which sub-processors are in the path for the models we use, and does the retention commitment flow down to them contractually?
• How would we evidence this to an auditor — is there a report, a configuration we can read back, or only the contract?

Question four catches a real failure mode. Where zero retention is a per-request flag, every code path that forgets it silently opts back in, including the retry in your error handler and the one-off script somebody ran against production. If it can be set account-wide, set it account-wide.

The half you are responsible for

Points 1 through 3 are yours and no vendor commitment touches them. The list of things that routinely persist prompts inside your own estate is longer than people expect: application logs at debug level, exception trackers that attach request bodies, APM tracing that captures span attributes, HTTP client debug output, the queue you put requests on for retry, the conversation history table in your own database, and the analytics event that helpfully included the user message as a property.

Grep for your own request-logging call sites before you audit anyone else’s. A useful default is that prompt and completion bodies are never logged at all outside an explicitly gated debug mode, and that the gate is a deployment-time configuration rather than a code constant somebody can flip locally and forget.