Guides › Zero data retention

Zero Data Retention Explained: What ZDR Covers, What It Leaves Out, and How to Verify It

Zero data retention (ZDR) is a commitment by an AI provider not to store a customer's prompts and outputs at rest after the response has been returned. The data still crosses to the provider, is processed by its systems and is visible to them at inference time; what changes is that no copy persists afterward for the provider's own purposes. OpenAI and Anthropic offer it on their API platforms to qualifying organizations, Azure OpenAI reaches a similar state through an approved modification to abuse monitoring, and none of the three makes it the default. This page explains what the commitment covers on each, the features every provider excludes from it, how to confirm you actually have it, and why it is one control among five rather than the answer to data sovereignty.

What zero data retention means, precisely

Every provider's default on its commercial tiers is to exclude customer content from training and to retain prompts and outputs for a period, typically 30 days, for abuse monitoring, support and debugging. Zero data retention removes the second part. Under a ZDR arrangement the provider processes the request, returns the response, and keeps no copy of either in its logs or stores. The processing itself is unchanged: the content is decrypted on the provider's infrastructure, read by the model and by whatever safety classifiers run around it, and handled by the provider's subprocessors in the same way as before. ZDR is a commitment about persistence after the fact.

Three consequences follow. ZDR narrows the window in which a provider breach, insider or legal order could reach your content from weeks to the duration of a request. It does not stop the content from being seen, so it does not satisfy a requirement that a category of data never be disclosed to a third party. And because it is a commitment rather than an architecture, it is verified by contract, configuration and audit report rather than by inspection, which is the same position every provider commitment puts you in; the data sovereignty guide covers why that matters.

Provider by provider

The table paraphrases each provider's published position as of October 2026. The provider policy comparison carries the full retention, residency and admin-control picture; this table is only the ZDR column.

What every provider excludes

ZDR is scoped to request-and-response processing, and anything that exists by storing data is outside it by definition. Across the providers the excluded set is similar. Uploaded files and the Files API persist until deleted. Batch processing holds inputs and outputs for the life of the job. Stored conversation state, whether called threads, stored completions or the Responses API's retained state, persists because that is its purpose. Code execution sandboxes hold what runs in them. Connectors and managed agents store what they retrieve alongside the session. Some models are excluded outright: Anthropic's Covered Models require 30-day retention and are outside ZDR unless expressly authorized. And the chat products, as distinct from the APIs, are not ZDR products at all; ChatGPT Enterprise, Claude Enterprise and their peers run under workspace retention settings, which on several of them default to indefinite. A team that negotiates ZDR for its API integration and then builds the feature on batch jobs, file uploads and a stored-state endpoint has ZDR on paper and 30-day retention in practice.

Azure OpenAI deserves its own paragraph because the mechanism is different. Microsoft states that prompts and completions are not used to train models and that the models are stateless, and that by default a separate abuse monitoring store holds content flagged for review, accessible only to authorized employees through secure workstations with just-in-time approval. Customers processing highly sensitive data can apply, through a Limited Access form, for modified abuse monitoring; if approved, the storage and human review step is not performed, although automated review may still run. The approval is visible in the resource's properties as a ContentLogging capability set to false, which is the closest thing any provider offers to a configuration you can check rather than a clause you have to trust.

How to verify you have it

Because ZDR is granted per organization and often per endpoint, the first check is the paperwork: an order form, DPA amendment or written confirmation that names the organization, the endpoints and the models covered, with the exclusions listed. The second check is the account. OpenAI applies ZDR to the API organization, and the Anthropic arrangement is likewise organizational, so an integration that quietly uses a second API key under a different organization is not covered; inventory the keys. The third is the feature list in your own code. Walk the integration and mark every call that uploads a file, creates a batch, stores state, runs code or calls a connector; each one is outside the arrangement and needs its own retention decision. The fourth is the audit report. SOC 2 Type 2 and ISO/IEC 27001 reports describe the provider's retention controls in general; they do not attest to your organization's ZDR flag, which is why the written confirmation matters.

One more check belongs on your side of the boundary. ZDR describes the provider's logs. Your own gateway, observability tooling and application logs typically capture the full prompt and response, and a ZDR arrangement with the provider paired with ninety days of plaintext prompts in your log platform has moved the retention problem rather than solved it. Retrieval telemetry should record what was retrieved for whom under opaque identifiers, not the content; the telemetry page describes that design.

Why ZDR is one control, not the answer

Consider the two questions a regulator or customer actually asks. Did personal data, health data, controlled unclassified information or a trade secret reach a third party? And can you show what reached them, when, and for which user? ZDR improves neither answer. The data crossed, under ZDR exactly as without it, and the provider holds no record you could use to reconstruct what crossed, which is a feature for the first question and a gap for the second. The controls that change the answers sit before the boundary: scope each retrieval to the asking user's entitlements so that over-permissioned content is not sent in the first place, substitute stand-ins for real identifiers so that what crosses is not the regulated record, and record every retrieval on your side. With those in place, ZDR does what it is good at, which is shrinking the residual exposure of content that did need to cross. The RAG vs fine-tuning page makes the related point about training: data encoded into weights has no retention window at all.

Where Hardshell sits

Hardshell works on the question ZDR does not reach, which is what crosses. It connects to the systems where enterprise data already lives without migrating it, enforces each user's existing permissions at query time, substitutes stand-ins for real identifiers before content reaches ChatGPT, Claude, Microsoft 365 Copilot, Gemini or any other provider, and records every retrieval under opaque IDs. With substitution in place, the provider's retention terms still matter and stop being the whole risk, because the provider never held the identifiers. It deploys as a cloud service, in a private cloud, or as an offline bundle.

Frequently asked questions

What does zero data retention mean?

The provider does not store your prompts and outputs at rest after returning the response. The content is still transmitted to and processed by the provider at inference time; ZDR removes the copy that would otherwise be kept for abuse monitoring, support or debugging.

Which AI providers offer zero data retention?

OpenAI offers it on its API platform for qualifying organizations. Anthropic arranges it per organization through sales for the Messages and Token Counting APIs, with the Covered Models excluded unless authorized. Azure OpenAI customers can apply for modified abuse monitoring, which removes the storage and human review step. Microsoft 365 Copilot and Gemini for Workspace do not use the concept; your tenant's retention policies apply.

Does ZDR apply to ChatGPT Enterprise or Claude Enterprise?

No. ZDR is an API-platform arrangement. The chat products run under workspace retention settings: OpenAI purges deleted chats within 30 days and keeps project and GPT files until removed, and Claude Enterprise retains indefinitely unless an Owner sets a custom period of 30 days or more.

Is zero data retention the same as not training on my data?

No. All four major providers exclude commercial customer content from training by default or by terms, with or without ZDR. Training exclusion is about what the provider learns from; ZDR is about what it keeps.

Does zero data retention make it safe to send regulated data to an AI provider?

It reduces how long the provider holds it, which helps. It does not change that the data was disclosed to and processed by a third party, which is the test most regulations apply. For regulated identifiers, substitution before the boundary and retrieval scoped to the user's entitlements are the controls that change the answer; ZDR then covers the residual.

How can I confirm ZDR is actually enabled?

Get written confirmation naming the organization, endpoints and models covered; check that every API key in use belongs to that organization; walk your integration for excluded features such as files, batch, stored state, code execution and connectors; and, on Azure OpenAI, check the resource for the ContentLogging capability set to false.