
Summary
- OpenAI says it will continue offering zero data retention (ZDR) to eligible API customers
- The company previewed "private safety processing," a system that detects misuse risk without human review of content
- When an alert fires, OpenAI only sees the risk category and severity — it's the customer who decides whether to share the actual content
No logs kept, so how do you catch the risks?
On August 19, OpenAI announced on its blog and X account that it will keep offering zero data retention (ZDR) to eligible API customers, extending the policy to frontier models as well. Alongside that, the company previewed a new safety system called "private safety processing," designed to catch misuse without any human ever looking at the content itself. As businesses hand AI longer, more autonomous tasks, OpenAI is trying to resolve a tension: how do you spot dangerous behavior if you're not keeping a record of what happened?
What zero data retention actually means
ZDR is OpenAI's policy of not storing the requests and responses that pass through its API. It's a condition that enterprise customers in industries like law, healthcare, and finance — where conversation data simply can't leak — have long demanded before adopting the API, and this announcement reconfirms that the policy now covers frontier models too. The catch is that if nothing gets stored, the safety team loses any way to check for abuse after the fact. That's the gap OpenAI says it's addressing with private safety processing, which it described on X as "designed to improve safety" without compromising on data retention.
A system built to spot risk without reading the content
According to the flow OpenAI published, an API request first passes through the "private safety processing" stage — a step that OpenAI employees cannot access. The request data is encrypted and stored in infrastructure the customer controls, and the following "automated safety review" step determines whether misuse is occurring without any human review and without the content ever being held on OpenAI's servers.
| Stage | Description |
|---|---|
| API request | Customer calls a frontier model |
| Private safety processing | Not accessible to OpenAI staff |
| Customer-controlled data storage | Encrypted, managed by the customer |
| Automated safety review | Detects misuse without human review or server-side storage |
| Customer alert (solid line) | Customer reviews the alert and decides whether to share content |
| OpenAI alert (dotted line) | OpenAI sees only category and severity; content stays private |
Once an alert fires, who's actually in charge?
If the review flags a risk, notifications go out in two directions. One goes to the customer, who can investigate the alert directly and choose to share the content with OpenAI if they decide it's warranted. The other goes to OpenAI — but all OpenAI sees there is the risk's category and severity, not the actual content. In other words, the final call on whether content ever gets disclosed rests with the customer, not with OpenAI.
How far does this go right now?
This announcement applies to eligible API customers who were already using ZDR. Private safety processing is still described as a "preview," and OpenAI hasn't said how broadly it will roll out or whether it will ever extend to regular ChatGPT users. Notably, on August 13, OpenAI added a "computer history" feature to the ChatGPT desktop app that logs users' computer activity — meaning the same company is simultaneously building features that remember more, for longer, and a policy built around keeping nothing at all.
Editor's take
One of the first questions enterprise customers ask when evaluating an API is where their data ends up. ZDR is really just a reaffirmation of an existing answer to that question, but private safety processing pushes further. The promise of "we don't keep your data" and the promise of "we can catch dangerous misuse" are, by nature, in tension. What OpenAI has done here isn't resolve that tension — it's routed around it, by having an automated system look at content instead of a human, and by handing the final disclosure decision to the customer.
Anyone who's dealt with this kind of architecture in practice will recognize the pattern. In financial services API reviews, the sticking point is always satisfying both "are logs retained" and "can anomalies be detected" at once — and until now, you usually had to give up one to get the other. Designing things so that only an alert's category and severity change hands, not the content itself, reads as an attempt to satisfy both requirements simultaneously. Whether this actually keeps safety teams' response times fast, and whether automated review can match the precision of human review, remains unverified since it's still just a preview.
For companies in Korea using the OpenAI API, the practical homework is checking with their account rep on whether ZDR was already part of their contract terms, and whether private safety processing requires a separate opt-in. It's likely that within a few weeks this moves from preview to general availability, at which point the eligibility criteria and pricing terms should become clearer.





Comments