Zero Data Retention was never going to be enough

What ZDR actually gets you

Look closely at how ZDR is typically described and the shape of the trade-off becomes clear. It is usually a configurable option, available to eligible organisations and endpoints — not a blanket guarantee across every deployment. Your sensitive data still has to travel to a third party's infrastructure to be processed. Once it is there, you are relying on that vendor's technical controls, contractual terms, and internal discipline to make good on the 'we did not keep it' promise.

You can audit the contract. You generally cannot audit the datacentre. You cannot observe the routing, the staff access controls, or the subtle ways a provider might reconcile safety monitoring with the prohibition on retaining content. The guarantee is as strong as the weakest interpretation of the words in the agreement.

And the tension is only getting sharper. As agentic workloads get longer-running and more autonomous, safety teams increasingly want to look across related interactions to catch problems that do not show up in any single request — which is exactly the kind of visibility ZDR is supposed to prevent. Vendors are now building elaborate systems to reconcile the two: monitor for misuse patterns without exposing the underlying content to a human reviewer. It is clever engineering. It is also a sign that ZDR was patching a structural problem rather than removing it.

The question underneath the question

Here is the thing most ZDR conversations skip past: not retaining the data is only interesting if the data left your environment in the first place.

If your procurement analyst agent is pulling NHS numbers, if your HR policy agent is reasoning over disciplinary records, if your citizen assistant is handling case files — the safest promise about what a third party does after receiving that content is never going to be as strong as simply not sending it.

That is a different question from 'does our vendor retain our data.' It is 'does our data need to leave our boundary at all.' The organisations that get this right do not start by comparing vendor privacy policies. They start by classifying content and deciding which classes of data are permitted to cross the perimeter, under what conditions, and for which models.

Once that decision is explicit, ZDR becomes a useful option for the subset of work that genuinely needs a frontier model and content that can leave. It is no longer the primary control for sensitive work.

How Udal answers it

Udal is a control plane you run inside your own environment — your cloud, on premises, or a sovereign cloud — for building, deploying, and governing AI agents. The design principle is simple: your infrastructure, your data, your AI.

Concretely, that means:

• Routing decided by policy, not habit. Every request passes through a model gateway that decides where it goes based on data classification, project, and entitlements — not on which model a developer happens to like. Work touching regulated or personal data is routed to open-weight models running inside your own boundary. Nothing about that data has to leave the estate for the task to get done.
• Frontier models, allow-listed and earned. Commercial frontier models — Claude, GPT, Gemini and the rest — stay in the picture, because sometimes a task genuinely needs that level of capability. But they are reached through an explicit allow-list, with per-model cost accounting and egress controls, rather than being the default path for every request regardless of sensitivity.
• Guardrails before anything crosses the boundary. A pluggable PII and content classifier screens inputs at the model and tool boundary. In an accredited deployment, the platform refuses to fall back to a development-grade heuristic classifier — it requires the real thing.
• Logging that cannot leak what it is watching. Audit and monitoring feeds carry governance metadata — who did what, when, under which policy — never the run's actual inputs or model content. You get a full, tamper-evident audit trail without that trail becoming a second copy of your sensitive data sitting in a SIEM somewhere.
• Fail closed, by design. An empty authorisation policy denies everything. An unreachable policy engine denies. A misconfigured accredited install refuses to start rather than run insecurely. The default posture is 'no,' not 'yes, unless.'

ZDR and self-hosting are not the same debate

It is worth separating two conversations that are often collapsed. One is whether a vendor keeps your data. The other is whether your data has to leave your environment to be processed. ZDR addresses the first. Self-hosting and policy-based routing address the second.

They can work together. An organisation might self-host its highest-sensitivity work, use ZDR-enabled frontier APIs for cleared public-domain tasks, and forbid everything else. The mistake is treating ZDR as a substitute for the boundary decision.

The boundary decision is harder because it requires the organisation to know what it is handling and to enforce that classification technically. That is why many teams skip it and settle for the contract instead. The contract is easier to buy; the boundary is harder to build. But the boundary is what actually protects the data.

A different kind of guarantee

ZDR asks you to trust that a promise made by a third party about your data will hold. Udal's architecture asks something much smaller of you: trust the boundary you already control.

That is not a knock on the labs offering ZDR — it is a genuinely useful option, and Udal's model gateway is built to reach frontier models through it when a task calls for that capability. But for the sensitive core of enterprise AI work — the regulated data, the case files, the records that cannot leave the building even by promise — the strongest privacy control is not a better contract. It is not having to send the data in the first place.

The organisations that understand this do not treat privacy as a vendor selection checkbox. They treat it as an architectural property: data that does not leave cannot be retained, inspected, leaked, or subpoenaed from a provider. The strongest retention policy is the one enforced by physics.

Questions to ask before the next AI procurement

A few questions make the difference between buying a capability and buying a control gap.

• For the work this agent will do, does any data need to leave our network at all?
• If we use ZDR, which endpoints, regions and model versions is it actually guaranteed for?
• Can we reproduce a decision and its full chain without asking a vendor for logs?
• If the vendor's safety team needs to review misuse patterns, what metadata can they see and what can they not?
• What happens when a model update, price change or terms change makes this vendor unsuitable? Can we switch without rebuilding the process?