The Honest Limits of Private AI (and Why "Zero Retention LLM" Is Usually False)

Every AI wrapper, agent, and assistant on the market right now wants you to believe your data vanishes the moment inference completes. The phrase "zero retention LLM" appears in pitch decks, pricing pages, and enterprise sales calls like an incantation — as if saying it makes it architecturally true. It usually isn't. What follows is a specific, grounded breakdown of where the claim breaks down, why the real threat model has shifted from training to discovery, and what we've learned shipping a product that calls frontier APIs while trying to keep its promises narrow enough to be honest.

Key Takeaways

Most "zero retention" claims apply only to a single layer of the stack — typically the model-provider API — and do not extend to caching layers, grounding services, file uploads, abuse monitoring, or the product's own infrastructure.
Even when a contractual zero-data-retention agreement exists, legal process (court-ordered preservation, litigation discovery) can override it — making discovery, not model training, the sharper privacy risk in 2026.
"Not trained on your data" and "not retained" are two separate controls; conflating them creates audit gaps that most enterprise buyers never catch.
Policy-based privacy promises are weaker than architecture-based ones — but even architecture has honest limits when any slice of a request must reach a frontier provider at inference time.
At Selina, we encrypt content at rest and use zero-knowledge encryption for files and transfers (SelinaSEND), but memory is NOT end-to-end encrypted — because a slice of each request reaches a frontier provider. We keep non-content operational metadata for a short retention window, not zero. Stating the limit plainly is the point.

What Does "Zero Data Retention" Actually Mean in Practice?

It means less than you think. At a technical level, zero data retention (ZDR) is a contractual agreement between an application developer and a model provider: prompts and completions are not persisted after the response is returned. No logs on the provider side. No use for training. That's the theory.

In practice, ZDR is not automatic or default at any major provider. Standard API usage typically retains data for 30 days for abuse monitoring and may feed model improvement unless the customer explicitly opts out. True "zero retention" is a separate agreement — usually an enterprise add-on, sometimes gated behind spend thresholds or sales conversations.

Even when granted, the coverage is narrower than the name implies. Certain metadata and abuse-monitoring data may still be retained for a limited window to satisfy legal obligations and safety requirements. "Zero" doesn't mean zero in every sense. It means zero for a specific data category, on a specific endpoint, under a specific contract — with carve-outs.

Why Is ZDR Coverage Inconsistent Even Within One Provider?

Because product suites are not monoliths. A provider may offer ZDR on its API while retaining data freely on its consumer chat product, its team plans, and its file-upload endpoints. An employee using a provider's chat interface through a browser isn't protected by the API-level ZDR policy — even if the company has an enterprise API agreement in place.

This gets worse when you look at specific features. Google's Gemini API documentation shows that state storage is enabled by default on the Interactions API, requiring an explicit opt-out, and the Live API retains session state for up to 24 hours if a session handle is generated. You have to verify ZDR feature-by-feature, endpoint-by-endpoint. If you assume it applies product-wide, you're wrong.

This is the operational reality we navigate at Selina. We route requests through a stack of frontier models, routed per task. Each of those providers has its own retention surface. We negotiate and verify ZDR where it's available, but we don't pretend the result is hermetic. Non-content operational metadata is kept for a short retention window. We don't call that zero retention because it isn't.

How Are "Not Trained On" and "Not Retained" Different?

They are two separate controls, and conflating them is one of the most common audit failures in enterprise AI procurement. Excluding data from model training is available on enterprise accounts independently of ZDR. You can have training exclusion without retention deletion, and vice versa.

The distinction matters because the risk profiles are different. Training risk is about your data influencing future model outputs — a diffuse, probabilistic concern. Retention risk is about your data existing as a retrievable artifact on someone else's infrastructure — a concrete, discoverable concern. If you only check the "not trained on" box and assume retention is covered, you've left the sharper risk unaddressed.

