Free checklist · LLM data retention

The LLM Data Retention Checklist

31 checks to compare retention defaults across every LLM provider, enforce stricter overrides, and prove deletion to auditors and data subjects.

No paywall Provider-neutral Built for platform, security, and privacy teams
  • Training opt-outs and minimized retention are set for every provider
  • Routing never silently falls back to a provider with unacceptable terms
  • Gateway logs live in your cloud and expire on a TTL you set
  • Erasure requests reach logs, caches, backups, and exported copies

What the checklist covers:

31

Evaluation criteria for retention, deletion, and residency across your LLM stack

5

Control areas, from provider defaults to continuous deletion verification

12

Must-have controls, flagged so you know what to fix first

5

Providers covered: OpenAI, Anthropic, Azure OpenAI, Amazon Bedrock, and Google Vertex AI

Inside the checklist

Download the checklist to get:

A working framework your platform, security, and privacy teams can use to evaluate an AI gateway or audit the retention story across every model provider you use.

Download the Checklist

✓

The full 31-point LLM data retention framework

Every criterion grouped by control area, with the question to ask and a must-have, should-have, or nice-to-have priority.

✓

A three-step rollout plan

Catalog your providers and contract terms, configure overrides at the gateway and provider level, then verify deletion on a schedule.

✓

A regulatory retention map

How retention schedules line up with GDPR Article 17, HIPAA record rules, and SEC 17a-4 / FINRA where they apply.

✓

A vendor evidence-pack request list

The architecture diagrams, retention configs, deletion-event logs, and subprocessor disclosures to ask any vendor for.

Why it matters

Your Data Retention Story Is Only as Strong as Your Weakest LLM Provider

Every LLM provider sets its own retention windows, training-data policy, and deletion guarantees, and those defaults change over time. Some offer zero-data-retention modes, but only to eligible accounts and only on certain endpoints. Others retain data for abuse monitoring unless you opt out. Those choices decide your exposure to subpoenas, breach notifications, and right-to-be-forgotten requests.

Most enterprises now use several providers at once, which multiplies the problem. A request can be routed to one provider, fail over to another, write a cached copy, land in gateway logs, and be exported to a SIEM, all within a second. Each of those copies has its own retention clock.

Enterprise app prompt + user data AI Gateway routing · residency · TTL Approved providers ZDR / minimized · training opt-out Unapproved provider never reached via fallback Logs in your cloud TTL by data class Deletion evidence erasure · holds · audit log request allow-list blocked prove log write Every copy has a clock provider · logs · cache · exports

One prompt, many copies. The checklist helps you decide how long each copy lives and how you prove it's gone.

Teams usually discover the gaps during a privacy review or the first erasure request. Zero-retention settings often don't cover stateful features like assistants, threads, files, vector stores, and batch jobs. Fallback routing quietly sends traffic to a provider nobody reviewed. Gateway logs, semantic caches, and embeddings keep copies of prompts long after the provider has deleted theirs. And nobody can produce evidence that deletion actually happened.

What good LLM data retention looks like

Every provider is cataloged with its default retention, training policy, and contract terms, and configured for zero or minimized retention wherever the account is eligible. Routing and fallback are restricted to an approved-provider allow-list, and data residency is enforced at runtime, not just at deployment.

Gateway logs live in storage you own, with shorter TTLs for sensitive classes like PHI, PCI, and EU PII. Caches expire automatically. Erasure requests reach logs, backups, exports, and derived data, and are reconciled with litigation holds and regulated retention by policy. Retention changes and deletion events are logged, so you can hand auditors evidence instead of assurances.

Control retention at the AI gateway

You can't change how a provider stores data, but you can control which providers see it, what you keep, and for how long. An AI gateway is the one point every request passes through, which makes it the right place to enforce provider allow-lists, residency, log TTLs, and deletion. For full retention ownership, self-hosted models keep the entire lifecycle inside your infrastructure.

The LLM Data Retention Checklist turns that standard into 31 criteria you can run against every provider and your gateway. Download it to close the gaps before an erasure request or audit finds them.

Preview

The five control areas in the LLM data retention checklist

A sample of the criteria in each area. The full checklist includes all 31, with priorities and evaluation questions.

Area 1 · 7 checks

Provider defaults and opt-outs

Zero or minimized retention and training opt-out are set where eligible

Stateful features that retain data under zero-retention modes are inventoried

+5 more checks

Area 2 · 5 checks

Gateway-level retention controls

Gateway logs are stored in your own cloud storage

Prompt and response bodies auto-delete after a configurable TTL

+3 more checks

Area 3 · 8 checks

Right to erasure and deletion

All data tied to a data subject can be located and deleted per GDPR Article 17

Erasure, litigation holds, and regulated retention are reconciled by policy

+6 more checks

Area 4 · 4 checks

Data residency and sovereignty

Residency is enforced at runtime across inference, agents, tools, and observability

Region-specific endpoints are enforced by geography

+2 more checks

Area 5 · 7 checks

Audit, evidence, and verification

Retention configuration changes are logged with who, what, and when

Each subprocessor's retention terms are visible to customers

+5 more checks

How to use · 3 steps

Rolling it out

Catalog every LLM, embeddings, and tool provider with its default retention and contract terms

Configure TTLs, opt-outs, and zero-retention modes at gateway and provider level

Verify deletion with receipts, audit logs, and provider attestations

4.7

★★★★★

Gartner Peer Insights

Rated 4.7 on Gartner Peer Insights

Platform teams run TrueFoundry's AI Gateway for LLM, MCP, and agent traffic in production, with logging that stays in their own cloud, retention by team and data class, runtime data residency enforcement, and self-hosted deployment for full retention ownership.

96%

of reviewers likely to recommend

4.9

ease of deployment and admin

3–4 ms

added gateway latency

LLM data retention checklist FAQ

What is a data retention policy for LLM providers?

A data retention policy for LLM providers defines how long prompts, responses, files, logs, caches, and derived data are kept by each model provider and by your own AI stack, whether that data can be used for training, and how it is deleted. It determines your exposure to subpoenas, breach notifications, and right-to-be-forgotten requests.

What is zero data retention for LLMs?

Zero data retention is a mode some LLM providers offer to eligible accounts in which prompts and responses are not stored after the request is processed. Eligibility, covered endpoints, and terms vary by provider, and stateful features such as assistants, threads, files, vector stores, and batch jobs may still retain data, so each one needs to be inventoried.

Do LLM providers train on API data?

It depends on the provider, the product, and your contract. Many enterprise API terms exclude customer data from training by default, but defaults and opt-out settings change, so teams should confirm training opt-outs for each provider and monitor provider terms for changes.

How do you handle GDPR right-to-erasure requests for LLM data?

You need user-attributed logs so all data tied to a data subject can be located, then deletion that extends to gateway logs, caches, backups, exported copies, and derived data such as embeddings, plus requests propagated to downstream providers where they offer deletion mechanisms. Erasure also has to be reconciled with litigation holds and regulated retention.

How does an AI gateway help with LLM data retention?

An AI gateway is the one point every LLM request passes through, so it can restrict routing to providers with acceptable retention terms, enforce data residency at runtime, store logs in your own cloud with TTLs by data class, expire caches, and record retention changes and deletion events as audit evidence.

Who should use the LLM data retention checklist?

Platform engineering, security, privacy, legal, and compliance teams who use multiple LLM providers and need to answer auditors, regulators, and data subjects about where AI data lives, how long it is kept, and how deletion is proven.