Zero data retention

Zero data retention (ZDR) is a contractual configuration for LLM APIs under which the provider does not store a customer's inputs and outputs at rest after the response is returned, a commitment scoped to stateless API surfaces and subject to safety carve-outs, including frontier models a provider can designate as requiring a minimum retention window.

How it works

ZDR is granted by agreement with the provider rather than self-served, and once in force it applies per surface, not per account. Requests to eligible stateless endpoints are processed and their inputs and outputs are not stored at rest after the response returns, while trust-and-safety machinery keeps its own records: classifier outputs, and content flagged for violation review, persist on separate clocks even under ZDR. Stateful capabilities such as file storage, batch processing, and server-side agent state retain data by design, so they typically sit outside the agreement or under separate feature-specific terms. Providers additionally carve out their most capable models: a designated frontier model can require a minimum retention window for safety review, making ZDR unavailable for it, and requests from a ZDR-configured organization fail with a validation error until the retention posture changes. Retention can be scoped per workspace, so one organization can run a mandated-retention workspace for frontier-model traffic beside ZDR workspaces for everything else. Other vendors express the same shape under different names, a reserved safety-retention right on the most capable models, or platform-side modified abuse monitoring, and cloud platforms reselling a model set their own retention terms.

Why it matters

Retention tier is a compliance boundary, not a performance knob: for an organization holding a data-processing agreement, a regulated-data commitment, or a customer promise about data handling, ZDR is often exactly the control its auditors ask for, and the tier a workload runs under is one of the controls that determine which models and features it may use. The carve-outs matter more than the headline, because an agentic system using files, batches, or server-side state is partly outside ZDR even when the organization nominally has it, so the agreement's coverage map, not its existence, is the real artifact. The frontier-model exception changes the upgrade calculus: adopting a newly designated model stops being an engineering decision and becomes a legal review with an engineering step at the end. ZDR is also narrower than the privacy outcomes it gets credited with: it governs provider-side storage of prompts and outputs. Training-data opt-out is a separate protection that typically applies by default, and data residency answers where data is processed rather than how long it persists. Conflating the three is how a team comes to believe it bought more privacy than its contract delivers.

In practice

An organization with a ZDR agreement points a workload at a newly released frontier model, and every request fails with a validation error because the model mandates a minimum retention window the organization's configuration forbids. The unblock is not in the codebase: the owner of the data-handling commitments approves a retention change scoped to one workspace, that workspace carries the new model's traffic under the mandated window, and the remaining workspaces keep ZDR. The engineering change was a configuration detail; the actual work was the compliance decision and knowing in advance who makes it. Teams that discover this seam on launch day lose the time between the error and the lawyer.

Practical considerations

Read eligibility per feature rather than per account, since stateless endpoints, batch surfaces, file stores, and managed agent state each carry their own retention behavior under the same agreement. A conflict between a workload's retention configuration and a model's requirement surfaces as a hard validation error rather than a silent downgrade, so route on that error deliberately. Where the provider's controls allow it, isolate mandated-retention traffic in its own workspace so the rest of the organization's ZDR posture survives a single model adoption. Treat safety-side records, flagged-content review and classifier outputs, as retained regardless of ZDR, and source that detail from the provider's retention docs during compliance review rather than inferring it from the term's name. The same model can carry different retention terms on different cloud platforms, so a multi-platform deployment audits each platform's policy separately. Revisit the posture at every model adoption, since a provider designating its newest model for mandatory retention changes what your agreement permits without anything changing on your side.

Defined by Ready Solutions AI