Zero Data Retention Is a Workflow Audit, Not a Checkbox

By Greg Nowak. Last updated 2026-08-30.

Zero Data Retention sounds comprehensive. It is useful, but it answers a fairly specific question: what does the AI provider keep after processing a request?

OpenAI says eligible API customers using Zero Data Retention can prevent their prompts and model responses from being retained after processing. Its August 19 announcement also previews Private Safety Processing, which is designed to detect patterns across related interactions without giving OpenAI personnel access to the underlying customer content.

That is a meaningful provider-side commitment. It does not control the rest of the application.

The same prompt might still appear in an observability tool, a retry queue or a verbose error trace. An uploaded document may remain in storage. A response may be passed to an external service with its own retention policy. If you need to make a defensible claim about retention, you have to follow the data through the whole workflow.

Provider retention is only one part of the picture

OpenAI’s data-control documentation describes several kinds of storage, with rules that vary by endpoint. Under Zero Data Retention, customer content is excluded from abuse-monitoring logs. For supported Responses and Chat Completions requests, the store parameter is treated as false. Endpoints and capabilities marked as ineligible may still retain application state.

The endpoint table makes those differences tangible. Chat Completions, Responses, embeddings and several other endpoints are listed as ZDR eligible, subject to the documented limitations. Conversations, files, batches and vector stores are among the ineligible resources, and some application state remains until it is deleted. Information sent to third-party services, including remote MCP servers, falls under those services’ retention policies.

So “we enabled ZDR” is the start of the answer, not the complete data lifecycle. A credible review asks which endpoints the application calls, which optional features it uses, where every copy goes and what eventually removes it.

Layer to inspect	Question to answer	Evidence worth keeping
Inputs	Which fields, files and identifiers enter the workflow?	Approved data map and redaction rules
Application	What reaches proxies, logs, queues, retries and error traces?	Logging settings, access rules and TTLs
OpenAI project	Which project, endpoints, storage parameters and region are in use?	Retrieved project configuration and endpoint inventory
Persistent state	Which conversations, files, batches or vector stores remain?	Purpose, owner and deletion trigger for each object
External services	Which analytics tools, connectors and processors receive content?	Data-flow records and retention terms
Deletion	Do expiry and deletion work at every layer?	Test results, timestamps and documented exceptions

A practical ZDR review follows each copy from collection to verified deletion.

Check the project the workload actually uses

Approved organisations can configure OpenAI retention controls at organisation and project level. A project may inherit the organisation default, explicitly use Zero Data Retention or Modified Abuse Monitoring, or have those controls disabled. The project data-retention API lets a team retrieve the configured type for a specific project.

This turns configuration into something you can inspect. Record the project identifier used by each workload, retrieve its effective retention setting and compare the result with the policy you intended to apply. That simple check can expose a development, migration or specialist workload running under a differently configured project.

Next, compare the endpoints and features in use with the current eligibility table. Pay close attention to stateful resources, background processing, uploaded files, external tools and features with explicit limitations. The point is not to rule out useful capabilities. It is to understand their storage behaviour before deciding whether they belong in the workflow.

Regional processing needs its own check. OpenAI documents data residency as a per-project option for eligible customers and supported configurations. It also distinguishes customer content from system data and lists circumstances that fall outside the selected region. Verify the project region and the hostname used by the application, then record the documented scope and limitations. “EU region” should not become a broader promise than the configuration supports.

Translate privacy principles into engineering decisions

The European Commission’s GDPR principles offer two useful tests. Data minimisation means personal data should be adequate, relevant and limited to what the purpose requires. Storage limitation means keeping it for the shortest appropriate period, while accounting for the purpose and any applicable legal obligations.

For an engineering team, that leads to concrete questions:

Which input fields does the model task genuinely require?
Can direct identifiers or secrets be removed, masked or tokenised before inference?
Does an operational log need the content, or would latency, status and token counts be enough?
Which system holds the authoritative record, and which copies are temporary?
How long should each copy remain, and who approved that period?
What starts deletion: request completion, job expiry, account closure or a user request?

A single TTL applied everywhere rarely captures this properly. Records can have different purposes and retention periods, but every retained copy should still have a named purpose, owner, access policy and deletion rule. If another obligation requires longer retention, document that exception instead of leaving it buried in a default setting.

Look closely at logs, including the awkward paths

The OWASP AI Testing Guide identifies logs and persistent storage as possible sources of exposure when they capture raw prompts, model outputs, tokens or other sensitive context. Its recommendations include redacting data at ingestion, masking or tokenising secrets, sanitising logs and error traces, applying data-loss-prevention scanning, and limiting access through role-based controls and least privilege.

Review more than successful API calls. Failures, retries, debugging modes and verbose error handling often produce different records from the normal path. Use representative synthetic markers during testing, then search approved systems for unexpected copies. This gives the team something traceable without introducing real personal or confidential data into the exercise.

Redaction needs to be tested as well as documented. It must happen before content reaches the store it is supposed to protect. Tests should cover prompts, responses, tool output, uploaded material and errors. A policy that says “PII is removed” does not show that every code path applies the rule.

Finish with a register people can use

The most useful deliverable is a compact processing register that connects each data category with its purpose, systems, OpenAI project, endpoints, region, access group, retention period and deletion mechanism. It should clearly separate provider retention, storage controlled by the application and processing by third parties.

Back that register with configuration snapshots and deletion-test results. It then becomes practical evidence for internal reviews and for discussions with security, privacy and procurement teams, rather than another policy document that engineering has to interpret.

Greg can help run this as a focused workflow audit: mapping prompts, responses, proxies, queues, retries, files, analytics and vector storage; checking project settings and endpoint eligibility; defining workable redaction and TTL rules; and testing deletion across the complete path.

Zero Data Retention is valuable. The stronger position, though, is being able to show what the workflow collects, where each copy travels, why it remains and what removes it.

Related on GrN.dk

Need help with this kind of work?

Plan your workflow audit Get in touch with Greg.

Sources

Last modified

2026-08-30