Skip to content
Security · 7 min read

Zero retention vs zero logging

The privacy promises inference vendors make sound reassuringly absolute: zero retention, no logging, we don't train on your data. But these terms describe different controls, they operate at different layers of the stack, and vendors often use the warmest-sounding one to cover a much narrower commitment than you assumed. Here's what each claim actually means and how to verify it.

Priya Nair
Head of Security

Three promises, three different controls

These three terms are often used interchangeably in vendor marketing. They shouldn't be. Each one describes a distinct data handling decision, and a provider can satisfy one while violating the other two.

No training on customer data is the narrowest commitment. It means your prompts and completions are not fed into a model fine-tuning, RLHF or evaluation pipeline. It says nothing about whether the data is stored, logged or reviewed by humans. A provider can keep every prompt in a database for six months and still truthfully claim they don't train on it.

Zero logging means prompt and completion text does not appear in application logs, distributed traces, or any observability pipeline where it could be read by operators or persisted beyond the request lifetime. A provider can achieve zero logging and still write every request to a database for analytics — logging and storage are separate code paths.

Zero data retention is the strongest of the three. It means request content is never written to persistent storage, never captured in logs or traces, and never used for training. The content exists only in volatile GPU memory, for the duration of a single inference call, and is overwritten when the call completes. As explained in our zero data retention deep dive, this is an architectural invariant, not a policy flag — there is no code path that persists request content because no such code path was built.

How a vendor can be honest and still misleading

A vendor with a 'no training' policy and 30-day prompt storage can advertise the part that sounds best without lying. They might say 'your data is never used to improve our models' — true. They might omit that it sits in an S3 bucket with a 30-day lifecycle policy. That omission matters: a subpoena, a breach, or an insider threat can reach that stored data. The question of whether your provider logs prompts is not answered by the training policy; it requires asking about each data path separately.

Mapping each claim to a real control

  • No training — enforced by pipeline exclusion: your tenant's data is never routed to the training infrastructure. Verifiable via subprocessor list and DPA language.
  • Zero logging — enforced by observability design: the logging layer captures metadata (token counts, latency, error classes) but never ingests the request or response body. Verifiable via response headers and access-control review.
  • Zero retention — enforced by architecture: the inference runtime decrypts into GPU memory, computes, streams back, and overwrites. No write path to disk, S3, or any persistent store. Verifiable via architecture review and the DPA.

Which one actually protects your data

No training is table stakes — any inference vendor serving enterprise customers should offer it. But it's the weakest data protection control of the three. Zero logging prevents operational exposure: it means a support engineer can't pull your prompt during a debug session, and an observability breach doesn't leak your content. Zero retention eliminates storage risk entirely: there is nothing to subpoena, nothing to breach, nothing to accidentally include in an analytics export.

The hierarchy is clear. If you had to choose one commitment to verify first, make it retention — because without storage, logging and training become mostly academic. If the data was never written anywhere, it can't be logged, and it certainly can't be trained on. This is why SOC 2 Type II audits treat data retention controls as foundational to the entire trust services criteria: get retention right and downstream controls get easier. Get it wrong and you're compensating for it at every layer.

The test that cuts through the language

When a vendor makes a data handling claim, ask one question: is this guaranteed by architecture or by policy? A policy can change with a config flag. An architecture that lacks a code path to disk cannot be subverted without a full rewrite of the serving stack. That distinction is what separates a marketing claim from a control your auditor will accept. If the answer includes the word 'policy' more than 'architecture,' you're getting the weaker version. If you want to see how dedicated hardware reinforces these guarantees, start with why single-tenant GPUs matter for privacy and our zero-retention architecture.

Run this privately, in your own environment

A solutions engineer will scope a zero-retention deployment for your models and volume.

Talk to an engineer