OpenAI’s expansion of ZDR for eligible frontier-model API customers shows that retention, safety and observability must be designed as separate layers.
OpenAI announced in August that eligible API customers could use frontier models under Zero Data Retention: prompts and model responses are not retained after processing, customer content is not available to OpenAI personnel for review subject to stated exceptions, and enterprise data is not used for training unless the customer opts in.
The company also previewed Private Safety Processing, designed to detect patterns across related interactions while remaining compatible with ZDR and customer-controlled storage or encryption keys.
The architecture question is bigger than one provider. Enterprises increasingly need to separate inference, retention, safety processing and business records.
“No retention” is not “no data”
A model request still processes data. The application may retrieve documents, create temporary files, call tools, write traces or store the final outcome in a business system. A ZDR commitment at the model layer covers only part of the flow.
A complete data map should include:
- user input before it reaches the model;
- retrieved context and caches;
- prompts assembled by orchestration;
- model responses;
- tool arguments and results;
- traces and observability data;
- human-review queues;
- final records written to CRM, ERP or case systems;
- backups and incident artefacts.
The strongest provider term cannot compensate for an application that logs every prompt in plain text.
Separate the four data purposes
1. Inference
Data required momentarily to produce the result. Minimise it, scope it and choose an approved processing region.
2. Business record
Evidence the organisation genuinely needs to keep: an approved decision, source references, a transaction identifier or a customer communication.
3. Operational telemetry
Metrics required to operate the service: latency, model version, tool status, cost and error codes. Often this can be useful without storing raw content.
4. Safety and investigation
Signals needed to detect abuse, security incidents or harmful patterns. This layer creates tension with minimal retention and needs explicit design.
Keeping these purposes separate makes retention policies more precise. It also allows sensitive content to be excluded from general logs while preserving enough evidence for accountability.
ZDR changes observability design
Raw prompt logging is the easiest form of debugging. It is also often the least compatible with privacy requirements.
Alternatives include:
- structured traces that store event type rather than full content;
- redaction before telemetry leaves the application;
- hashes or references to records held in customer systems;
- short-lived encrypted debug capture activated for a specific incident;
- customer-controlled storage and keys;
- synthetic replay cases for routine evaluation;
- field-level retention rules.
Teams should decide in advance how they will investigate a failure without relying on permanent content copies.
Safety must not become a hidden back door
Private Safety Processing illustrates one approach to analysing patterns while limiting personnel access. Whatever the provider, enterprises should ask precise questions:
- Is content stored, and where?
- Who controls encryption keys?
- Which automated systems can inspect it?
- For how long are derived signals retained?
- What legal or safety exceptions apply?
- Can the customer audit or configure the process?
- Does enabling a feature change the retention commitment?
“ZDR-compatible” should be translated into an actual data-flow diagram and contract.
Not every workflow should use zero retention
Some regulated or high-consequence processes require records. A credit, employment or claims decision may need evidence about the information used, the policy version and the human review.
The objective is not to delete accountability. It is to retain the minimum useful evidence in the organisation’s authorised system rather than allow uncontrolled copies across providers and logs.
A well-designed workflow can avoid retaining conversational content while preserving a structured decision record.
The Lexdatum view
Zero Data Retention is not a toggle at the end of procurement. It is an architectural property of the complete system.
The model provider’s commitment is one layer. The application must also control retrieval, temporary state, tools, traces, records and incident access.
Privacy and observability are not opposites. They become compatible when teams stop treating raw content as the only form of evidence.
Sources
Research note: This analysis is based on public information available on 31 August 2026. Product capabilities, prices and regulatory interpretations can change. Vendor-reported metrics are identified as such. This is not legal, security or investment advice.