AI Data Retention Policy: Delete Every Workflow Copy
An AI data retention policy fails when it deletes the chat record but leaves the same content in a trace, checkpoint, cache, uploaded file, vector index, provider object, export, or backup. Internal AI workflows create more derivatives than ordinary request and response services, often under unrelated identifiers. The payoff from fixing this is concrete: one expiration or erasure request can reach every copy, survive partial failures, respect a legal hold, and produce evidence without retaining the deleted content. The design below uses a data inventory, stable deletion subjects, class-specific rules, and an idempotent deletion controller to make that possible.
Why deletion fails in AI workflows
A single user request can create several kinds of state. The API stores a prompt and response. An orchestrator checkpoints the run. A tracing service records model inputs, outputs, and tool arguments. A file service keeps attachments. Retrieval creates chunks and embeddings. A semantic cache may store the completed answer. A model provider may retain application state or abuse-monitoring records under its own rules. Backups and analyst exports add more copies later.
Deleting the row that powers the user interface reaches only one of those stores. Deleting by email address is not reliable either. Some records use an internal user ID, others use a conversation ID, and provider objects use vendor-issued IDs. A document uploaded by one employee may also appear in a shared index used by a department. Without a common subject and lineage record, an erasure job cannot know what to remove or what must stay.
Provider behavior makes assumptions dangerous. OpenAI documents endpoint-specific application state and separate abuse-monitoring retention in its API data controls. Some objects remain until deleted, while eligible customers and endpoints may use Zero Data Retention or Modified Abuse Monitoring controls. Anthropic says in its commercial data retention guidance that standard API inputs and outputs are automatically deleted from its backend within 30 days, subject to listed exceptions. Services such as Files can have longer retention under customer control. Your application policy must record the provider, endpoint, feature, and applicable contract instead of applying one vendor-wide assumption.
Inventory data by purpose and derivative
Start with a data map that follows content through the workflow. Do not begin by choosing a universal number of days. Retention follows purpose, legal duty, operational need, and risk. The NIST Privacy Framework is useful here because it treats privacy as a system risk to identify and manage, rather than a checkbox attached only to the model call.
Inventory at least these locations:
- API request and response bodies
- Conversation and session records
- Workflow checkpoints and retry payloads
- Tool-call arguments and results
- Prompt and response traces
- Uploaded source files and parsed artifacts
- Chunks, embeddings, and retrieval metadata
- Exact and semantic caches
- Evaluation datasets built from production traffic
- Support exports, analytics extracts, and debug bundles
- Model-provider files, conversations, threads, batches, or stored responses
- Primary database backups, object-store versions, and search snapshots
For each entry, record the controller, processor or vendor, business purpose, sensitivity, creation event, deletion interface, ordinary retention, legal-hold behavior, backup expiry, and owner. Also record whether the store contains raw content, a reversible token, a non-reversible digest, metadata, or a derived representation such as an embedding.
An embedding should not be dismissed as harmless because it is not readable prose. It remains a derivative of source content and may preserve links to a document, user, or tenant. Give it the same deletion subject as the source chunk. The same rule applies to cached responses, evaluation examples copied from production, and trace records that include prompt fragments.
Define retention classes before writing jobs
Use a small set of named classes rather than letting every service invent a TTL. A practical policy might distinguish transient request buffers, resumable workflow state, user-visible history, diagnostic traces, security audit records, retrieval artifacts, and backups. Each class needs a purpose, retention period, trigger, exceptions, and disposal method.
Raw prompt text and durable audit evidence usually should not share a class. A security audit event may need to prove who requested an action, which policy ran, and whether the action succeeded. It does not necessarily need the full prompt or tool output. Keep the minimal audit fields required for accountability and remove raw content sooner. The OWASP Logging Cheat Sheet says logs, temporary debug logs, backups, copies, and extracts must not be kept beyond their required retention period. It also notes that legal, regulatory, and contractual obligations affect those periods.
Write the policy as executable data. An example record could look like this:
{
"class": "workflow_checkpoint",
"purpose": "resume interrupted internal requests",
"retention_days": 14,
"expiry_trigger": "workflow_terminal_at",
"legal_hold_allowed": true,
"content_fields": ["state", "messages", "tool_results"],
"delete_mode": "hard_delete",
"backup_expiry_days": 35,
"owner": "workflow-platform"
}The values are examples, not universal recommendations. Your privacy, security, legal, and product owners must set them for the organization's data and obligations. The important property is that code reads the same versioned policy that reviewers approve.
Attach one deletion subject to every copy
Create a stable internal identifier that is safe to carry across stores. Call it deletion_subject_id. It can represent a person, tenant, source document, conversation, or case, depending on the request you must satisfy. Do not use an email address as the durable key because emails change and are copied into logs.
Every persistence operation should include the subject plus enough lineage to find derivatives:
{
"deletion_subject_id": "ds_8421",
"tenant_id": "org_19",
"source_object_id": "file_310",
"derivative_type": "embedding_chunk",
"store": "vector-primary",
"store_object_id": "vec_99127",
"policy_class": "retrieval_artifact",
"policy_version": "retention-2026-08",
"created_at": "2026-08-24T09:15:00Z"
}Keep this mapping in a deletion registry. It should contain identifiers and lifecycle metadata, not a second copy of the content. When an upload is split into pages, chunks, embeddings, summaries, and cached answers, register those children in the same transaction or an outbox that can be replayed. A write that creates content without registering its deletion identity is an integrity failure.
Some data has several subjects. A shared meeting summary may belong to a workspace and include several people. Model the relationship explicitly rather than choosing whichever user initiated the request. Policy must decide whether one person's erasure removes the whole shared object, redacts only that person's fields, or preserves it under another lawful purpose. The deletion controller should execute that decision, not invent it at runtime.
Build an idempotent deletion controller
A deletion request is a distributed workflow. It will encounter unavailable providers, expired credentials, already-deleted records, rate limits, and stores with asynchronous deletion. Treat those outcomes as state, not as reasons to mark the whole request complete.
Use this sequence:
- Resolve the authenticated request to one or more internal deletion subjects.
- Freeze the policy version and reason that apply to the request.
- Check for scoped legal holds before scheduling any destructive work.
- Read the registry and create one deletion task per store and object class.
- Delete local serving copies first or make them inaccessible immediately.
- Call provider deletion APIs using recorded vendor object IDs.
- Revoke caches and search entries that can still serve the content.
- Record each outcome as pending, confirmed, already absent, held, retryable, or blocked.
- Reconcile asynchronous operations until every task reaches a terminal state.
- Keep a minimal tombstone that proves scope, policy, timestamps, and outcomes without keeping deleted content.
Give each task an idempotency key derived from the deletion request, store, object, and policy action. A retry should repeat the same action. Treat a provider's not-found response as success only when the identifier was recorded correctly and policy allows that interpretation. An authentication failure, timeout, or malformed identifier is not confirmation.
Do not let one failed store block immediate removal from every healthy serving path. Make the content unavailable locally, then continue retrying the failed external deletion under an alerting policy. The request remains incomplete until blocked tasks are resolved or an authorized exception is recorded.
Handle provider state as its own data class
Provider settings are part of the architecture. Record them per project and endpoint, then test them. OpenAI's data-control documentation distinguishes abuse-monitoring logs from application state and lists storage requirements by endpoint. Anthropic distinguishes standard API retention from products and services that customers control. A procurement statement that a vendor "does not train on our data" does not answer how long an endpoint stores application state or how deletion works.
Keep a provider control register with:
- Account and project identifier
- API endpoint or product feature
- Data sent and object IDs returned
- Contractual retention setting
- Whether zero-data-retention controls apply
- Deletion API and expected completion behavior
- Exceptions for safety, law, or customer-controlled storage
- Date and evidence from the last verification test
OWASP's sensitive information disclosure guidance recommends clear policies for data retention, usage, and deletion. Turn that policy into an integration test. Create a synthetic provider object, register it, delete it through the controller, and verify that subsequent retrieval fails as documented. Repeat the test when endpoints, account controls, or vendor terms change.
Keep legal holds narrow and visible
A legal hold should suspend deletion only for the subjects, stores, and classes covered by the hold. A global deletion_disabled flag is easy to enable and hard to unwind. It also keeps unrelated data longer than policy allows.
Represent a hold as a versioned policy object with its authority, scope, start time, optional end condition, and owner. The controller should mark matching tasks as held before any destructive call. Other tasks continue normally. When the hold is released, the system should enqueue overdue deletions from their original expiry dates instead of starting a fresh retention period.
Do not place raw held content in the deletion registry. The source store remains responsible for access control, integrity, and preservation. The registry needs only the hold relationship and the object identifiers required to resume disposal later.
Design backup expiry rather than instant deletion
Most backup systems cannot remove one row safely from an immutable snapshot. State that limitation in the policy. Erasure from active systems can happen promptly while encrypted backups age out on a defined schedule. If a backup is restored, a deletion replay must run before the restored environment serves traffic.
Track the latest backup that may contain each deleted object class and the date that backup expires. The deletion request is operationally complete when active and provider tasks are confirmed, but its tombstone should retain a backup-expiry status until the relevant restore points are gone. This avoids claiming that every byte disappeared immediately when the architecture cannot support that claim.
Test restoration. Restore a representative snapshot into an isolated environment, apply the deletion ledger, rebuild indexes and caches, and prove that deleted subjects cannot be retrieved. A retention policy that has never been tested against a restore is only a plan for the normal path.
Verify expiration and erasure separately
Scheduled expiry and user-triggered erasure use the same controller, but both need fixtures. Build tests around synthetic subjects so verification never requires exposing production prompts.
Cover these cases:
- A completed workflow reaches its checkpoint TTL and all registered checkpoints disappear.
- A conversation deletion removes local history, traces, caches, provider objects, and derived embeddings.
- A retry after partial completion does not recreate data or duplicate destructive side effects.
- A provider timeout remains pending and raises an alert rather than becoming confirmed.
- A legal hold pauses only matching data and resumes overdue deletion after release.
- An unregistered derivative causes the inventory reconciliation job to fail.
- A backup restore replays completed deletion tombstones before traffic is enabled.
- An already-absent object reaches a documented terminal outcome.
- A tenant cannot request or inspect another tenant's deletion subjects.
- Completion evidence contains no prompt, response, file text, or reversible secret.
Run a daily reconciliation between store inventories and the deletion registry. Sample records by class, verify that expired objects are absent, and flag records with no policy class or subject. Monitor pending task age, blocked deletions, hold counts, provider error classes, expired objects still serving, and backup expiry lag. Do not use "deletion job ran" as the success metric. The useful measure is whether every in-scope store confirmed the expected state.
Avoid the shortcuts that break erasure
Do not treat a UI delete as a data delete. Do not assume a provider's default applies to every endpoint. Do not retain full prompt text inside an audit tombstone. Do not reset retention when content moves to an evaluation set. Do not let a cache use a different identity from its source. Do not mark a timeout as success. Do not ignore backups because they are offline.
The most damaging shortcut is allowing services to persist new derivatives without the deletion subject and policy class. Stop that at the write boundary. Add a schema requirement, an outbox assertion, or a storage wrapper that refuses unclassified content. Reconciliation can catch drift later, but prevention keeps the inventory trustworthy.
Start with one deletion drill
Pick one internal workflow that stores a prompt, response, trace, checkpoint, file, or embedding. Create a synthetic subject, run it through the real system, then issue an erasure request. List every resulting object ID before deletion and make the controller account for each one afterward. Include one provider timeout, one held object, and a restore from backup.
If any copy depends on a manual search, undocumented vendor setting, or an identifier that cannot be linked to the subject, fix that boundary before expanding the workflow. An AI data retention policy is working when one request can identify every derivative, drive every permitted deletion, isolate every hold, recover from partial failure, and prove completion without preserving the content it removed.
References
- OpenAI API data controls supports the distinctions among abuse monitoring, application state, endpoint behavior, deletion, and eligible retention controls.
- Anthropic commercial data retention supports the standard API retention period, listed exceptions, customer-controlled services, conversation deletion, and zero-data-retention arrangements.
- NIST Privacy Framework supports the system-level privacy-risk inventory and management approach.
- OWASP Logging Cheat Sheet supports class-specific log retention, protection, and disposal, including copies and backups.
- OWASP LLM02:2025 Sensitive Information Disclosure supports explicit policies for LLM data retention, use, and deletion.