Research summary — verify the current eligible list on OpenAI Trust Portal before standardizing

OpenAI ZDR-Eligible Models (2026): What's In Scope

By DDH Research Team at Digital Dashboard Hub·Updated June 21, 2026

Stop writing AI prompts from scratch.

Tell us your business + your task + your model. We write the prompt — perfectly tuned for ChatGPT, Claude, Grok, Gemini, Midjourney, or any model. Plus 500+ pre-built prompts in your library.

OpenAI Zero Data Retention (ZDR) — the opt-in commitment that the API will not persist inputs/outputs past the synchronous inference call — is gated on (a) Enterprise tier, (b) signed ZDR addendum, and (c) the specific endpoint and model being used. Not every model and endpoint is in the ZDR scope, and the list evolves as OpenAI ships new surfaces.

This page is the eligibility reference. The canonical source is the OpenAI Trust Portal (trust.openai.com) — access requires an OpenAI account and an NDA. We summarize the categorical structure of eligibility, the typical inclusion / exclusion pattern, and how to verify your specific deployment before routing regulated traffic.

Research summary, verify before standardizing. Eligibility changes; new models join, experimental surfaces sometimes start outside ZDR scope and join later. Always re-check the Trust Portal before standardizing on a new model or endpoint for ZDR-covered traffic. Related: /tutorial/configure-openai-zero-data-retention · /vs/zero-data-retention-vendors-2026 · /vs/openai-business-associate-agreement-vs-anthropic-baa.

Digital Dashboard Hub

Rate limits hurt because prompts are loose — ITPM blows up before RPM does. DDH's AI Prompt Builder writes cache-anchored prompts so 80%+ of your input tokens are billed at 10% of the rate, and you hit limits later (or never).

Start free 14-day trial — AICHAT30 = 30% off Pro for 3 months. →

OpenAI ZDR eligibility — categorical map (June 2026)

Feature	Endpoint family	ZDR eligibility
Chat Completions API (gpt-5 family, gpt-4.1, gpt-4o variants, o1/o3 reasoning)	Eligible (most models in this family)	Workhorse path for ZDR — verify the specific model snapshot on the Trust Portal
Responses API	Eligible	Modern unified API; same eligibility as Chat Completions on equivalent models
Embeddings API (text-embedding-3-small, -3-large)	Eligible	Standard inclusion
Batch API	Eligible (on eligible underlying models)	Async batch processing; eligibility inherits from the model used
Assistants API v2 (Threads + Messages)	Partially eligible — message generation eligible; file persistence has separate considerations	Stored Threads / Files are intentionally persistent — assess separately
Code Interpreter (within Assistants)	Excluded or scope-limited	Sandbox files persist for thread lifetime — not ZDR-equivalent
File Search (within Assistants)	Excluded from ZDR for the file storage portion	Indexed files are persistent by design — assess separately
Image generation (gpt-image-1.5, gpt-image-2, DALL-E 3)	Verify per-model on Trust Portal	Some image endpoints are eligible; others have caveats around generated-content retention
Whisper / audio transcription	Verify per-endpoint on Trust Portal	Audio handling has separate considerations
Text-to-speech (tts-1, tts-2-hd)	Verify per-endpoint	Generated audio handling has separate considerations
Fine-tuning API (training)	Training data is intentionally persistent — not ZDR by definition	Trained model storage is persistent; inference on fine-tuned eligible base models inherits ZDR
Real-time API (voice agents, sessions)	Verify per-endpoint on Trust Portal	Real-time / persistent session features may have separate scoping

Source: OpenAI Trust Portal at trust.openai.com (categorical structure consistent with publicly summarized eligibility as of June 2026). The portal hosts the canonical, signed list that you should pull under NDA and store in your audit evidence library. Verify the current list before standardizing on a specific model for ZDR-protected traffic — eligibility evolves as new endpoints ship.

How OpenAI's eligibility list is structured

OpenAI maintains ZDR eligibility at two levels: (a) the model — specific model snapshot (e.g., gpt-5.5-2025-05-09, gpt-4.1-2024-12-17) is either in or out of ZDR scope; and (b) the endpoint family — the API surface used to invoke the model (Chat Completions, Responses, Assistants, Batch, Embeddings, etc.) is either in or out for that model.

The intersection matters. A model can be ZDR-eligible on Chat Completions and ineligible on the same model invoked via Code Interpreter (because Code Interpreter introduces persistent sandbox files). Always check both the model and the endpoint.

Typical inclusion pattern for new GA models: chat completions and embeddings are usually eligible at GA. Batch is usually eligible shortly after. Assistants v2 message generation is usually eligible at GA but the persistent surfaces (Threads, Files, vector_stores) are scoped separately.

Typical exclusion pattern: experimental / preview endpoints (early access, beta) often start outside ZDR scope. Once they reach GA and the data-handling story has been finalized, they join the eligible list.

