Zero Data Retention should now be a standard requirement when operators evaluate AI tools that may handle sensitive business information. The label alone is insufficient: buyers need written confirmation of what data is retained, where exceptions apply, and which vendors or subprocessors can access it.
Consider Leila, a fictional composite of an operations lead at a growing software company. At 4:40 p.m. in a Manchester meeting room, she was holding a printed security questionnaire covered in blue pen while her team waited to approve an AI support tool before the next morning’s deployment window.
The tool could summarize tickets and draft replies. The vendor’s website promised that customer data would not train its models. Yet the contract said nothing clear about prompt logs, abuse monitoring, attachments, backups or the model provider behind the product.
Approval was now in doubt. If Leila signed, confidential customer records might pass through systems her company had never reviewed. If she paused, the support team would miss its deployment window and return to a queue already spilling into the next shift.
“No training” leaves several questions unanswered
Operators often see “we do not train on your data” and treat it as a privacy answer. It addresses one use of the data. It does not necessarily explain whether prompts, outputs, uploaded files or metadata are stored for debugging, security monitoring, analytics or legal compliance.
Zero Data Retention, usually shortened to ZDR, asks a stricter question: after the service processes a request, does the provider retain the submitted content or generated response?
The answer can still depend on the product, account type, endpoint and configuration. A vendor may offer ZDR for one model while keeping logs for another. Safety systems may create exceptions. Application logs outside the model provider may preserve data even when the underlying model endpoint does not.
This is why the term belongs in procurement requirements, followed immediately by verification. A badge on a pricing page cannot describe the complete data path.
Leila stopped the approval meeting and drew four boxes on the whiteboard: her company, the AI application, the model provider and any monitoring service. The team could explain the first box. The other three contained assumptions.
Map the data before comparing model quality
A useful AI review starts with one representative request. Follow every part of it from entry to deletion.
For a support tool, that request might contain a customer’s name, account history, internal notes and an attachment. Ask where each element travels, which systems log it, who can access those logs and when deletion occurs. Then repeat the exercise for the output, because generated text may reproduce sensitive details from the input.
The practical review should cover several points:
- Confirm whether ZDR applies to prompts, outputs, files, metadata and error logs.
- Identify every model provider and subprocessor involved in the selected configuration.
- Check whether administrators must enable ZDR or request separate approval.
- Document exceptions for abuse detection, legal obligations and human review.
- Test what appears in dashboards, observability tools, support consoles and exports.
- Record what changes if the team switches models, regions or product tiers.
This is also where hands-on testing matters. Written terms may describe the intended policy, while an admin console reveals that conversation history is enabled by default. A network trace may show an additional service receiving request content. Neither observation proves misuse, but both deserve an answer before deployment.
The same discipline applies when an AI tool can take actions rather than generate text. Retention is one part of a wider control problem, as the scenario in LLM Attack Surface: How a Poisoned Document Exposed a Refund Agent’s Authority demonstrates.
Turn ZDR into a contract requirement
A procurement requirement should be testable. “Vendor supports ZDR” is too loose to enforce because it leaves the scope undefined.
Write the requirement around the actual deployment instead. Specify the models, endpoints and account configuration covered. State which content categories must not be retained. Require disclosure of exceptions, subprocessors and configuration changes that could alter retention. Assign someone to verify the setting after launch and after material vendor updates.
Keep evidence with the decision. Useful records include the applicable contract language, current product documentation, configuration screenshots, test results and the date each item was checked. Avoid copying secrets or customer data into the evidence package.
Operators should also plan for failure. If ZDR becomes unavailable, decide whether the application blocks requests, removes sensitive fields or falls back to a separately approved model. Silent fallback to a retaining endpoint defeats the control at the moment it matters most.
That contingency thinking resembles the two-path approach described in AI Release Planning: How Lena Built Two Launch Paths Around a Paused Model Run: define the acceptable alternative before pressure turns an exception into policy.
The approval changes when the evidence changes
With the deployment window closing, Leila’s team replaced the broad vendor claim with a narrower decision. They approved only the documented configuration, disabled optional history, restricted the first rollout to tickets without attachments and recorded the unresolved logging questions for follow-up.
The support team still launched, but with a smaller boundary than planned. On the whiteboard, the four boxes now had owners, evidence and stop conditions beside them.
That is the operational value of ZDR. It gives buyers a clear baseline for sensitive AI workloads, then forces the harder and more useful work: proving where the baseline applies.
Before approving the next AI tool, take one realistic prompt and trace it through every system that can store, inspect or forward it. Any unexplained box is a reason to narrow the rollout.
Comments
No comments yet.