이미지: X — 프론티어랩 화면 갈무리
Summary
- OpenAI said it will continue its zero data retention (ZDR) policy for eligible API customers
- It previewed "private safety processing," which detects abuse risks without humans viewing the content
- When an alert is triggered, OpenAI only sees the category and severity of the risk, while the customer decides whether to share the actual content
- 발표 채널
- 오픈AI 블로그·X 계정, 2026-08-19
- 기존 정책
- 적격 API 고객 대상 제로 데이터 리텐션(ZDR) 유지
- 신규 기능
- 프라이빗 세이프티 프로세싱(미리보기)
- 데이터 저장
- 고객 통제 하 암호화 저장
- 오픈AI 열람 범위
- 경보의 범주·심각도만, 콘텐츠는 비공개
- 고객 권한
- 경보 확인 후 오픈AI 공유 여부 직접 결정
No conversation logs kept — so how do you catch risks?
On August 19, OpenAI announced via its blog and X account that it will continue its zero data retention (ZDR) policy for eligible API customers, extending it to frontier models as well. At the same time, it previewed a new safety system called "private safety processing," which detects abuse risks without having a human directly review the content. As enterprises hand off longer and more autonomous tasks to AI, this is an attempt to resolve the contradiction of needing to catch risks without storing conversation data.
What zero data retention means
ZDR is a policy under which OpenAI does not keep requests and responses processed through its API on its servers. It's a condition that enterprise customers in industries like law, healthcare, and finance — where conversation content must not leak — have long required when using the API, and OpenAI's announcement reaffirmed that this policy will continue to apply even to frontier models. The problem is that if no data is retained at all, the safety team also loses any way to check for misuse after the fact. This is the context behind OpenAI's post on X stating that it is "previewing private safety processing, designed to improve safety."
A structure that catches risks without seeing content
According to the published flowchart, API requests first pass through a "private safety processing" stage. OpenAI employees cannot access this stage. The request data is encrypted and stored in customer-controlled storage, and the subsequent "automated safety review" stage determines whether abuse has occurred without human review or content retention on OpenAI's servers.
| Stage | Description |
|---|---|
| API request | Customer calls a frontier model |
| Private safety processing | Not accessible to OpenAI employees |
| Customer-controlled data storage | Encrypted, managed by the customer |
| Automated safety review | Detects abuse without human review or server-side storage |
| Customer alert (solid line) | Customer reviews the alert and decides whether to share |
| OpenAI alert (dotted line) | Only category and severity visible; content stays private |
Once an alert fires, who decides what happens next
If the review detects a risk, notifications go out along two paths. One is an alert sent to the customer, who can investigate it directly and choose to share the content with OpenAI if deemed necessary. The other is an alert sent to OpenAI, but in this case OpenAI can only see the risk's category and severity — the actual content is not displayed. In other words, the final decision on whether to disclose content rests with the customer, not OpenAI.
How far does this apply for now
This announcement applies to eligible API customers who have already been using ZDR. Private safety processing is introduced only as a "preview" stage, and the announcement does not specify the full scope of rollout or whether it will extend to general ChatGPT users. On August 13, OpenAI added a "computer history" feature to the ChatGPT desktop app that records users' computer activity — meaning a feature that remembers more data for longer and this new policy of retaining none at all emerged from the same company around the same time.
Editor's view
One of the first questions enterprise customers ask when choosing an API is "where does my data end up." ZDR is just a reaffirmation of the answer to that question, but private safety processing is a step further. A promise not to retain data and a promise to filter out dangerous use inherently conflict with each other. What OpenAI has offered here isn't a way to eliminate that conflict, but a workaround — having an automated system, not human eyes, view the content, and handing final disclosure authority to the customer.
For teams that have dealt with this kind of structure in practice, the pattern is familiar. When reviewing API adoption in the financial sector, the condition that always comes up is satisfying "are logs kept" and "can anomalies be detected" at the same time — and until now, one of the two usually had to be sacrificed. A design where only the category and severity of an alert are exchanged, not the content itself, reads as an attempt to satisfy both requirements simultaneously. However, whether this structure will actually slow down the safety team's response time, and whether automated review will be as sophisticated as human review, remains unverified since it's still in preview.
For companies in Korea using the OpenAI API, the practical homework is to check with their account managers whether ZDR was already included in their contract terms and whether private safety processing requires a separate application. There's a good chance that within a few weeks, as this feature moves to general availability, the scope of application and pricing terms will be disclosed in detail.
