LLM API Data Retention vs Zero Data Retention: A Route-Level Audit

Use standard LLM API retention only when the submitted data is low sensitivity and a documented, time-bounded retention path fits your policy. Require zero data retention (ZDR) when prompts or outputs must not be stored by the provider for routine abuse monitoring or application state. In either case, approve the exact route—not the provider name.

The first action is to record the organization or project, endpoint, model, enabled features, gateway, subprocessors, and your own logs. Then test all six retention planes below. If one critical plane is unknown, contradicts the contract, or falls outside the approved boundary, stop sensitive traffic.

This is an engineering and procurement method, not a legal conclusion. ZDR can support a compliance program, but it does not by itself establish GDPR, HIPAA, financial-services, or other regulatory compliance.

Data Retention and ZDR Answer Different Questions

“Not used to train models” answers what the provider does with data for model improvement. It does not answer whether the same content appears in abuse-monitoring logs, conversation state, files, caches, tool calls, support systems, or your telemetry.

Ordinary API retention usually means the provider may keep some customer content for a stated period and purpose. The scope can differ by endpoint and feature. ZDR is a narrower arrangement under which eligible content is not retained in the provider's routine storage path after the response, subject to the provider's documented safety, legal, and product exceptions.

That distinction has two practical consequences:

1. A no-training API can still be unacceptable for a workload whose policy prohibits storage.
2. A ZDR-approved account can still leave the ZDR boundary by enabling an ineligible file, agent, batch, search, cache, code-execution, or third-party tool feature.

A request flag such as store=false is useful configuration evidence, but it is not a contract. It cannot prove that the organization has ZDR, that abuse-monitoring retention changed, or that every attached feature and downstream service is eligible.

Audit the Six Places Data Can Persist

Treat retention as six independent planes. A route passes only when every plane required by the workload has a known and approved answer.

The six-plane framework is an editorial audit method, not an industry certification. Its value is that it prevents one favorable policy sentence from hiding a separate retention path.

When Standard Retention Is the Better Decision

ZDR is not automatically the safest architecture for every workload. A route with explicit limited retention, strong access controls, documented deletion, and no sensitive input can be easier to operate and audit than a nominal ZDR route with unknown downstream services.

Standard retention can be reasonable when all of these are true:

• inputs are public, synthetic, or de-identified under a tested process
• the business purpose does not require secrets, personal data, confidential documents, or unreleased code
• the documented abuse-monitoring and application-state windows fit policy
• files, tools, caches, and stateful endpoints are inventoried
• your application logs use an approved TTL and redaction policy
• a named reviewer accepts the residual risk and recheck date

For example, a public-product FAQ classifier using synthetic regression tests may accept a documented default retention window. A source-code review assistant receiving an unreleased repository may not. The difference is the data classification and route evidence, not whether one model is “more private.”

Use ZDR when your policy or contract prohibits routine provider storage of the submitted content, or when the consequence of retention exceeds the accepted risk. Even then, minimize input, redact unnecessary identifiers, and restrict features. ZDR is a control layer, not permission to send every field.

Current Route Matrix: What the Official Docs Actually Establish

The following boundaries were checked against official documentation on July 27, 2026. They are starting points for route verification, not provider-wide certifications. Recheck the exact row before deployment because endpoint and feature eligibility changes.

Cloud platforms and gateways are different route owners from direct model APIs. A contract with one does not silently extend to another. Likewise, a provider's consumer chat, developer console, free tier, and paid API can have different terms.

If a gateway or proxy is in the path, require evidence for both the gateway and exact upstream endpoint. Do not approve a sensitive workload from an upstream ZDR badge alone. No public ZDR evidence was verified here for laozhang.ai, so this article does not recommend that gateway for a ZDR-required route.

Build a Route Evidence Card

The deliverable is not a screenshot of a marketing page. It is a versioned record that another reviewer can use to reconstruct the deployed data path.

Copy this evidence card into the security ticket or architecture decision record:

text
Workload and data class:
Policy requirement:

Route owner:
Gateway / cloud / proxy:
Upstream provider and endpoint:
Organization / project / workspace ID:
Model and pinned version:
Region:
Enabled features and tools:
Fallback routes:

Training-use rule:
Abuse/safety-log retention:
Provider application state:
Feature-specific storage and TTL:
Provider project logging and effective `store`:
Datasets, exports, sharing, and deletion:
Subprocessors/downstream services:
Customer logs, queues, databases, and backups:

Official eligibility page and checked date:
Contract / DPA / ZDR approval reference:
Configuration export or admin evidence:
Deletion or expiry test:
Known legal/safety exceptions:

