Zero Data Retention and OpenAI's Private Safety Processing

Zero Data Retention means OpenAI doesn't store your prompts or completions after a request, and doesn't use them to train models, which removes the logging barrier that has blocked regulated teams from frontier APIs. On August 19, 2026, OpenAI reaffirmed Zero Data Retention for frontier models and previewed Private Safety Processing, a way to catch safety risks across turns without keeping your content. The catch: "no retention" is not "no processing," so security teams still have things to verify. At Van Data Team, we help teams do that verification.

Key Takeaways

• On August 19, 2026, OpenAI reaffirmed Zero Data Retention for frontier models: prompts and completions aren't stored after a request or used for training, for eligible API customers.
• OpenAI also previewed Private Safety Processing, a system that checks safety risk across related interactions without personnel accessing your content. It rolls out with a white paper in September.
• This matters because logging and retention were the main blockers stopping regulated teams, in finance, defense, and healthcare, from routing sensitive data through frontier APIs.
• The framing is competitive: per TechCrunch and Axios, OpenAI is contrasting ZDR with Anthropic's retention window for enterprise.
• Van Data Team's recommendation: treat Zero Data Retention as a lever, not a guarantee you can skip verifying. Confirm eligibility, read the terms, and wait for the PSP white paper before relying on it.

What Did OpenAI Announce?

OpenAI announced two things: it will keep offering Zero Data Retention for frontier models, and it previewed a private way to run safety checks across a conversation.

Reported fact: On August 19, 2026, OpenAI reaffirmed Zero Data Retention for frontier models. For eligible API customers, OpenAI does not retain prompts or model responses after a request is processed, and does not use them for training. That's the core promise, and it's the one that unblocks regulated deployments.

The second announcement is Private Safety Processing, or PSP. OpenAI's reasoning is that some risks only appear across interactions, not in a single prompt. Their example: someone asks about a weakness in a company's software in one conversation, then asks about remote access in another.

PSP is meant to spot that pattern across related interactions, without OpenAI personnel accessing retained content. According to Axios, OpenAI plans to roll out PSP and publish a technical white paper in September.

There's a competitive edge to the timing. TechCrunch frames it as OpenAI trying to one-up Anthropic, which reportedly requires a retention window for enterprise customers on its latest models. Treat the vendor comparison as context, not gospel, and verify each provider's current terms yourself.

What Is Zero Data Retention, Really?

Zero Data Retention is a promise about storage, not a promise about processing. Getting that distinction right is the whole point.

Van Data Team analysis: Under ZDR, your prompt is sent, the model processes it, a response comes back, and nothing is written to durable storage afterward. It isn't logged for humans to read later, and it isn't fed into training. That's genuinely valuable. It's also narrower than "OpenAI never sees my data."

The model still reads your content to answer it. Safety systems still run. The data crosses the network and lives in memory during the request.

So ZDR removes the retained trail, which is what most compliance regimes care about, but it doesn't make the request invisible. The table below draws the line.

How Does Private Safety Processing Fit?

Private Safety Processing exists to resolve a real tension: good safety usually wants history, but retention is exactly what regulated customers can't accept.

Van Data Team analysis: Think about how abuse detection normally works. To see that someone is building toward something harmful, a system looks across their activity over time. That's the opposite of statelessness. So there's a genuine conflict between "catch multi-turn risk" and "keep nothing."

PSP is OpenAI's answer to that conflict. The claim is that automated systems can spot risky patterns across related interactions without any person seeing the underlying content, and without breaking the retention promise. If it holds up, that's a meaningful piece of engineering: safety without a human-readable log.

But it's a preview, and the details matter. The whole value rests on the trust boundary, what the system can see, what it retains even briefly, and who can access it. That's precisely what the September white paper should spell out.

Until then, treat PSP as a direction of travel, not a control you can cite in an audit. The same skepticism we bring to any autonomous safety system, described in our guide to defensive AI agents, applies here.

What Should You Verify Before Trusting Zero Data Retention?

Verify the boundary before you route anything sensitive, because Zero Data Retention is only as good as the terms and the scope it actually applies to.

Treat it like any zero-trust decision: don't assume, confirm. The checklist below is the practical work.

• Eligibility and scope: confirm your specific account, endpoints, and models are covered by ZDR, not just that ZDR exists somewhere.
• The contract: read the data processing terms and any exceptions, and make sure "no retention" is written down, not just implied.
• Data classification: decide what you're allowed to send even under ZDR, because the least-risk data is the data you never transmit.
• The trust boundary: be clear that you're trusting an attestation. Decide whether attestation plus contract is enough for your regulator, or whether you need more.
• Your own controls: you still own the content before it leaves your systems, so keep redaction, access control, and logging on your side of the line.
• PSP timing: don't build a compliance claim on Private Safety Processing until the white paper lands and you've read how the trust boundary actually works.

