Zero data retention

Governance

A commitment that inputs and outputs are not stored after a request completes.

What is zero data retention?

Zero data retention is a commitment that the inputs and outputs of a request are not stored once the request completes. It governs the model provider's side of the boundary, where content exists only for the duration of inference. The commitment is a configuration with contractual backing, which is what makes it verifiable rather than merely reassuring.

Also called: ZDR

Why zero retention answers only half of the data question

Zero retention is frequently read as a complete answer to data protection, when it addresses one specific portion of the problem. It governs what the provider keeps, and says nothing about the traces and evaluation stores a deploying organisation maintains on its own side. Those are usually where content actually accumulates, under a retention policy nobody has reviewed. A procurement team confirming zero retention upstream while never examining its own logging has moved the exposure rather than removed it.

  • The commitment removes a class of exposure at the provider's end of the path.
  • Abuse monitoring is the usual exception, so the terms have to be read closely.
  • Retention on the deploying side is where content accumulates in practice.
  • A verifiable setting is stronger evidence than an assurance in a proposal.

How zero data retention works

  • The retention setting is applied at the endpoint and recorded in the configuration.
  • Contractual terms confirming the commitment are obtained before the first request.
  • Exceptions such as abuse monitoring are identified and assessed explicitly.
  • The organisation's own logging and tracing retention is set deliberately by policy.
  • Evaluation and monitoring stores are brought within the same retention schedule.
  • The configuration is reverified after every provider or endpoint change.

How zero data retention is evaluated

The commitment covers one end of the path, so verification has to examine both. Confirm the following across the whole request path:

  • retention setting at the endpoint, confirmed from the provider's configuration
  • contractual term covering retention and any stated exception
  • retention period on prompt content inside the organisation's own traces
  • content held in evaluation and monitoring stores, with its retention
  • deletion evidence for content captured before the setting was applied

Limitations, risks and common failure modes

  • Zero retention is agreed upstream while internal traces keep prompts indefinitely.
  • An abuse monitoring exception retains content the organisation assumed was discarded.
  • A fallback provider is called during an outage under entirely different terms.
  • The setting is applied to one endpoint and omitted on another in the same deployment.
  • Content captured before the commitment was in force is never deleted.

All 315 terms