Categorical exclusions: any endpoint that is fundamentally persistent by design (fine-tuning training data, stored Threads, file search indexes, vector_stores, persistent assistants) is not ZDR. These surfaces have separate retention and access controls; some can be configured for short retention but they are not zero-retention by definition.

Verifying eligibility for a specific deployment

Before routing ZDR-protected traffic through a model + endpoint combination, verify:

1. Pull the current ZDR-eligible list from the OpenAI Trust Portal (under NDA).

2. Confirm both the specific model snapshot you're using and the endpoint family are listed.

3. If your BAA is also in force for HIPAA traffic, confirm the BAA-eligible list. Your usable surface is the intersection.

4. Document the verification in your audit evidence (date, list version, signed-off-by).

5. Add a runtime guard in your application that fails fast if the LLM call uses a non-eligible model or endpoint.

Runtime guard pattern (TypeScript): const ZDR_ELIGIBLE_MODELS = new Set(['gpt-5.5-2025-05-09', 'gpt-4.1-2024-12-17', 'text-embedding-3-large']); function assertZdrEligible(model: string) { if (!ZDR_ELIGIBLE_MODELS.has(model)) throw new Error(`Model ${model} not in ZDR-eligible list`); }. Call assertZdrEligible() in your safeLlmCall wrapper before invoking.

Model snapshot pinning

OpenAI's model versioning uses snapshot IDs (e.g., gpt-5.5-2025-05-09) alongside aliases (e.g., gpt-5.5). For ZDR-protected traffic, pin to the specific snapshot, not the alias. Reasons:

Auditability: when an auditor samples a log entry, the snapshot ID resolves to a specific point-in-time eligibility. Aliases are mutable — the same alias may point to different snapshots over time, complicating evidence.

Eligibility stability: when OpenAI promotes a new model behind an alias, the new snapshot may have a different ZDR scope than the previous one. Pinning prevents accidentally drifting into a different scope.

Behavioral stability: pinned snapshots have consistent behavior. Auditors and your customers expect deterministic LLM behavior; pinning supports that.

Cost predictability: pricing changes may apply on new snapshots; pinning to a known snapshot stabilizes per-token cost for forecasting.

Trade-off: pinned snapshots eventually deprecate (12-24 month typical lifecycle). Build a snapshot-upgrade process that includes (a) verifying the new snapshot's ZDR + BAA eligibility, (b) running the new snapshot through your evaluation harness to verify behavior parity, (c) updating the runtime allowlist, (d) cutting traffic over.

What's NOT in scope under ZDR

Even with ZDR enabled on every eligible call, the following surfaces are not ZDR-equivalent and must be handled separately:

Stored Threads in Assistants v2: a Thread persists for the configured retention, holding the full message history. Decide whether to use Assistants Threads for ZDR-protected workloads — many regulated buyers prefer to manage conversation state in their own database to maintain full control over retention.

Stored Files in Assistants: uploaded files persist until deleted. For ZDR-protected workloads, either upload sanitized / de-identified files only, or use the file upload as a transient operation (upload, use, immediately delete in code).

Vector Stores (within Assistants File Search): indexed file content persists in the vector store. Manage retention via deletion policies in your application.

Fine-tuning training data: training datasets are stored to enable training. Retention is per your fine-tuning configuration. Strong de-identification of training data is the standard approach.

Stored Completions (if enabled for the project): when stored_completions is enabled for analytics / debugging, completions persist per the configured retention. Disable stored_completions for ZDR-protected projects.

Operational metadata (universal exception): token counts, latency, model ID, project ID, organization ID, error codes. Retained per OpenAI's operational logs. Not the inputs/outputs themselves.

Eligibility for cached prompts

OpenAI's automatic prompt caching applies to repeated prompt prefixes. Cached content is stored encrypted in OpenAI's inference layer; eviction is automatic based on the cache's TTL.

Under ZDR, the cached content is treated consistent with the ZDR commitment: not surfaced to humans, not used for training, evicted per TTL. Verify with your account team that your ZDR addendum's cache treatment matches your retention posture.

If your compliance posture requires no caching at all (some sovereign / classified workloads), explicit cache-disable can be requested. Verify current Enterprise configuration options with your account team.

Practical workflow for a new model adoption

When OpenAI announces a new GA model and you want to adopt it for ZDR-protected traffic:

Step 1: wait for the Trust Portal to update with the new model's ZDR + BAA eligibility. This is typically days to weeks after GA. Do not assume eligibility based on the model family.

Step 2: pull the updated Trust Portal documentation and store in your audit evidence library.

Step 3: update your runtime allowlist with the new snapshot. Add the snapshot to ZDR_ELIGIBLE_MODELS and BAA_ELIGIBLE_MODELS as applicable.

Step 4: run your evaluation harness against the new model to verify quality parity. ZDR-protected workloads should not degrade quality vs the prior snapshot.

