OpenAI is expanding Zero Data Retention support to its frontier models, but there is an interesting problem that comes with that promise. If OpenAI does not retain a customer’s prompts and responses, how can it detect dangerous behavior that only becomes obvious across multiple interactions?
The company thinks it has an answer called Private Safety Processing. While the technology is still being tested, the basic idea is fairly easy to understand once you get past the terminology.
Zero Data Retention, or ZDR, is available to eligible OpenAI API customers. Under ZDR, OpenAI says it does not retain customer prompts or model responses after a request has been processed, and OpenAI personnel cannot review that customer content. Enterprise customer data is also not used to train OpenAI models unless the customer explicitly opts in.
That can be attractive to organizations dealing with sensitive information, including financial records, health information, confidential corporate data, and proprietary research. Sending that information to an AI model is one thing, but allowing the AI provider to keep a copy is another.
The problem is that ZDR can make certain types of safety monitoring more difficult. Imagine someone sends 20 requests to an AI model, with each request looking harmless when examined on its own. Taken together, however, those requests might reveal an attempt to bypass safeguards or use the model for something dangerous.
Existing ZDR-compatible safety systems evaluate interactions individually, according to OpenAI. That approach becomes more limiting as AI models take on longer and more complicated jobs where intent may only become apparent after several interactions.
AI agents make this even more important. An agent could begin a task with legitimate instructions but eventually behave in a way the user did not authorize, and OpenAI specifically gives the example of a system continuing to act after the user has told it to stop.
Private Safety Processing is designed to give automated safety systems more context without giving OpenAI employees access to the actual customer content. Essentially, OpenAI wants its computers to spot suspicious patterns without letting its people read what customers are saying.
For ZDR deployments, the content can remain on infrastructure controlled by the customer. OpenAI is also developing an option where the information can be stored on OpenAI infrastructure but encrypted using keys controlled by the customer, and OpenAI says its personnel would not have copies of those keys.
The automated safety system can then examine patterns across related interactions. If it detects something potentially dangerous, OpenAI receives what the company describes as a narrowly defined safety signal rather than the underlying prompts and responses.
One way to think about it is a security alarm inside a locked room. OpenAI does not have the key to the room and cannot see what is happening inside, but the alarm can still report that something potentially dangerous has happened.
That signal could then be used to determine whether enforcement is necessary, but OpenAI says its personnel still would not gain access to the customer content after something is flagged. Customers would instead investigate using information available in their own systems.
If a customer wants to appeal an enforcement decision, explain legitimate activity, or assist OpenAI with an investigation into verified abuse, it could choose to share the relevant information. In other words, a safety alert does not automatically give OpenAI permission to open the door and inspect the underlying conversations.
There is a bigger story here than another enterprise privacy feature. OpenAI is effectively acknowledging that evaluating individual prompts becomes less useful as frontier AI systems become more capable because dangerous intent may develop across a conversation, repeated attempts to probe safeguards, multiple accounts, or a long-running agentic task.
That creates an uncomfortable tradeoff for AI companies and their customers. Better safety monitoring benefits from more context, while better privacy generally means giving the AI provider access to less information.
Private Safety Processing is OpenAI’s attempt to satisfy both requirements. There is also an obvious business incentive to make it work, since companies in healthcare, finance, research, and other sensitive industries may have strict rules about where information can be stored and who can access it.
Asking those organizations to surrender Zero Data Retention in exchange for access to more capable models could make frontier AI considerably less attractive. Giving them stronger models while allowing sensitive information to remain under their control is a much easier proposition to sell.
The big unanswered questions are technical. OpenAI explains what Private Safety Processing is supposed to accomplish, but the interesting details will be exactly how automated systems analyze customer-controlled or customer-key-encrypted information while preventing OpenAI from accessing the underlying content.
We should learn more soon, as Private Safety Processing is currently being tested with early customers. OpenAI says it plans to begin rolling out the technology in September and will publish a technical white paper explaining its approach.
For now, the easiest way to understand Private Safety Processing is that OpenAI wants its systems to recognize potentially dangerous patterns across AI activity without giving OpenAI employees the ability to read the conversations themselves. If the technology works as advertised, stronger AI safety monitoring and Zero Data Retention may not be as contradictory as they initially sound.
Support independent tech journalism
NERDS.xyz is independently owned and operated. If you enjoy my coverage of Linux, AI, hardware, cybersecurity, and tech culture, consider supporting the site on Ko-fi.
Support NERDS.xyz