What "Zero Data Retention" Terms Mean and How They Differ

Zero data retention is not a defined term. It is a family of clauses that share a name, and two agreements using the phrase can differ on which data, which endpoints, which purpose and for how long.

The phrase is not standardised

There is no specification behind it and no certification that attests to it. It is a commercial commitment, drafted by the party making it, and the useful skill is reading one rather than collecting them. Two confusions cause most of the trouble.

The first is between retention and training use. These are separate promises. A commitment not to train on your data says nothing about whether it is stored; a commitment not to store it implies the first but is a much stronger claim. Most enterprise agreements have contained the no-training term for some time, and a team that reads its existing agreement carefully sometimes finds it already has what it thought it was migrating for.

The second is between content and metadata. No provider retains nothing: token counts, model identifiers, timestamps, account identifiers and error codes survive, because they are how you are billed and rate-limited. “Zero” always means zero of some defined class, and the definition of that class is the clause.

The dimensions it varies along

• Which data. Prompts and completions, certainly. But also uploaded files? Embedding inputs? Fine-tuning datasets? Tool call arguments and results? Images and audio? Ask for the list, in the clause, not in a sales email.
• Which endpoints and features. Some features are stateful by construction — anything that stores a conversation, a file index, a batch job or a cache. A zero-retention term usually carves these out or excludes the feature entirely, which means the term and the feature list are one decision, not two.
• Which purpose. Retention for training, for abuse monitoring, for service operation and for incident investigation are typically treated separately. A clause can eliminate one and leave the rest.
• For how long. “Zero” in practice often means “transiently, in memory, for the duration of the request”, and sometimes means “bounded to N days”. Both are defensible; they are not the same, and only one of them is what the phrase implies.
• Who is bound. The provider, or the provider and its subprocessors? If the model is hosted by a third party, or served through a cloud marketplace, there are at least two parties handling the content and possibly two agreements.
• Where. A retention term and a residency term are different, and a clause that says nothing is not retained still allows processing anywhere.
• Under what conditions it lapses. Nearly every such clause permits retention where required by law or where necessary to investigate a suspected violation. That is reasonable drafting, and it is also the mechanism by which the content you were told was never stored can exist.
• How it is switched on. Contract only, an organisation-level setting, a per-project configuration, or an allow-list applied to specific accounts. This determines whether a new project inherits it or silently does not.
• Notice of change. How much warning you get if the term or its carve-outs move, and whether that gives you a termination right. This is the dimension that interacts with the rest of the terms that change when you migrate.

Caching and abuse monitoring

Two carve-outs are common enough to deserve naming as clause types.

Prompt caching is retention. That is what a cache is: content held server-side so it does not have to be re-sent or re-processed. A cache with a bounded lifetime is a bounded retention window with a different name. So a zero-retention term either excludes caching, or defines a maximum cache lifetime and scope, or contradicts itself. Since caching is often the largest single lever on your cost model, this carve-out is where a compliance decision quietly becomes a budget decision — work out what the calls cost uncached before you treat the term as free.

Abuse monitoring is the other. Providers retain some content for a period so that a human can review suspected misuse, and that is often a regulatory or platform-policy obligation of theirs rather than a preference. A term that removes it usually does so through a separate approval with its own conditions — commonly that you accept responsibility for your own misuse detection. Ask what replaces the monitoring, because the answer is sometimes “you do” and that is an engineering commitment, not a signature.

What evidence you get that it is true

A term with no observable artefact cannot be audited, and an auditor will ask. Work out in advance which of these you will be able to produce: a configuration setting whose value you can screenshot or export; a field in an API response or an account API confirming the mode; a contractual assertion in the executed agreement; an independent report whose scope explicitly covers the retention control; or a documented data flow signed off by the provider. Ranked by how much weight they carry, those are roughly in reverse order — but a configuration flag you can export daily has the advantage of detecting the day it changes.

Ask specifically whether the control appears in the scope of any third-party audit report you are given. A report covering a provider’s general operations does not necessarily test the retention behaviour of a specific contractual mode, and the scope section is where that is decided.

What it costs you at exit

The tension nobody flags at signing: retention and portability point in opposite directions. If nothing is retained, there is nothing to export, which means your own logging is the only record of what was sent and returned — and if you built on the assumption that the provider held a copy, your audit trail has a hole exactly where the migration needs it.

It also removes the vendor’s ability to help you debug. “We have no record of that request” is the correct answer under a zero-retention term, and it is the answer to every support question that depends on content. Decide before you sign whether you are willing to pay that, and whether the answer is really yes for every workload or only for the regulated one — which is the argument auditing whether you need it at all takes up.