Sensitive data and AI: what a zero-retention policy really guarantees
"We do not retain your data" is reassuring, and does not cover the ground you imagine. The clause concerns retention, never transmission : and leaves out logs, abuse detection, cache and backups.
What the clause says, and what it does not
"We do not retain your data" and "we do not train our models on your data" are two distinct promises, often conflated, and neither covers the ground people assume.
The first concerns retention, and it leaves intact the fact that the data was transmitted, decrypted in memory and then processed on infrastructure you do not administer. For professional secrecy or a trade secret it is precisely that fact which counts, rather than whatever becomes of the data afterwards.
The second concerns retraining, a real and useful guarantee but a narrow one, since it forbids neither logging, nor temporary retention for the purpose of abuse detection, nor operator access during an incident.
A contract remains the appropriate tool for framing a processing operation. It becomes insufficient when the obligation bears on not communicating the information at all : the distinction developed in legal translation and AI.
The four places data settles anyway
Even with a good-faith provider applying its policy to the letter, a request leaves traces in places the commercial promise does not cover.
| Location | Why it exists | What the clause says about it |
|---|---|---|
| Operational logs | Diagnose incidents, measure load | Nothing, or a period distinct from the headline promise |
| Abuse detection | Provider's duty to monitor prohibited usage | Explicit carve-out from non-retention, often in a footnote |
| Response cache | Cut cost and latency on repeated requests | Rarely mentioned; its partitioning even less |
| Backups | Business continuity | Own rotation cycle, independent of deletion |
None of these four is a provider failing: they are normal components of a production service. The problem is that they are invisible from the contract, and therefore escape an impact assessment that relies on that contract.
The deletion case deserves separate examination, so clearly does it illustrate the gap between the clause and the system. An erasure request handled immediately in the primary store has no effect on backups until their rotation cycle expires. That behaviour is accepted and documented, but it is rarely anticipated by the organisation that requested the deletion.
The special case of sensitive data
For special categories of data, health, opinions, trade union membership, biometrics, the reasoning changes in nature. It is no longer about optimising a risk but about justifying an exception, since processing them is prohibited in principle and only possible in an exhaustively listed set of cases.
That reversal carries three practical consequences for the architecture of the system, none of which a contractual clause can replace.
- The burden of proof is reversed, it is not enough that the risk appears low; you must demonstrate that the processing falls under an exception and that the measures are proportionate. A provider clause demonstrates nothing on your side.
- The classifier must be local, detecting that a request contains health data means reading the request. Asking an API to evaluate "is this data allowed to leave for an API?" means you have already sent it. See the orchestration engine.
- Failover must be forbidden, on a sensitive flow, automatic fallback to a hosted model during a local outage cancels the measure at the precise moment it mattered. An outage must produce an error.
The sectors concerned also have their own regimes: health data hosting for healthcare, specific requirements in the public sector, professional secrecy in legal.
What on-premises guarantees, and what it does not
Running the model inside your own infrastructure removes the cause of the problem rather than its effects: there is no retention at a third party because there was no transmission, and the promise becomes verifiable because it now bears on components you administer yourself.
It is worth being precise about what this does not solve, or you simply replace one misplaced trust with another.
The four locations in the table above still exist, simply on your side rather than at a provider's. Local logs keeping requests in clear text for two years, on a server whose access nobody audits, are a more concrete risk than a properly contracted API. The difference is not that there is nothing left to do: it is that you can do it, and demonstrate it.
On-premises, zero retention therefore becomes an operational property: periods explicitly set in all four places, purge implemented and executed, log access restricted and traced, cache partitioned by clearance. That is more work than a signature at the bottom of a contract, and it is the only version that can be demonstrated.
How to verify rather than believe
Four questions separate a real policy from a marketing formula, whatever the provider : including your own team.
- What is the retention period of technical logs, and is it distinct from the one announced for user data? A vague answer is already an answer.
- What happens to a request flagged by abuse detection: how long is it kept, and who can read it?
- Does the cache key include the caller's identity and clearance scope? If not, a response computed for an authorised user can be served again to another.
- What is the real deletion delay, backups included? That is the figure to record in the register, not the primary store's.
Asked of a provider, these four questions reveal the maturity of its offering; asked of your own team, they most often reveal that the local deployment does not yet hold the properties readily attributed to it.
This article describes architectural consequences; it is not legal advice. Sources: CNIL recommendations on AI and GDPR, specific recommendations on developing AI systems, ANSSI security recommendations. Accessed August 28, 2026.
What to remember
Contractual zero retention and architectural zero retention carry the same name and are not demonstrated the same way. The first binds a third party to a fact you cannot observe; the second describes a system whose logs, purge and access you hold.
On sensitive data, where the burden of proof falls on you, that difference is decisive. It does not spare you the operational work : it makes it possible. To apply the frame to your case, a no-commitment conversation is enough to identify which of the four locations is the problem for you.
Frequently asked questions
What does a zero-retention policy actually guarantee?
It guarantees what a provider commits not to keep. It says nothing about transmission, which did happen: the data was sent, decrypted and processed on infrastructure you do not administer. It also leaves out operational logs, abuse detection, the response cache and backups, each with its own period.
Are zero retention and no-retraining the same thing?
No, they are two distinct promises often conflated. The first concerns retention, the second the use of data to improve the model. No-retraining is a real but narrow guarantee: it forbids neither logging, nor temporary retention for abuse detection, nor operator access during an incident.
Can you process health data with an AI API?
The reasoning changes in nature for special categories of data: processing them is prohibited in principle and only possible in an exhaustively listed set of cases, which reverses the burden of proof. A provider clause demonstrates nothing on your side, and the sectors concerned also have their own regimes, such as health data hosting.
Is on-premises deployment enough to guarantee zero retention?
No, it gives you the ability. Logs, cache and backups still exist, just on your side. Local logs keeping requests in clear text for two years, on a server whose access nobody audits, are a more concrete risk than a properly contracted API. On-premises, zero retention is an operational property you have to hold.
How do you verify a provider's retention policy?
Four questions are enough: what period applies to technical logs, and is it distinct from the announced one; what happens to a request flagged by abuse detection, and who can read it; does the cache key include the caller's identity and clearance; what is the real deletion delay, backups included. A vague answer is already an answer.