Brave Leo now runs on NEAR AI Cloud
NEAR AI
Sign inStart building
← All articles

Zero Data Retention Isn't Enough

Michael Coburn & Cameron DennisInterim CISO · Director of AI Ecosystem
Zero Data Retention Isn't Enough

Zero data retention doesn't mean what you think it means.

Zero data retention is what most AI labs use to build trust with enterprises. But for most customers, your data sits on the provider's servers for up to 30 days, readable by the provider (Anthropic, n.d.-b; OpenAI, n.d.-b). They should call that default what it is: 30-day retention, not zero retention.

There is a better standard: verifiable privacy. Under verifiable privacy, the provider does not merely promise it cannot see your data; it gives you proof you can check yourself.

Zero data retention is a contractual promise. Verifiable privacy is a technical proof you can check yourself.

What ZDR actually is

Zero data retention (ZDR) means a provider commits not to retain your inputs or outputs after a request completes: no logs, no training use. However, this commitment is contractual rather than technical. It does not address what can happen to your data during processing or the policy's underlying exceptions.

ZDR isn't even the default

ZDR is something you have to negotiate for, usually through sales, not something switched on for everyone (Anthropic, n.d.-c; OpenAI, n.d.-b). Consumer plans, free and paid, generally don't get it at all (Anthropic, n.d.-c; Claburn, 2026). By default, OpenAI keeps abuse-monitoring logs for up to 30 days; ZDR is the exception you apply for (OpenAI, n.d.-b).

And even once you have it, the "zero" carries exceptions. Anthropic's ZDR terms still keep safety-classifier results, and allow storage where needed to combat misuse (Anthropic, n.d.-c). For its most capable models, Anthropic required 30 days of retention from June 2026, even for ZDR customers (Anthropic, n.d.-a; Claburn, 2026). OpenAI retains images flagged as potential child sexual abuse material for review and legally required reporting, even under ZDR (OpenAI, 2026). Without ZDR, flagged conversations at Anthropic can be kept for up to 2 years (Anthropic, n.d.-b). The "zero" is doing a lot of work it hasn't earned.

There's a real reason for this, and it isn't a conspiracy. Abuse monitoring requires that someone, or something, can see the data. Turning that visibility off can also cost features. At OpenAI, extended prompt caching stores data derived from your prompts for up to 24 hours, so it is not ZDR-eligible (OpenAI, n.d.-a). Providers aren't hiding the tradeoff so much as the architecture forces it: if the host has to see your data to protect against misuse, it can't also promise never to look.

Providers are now trying to have both. OpenAI's Private Safety Processing, now rolling out to API customers, and Anthropic's Enterprise Frontier Safeguards aim to keep abuse detection while moving stored content under the customer's control (Claburn, 2026; OpenAI, 2026). Both are steps forward. Both still ask the customer to trust that the provider sees only what it says it sees.

By default, prompts outlive the request: readable by the provider while it runs, default logs for 30 days at both labs, flagged chats kept up to 2 years and classifier scores up to 7 years at Anthropic.

The window nobody sees into

Even under ZDR, data is visible to the provider while it's processed, and it can be retained under the exceptions above. Who accessed it during that window? What ran against it? ZDR gives you no way to check. "Deleted" means the original, not what was derived from it. Anthropic, for example, keeps classification scores for up to 7 years on conversations its systems flag as policy violations (Anthropic, n.d.-b). Even under ZDR, it retains safety-classifier results (Anthropic, n.d.-c).

Every prompt carrying your contracts, code, or strategy sits on someone else's infrastructure, on a trust-me basis. At scale, that's not a minor leak. It's an aggregate fingerprint of how your company thinks, accumulating inside one provider's systems.

And data the provider can read isn't just a trust question. It's a target. A breach. A legal subpoena. A disgruntled employee with access they shouldn't have. ZDR is a retention commitment, not an access control. It was not designed to defend against any of that, because the data is still readable while it's there.

A working precedent: screen before you trust

After the September 24, 2026 Bitget hack, NEAR Intents' SHIELD screened cross-chain transfers before settlement. By NEAR Intents' own estimates, it flagged more than $50 million in attempted laundering and froze $503,000 mid-execution (Gomez, 2026; Redman, 2026). Most of the flagged funds were turned away rather than recovered; they moved to other providers (Gomez, 2026; Le Journal du Coin, 2026). Screen first, act only on a genuine flag.

