What Zero Data Retention Really Means

“Zero data retention” sounds wonderfully final. It also means different things depending on the provider, endpoint, account status, feature, and exception list. Naturally, this is where the fun begins to die.

At minimum, teams should separate four questions. Is customer content used for model training? Is content stored for abuse monitoring? Is application state stored to make the feature work? Are image and file inputs treated differently from text?

OpenAI’s current API data controls documentation says API data is not used to train or improve OpenAI models unless the customer opts in. It also describes default abuse-monitoring logs, retention controls such as Modified Abuse Monitoring and Zero Data Retention for eligible approved customers, endpoint-specific application state, and image/file input exceptions for certain safety reviews.

Microsoft’s Foundry Models sold by Azure data privacy documentation uses its own structure. It says prompts and completions are not available to other customers, not available to OpenAI or other model providers, and not used to train foundation models without permission or instruction. It also describes stored features, abuse monitoring, geography, and ways approved customers can verify when abuse-monitoring storage is off.

The lesson is not “provider A good, provider B bad.” The lesson is that ZDR is a configuration and eligibility story, not a slogan. One endpoint may be eligible. Another may store application state. One feature may retain until deleted. Another may keep temporary state for polling, caching, safety, or download windows.

Image workflows make this more important. Image generation, edits, file inputs, videos, batch jobs, and assistants-style stateful workflows can have different storage behaviours. A procurement answer copied from a text-completion endpoint may not answer the image-upload question.

When evaluating a provider, ask for the boring table. Endpoint. Training use. Abuse monitoring. Application state. File retention. Image retention. Human review. Safety exceptions. Deletion API. Region. Subprocessors. Eligibility requirements for modified monitoring or ZDR. Boring tables save exciting incidents.

For Unexposed-style products, the cleanest customer promise is not merely “our provider has ZDR.” It is “our product is designed not to retain customer prompts or images, and our provider route matches that promise for the endpoints we use.” The product-level promise matters because provider controls are only one layer.

Zero data retention is valuable. It is also not a magic stamp. Read the endpoint behaviour or the phrase will do that thing phrases love to do: sound better than the system underneath.

Further reading: OpenAI API data controls, Microsoft Foundry data privacy, and The case for zero prompt history.