Step 5: stage rollout. Start with a small percentage of traffic, monitor error rate + latency + cost, ramp to 100% over a defined window.

Step 6: deprecate the prior snapshot on the documented OpenAI deprecation timeline.

Step 7: document the rollout in your change management log per SOC 2 CC8.

Digital Dashboard Hub

Knowing the limits is step one. Writing prompts that don't crash into them is step two — cache anchors, batch-ready structure, capped outputs. DDH does step two automatically.

Try DDH's AI Prompt Builder — free 14 days, no card. AICHAT30 = 30% off Pro. →

Related calculators

OpenAI Pricing Calculator →GPT-5.5, 5.4, mini, nano — full per-call cost in one input.Claude Pricing Calculator →Opus 4.8, Sonnet 4.6, Haiku 4.5, Fable 5 — input + output combined.Context Window Comparison →Max input length and price per 1M for every current model.

Continue your research on adjacent topics — calculators, rate limits, head-to-head comparisons, and guides.

Related prompt tools

Configure OpenAI zero data retention→Zero data retention vendors 2026→OpenAI BAA vs Anthropic BAA→OpenAI vs Anthropic vs Azure OpenAI compliance→

Use the data programmatically

Every page on this site is also exposed as a free, CORS-open JSON endpoint. No auth, no rate limit (fair-use, please cache). License is CC-BY-4.0 — link back to attribution.canonicalUrl in the response.

Endpoint: https://aipromptshub.co/api/limits/openai-zdr-eligible-models-2026

curl

curl -s 'https://aipromptshub.co/api/limits/openai-zdr-eligible-models-2026' | jq .

Python

import requests

r = requests.get("https://aipromptshub.co/api/limits/openai-zdr-eligible-models-2026", timeout=10)
r.raise_for_status()
data = r.json()
print(data["title"])
for source in data.get("sources", []):
    print("source:", source)

JavaScript / Node

// Node 20+ / modern browser
const res = await fetch("https://aipromptshub.co/api/limits/openai-zdr-eligible-models-2026");
if (!res.ok) throw new Error("HTTP " + res.status);
const openai_zdr_eligible_models_2026 = await res.json();
console.log(openai_zdr_eligible_models_2026.title);
for (const source of openai_zdr_eligible_models_2026.sources ?? []) {
  console.log("source:", source);
}

Spec: /api/openapi.yaml · Docs: /api/docs

Frequently Asked Questions

Is every OpenAI model ZDR-eligible?

No. Eligibility is per-model + per-endpoint and maintained on the OpenAI Trust Portal. Chat Completions on GA gpt-5 family and gpt-4.1 / 4o family models are broadly eligible. Experimental / preview surfaces and persistent surfaces (Assistants Threads, Files, Vector Stores, fine-tuning training data) have caveats or are excluded.

How do I check the current eligibility list?

Log into trust.openai.com under your OpenAI account, sign the mutual NDA, and download the ZDR eligibility documentation. Public artifacts (SOC 3, high-level overviews) are available without NDA. The detailed model + endpoint eligibility list is NDA-gated.

Should I pin model snapshot for ZDR-protected traffic?

Yes — pin to specific snapshot IDs (e.g., gpt-5.5-2025-05-09) rather than aliases (gpt-5.5). Snapshots have stable eligibility, behavior, and pricing. Aliases shift, which makes audit evidence harder to assemble.

How does ZDR interact with the BAA-eligible list?

Your usable surface for HIPAA-covered traffic is the intersection of ZDR-eligible AND BAA-eligible. Both lists exist on the Trust Portal. Always verify the intersection before routing PHI through a model + endpoint combination.

Does fine-tuning fall under ZDR?

No — fine-tuning training data is intentionally persistent. Training datasets are stored to enable training. Inference on a fine-tuned model can be ZDR-protected if the base model is ZDR-eligible; the training dataset storage has separate retention and access controls.

What about cached prompts under ZDR?

OpenAI's automatic prompt caching is treated consistent with the ZDR commitment — cached content not surfaced to humans, evicted per TTL. If you need explicit cache-disable, request via Enterprise sales.

Does ZDR apply to fine-tuned models?

Inference on fine-tuned models can be ZDR-protected if the base model is ZDR-eligible. The fine-tuned model artifact itself is a separate persistent asset. Verify with your Enterprise team that your fine-tuned model's inference is in the ZDR scope.

How often does the eligibility list update?

Updates typically follow new model launches (days to weeks after GA). The Trust Portal is the canonical source. Subscribe to OpenAI Trust Portal notifications if available; otherwise review monthly during your SOC 2 / HIPAA program management cadence.

ZDR scope verified. Now ship eligibility-aware prompts.

ZDR eligibility decides which models you can use. The prompt decides whether those models earn their rate. AI Prompts Hub writes ZDR-eligible-model-tuned prompts (gpt-5 family, gpt-4.1, o-series) — so every covered call does useful work.

Browse all prompt tools →