Decision: ALLOW / ALLOW WITH LIMITS / STOP
Allowed data classes:
Reviewer and owner:
Recheck date and change triggers:

Do not put secrets, raw prompts, personal data, or customer content into the evidence card. Store references to protected configuration and contract evidence under the appropriate access controls.

The card is complete only when the route name resolves to a real deployed configuration. “OpenAI,” “Claude,” or “Gemini” is not a route. “Production project X, direct endpoint Y, pinned model Z, text-only, no files/tools/fallbacks, ZDR approval reference, application-log TTL seven days” is auditable.

Verify Before Sensitive Traffic Goes Live

Use a non-sensitive test request and fail closed:

1. Classify the workload. Write which fields can reach the model and which data classes are prohibited.
2. Draw every hop. Include SDK telemetry, API gateway, cloud platform, model endpoint, tools, search, MCP servers, queues, observability, support exports, and backups.
3. Match scope, not branding. Confirm the organization, project, workspace, region, endpoint, model, and plan named by the official policy or contract.
4. Inventory features. Start with the smallest stateless request. Add files, caches, batch, agents, grounding, code execution, or tools only after each one passes separately.
5. Capture configuration evidence. Export the relevant admin setting or API configuration. A request parameter proves only that parameter was sent.
6. Test customer controls. Send synthetic markers, then verify redaction, log destinations, TTL, deletion, backups, and support tooling without exposing real sensitive data.
7. Record exceptions and obtain approval. Security, privacy, legal, and procurement owners should review the boundary appropriate to the workload.
8. Gate the route. Enforce an allowlist for approved endpoint, model, features, and fallbacks. Reject or redact requests outside the allowed data class.

The acceptance result should be observable: a reviewer can identify the exact allowed route, see current evidence for all six planes, reproduce the configuration check, and show that an unapproved feature or fallback is blocked.

Worked example: a source-code summarizer

Assume a team wants to summarize an unreleased repository. The contract requires ZDR, and a direct Messages endpoint is documented as eligible for the organization's approved arrangement. That is not yet an approval.

The route passes only if the team confirms the production organization, selected model, no storage-requiring feature, no unapproved fallback, and an application log policy that removes prompt bodies. If a developer later enables code execution or an MCP connector that is outside the documented ZDR scope, the release gate must reject the change. The original provider approval did not cover the new feature.

If the team needs an MCP workflow, the next task is to design its tool boundary and credential controls; the Claude MCP internal-tools integration guide covers that architecture. It does not convert the connector into a ZDR-eligible feature.

Fail-Closed Stop Rules

Stop sensitive traffic when any of these is true:

• the ZDR claim has no current official scope or contractual reference
• the contract, dashboard, API configuration, and deployed organization do not agree
• an endpoint, model, file, cache, batch job, agent, search feature, code executor, or tool is not explicitly in scope
• a gateway cannot identify the exact upstream endpoint or may fall back to a non-approved route
• a subprocessor's retention or region is unknown
• application logs, traces, queues, backups, or support exports retain prompt bodies outside policy
• a legal or safety exception conflicts with the workload's absolute-retention requirement
• the route changed after the last review

Do not “temporarily” permit real sensitive data while waiting for a policy answer. Use synthetic or redacted test data, select a verified alternative route, or keep the workload offline.

Recheck on Every Material Route Change

ZDR evidence expires when the deployed facts change. Trigger a new review after:

• contract renewal or provider policy update
• organization, project, workspace, account plan, or region change
• model alias, model version, or endpoint migration
• enabling files, batch, memory, caching, sessions, agents, search, grounding, code execution, MCP, or another tool
• changing project logging, effective store, log-retention window, or dataset creation, export, or sharing
• adding or changing a gateway, proxy, fallback, subprocessor, analytics SDK, or support integration
• changing application logging, backup, deletion, or incident-response behavior

Put the evidence-card version in the deployment record and make the approved feature set machine-enforceable where possible. A quarterly review is useful, but a route-change gate catches risk when it is introduced.

Once retention is cleared, compare cost, quality, and support ownership with the cheapest LLM API provider decision guide. If the actual job is deleting Gemini or other Google AI history rather than approving an API route, use the separate Google AI data deletion guide.

Bottom Line

Choose standard retention for low-sensitivity workloads only when the documented window, features, downstream services, and customer logs fit policy. Choose ZDR when the workload cannot tolerate routine provider storage—but accept the route only after the organization, endpoint, model, features, gateway chain, and six retention planes are verified.

The release rule is deliberately strict: unknown is STOP for sensitive traffic. Record the evidence card, enforce the approved route, and reopen the decision whenever the route changes.