OpenAI's abuse detection invents a third category of enterprise data

OpenAI is previewing a system it calls Private Safety Processing with early customers, and says it will begin rolling it out and publish a technical white paper in September ^[1][3]. The mechanism matters less for what it detects than for what it does to the wording of every Zero Data Retention contract already signed: it establishes a class of data that is analysed by machine, retained by nobody, and not readable by OpenAI staff ^[2][10].

The contradiction being patched is an old one. ZDR, as sold to eligible API customers, means prompts and model responses are not retained after a request is processed ^[5]. Abuse detection wants history. Existing safeguards evaluate requests individually, while the new system analyses related activity to find patterns of potential misuse ^[11]. OpenAI's answer is to leave content where the customer already controls it and run analysis there ^[8], with a second option in development that stores content on OpenAI infrastructure under customer-controlled encryption keys ^[9]. In both configurations, according to the company, automated systems return limited safety signals without revealing prompts or responses ^[10]. When a risk is detected, OpenAI receives a defined signal indicating the type of activity involved, which can inform enforcement decisions ^[13].

Which makes explicit what was always true: ZDR is a no-retention guarantee, not a no-analysis guarantee ^[1]. That distinction stayed theoretical while safeguards worked one request at a time. It stops being theoretical when the output is a cross-session behavioural signal about a named customer, because the signal is a new artefact, derived from customer content, held by the vendor, and capable of triggering account action ^[13].

There is also an existing carve-out that DPIA authors should already have logged: images flagged as potential CSAM may be retained for manual review and reporting ^[6]. Any document that treats ZDR as absolute is wrong on its own terms.

The appeals design is where the operational burden lands. Because OpenAI personnel are restricted from the underlying content ^[2], customers investigate alerts using information available in their own systems and decide what to share in order to appeal a decision, clarify legitimate activity, or support an investigation into verified abuse ^[14]. Read that as a logging requirement rather than a courtesy: an organisation that cannot reconstruct the session behind a signal cannot contest it ^[2].

OpenAI repeats that enterprise customer data is not used to train its models unless customers opt in ^[7], and frames the programme as collaborative, writing that "no AI lab can address emerging risks alone" ^[4]. Abridge CISO Zach Powers is quoted saying the level of partnership on trust and security is uncommon, citing direct work with OpenAI product, engineering, policy and leadership teams ^[12].

What to watch is the September white paper ^[3]: whether the signal taxonomy is published, how long signals persist, whether OpenAI characterises them as personal data, and how key control in the planned encrypted-storage option is evidenced to an auditor rather than asserted ^[9]. Until that lands, the preview is a description of intent, not something a procurement team can attach to a schedule ^[3].