On 19 August 2026, OpenAI previewed Private Safety Processing, an approach intended to keep safety measures compatible with Zero Data Retention (ZDR). According to the announcement, for eligible API customers using ZDR, prompts and responses are not retained after a request is processed; customer content is also not used to train models unless a customer explicitly opts in. This is a provider announcement, not an independent assessment of effectiveness or compliance. It nevertheless raises a practical management issue: as AI works with more sensitive data, a business cannot ask only whether a provider retains data.
A fuller question is which data actually enters a workflow, where it is stored and for how long, who may access it, and what evidence lets an organisation verify those commitments. Zero retention may be an important technical choice, but it does not replace data classification, internal permissions, tool configuration, or accountability for the person approving a use case.
From a provider policy to an enterprise data map
A data policy is often read at contract level while risk emerges at work level. An employee may paste a customer summary into a tool, export a file for analysis, or connect an agent to internal knowledge. Each step creates different questions about purpose, access, logging, and the ability to delete or revoke permissions. A data map by use case turns a general statement into controls that can be assigned.
| Management point | Question to settle | Evidence to retain |
|---|---|---|
| Input data | Which data types are permitted or prohibited in AI? | Data classification and use-case guidance. |
| Access and retention | Who may access sources, logs, and outputs; where are they held and for how long? | Permission settings, provider terms, and change logs. |
| Operating review | Who reviews when a workflow or policy changes? | An owner, review rhythm, and incident process. |
Less retention does not remove every responsibility
Even where a service commits not to retain prompts or responses after processing, an organisation must consider other points in the chain. Data may remain in source systems, enterprise logs, user devices, backups, or integrated applications. A workflow may also create a decision, draft, or action that should be retained as a work record. The aim is therefore not to erase every trace, but to distinguish data that needs protection from records that need retention for accountability, and to clarify who decides both.
Example: an assistant summarising customer feedback
A marketing team wants to use AI to summarise open survey feedback. It can begin with de-identified data, restrict access to the survey repository, and require users to check whether a summary reveals identifying detail before sharing it. The use-case owner retains a record of the source data, purpose, provider, access rights, and response to deletion requests. A ZDR choice, where suitable, is then one control within a wider design.
Leaders should request checkable answers
Rather than ask for a long AI policy, leaders can begin with a few priority use cases and request short answers to four issues: which data enters, where the result goes, who may use or approve it, and which review mechanism operates when change occurs. These answers need updating as providers, features, or processes change. This makes data security part of operating design, not merely a commitment made while buying a tool.
The 19 August announcement signals that providers are trying to combine safety measures with data-control commitments. For businesses, the lesson is to turn those technical capabilities into choices with owners, scope, and evidence. This is a management analysis, not specialist legal or security advice.
References
OpenAI. (2026, August 19). Offering Zero Data Retention for frontier models. https://openai.com/index/offering-zero-data-retention-for-frontier-models/