One more item is easy to miss: data residency. ZDR is a promise about whether data is kept, not about where it's processed. If your regulator cares about geography, confirm the processing region separately. "Not retained" and "processed in your jurisdiction" are two different promises, and a workload can need both.

None of this cancels the benefit. It just keeps the benefit honest. ZDR genuinely removes the biggest blocker, and doing this verification is how you turn a vendor promise into a decision you can defend in front of an auditor.

What Does Zero Data Retention Unlock?

For a regulated team, Zero Data Retention changes what you're allowed to send, not just how fast you can move.

Think about the workflows that stalled. A bank wanted to summarize customer support transcripts, but couldn't accept a retained copy sitting on a vendor's servers. A defense contractor wanted to draft from sensitive documents, but a retention trail was a non-starter. A hospital wanted to structure clinical notes, but patient data can't be logged for training.

In each case, the model could do the work. The retention policy was the wall. ZDR takes down that wall for the cases where retention was the only blocker. Here's what it tends to unlock:

• Pilots on real data, instead of synthetic stand-ins that never quite behave like production.
• Sensitive summarization and extraction, where the input is confidential but the output is useful.
• Multi-turn assistants on regulated content, once PSP ships and you've read how it works.
• Faster procurement, because "nothing is retained" is a shorter security review than "here's how we protect what we keep."

It doesn't unlock everything. Some data is barred from leaving your walls by policy, no matter the retention terms. Some regulators want more than an attestation. But for the large middle ground, where the data was fine to process and only the storage was the problem, ZDR is the difference between blocked and shipped.

That middle ground is bigger than most teams assume. A lot of "we can't use AI on that" turns out to mean "we can't retain that," and those are not the same constraint. Separating the two is often the fastest win available, because it reclassifies workloads you'd already written off.

What Were Teams Doing Before?

Before Zero Data Retention, regulated teams had three unappealing options, and each one cost time or capability.

• Skip the frontier model entirely, and settle for a weaker self-hosted one you could fully control.
• Negotiate a custom legal exemption, which meant months of contract work for every new use case.
• Stand up an offline or dedicated deployment, which is expensive and slow to keep current.

Each of those trades something real away. Self-hosting caps you at whatever model you can run yourself. Custom contracts don't scale across teams. Offline deployments lag the frontier by months and carry heavy operational cost.

ZDR collapses that. If retention was the only reason you couldn't use a standard endpoint, you can route through it under the same terms now, without a bespoke exemption or a separate stack to babysit. That's the practical shift: the same API everyone else uses, on data you couldn't send before.

Should You Route Sensitive Data Through It Now?

Route sensitive data through it when you've verified eligibility and terms, and hold back on anything that depends on Private Safety Processing until it ships.

Van Data Team analysis: For many regulated teams, ZDR is the unlock they've been waiting for. If logging and retention were the reason you kept frontier models out of a sensitive workflow, and ZDR is contractually confirmed for your setup, the barrier is genuinely lower now. You can pilot on real data instead of synthetic stand-ins.

Be more cautious where PSP is load-bearing. If your safety story depends on catching multi-turn abuse privately, that capability is previewed, not shipped. Design for it, but don't promise it to your risk committee yet. And keep your own guardrails running regardless, because a provider's safety layer is a complement to yours, not a replacement, a point we make in our guide to governing agentic AI and securing AI-generated code.

A quick rule of thumb helps here. Sort each workload into one of three buckets:

• Go now: retention was the only blocker, ZDR is contractually confirmed for your account, and the workflow doesn't depend on PSP. Pilot on real data.
• Design now, ship later: the workflow needs multi-turn safety that PSP is meant to provide. Build it, but wait for the white paper before you promise it to your risk committee.
• Hold: policy bars the data from leaving your walls at all, or your regulator wants more than an attestation. ZDR doesn't change that, so keep it in-house.

Most teams find more workloads in the first bucket than they expected. The point of the exercise is to stop treating "AI plus sensitive data" as one blocked category, and start sorting it by the specific reason each workload was blocked.

If you want help scoping this, our AI agent and platform services can review your data flows, confirm what ZDR actually covers for your account, and design the controls that sit around the API. The goal is a deployment your security and compliance teams can sign off on, not just a demo that works.

Zero Data Retention Is a Lever, Not a Free Pass

Zero Data Retention meaningfully lowers the barrier to using frontier models on sensitive data, but it rewards teams that verify the terms rather than assume them.

OpenAI's move is real and useful. Not storing prompts or completions is exactly what unblocks finance, defense, and healthcare workloads, and Private Safety Processing is a thoughtful attempt to keep safety without keeping data. The direction is good.

The discipline is unchanged. Confirm your eligibility, read the data terms, classify what you send, keep your own controls, and wait for the PSP white paper before you lean on it. Do that, and you get the upside without betting your compliance posture on a headline. Explore more security and agent-operations guidance from Van Data Team, or use the checklist above to decide what you can route through the API this quarter.