Your compliance team asks whether the AI vendor keeps your data. The vendor's page says zero data retention. Everyone checks the box and moves on. That box is where the trouble starts. Zero data retention (ZDR) is a vendor's commitment not to store your prompts and responses after it processes a request. In practice it is one name for several separate promises, and each promise has its own conditions.
Vendor data terms are one of the first documents we read in AI readiness work, before a pilot touches a real record. The best teaching case the market has produced arrived on August 19, 2026, when OpenAI formalized Zero Data Retention for its frontier models and introduced a safety system called Private Safety Processing. On September 22, 2026, it began rolling that system out to API customers in phases. The fine print is public, and nothing below is a criticism of OpenAI. Publishing the exceptions is what an honest version of this product looks like.
What OpenAI's zero data retention actually covers
OpenAI's zero data retention commitment for eligible API customers has three parts. OpenAI does not retain prompts or responses after a request is processed. Customer content is not available to OpenAI personnel for review. Enterprise data does not train its models unless the customer opts in.
Read it as a buyer and two words carry the weight. "Eligible" means ZDR is not the default. You qualify for it, and then you confirm that your account actually has it. "Personnel" means the promise is about people, not systems. Automated safety systems still process your content. Each clause answers a different risk, and a vendor can keep one while another does not apply to you.
Zero retention can still leave a 30-day record
Zero data retention does not mean nothing is ever stored. OpenAI keeps some flagged content because the law requires it, and its safety system can write encrypted records into your own storage for 30 days.
OpenAI's announcement is candid about the first exception. Images flagged as potential child sexual abuse material are kept for manual review and reporting, ZDR or not, because providers are required by law to report it.
The more useful detail sits in the Private Safety Processing implementation guide. When a safety classifier refers an interaction, or a sampling policy selects one, the system encrypts that prompt and response. Then it writes the record to the customer's own S3 or Azure storage with a 30-day expiry. The customer must set lifecycle rules that do not delete those records earlier. OpenAI keeps an index and a storage reference, not a copy. With customer-managed keys on, OpenAI's key alone cannot decrypt the record. What OpenAI sees is an alert category and severity, with no content.
That is a careful design. It is also not what most compliance teams picture when they read "zero retention." The retention moved into a bucket you own. You now hold up to 30 days of encrypted AI interactions, and your own access controls and retention policy have to account for them.
Storage models differ too. In ZDR deployments, content stays on infrastructure the customer controls. OpenAI is also developing an option to store content on its own infrastructure, encrypted with keys the customer controls. Those are different trust models. One keeps the data out of the vendor's hands. The other keeps it out of the vendor's reach. Your security team will care which one it is signing.
Five questions to ask an AI vendor about data retention
Five written answers separate a zero data retention badge from a guarantee that covers your account, your content, and every provider in the chain.
Ask what "eligible" means for your account. Get the tier, the covered models, and the enrollment step in writing. A promise that covers another class of customer does not cover you.
Ask where safety monitoring runs and what it emits. Every serious vendor monitors for abuse. Find out whether the monitor's output contains your content or only a category.
Ask what is kept, where, and for how long. Include records the vendor writes into your storage. An encrypted record in your own bucket is still a record your policy must cover.
Ask what the law makes them keep. Every provider has statutory carve-outs. A vendor who says "nothing, ever" has not read its own obligations.
Ask who holds the keys and who sits downstream. Vendor-held keys mean vendor access. If your vendor resells a model from another provider, that provider's retention terms apply too. Get the whole chain in writing.
Where this fits your AI program
AI vendor data terms are a readiness question, not a procurement afterthought. Answer them before a pilot touches sensitive records, because renegotiating a data agreement under a live workload is slow and expensive. The answers also belong in your AI usage policy, so your people know which tools are cleared for which data. Our checklist of what an AI usage policy should cover has the rest.
Our AI readiness assessments treat vendor data posture as a hard constraint, next to the technical ones. Start with the five questions above. A vendor who cannot answer them in writing has already answered.