When we built Selina's data pipeline, we had to map this distinction across every provider we route through. The question set is unglamorous but necessary: Does this endpoint retain prompts? For how long? Is that retention contractual or configurable? Does the file-upload path share the same policy as chat completions? What about grounding or web-search features? The answers are rarely the same twice.

Why Is Litigation Discovery — Not Training — the Real Leak Vector?

Because courts don't care about your retention policy. In January 2026, US District Judge Sidney Stein affirmed an order compelling OpenAI to produce a 20-million-log sample of ChatGPT conversations in the consolidated copyright MDL. Not a subset. Not cherry-picked examples. The entire sample.

The court's reasoning was straightforward. Users voluntarily submitted their communications — unlike wiretap subjects — so privacy objections carried less weight. You typed it into a chat box. That fact, legally, weakens your expectation of privacy in discovery.

OpenAI itself acknowledged that a court order forced it to retain consumer ChatGPT and API content going forward, even as the company said it was actively challenging the order. The friction is in the gap between marketing messaging and legal reality: you can market deletion and ZDR, but your terms of service also reserve the right to preserve and disclose data to comply with legal process.

As legal analysis from Terms.Law pointed out, this case stopped being just a copyright dispute the moment the court turned to user chat logs. It became a precedent for whether any data that passes through a frontier model can be compelled into evidence.

This is the threat model that most "zero-retention" marketing ignores entirely. ZDR protects you from routine data persistence. It does not protect you from a preservation order. If data existed on a provider's servers at any point — even transiently — a court can order that provider to start retaining it going forward. The legal surface is not the same as the technical surface.

What Does This Mean for Products Built on Frontier APIs?

It means every product that calls a frontier API has an honest limit — and most won't tell you what it is.

Here's ours. At Selina, content in your account is encrypted at rest. Files and transfers through SelinaSEND use zero-knowledge, end-to-end encryption — we can't read them by design. But memory is NOT end-to-end encrypted and is NOT zero-knowledge encrypted. A slice of each request reaches a frontier provider at inference time. That's the architectural reality of any product that uses external models for reasoning. We can encrypt what we store. We cannot encrypt what we send to a model for processing without making the model unable to process it.

This is not a disclaimer bolted on. It's the central design constraint. The moment you call a frontier API, you've introduced a data-processing layer you do not fully control. You control what you send. You control how you redact, truncate, or anonymize before sending. You control the contractual terms under which the provider handles it. But you do not control the provider's infrastructure, its legal exposure, or its response to a court order.

Any product that claims otherwise is either lying or confused about its own architecture.

What's the Difference Between Policy-Based and Architecture-Based Privacy?

Policy-based privacy is a promise. Architecture-based privacy is a constraint. The difference matters because promises can be overridden — by internal policy changes, by acquisitions, by court orders — and constraints cannot, or at least not without rebuilding the system.

ZDR agreements are policy-based. They say: "we promise not to store this." Encryption at rest is architecture-based — the data is unreadable without the key, regardless of policy. End-to-end encryption is a stronger architectural constraint — even the service operator can't read the data, because they never hold the key.

The industry is starting to recognize this gap. Vercel's AI Gateway now handles ZDR negotiation and enforcement at the infrastructure level, routing requests only to providers with verified zero-data-retention agreements — reflecting the acknowledgment that contractual promises alone aren't sufficient. The enforcement moved from legal to technical.

A more ambitious approach is confidential computing — running inference inside trusted execution environments (TEEs) where even the cloud provider's infrastructure can't access the data during processing. Industry projections suggest that by 2026, over 60% of enterprises processing sensitive AI data will require TEE-based isolation as a deployment condition, up from under 15% in 2024. The pitch: computation happens inside an isolated, encrypted memory region. The reality: TEEs add latency, limit model size, and are not yet widely available for frontier-scale models. The gap between "technically possible" and "production-ready at frontier quality" is real.

At Selina, we sit in the honest middle. Files and transfers are zero-knowledge encrypted — that's an architectural guarantee. Memory encryption at rest is architectural. But the inference path is policy-governed, not cryptographically sealed, because we call frontier models. We think that's the truthful description of where we are, and where most products that use external models actually are, whether they say so or not.

