Zero Data Retention vs No Training: What Each One Actually Covers
Zero data retention and no training are two different promises. Retention is about whether your content is stored after a request finishes. Training is about whether it changes a model's weights. Neither implies the other, and a retention promise usually covers only the model provider — while seven other planes in a typical deployment keep their own clocks.
Two axes, not one
Almost every confusing vendor conversation about privacy comes from treating these as the same statement. They are not even measured the same way. A provider can hold your content for thirty days and never train on it. A different provider can train on your content and discard the original immediately. Both can truthfully use the word "private" in a headline.
| Zero retention | No training | |
|---|---|---|
| What is being promised? | Content is not kept after the request completes. | Content is not used to change model weights. |
| What does the opposite look like? | Content sits in a store somewhere with a lifetime. | Content becomes part of a future model's parameters. |
| How long does the exposure last? | Until the retention window elapses and backups age out. | Indefinitely, and it cannot be reversed by deletion. |
| Can you verify it yourself? | Partly — you can inspect the planes you operate. | No. This one rests entirely on the contract. |
| Does the other one follow from it? | No. Data can be retained and never trained on. | No. Data can be trained on without being retained afterwards. |
The practical consequence is in the last row. Ask for both commitments explicitly, in writing, and do not accept one as evidence of the other.
The eight planes a request can leave content on
"We retain nothing" is nearly always a statement about a single plane — the model provider. That is a real control and worth having. It is just not the same as your content being gone. A single request in a typical deployment touches eight places that can hold content, each with its own owner and its own lifetime.
01Workspace / conversation store
- What it holds:
- Chat threads, titles, and any content a user pinned or saved in the product itself.
- Who controls the clock:
- The workspace operator — you, or whoever runs the deployment.
- Commonly missed:
- A provider promising zero retention says nothing about this plane. The conversation can be gone from the provider and still sit in the product's own database indefinitely.
- Ask the vendor:
- Where is conversation history stored, who can delete it, and does deletion remove it from backups on a stated schedule?
02Model provider
- What it holds:
- The prompt and completion for the duration of the inference call, plus anything the provider keeps afterwards.
- Who controls the clock:
- The provider, under whatever contract governs the account.
- Commonly missed:
- This is the only plane most 'zero data retention' statements actually cover. It is a real and meaningful control — it is just not the whole picture.
- Ask the vendor:
- Is the zero-retention term contractual or a product setting, and does it survive a support escalation or an abuse investigation?
03Inference gateway / proxy
- What it holds:
- Request and response bodies passing through whatever routes traffic to the model, plus routing metadata.
- Who controls the clock:
- Whoever operates the gateway — often a third layer neither the customer nor the model provider.
- Commonly missed:
- Gateways log by default. A gateway that logs full request bodies quietly reintroduces content retention that both the workspace and the provider had eliminated.
- Ask the vendor:
- Does the gateway log request and response bodies, or only metadata? Show the configuration, not the policy.
04Files and attachments
- What it holds:
- Uploaded documents in their original form, plus any extracted text or intermediate conversions.
- Who controls the clock:
- The workspace operator, usually in object storage separate from the conversation store.
- Commonly missed:
- Deleting a conversation frequently leaves the uploaded file and its extracted text behind, because they live in a different system with a different lifecycle.
- Ask the vendor:
- When a conversation is deleted, what happens to the uploaded file, the extracted text, and any converted derivative?
05Embeddings and vector index
- What it holds:
- Numeric representations of document content, plus the chunk text most systems store alongside them for retrieval.
- Who controls the clock:
- The workspace operator.
- Commonly missed:
- The most consistently overlooked plane. Teams treat embeddings as anonymous math, but the stored chunk text sitting next to each vector is usually the source content verbatim.
- Ask the vendor:
- Does the index store the source text alongside the vectors, and does deleting a document remove both?
06Abuse and safety monitoring
- What it holds:
- Flagged prompts and completions retained for review, typically outside the normal retention policy.
- Who controls the clock:
- The model provider, sometimes the gateway operator.
- Commonly missed:
- Abuse-monitoring retention is often carved out of a zero-retention commitment entirely, and the carve-out is where content survives longest.
- Ask the vendor:
- Is abuse monitoring excluded from the retention commitment? If a request is flagged, how long is it kept and who reads it?
07Backups and snapshots
- What it holds:
- Point-in-time copies of every store above.
- Who controls the clock:
- The workspace operator, on the backup system's own schedule.
- Commonly missed:
- Deletion is not deletion until the backups age out. A thirty-day backup window means a thirty-day floor on real erasure, no matter what the product's delete button does.
- Ask the vendor:
- What is the backup retention window, and is a deletion request honoured inside backups or only going forward?
08Audit log
- What it holds:
- The record that a request happened — who, when, which model, which workspace. Content inclusion is a design choice.
- Who controls the clock:
- The workspace operator, deliberately.
- Commonly missed:
- This plane is supposed to persist. Treating it as a retention problem to be minimised away is how teams end up unable to reconstruct their own AI use.
- Ask the vendor:
- Can the audit log record the fact of a request without storing its content, and can retention be set independently of the conversation store?
Why an audit trail is not a contradiction
Teams that take minimisation seriously often arrive at an uncomfortable conclusion: if the goal is to keep nothing, an audit log looks like a violation of the goal. It is not, because it answers a different question. Every other plane holds what was said. The audit plane holds that a request happened — who asked, when, against which model, in which workspace.
Those can be separated. An audit record can carry full content, redacted fields, or nothing but metadata and a hash, and the right choice differs by organisation. What does not work is treating the audit plane as one more thing to minimise away, then being unable to reconstruct your own AI use when someone asks. The follow-on question — which of those three logging modes to pick, and where each one breaks — is its own subject.
How PrivateStack handles these planes
PrivateStack separates the audit plane from the content planes deliberately: the record that a request happened is kept under its own retention setting and its own access controls, independent of whether the conversation itself is kept. Workspace retention is a configurable setting rather than a fixed product behaviour, and the Enterprise deployment runs the data plane inside the customer's own AWS account, which moves several of these planes under the customer's direct control rather than ours.
The honest limit worth stating: no vendor can let you verify the model-provider plane yourself. That one rests on the contract, whoever you buy from. Everything else on the list above is inspectable, and you should insist on inspecting it. The full control set is on the security page, and the audit trail requirements checklist covers what the audit plane needs to carry.
Questions people actually ask
- Does zero data retention mean my data is not used for training?
- Not by itself. They are separate commitments on separate axes. A provider can retain content for thirty days and never train on it, or train on content it discards immediately afterwards. Ask for both in writing; do not infer one from the other.
- If a provider retains nothing, why would my workspace still have an audit log?
- Because they sit on different planes and answer different questions. The provider's commitment covers what the provider keeps. The audit log is your own record that a request happened at all — who asked, when, and against which model. It can record that a request occurred without storing what was in it.
- Can zero retention and a usable audit trail actually coexist?
- Yes, and that is the normal design. Keep content off the planes you do not need it on, and keep the audit plane deliberately — with its own retention setting, its own access controls, and a decision about whether it stores content, redacted fields, or metadata alone.
- What is the single most overlooked plane?
- The vector index. Teams treat embeddings as anonymous numbers, but most systems store the source chunk text alongside each vector so it can be returned during retrieval. Deleting the original document does not always remove that copy.
Comparing deployment models rather than individual controls? The closed-API comparison covers where each approach genuinely wins.