What is zero data retention (ZDR)?
Zero data retention (ZDR) means the AI vendor stores neither your prompts nor the model's responses after the call is answered. That's different from the promise of 'no training,' which doesn't rule out storage for things like abuse detection. At the major vendors, ZDR is something you negotiate per contract, not a switch you flip.
When sensitive information is sent to an AI service, one question becomes central: what happens to the data after the response comes back? Zero data retention – ZDR – is vendors’ answer to exactly that. But the term is often misunderstood, and it rarely looks like a simple setting.
The definition
Zero data retention means the vendor stores neither your prompt nor the model’s response after the call has been answered. The data is processed in the moment to generate the answer and is then not stored – it doesn’t remain in logs or intermediate storage afterward.
It’s a stronger commitment than the most common phrasing, “we don’t train on your data.” The difference matters and is often underestimated.
ZDR is not the same thing as “no training”
Many vendors promise that your data isn’t used to train the model. That’s good, but it says nothing about storage. Data can very well be stored for a time even if it never trains the model – for example, to detect abuse, for troubleshooting, or for support.
ZDR removes the storage itself. So a vendor can offer “no training” without offering ZDR. When you read the terms, it’s worth distinguishing between the two: one protects against your data improving a future model, the other against it being retained at all.
For a business that handles sensitive information, it’s often the second question that weighs heaviest. If the prompts contain personal data or trade secrets, it matters less that they don’t train the model – the risk lies in them being stored at the vendor at all, in logs that can be accessed during an incident or a government request. In that case, “no training” isn’t a good enough answer; it’s the storage itself that needs to go. Knowing which of the two commitments a contract actually gives is therefore crucial for judging whether the service is fit for sensitive workflows.
A negotiation, not a switch
The biggest misunderstanding is that ZDR would be a setting you turn on. At the major vendors, it’s more of a negotiation conducted during the contracting process.
The paths there differ. Broadly speaking, it can involve a request within an enterprise agreement, approval from the vendor’s sales side, or a specific application for restricted access. What they have in common is that it requires an active step and often a written approval – not a click.
In addition, certain endpoints can be excluded even after ZDR has been granted. A concrete scenario: a company gets ZDR confirmed for its main calls, but a particular feature turns out to fall outside the agreement. The conclusion is that terms have to be confirmed per endpoint and model, not for the vendor as a whole.
Demand the terms in writing
Since retention periods and exception lists change over time, figures in articles and blog posts are shaky ground. What applied last year can be outdated today, and what applies to one endpoint doesn’t necessarily apply to another.
Rely on the principle – that ZDR must be requested, approved, and apply per endpoint – and demand the current terms in writing from the vendor for every endpoint and model you use. That way, your documentation rests on the contract, not on secondhand information.
Questions to ask the vendor
When you evaluate ZDR in a contract, there are a few concrete questions that cut through the marketing:
- Is the prompt and response stored after the call is answered – yes or no? Keep this clearly separate from the question of training.
- Does ZDR apply to all the endpoints and models we’re going to use, or are some excluded? Ask for the exceptions in writing.
- How is ZDR granted, and what’s required of us to activate it? An application, an enterprise agreement, approval?
- What applies to logs created for abuse detection or support? Even with “no training,” that kind of storage can exist.
The answers belong in the contract or a written addendum. A verbal assurance or a link to a general help page isn’t sufficient documentation the day someone asks.
Want to see how ZDR connects to residency, transfer mechanisms, and government access across a full AI project? Find more on our AI page. Need help figuring out what a vendor contract actually says about storage? Get in touch and we’ll go through it together.
Frequently asked questions
Is zero data retention the same thing as data not being used for training?
No, they're two different things. 'No training' means your data doesn't train the model, but it can still be stored for a time, for example for abuse detection or support. ZDR goes further: neither the prompt nor the response is stored after the call is answered. So a vendor can promise one without the other.
Can I just switch on ZDR in the service?
Rarely. At the major vendors, ZDR is a negotiation rather than a setting. It can require an application, approval from the sales organization, or an enterprise agreement. Don't assume a checkbox is enough – the requirement usually has to be raised in the contracting process and confirmed in writing.
Does ZDR apply to all models and endpoints?
Not necessarily. Even when ZDR has been granted, certain endpoints or features can be excluded. That's why you have to confirm the terms per endpoint and model, not for the vendor as a whole. A general commitment at the vendor level says little about the specific call your service makes.
How do you apply for ZDR at the major vendors?
The paths differ. Broadly speaking, it can involve a request within an enterprise agreement, approval from the vendor's sales side, or a specific application for restricted access. Since the processes change, you should work from the principle, that ZDR must be requested and approved, and confirm the current path with the vendor.
Why isn't it enough to rely on retention figures in articles?
Because retention periods and exception lists change over time and differ between contracts and endpoints. A figure that was correct last year can be outdated today. Instead, demand the current terms in writing per endpoint and model, so your documentation rests on the contract, not on secondhand information.