AI Data Retention: ‘Not Used for Training’ Does Not Mean Deleted

“We do not train on your data” sounds like a complete privacy promise. It is not. Your prompts may still be retained for abuse monitoring. Your own application may save every conversation. Your observability vendor may receive the same text in a trace. A search index may hold a derived copy long after the original disappeared.

AI data retention is the question of what remains, where, for how long, for which purpose and under whose control. Training is a different question: whether those records are used to change a model. Confusing the two produces attractive procurement slides and uncomfortable answers when a customer asks for deletion.

Separate the four promises

Training use: may the provider use input or output to improve models? Retention: which systems keep records and for how long? Access: who can read them, including support and subprocessors? Deletion: what happens when a record expires or a person exercises a right? A contract that answers only the first question leaves three important product decisions unresolved.

OpenAI's API documentation says API data is not used for training by default unless the customer opts in, a policy in place since March 2023. Separately, default abuse-monitoring logs may contain prompts, responses and derived metadata and may be retained for up to 30 days. Certain features also create application state with their own retention behavior.

Anthropic's commercial retention policy similarly describes automatic deletion of standard API inputs and outputs within 30 days, with exceptions for features, agreements, enforcement and legal obligations. Its policy says retained data is not used for training without express permission. These are API/commercial descriptions, not a promise about every consumer chat plan.

Do not silently import the terms of one product into another. Consumer chat, an enterprise workspace, an API, uploaded files, persistent conversation state and a third-party wrapper can all have different controls. Before sending sensitive data, check the exact endpoint, feature, agreement and account configuration you will actually use.

Zero data retention has a scope

Zero data retention is a provider arrangement for eligible use cases, not a universal switch meaning “nothing is ever stored anywhere.” OpenAI describes eligibility and approval requirements. Anthropic describes coverage limits and exceptions, including some safety-related information and legal or misuse-related needs. Feature-specific documentation matters as much as the headline.

Ask procurement-grade questions: which endpoints are covered? Which optional tools persist state? What information remains outside the covered content? Does enabling a feature change the answer? How is a contractual exception handled? The right response is a written scope, not a logo on a security slide.

And even a correctly configured provider arrangement does not govern your database, logs, exports or backups. The provider may be the shortest-lived copy in the entire workflow. If your debug logs retain full prompts for ninety days, your own instrumentation is the retention problem.

Design a retention ledger before writing the policy

For each data destination, record the purpose, the minimum useful content, its identifier, the owner, access controls, retention duration, deletion mechanism and exceptions. Trace a single example from input through retrieval, model request, output, monitoring, search indexing and export. The policy should describe that map—not a hoped-for architecture.

Separate operational evidence from content. You may need to know that a request failed, which tool timed out and how long it took. You may not need the customer's entire medical note to diagnose that failure. Prefer event identifiers and minimized metadata; redact before transmission to a logging service, not after a sensitive record has already landed there.

Derived data deserves the same question. An embedding, summary or classifier result can still relate to a person. Do not treat a transformed representation as anonymous merely because it is difficult to read. Keep a lineage identifier that lets you locate derivatives without copying the original into every system.

This develops the argument in The Data You Never Collect Cannot Leak. Minimization is not an anti-debugging ideology. It is a decision to collect evidence suited to the question instead of keeping everything because storage is cheap.

The law does not hand you one magic duration

GDPR Article 5(1)(e) requires identifiable personal data to be kept no longer than necessary for the purposes of processing, with specified safeguards and exceptions. It does not say that every AI product gets a universal thirty-day safe harbor. Necessary duration depends on purpose, context and applicable obligations.

The right to erasure under Article 17 also has conditions and exceptions. A legal hold, required recordkeeping or another applicable basis may change what can be deleted immediately. Get qualified legal review of the actual processing, jurisdiction and promise. An editorial checklist cannot decide that for you.

A useful product requirement is nevertheless straightforward: every retained copy needs a reason that can be stated and defended. “We might need it someday” is not a meaningful operational purpose. If the team cannot name the purpose, it cannot decide when the record should expire.

Rehearse deletion like a customer journey

Create a synthetic record with a traceable identifier. Request deletion through the same path a real customer uses. Verify active storage, retrieval indexes, caches, traces and exports. Check whether a worker failed silently, whether the search index still returns the old text and whether the UI merely hid the record.

Backups need a distinct policy. Some systems expire backup data on a documented schedule rather than editing every historical snapshot immediately. State that schedule clearly, restrict use, and prevent restoration from resurrecting deleted records into active processing. A restore rehearsal should include deletion markers or an equivalent mechanism.

Do not promise that removing a source record instantly “untrains” a model. Deleting stored records, stopping future training and altering learned parameters are different operations. The training-data consent essay covers the choice; the deletion promise must accurately explain the consequences and limitations.

Trust belongs in the interface too

A person deciding whether to paste a sensitive document should not need to reverse-engineer three privacy policies. Say what is saved, which controls apply and where the person can remove it. Put useful information near the action, with fuller details available. Avoid an absolute “private” label when the truth is a qualified operational arrangement.

Make preferences consistent across account settings and pipelines. An opt-out that stops one frontend toggle but leaves a downstream export running is not honored. Global Privacy Control illustrates this broader product principle, although its specific legal meaning concerns sale, sharing and targeted advertising—not every form of AI retention.

The commercial reward is not a claim that privacy automatically boosts conversion. It is reduced ambiguity: procurement can see what it is buying, customers can understand the promise, and operators can test whether that promise holds. Good retention design turns trust from adjective into observable behavior.

Sources and limits

Primary sources support the standards and policy descriptions. The planning tools and proposed release practices are editorial models, not audit certificates, legal advice or measured production results. Provider documentation can change; verify the applicable agreement before procurement.

• OpenAI API: Data controls and retention
• Anthropic Privacy Center: Commercial data retention
• Anthropic Privacy Center: Zero retention scope and exceptions
• EUR-Lex: GDPR, Articles 5 and 17