OpenAI тестирует Private Safety Processing для Zero Data Retention в frontier models

19 августа 2026 года OpenAI announced a preview of Private Safety Processing for eligible API customers using Zero Data Retention. Source: https://openai.com/index/offering-zero-data-retention-for-frontier-models/

Zero Data Retention means OpenAI does not retain customer prompts or model responses after processing a request, and customer content is not available to OpenAI personnel for review. The new preview addresses a specific enterprise problem: serious safety risks can appear across multiple related interactions, while existing ZDR-compatible protections evaluate interactions one request at a time.

How the preview works, according to OpenAI:

• customer content can remain on customer-controlled infrastructure in ZDR deployments;
• OpenAI is also developing an option where content is stored on OpenAI infrastructure, encrypted with customer-controlled keys;
• automated systems can produce limited safety signals about misuse patterns without exposing prompts or responses to OpenAI personnel;
• customers can investigate alerts in their own systems and choose what to share with OpenAI during appeals or abuse investigations;
• OpenAI plans to start rollout and publish a technical white paper in September 2026.

Private Safety Processing is an enterprise AI privacy pattern: safety monitoring has to work across agent sessions, but raw content access must stay constrained by the customer’s security model. Use ZDR when sensitive prompts, regulated data or contractual commitments make ordinary provider-side retention unacceptable.

Why this matters for API infrastructure: agentic workloads are longer than single chat completions, so governance has to track related calls, tool actions, retries and enforcement signals. For production teams, the practical question becomes where privacy, safety, logs, routing and fallback decisions live when the same application calls several model providers.

Production checklist: 1. Separate prompt/response retention policy from metadata retention policy in your architecture docs. 2. Log provider safety signals, 429 errors, timeouts and fallback events as different classes of events. 3. Check whether a backup model or router preserves the same privacy promise before sending failover traffic. 4. Keep customer-controlled keys and audit trails outside the application code that performs model calls. 5. Test long-running agent sessions, because risk, cost and rate-limit problems often appear across many related requests.

The safest production pattern is to treat privacy mode, safety signaling and model routing as one control plane. If a team routes around provider failures without checking retention and audit requirements, failover can solve availability while breaking compliance.