Zero Retention Moves the Audit Trail to the Customer
Executive summary
OpenAI's August 19 announcement extended a clear enterprise promise: eligible API customers using zero data retention can keep prompts and model responses from being retained by the provider after processing. Its preview of Private Safety Processing aims to detect risky patterns across interactions while content remains on customer-controlled infrastructure or is encrypted with customer-held keys.
The mainstream interpretation is that zero retention removes the data-governance obstacle to frontier AI. That is only partly right. It reduces a provider-side copy of sensitive content, which can materially shrink breach, access and discovery exposure. It does not remove application state, customer logs, retrieved documents, tool traces, human-review evidence or legal retention duties. In many production systems, those records are necessary to operate the product.
The more defensible thesis is that zero retention changes where evidence must live. The provider sees less content; the customer becomes more responsible for reconstructing what an agent saw, decided and did. That trade can be attractive, especially for regulated or proprietary workflows, but only when operators design a customer-owned audit plane before turning provider retention off.
Market context
Enterprise AI contracts have gradually separated three questions that are often collapsed in procurement discussions: whether customer content trains a model, whether content is stored after inference, and whether people can review stored content. A no-training commitment does not imply zero retention. Zero retention does not imply that no metadata or safety signal exists. And a provider's inference policy does not govern copies created in a customer's application, observability stack or connected data source.
OpenAI's data-control documentation says API content is not used for training unless the customer opts in. Under the standard setting, abuse-monitoring logs may include prompts and responses and can be retained for up to 30 days. Eligible customers can obtain modified abuse monitoring or zero data retention. ZDR forces storage off for eligible response and chat-completion requests, but some endpoints and capabilities that require application state remain ineligible.
The August announcement adds a new direction. Private Safety Processing is intended to examine patterns across related interactions without giving OpenAI personnel the underlying prompts or outputs. Under the preview, content can remain on customer infrastructure or be stored encrypted under customer-controlled keys. OpenAI would receive a narrow risk signal; customers would investigate with records available in their own systems and could choose what to share during an appeal or abuse investigation. A technical paper is expected in September, so architectural and performance claims remain a preview rather than validated production evidence.
Other providers expose similar boundaries with different implementation details. Anthropic offers organization-level ZDR for eligible API features, while stateful features can fall outside the arrangement. Google documents steps required to achieve ZDR in Vertex AI and identifies features, such as some grounding modes, that impose defined retention. Microsoft describes automated abuse review and a modified-monitoring path that removes the default storage and human-review process for approved customers. Amazon Bedrock exposes retention modes and can block a request when a model's requirements conflict with an account's zero-retention policy.
The market is therefore converging on configurable retention, not one universal definition of privacy.
Findings
Finding 1
Zero retention reduces provider exposure; it does not make the application stateless.
An inference request can be ephemeral while the product around it remains full of durable data. A support assistant may read a ticket stored for years. A coding agent may operate inside a repository whose history is permanent. A financial workflow may retrieve invoices, create approvals and write entries into an accounting system. The provider can discard the prompt and output while the customer retains the source, tool calls and business result.
That is not a loophole. It is how the application delivers continuity, accountability and service. The mistake is treating a provider setting as an end-to-end data map.
Stateful AI features make the boundary visible. OpenAI notes that capabilities ineligible for ZDR may store application state. Anthropic's API retention documentation likewise distinguishes eligible message calls from features such as code execution that retain jobs, files or container state. Google's Vertex AI guidance says customers seeking ZDR must avoid or reconfigure specific services: Google Search grounding retains prompts, context and outputs for 30 days, Maps grounding also has 30-day storage, and optional Gemini Live session resumption caches session data for up to 24 hours.
The relevant architecture question is not “Do we have ZDR?” It is “Which component persists which object, for what purpose, under whose key, and for how long?”
| Platform / path | Standard or documented retention boundary | ZDR or reduced-retention control | Important feature boundary |
|---|---|---|---|
| OpenAI API | Abuse-monitoring logs may contain customer content for up to 30 days | Approved ZDR excludes customer content from those logs and forces supported response storage off | Ineligible endpoints or capabilities may retain application state |
| Anthropic API | Standard commercial API inputs and outputs are generally deleted within 30 days | Approved organization-level ZDR avoids storing eligible prompts and responses at rest after the response | Stateful features marked ineligible step outside ZDR; model eligibility can also differ |
| Google Vertex AI | Retention varies by abuse monitoring, grounding and session feature | Customers can request an abuse-monitoring exception and disable or avoid retention-bearing features | Search/Maps grounding and session resumption have specific storage periods or restrictions |
| Microsoft Foundry direct models | Flagged prompts and completions may enter a segregated store for human abuse review | Approved modified abuse monitoring removes that storage and human-review process; automated review can remain | Enforcement can still follow detected severe or recurring misuse |
| Amazon Bedrock | Retention depends on effective mode and model requirements | none prevents durable request/response storage and provider sharing; incompatible requests are blocked | Some models require another mode and become unavailable under none |
Source: provider documentation linked in the table discussion and Microsoft's data-privacy documentation and Amazon Bedrock retention documentation. Period: documentation available through August 23, 2026. Units: stated retention periods and qualitative controls. Method: direct comparison of provider descriptions; terminology is preserved where possible. Limitation: contract terms, product eligibility and technical behavior can differ by customer, region, model and feature. The rows are not certifications of equivalence.
Finding 2
Privacy and observability pull in opposite directions unless the customer owns the evidence.
Long-running agents make cross-interaction context valuable for both product quality and safety. A single call may look harmless while a sequence reveals credential probing, policy evasion or action beyond the user's instruction. OpenAI explicitly cites this problem in the Private Safety Processing preview. Yet storing the full sequence at the provider can conflict with a customer's obligations around financial records, health data, source code or confidential strategy.
The proposed compromise is computational separation: allow automated systems to detect patterns without exposing underlying content to provider personnel. That can reduce access risk, but it does not answer the operational questions after an alert. Was the classifier correct? Which user instruction preceded the action? What source document was retrieved? Did the model act, or merely propose an action? Which human approved it? Was the same event recorded in the business system?
OpenAI says customers using the preview can investigate from their own systems and share relevant evidence if they choose to appeal or support an investigation. That sentence contains the operating model. The customer must maintain enough evidence to explain an event that the provider intentionally cannot see.
Retention therefore needs two tiers. The content tier should minimize sensitive text and files. The evidence tier should retain structured, least-privilege facts: tenant and user identifiers, model and policy version, retrieval references, tool name, requested action, authorization result, timestamp, outcome and linked business-object ID. Sensitive payloads can remain encrypted or stored in the system of record, referenced rather than copied into every trace.
This design also improves vendor portability. A provider-owned transcript is convenient until the organization changes models, routes tasks across multiple providers or needs to compare behavior. A customer-owned event schema preserves the audit trail across vendors without requiring every vendor to retain content.
Finding 3
Zero retention is a feature and capability choice, not merely a contract clause.
The strongest privacy setting can remove product conveniences. Persistent threads, background work, hosted files, cached context, search grounding and code-execution containers all need some form of state. Providers handle the conflict differently: some features are blocked, some become ineligible for ZDR, some store narrowly defined artifacts, and some require a separate workspace or retention mode.
This produces a non-obvious procurement cost. A team can negotiate ZDR and later discover that the workflow depends on a feature outside the approved boundary. It can then weaken the control, redesign the application, or operate the state itself. The last option may offer the best governance, but it moves engineering, key management, incident response and deletion work onto the customer.
Amazon's explicit blocking model is useful because it makes incompatibility fail closed. Under its documented none mode, requests to models requiring retention do not silently proceed; the model becomes unavailable. Anthropic documents that ZDR does not automatically block every ineligible feature, so using one can step outside the arrangement for that data. The control plane matters as much as the policy language.
Operators should treat retention mode as a runtime attribute attached to every request, model, feature and workspace. A policy that exists only in a contract repository will not prevent an engineer from enabling a stateful tool or routing data through an unapproved path.
Implications for operators
Build a retention inventory at the workflow level. Record each source, prompt assembly step, model endpoint, tool, cache, trace, human-review queue and downstream write. For every component, name the data owner, purpose, storage location, encryption boundary, retention period and deletion mechanism. Re-run the inventory when a model or feature changes.
Separate no-training, no-provider-retention and no-human-access requirements. They address different risks and should be tested independently. Procurement language should identify eligible endpoints, excluded features, regional processing, metadata treatment, safety-monitoring behavior and the remedy when a provider changes eligibility.
Create a customer-owned audit plane before enabling ZDR. The minimum record should allow an investigator to link user authority, model behavior, tool execution and business outcome without duplicating every sensitive payload. Use immutable event IDs, signed approvals for consequential actions and references back to systems of record.
Make incompatible features fail closed. Policy should be enforced in gateways and infrastructure permissions, not left to developer memory. Requests that require unapproved retention should be blocked or routed to a workspace with an explicitly different data classification.
Test the incident path. Run exercises for a false safety alert, an actual policy breach, a disputed agent action and a deletion request. Determine what the provider can explain, what the customer can reconstruct and which evidence may be shared without expanding the original exposure.
Measure the cost of owning state. Compare the reduction in provider-side risk with the engineering and compliance cost of hosted conversation history, retrieval stores, encryption keys, logging, deletion and legal holds. ZDR can be the right decision without being the free decision.
Risks & open questions
The thesis would weaken if privacy-preserving safety processing proves that providers can deliver cross-session detection, useful explanations and stateful features without retaining accessible customer content or forcing customers to build a parallel evidence system. OpenAI's preview points in that direction, but the promised technical paper and production results are not yet available.
Public documentation also cannot establish how controls operate for every negotiated customer. Eligibility, region, model, endpoint and contract language can change. The comparison above should be used as a due-diligence map, not a substitute for legal terms or a technical test.
There is also a risk of under-logging. Organizations can interpret data minimization so aggressively that fraud, discrimination, financial error or unauthorized action becomes impossible to investigate. The answer is not indiscriminate transcript retention. It is purpose-limited evidence with access controls and expiry appropriate to the business obligation.
Finally, privacy-preserving safety signals create governance questions of their own. Customers need to know the signal taxonomy, false-positive process, appeal evidence, service consequences and whether a provider can suspend access without viewing content. Providers need a way to enforce policy without recreating the sensitive repository ZDR was meant to remove.
Appendix / methodology notes
This report reviewed primary product and policy documentation available through August 23, 2026 from OpenAI, Anthropic, Google Cloud, Microsoft and Amazon Web Services. Retention periods were transcribed only when explicitly stated. Qualitative controls were not converted into numeric scores because provider definitions, model eligibility and customer contracts are not directly comparable.
The chart-ready table reports policy boundaries, not measured adoption, breach probability or compliance status. A stronger future dataset would add, by provider and endpoint: percentage of enterprise traffic under each retention mode; number of stateful features eligible for ZDR; alert precision and recall; time to investigate; frequency of customer appeals; and cost per audited workflow. Those data are not publicly available on a consistent basis.
The recommendations are Blackrock Research's operational synthesis. They distinguish sourced provider behavior from inference: provider documentation supports the stated retention controls; the conclusion that audit responsibility shifts toward the customer is an inference from those controls and from OpenAI's description of customer-led investigation under Private Safety Processing.