OpenAI said on August 19 that eligible API customers can use frontier models without the provider retaining prompts or responses after processing. On September 1, Anthropic announced Enterprise Frontier Safeguards, which stores monitored activity in cloud infrastructure controlled by the customer. Two major providers are now trying to combine cross-session safety checks with zero data retention.
That makes the label more important and easier to misunderstand. A model endpoint can discard a prompt while a file store, search tool, cache, trace, or help desk keeps the same text. Start every chatbot zero data retention review with these questions:
- Which exact data classes does the promise cover?
- At what moment does each copy disappear?
- Which products, models, endpoints, and regions qualify?
- Which features create stored state outside the core model call?
- Does the provider use customer content for training or human review?
- What metadata remains after content deletion?
- Where do safety signals live, and who can inspect them?
- Which subprocessors receive prompts, files, outputs, or identifiers?
- How do backups, failed requests, and support tickets expire?
- What evidence can prove the deployed configuration matches the contract?
Do not approve a one-word "ZDR" answer. Ask the vendor to complete the review for the exact chatbot configuration you plan to run.
Separate the promises hidden inside ZDR
Zero data retention describes storage after processing. It does not automatically answer several nearby questions.
No training. A provider may promise not to train on business data yet retain prompts for abuse monitoring, debugging, or support. Training policy and retention policy need separate contract language.
No human access. Automated systems may inspect content during processing. Ask whether provider staff, contractors, or subprocessor staff can later read stored content or safety flags.
Data residency. A request may run in an approved region and still remain there for 30 days. It may also be processed outside your target region and deleted immediately. The AI chatbot data residency checklist covers location. ZDR covers time.
Deletion on request. A deletion API removes a named record after you call it. True ZDR should not depend on a customer remembering to delete routine model traffic.
Minimal metadata. A provider can discard prompt text while keeping timestamps, token counts, model names, account IDs, IP addresses, error codes, and safety classifications. Some of that data is useful and low risk. It still belongs in the inventory.
The practical definition should be narrow: named customer content is unavailable after the request finishes, except for documented features or legal obligations. OpenAI, for example, documents a specific exception for images flagged as potential child sexual abuse material. Precise exceptions are more trustworthy than an absolute claim that cannot survive real operations.
Map every copy made by one conversation
Follow a realistic message through the full system. Suppose a customer writes:
I am Rina Patel. Please refund order 3148 to my card. I uploaded the damaged-item photo yesterday.
The chatbot loads the order, retrieves the return policy, calls a commerce API, produces an answer, records a trace, and may hand the case to support. The model request is only one row in the retention register.
| Copy | Content present | Why it exists | Retention clock | Deletion evidence |
|---|---|---|---|---|
| Browser session | Message text and session ID | Continue the chat | Session end | Browser storage inspection |
| Chatbot database | Transcript and contact link | Support review | 30 days | Record lookup after expiry |
| Retrieval query | Order issue and policy chunks | Ground the answer | Request end | Provider configuration and test |
| Model request | Prompt, retrieved text, output | Generate the answer | Request end under ZDR | Contract plus endpoint setting |
| Uploaded file | Damage photo and metadata | Support the refund | 7 days | File API lookup returns missing |
| Tool provider | Order ID and refund request | Change the order | Commerce policy | Refund record and audit policy |
| Observability | Trace ID, latency, sampled fields | Diagnose failures | 14 days | Log search after expiry |
| Human handoff | Redacted summary and ticket ID | Resolve the case | Help-desk policy | Ticket deletion report |
This example exposes two common mistakes. The photo can outlive the model request because file storage has its own lifecycle. The refund system must retain a financial record even when the AI provider keeps nothing. Your public claim should describe the chatbot boundary, not imply that every connected business system erases required records.
Build the same table for a normal answer, a file upload, a failed tool call, and a human handoff. Use actual field names. "Operational data" is too vague to reveal that an error trace contains the customer's message.
Test features, not provider logos
Current provider documentation gives a useful warning. Google's Gemini Developer API ZDR guide says approved projects can clear user content and identifiable metadata before abuse-monitoring logs are written. The same page lists separate storage behavior for specific features.
Grounding with Google Search or Maps stores prompts, context, and generated output for 30 days. The Interactions API stores conversation state unless store is set to false. Session resumption in the Live API can keep state for up to 24 hours. Uploaded files remain until deletion or expiry, and explicit context caches use their configured lifetime.
Those are not obscure edge cases. Search, conversation state, files, live voice, and caching are exactly the features teams add after a chatbot pilot works. A provider-level ZDR approval can become false when one developer enables a convenient option.
Require a feature matrix with four answers for each component:
- Is it allowed in the approved ZDR configuration?
- Does it store content, identifiers, or derived signals?
- Which setting prevents storage?
- How will a release test catch that setting changing?
Include model calls, batch jobs, prompt caches, file APIs, web search, code execution, voice sessions, moderation, tool connectors, analytics, and support diagnostics. If the vendor cannot answer at feature level, the deployment is not ready for a strong privacy claim.
Ask for evidence in layers
A sales answer is a lead, not evidence. Build an approval packet that lets legal, security, and engineering check the same design.
Start with the contract. It should name covered products, covered data, retention timing, training rules, human access, exceptions, subprocessors, breach duties, deletion behavior, and change-notice terms. Link each promise to the current product documentation rather than pasting screenshots with no date.
Then collect configuration evidence. Record the organization ID, project ID, model identifier, endpoint, region, storage flags, cache settings, file expiry, and logging mode. Keep secrets out of the packet. A configuration export or policy-as-code check is better than a dashboard screenshot because it can run again.
Finally, collect runtime evidence. Send a synthetic marker through the system and search for it after the promised window. Inspect your own logs, files, caches, queues, tickets, and backups. Ask the provider what report, attestation, or audit right supports the parts you cannot observe.
The chatbot memory isolation guide addresses who can see a stored record. This review asks whether that record should still exist at all. You need both controls when the chatbot handles account-specific conversations.
Run a deletion drill with a unique marker
Use test data, never a real customer's sensitive details. Create a marker such as ZDR-TEST-2026-09-06-A7F2 and place it in a prompt, uploaded text file, failed tool request, and handoff summary. Record the time each system receives it.
After the documented retention window, search every system in the register. A useful test result looks like this:
Marker: ZDR-TEST-2026-09-06-A7F2 Model request retention: request lifetime Chat transcript retention: 30 days Diagnostic trace retention: 14 days, content redacted Uploaded file retention: 7 days Help-desk ticket retention: 365 days Day 8: file absent, transcript present, trace present without marker Day 15: trace absent, transcript present Day 31: transcript absent, ticket present under documented exception Result: approved claim applies to model traffic and chatbot storage, not to the human support record
This artifact is more useful than a green compliance badge. It states what disappeared, what remained, and why. Repeat the drill after a provider migration, model upgrade, new connector, new observability service, or retention-policy change.
Backups need their own result. Some systems delete active records immediately but let encrypted backups age out on a fixed schedule. Document the maximum backup lifetime, who can restore one, and how the restore process prevents deleted records from returning to production.
Keep safety monitoring compatible with customer control
Providers want enough context to detect misuse that spans several requests. Customers in regulated industries may be unable to give a model provider readable copies of sensitive traffic. Recent announcements show two designs for that conflict.
OpenAI says its Private Safety Processing preview can examine patterns across related interactions while customer content stays in customer-controlled infrastructure. It is also developing an option that stores encrypted content on OpenAI infrastructure with customer-controlled keys. The provider receives limited safety signals without giving its staff the underlying prompts and responses.
Anthropic says its Enterprise Frontier Safeguards will keep activity data in the customer's own cloud account under customer encryption keys, access policies, and audit logging. Automated monitoring sends detected patterns to the customer, whose cleared staff review the underlying activity. Eligible customers receive ZDR on named models while the system rolls out in phases.
These designs are new enough that procurement should ask about operational detail. Who deploys and updates the monitoring component? Which signals leave the customer account? Can the customer inspect false positives? What happens if monitoring is unavailable? Which party handles an urgent abuse report? A privacy architecture still needs an incident process.
Reject three misleading shortcuts
"We do not train on your data." This says nothing about temporary storage, staff access, logs, or feature state. Ask for the retention schedule.
"Everything runs in Europe." Regional control matters, and Mistral's recent infrastructure announcement shows growing demand for it. Geography does not state when data disappears.
"The model provider has ZDR." Your chatbot platform, analytics service, file store, connector, and help desk may retain copies before and after the model call. Review the full path.
Data minimization makes every answer easier. Redact payment details before they reach the model. Send only retrieved passages needed for the current question. Keep identity in a structured customer record instead of repeating it in every prompt. The chatbot privacy guide explains how to collect less without breaking support workflows.
Publish the claim your test can defend
The right statement may be narrower than "zero retention everywhere." That is fine. A defensible notice could say:
Our AI model provider does not retain prompts or generated answers after processing. We keep chatbot conversations for 30 days for support review. Uploaded files expire after seven days. If you ask for a person, the resulting support ticket follows our one-year ticket policy.
Customers can understand that. Engineers can test it. Legal can map it to the contract. A broad "private AI" badge does none of those jobs.
Zero data retention is a configuration and evidence problem, not a vendor adjective. Map every copy, test each feature, record the exceptions, and rerun the deletion drill whenever the system changes. Then keep the public promise as precise as the proof behind it.
No credit card required.