SHIELD works because blockchain data is already public. There's nothing to hide while it screens: it checks addresses and transaction patterns against signals from blockchain intelligence firms (Gomez, 2026; Le Journal du Coin, 2026; Redman, 2026). Screening private data is harder, because the checker must inspect the content itself. The open question: what does that pattern look like for private data? Run the same kind of checker inside a trusted execution environment (TEE), a hardware-isolated enclave. Screening then happens without exposing raw content to anyone, including the provider.

What Europe gets right

We've been working more with enterprises in Europe, and the common line is that they're slow to adopt AI. What that misses is how much they care about human creativity and integrity in a post-AI world. They understand more than people give them credit for.

We don't agree with everything regulators there have pushed for, but we do think a baseline of privacy regulation is good for society. The General Data Protection Regulation (GDPR) already asks for the how as well as the what. Article 25 requires data protection by design and by default, built into the technology itself (Regulation (EU) 2016/679, 2016, art. 25). What lags is the practice. Proving it still means paperwork, audits, and after-the-fact trust. That's the part that holds innovation back, not the principle underneath it.

The answer isn't less regulation. It's regulators being flexible enough to let technology supply that baseline in a scalable, automated, programmatic way. We need to better automate compliance, not just write more policy.

Private programmatic compliance

GDPR requires a lawful basis and purpose limitation for processing personal data (Regulation (EU) 2016/679, 2016, arts. 5(1)(b), 6). The EU AI Act adds governance and transparency duties. Most of its transparency obligations apply from August 2026, and its high-risk obligations now phase in through 2027–2028 (Șerban & Marcu, 2026). Today, proving compliance means trusting a provider's paperwork after the fact.

We would prefer a system that doesn't store your data at all. And if it has to, even briefly, it should be encrypted so the host cannot read it, with an attestation you can check yourself. That's a compliance engine running inside an enclave. It attests in real time which code processed the data, producing evidence for duties such as GDPR's purpose limitation and the AI Act's governance requirements, without the data ever leaving the enclave. Call it private programmatic compliance.

Done this way, it could supply much of the technical evidence Europe is asking for, at startup speed. It doesn't fight the intent of GDPR. It may fulfill parts of it faster.

What "verifiable" looks like

Verifiable privacy is not a slogan; it is a check any customer can run (NEAR AI, n.d.):

Three checks: request an attestation, check it, confirm the key.

  1. Request an attestation. The enclave produces a hardware-signed report of exactly what code is running and on what hardware.
  2. Check it. Compare that report against the published code and the hardware vendor's attestation service.
  3. Confirm the signature. Each response is signed by a key generated inside the enclave that never leaves it.

If any step fails, you know before your data goes in. That is the difference between a promise and a proof.

The honest caveat

This doesn't eliminate trust. It relocates it. The question becomes whether the logic inside the enclave is accurate and unbiased. Even SHIELD let roughly $166,000 slip through (Gomez, 2026; Redman, 2026).

It also relocates trust to the hardware, and to whoever physically controls it. Researchers built a memory-bus device for under $1,000 that extracted Intel TDX attestation keys. Their forged attestations passed Intel's own verification, and they showed NVIDIA GPU attestations could be borrowed from other machines (Chuang et al., 2026). The attack needs physical access, and Intel and AMD treat it as outside their threat model. Verifiable privacy therefore also depends on where the hardware sits and who can touch it.

That's still a far smaller, more auditable surface than trusting an entire company's internal practices. But it's a trust question worth naming. Verifiable privacy narrows the trust surface; it does not remove it.

Beyond the policy floor

The industry treats zero data retention as the privacy ceiling. It's actually the bare minimum. Verifiable privacy, attested by hardware and checkable by you rather than promised contractually, is where AI needs to go next.

Verify it yourself

If you want to use AI on data you can't afford to leak, start with one workload. NEAR AI Cloud runs open-weight models inside secure enclaves built on Intel and NVIDIA confidential computing. Every response is signed inside the enclave, so your team can check the proof against Intel and NVIDIA, not against us. These guarantees apply to NEAR-hosted models.

Disclosure: The authors work with NEAR AI. NEAR Intents and NEAR AI Cloud, referenced above, are part of the NEAR ecosystem.

References

More from NEAR AI