How Should You Audit a "Zero Retention" Claim?

Ask the questions that vendors don't volunteer answers to. Here's the checklist we'd use — and that we think any buyer or builder should use — when evaluating a ZDR claim from any product that calls a frontier API.

Which endpoints does ZDR cover? Chat completions, file uploads, embeddings, image generation, web grounding, caching — each may have a different retention policy. ZDR applies at the model-provider layer and the data-connectivity layer separately; configuring it at one layer does not extend it to the other.
Is ZDR the default, or does it require opt-in? If it requires opt-in, what happens to data processed before the opt-in was configured?
What metadata is retained even under ZDR? Token counts, timestamps, model identifiers, IP addresses, rate-limit counters — these are often carved out. "Zero retention" of content with full retention of metadata is a common and misleading pattern.
What happens under legal process? Does the provider's terms of service reserve the right to preserve data in response to a litigation hold or court order? (The answer is almost always yes.)
Does the consumer product share the API's retention policy? If employees can access the same models through a browser-based chat interface, that traffic likely isn't covered by ZDR.
Is ZDR enforced contractually or architecturally? A contractual promise is breakable. An infrastructure-level enforcement — like routing through a gateway that blocks non-ZDR endpoints — is harder to accidentally violate.
Is "not trained on" being conflated with "not retained"? These are different toggles. Verify both independently.

If a vendor can't answer these questions endpoint-by-endpoint, their ZDR claim is marketing, not engineering.

What Are the Honest Limits of Privacy in a Product That Calls a Frontier API?

They are substantial, and pretending otherwise is worse than stating them.

The moment a product sends data to an external model, it creates a trust dependency it cannot fully verify. You can minimize what you send — redact PII, truncate context, use ephemeral sessions. You can maximize contractual protections — negotiate ZDR, mandate training exclusion, require data-processing agreements. You can encrypt everything you control — storage at rest, file transfers, local caches. But you cannot encrypt the inference itself without making inference impossible — at least not with today's frontier models at production quality.

This is the honest architecture of any AI assistant, agent, or copilot that uses external models. Selina included. We encrypt content at rest. We use zero-knowledge encryption for files and SelinaSEND transfers. We keep operational metadata for a short retention window — not zero — because we need it for abuse prevention and service reliability. We route through a stack of frontier models, routed per task, under the strongest retention agreements we can negotiate. And we state, plainly, that memory is NOT end-to-end encrypted because a slice of each request reaches a frontier provider.

The alternative — claiming zero retention when it isn't architecturally zero — is a bet that no one will check. That MDL ruling suggests that bet is getting worse. Courts are checking. Regulators are checking. And eventually, your users will check too.

Where Does the Industry Go From Here?

Toward verifiable constraints, away from contractual promises — but slowly, and with its own set of honest limits.

TEE-based inference is the obvious technical direction. If you can run a model inside a hardware enclave that the cloud provider itself can't inspect, you've moved from "we promise not to look" to "we can't look." Current work on confidential computing for AI inference is real, but the performance overhead is non-trivial, and frontier-scale models are not yet routinely deployed in TEEs at production latency. The gap will close. It hasn't closed yet.

In the meantime, the practical bar is layered defense with honest disclosure. Encrypt what you store. Minimize what you send. Negotiate ZDR where available. Enforce it architecturally where possible. And tell your users, clearly, where the guarantees end.

Most vendors won't do the last part. It's commercially inconvenient to say "here's what we can't guarantee." But the alternative is a claim that a court order, a terms-of-service update, or a routine audit can falsify overnight. We'd rather have the narrower, defensible claim.

Delete means gone. Actually gone — on our infrastructure. What a frontier provider does with the slice it processed is governed by contract, not by our architecture. That's the limit. We say it plainly because plainness is the only version of trust that survives contact with reality.

If you want to see how we handle these tradeoffs in practice — start a free 7-day trial, no card required.

Continue reading

Sources & References

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.