“We don’t train on your data” does not mean “we don’t retain it.” Neither promise tells you where your data is processed. Zero data retention (ZDR) closes one of those gaps. It does not close all three.
The model may be stateless. The application is not.
Think about your ChatGPT conversation history. You close a session, return later, and reopen the conversation. That history lives in OpenAI’s systems. Regular chats remain saved until you delete them or a workspace retention policy removes them. Turning off model training does not delete that history. (ChatGPT retention)
Now consider an API request with no visible chat history. Anthropic does not use Claude API inputs and outputs for training by default, but its standard API retention policy allows storage for up to 30 days, with exceptions for certain services, agreements, and policy enforcement. That is a concrete example of retaining content without using it to train a model. (Anthropic’s retention policy)
The distinction matters: the provider’s systems store the data, even when the model itself has no lasting memory of the interaction. Conversation continuity and safety monitoring are two reasons retention exists independently of training.
For enterprises sending customer records, financial information, or confidential documents to AI services, “we don’t train on your data” answers only one question. You need to understand three separate controls.
Three controls, three different questions: no training, zero data retention, and data residency
|
Control |
What happens to your data |
What it answers |
What it does not answer |
|
No training |
Your content → excluded from model training |
Whether your content is used for training. |
How long it is stored, or where it is processed. |
|
Zero data retention (ZDR) |
Covered content → processed → not retained after processing |
A retention question. |
It does not mean your data stays inside your environment or a particular country. |
|
Data residency |
Your data → stored or processed in specified locations |
A geography question. |
Whether data is used for training, or how long it is retained. |
These controls work together. None replaces the others.
Check each commitment against the service, endpoint, and features your application actually uses. A setting attached to one API does not determine the behavior of an entire AI workflow. Provider documentation distinguishes training, abuse-monitoring logs, application state, and ZDR eligibility for this reason. (Example: API data controls)
What zero data retention does not cover
Zero data retention controls retention under the provider’s agreement. It does not eliminate disclosure. An external model still receives the information you send for processing.
It also does not guarantee that processing stays in your required region. Where data is stored and where inference runs are separate questions.
And the model provider is only one part of your system. Copies of sensitive data can persist in places ZDR never touches:
- Your application might log the full prompt before sending it.
- An observability platform might capture the response.
- A retrieval pipeline might store source documents.
- A connected tool might keep its own request history.
ZDR at the model provider does not erase those copies.
Ask specifically about abuse monitoring: whether request content is excluded, what exceptions remain, and whether any selected features store content.
The practical question is broader than “Does our model provider offer zero data retention?”
|
The question to ask instead |
Before asking how long it stays, ask why you sent it
Consider a banking assistant reviewing customer transactions.
|
Original request |
|
Request with protected identifiers |
The model needs relevant transaction information. For this task, the customer’s real name and account number add no analytical value.
Replacing those identifiers reduces what the provider receives. The application restores them for an authorized recipient when displaying the result.
But names and account numbers are only part of the problem. Merchant names, locations, dates, and unusual transactions still reveal sensitive information. Decide which fields the task requires, then remove or generalize the rest.
Removing too much context also has a cost: weaker analysis. Test the protected workflow against representative tasks. The objective is the minimum disclosure that still produces a useful, reliable result.
Two architectures, different disclosure
The architectural choice is whether raw sensitive values reach the external model.
1. Direct disclosure
Enterprise application → Raw prompt → External LLM → Response → Application
The provider receives every sensitive value included in the prompt. Your protection depends on its handling of that information and the controls across your own application.
2. Protection before disclosure
Enterprise application → Protecto Vault → Protected prompt → External LLM
Protected response → Protecto Vault → Authorized recipient
Protecto Vault replaces selected sensitive values with tokens before the model call, preserving consistent references across the protected content. We separate that protection from unmasking, so restoring original values is an explicit, policy-governed operation.
In an in-environment deployment, masking happens before the external model call, with original values and token mappings kept within your boundary. That deployment boundary is essential to the claim that raw values stay inside your environment.
Agent workflows need the same scrutiny. A protected initial prompt offers little protection if a later database query sends raw customer records directly to the model.
Context-based access control addresses who should receive sensitive information at each step. Identity, permissions, purpose, and request context inform the authorization decision. Where a tool needs a real identifier, the workflow should restore only the values authorized for that call and protect sensitive tool results before passing them onward.
Apply this design across retrieval, model calls, tools, and responses. A single masking step is not coverage for an entire agent workflow.
Protecto Vault reduces the sensitive information disclosed. Provider zero data retention and residency controls still matter for the information you choose to send.
Questions to ask your provider and your own team
Ask your provider
|
Topic |
Question |
|
Training |
Is our content excluded from training under our agreement and settings? |
|
Retention |
What content and metadata do you store, for how long, and for what purposes? |
|
ZDR |
Which models, endpoints, and features qualify for zero data retention? What abuse-monitoring or other exceptions remain? |
|
Geography |
Where do storage and inference happen? Which other service providers receive our content? |
Ask your own team
|
Topic |
Question |
|
Necessity |
Which sensitive fields does this task actually need? |
|
Coverage |
Do our controls cover retrieval, subsequent model calls, tools, responses, and application logs? |
|
Restoration |
Who can recover original values, under what conditions, and where are the mappings stored? |
|
Quality |
Does the protected workflow preserve enough context to perform the task reliably? |
Leadership needs to understand the exposure the business accepts. AI engineers need a workable data flow and measurable output quality. Security teams need evidence that protection extends across the workflow.
These are architecture decisions, not just settings to enable before launch.
Control disclosure before retention
No-training commitments, zero data retention, and residency controls each answer an important question. Data minimization adds another: did this sensitive value need to leave in the first place?
Start with one workflow. Identify the sensitive fields it sends, remove what the task does not need, and check each subsequent model call and tool interaction for fresh disclosures.
The fewer sensitive values you send, the fewer you depend on another organization to protect.
A provider cannot retain what you never sent.
Read more: Protecto Vault tokenization, policies, and controlled unmasking.
Provider commitments and product capabilities vary by service, deployment, configuration, and contract. Verify them against your implementation.
FAQs
What is zero data retention?
Zero data retention (ZDR) means a provider does not retain covered request and response content after processing it. It applies only to the services, endpoints, and features your agreement covers. It does not stop your own systems from keeping copies.
Is zero data retention the same as no training?
No. No training means your content is not used to train models. Zero data retention addresses how long content is stored. A provider can retain data without training on it.
Does zero data retention mean my data stays in my region?
No. Data residency is a separate control. Zero data retention does not say where storage or inference happens.
Does a provider’s zero data retention remove copies in my application?
No. Prompts and responses logged by your application, observability tools, retrieval pipelines, and connected tools persist independently of the model provider.
How can I reduce what AI providers retain?
Send less. Replace sensitive values with tokens before the model call, keep only the fields the task needs, and restore originals only for authorized recipients. A provider cannot retain what you never sent.
