Separate training, abuse logs, and application state

Teams often collapse three different questions into one privacy checkbox:

• Is customer content used to train models?
• Is content included in provider abuse-monitoring logs?
• Does an API feature store application state so it can work later?

OpenAI says API inputs and outputs are not used for model training by default unless an organization explicitly opts in. Standard API use may still generate abuse-monitoring logs containing prompts, responses, or derived metadata. OpenAI's data-control documentation says those logs are normally retained for up to 30 days unless law requires longer retention.

Approved ZDR and Modified Abuse Monitoring projects exclude customer content from abuse-monitoring logs. ZDR also changes eligible endpoints so they do not store application state. Some endpoints and features are not ZDR eligible, so enabling ZDR for an organization does not convert every stateful API object into an ephemeral one.

Verify the project and organization separately

ZDR requires OpenAI approval and acceptance of additional requirements. Once approved, an organization can configure retention controls at the organization level and override them per project. A project can inherit the organization setting, explicitly use ZDR or Modified Abuse Monitoring, or set the control to None.

Record the organization ID, project ID, retention mode, region, and environment in the deployment manifest. Make the production service use a project-scoped key from the reviewed ZDR project. A valid key from a different project can silently place requests under different retention controls.

Treat configuration verification as a release check. The person approving a privacy-sensitive deployment should compare the runtime project against the Data Retention tab in the OpenAI Platform, then keep evidence of that check with the release. Key rotation needs the same review because a newly issued credential can point to the wrong project even when the application code is unchanged.

Inventory endpoints and tools

OpenAI publishes a table that separates training use, abuse-monitoring retention, application-state retention, and ZDR eligibility for each endpoint. Build your own smaller table containing only the features your service calls:

For /v1/responses and /v1/chat/completions, ZDR forces store to false even when a request tries to set it to true. That behavior is useful, but store: false on an ordinary project is not the same as approved ZDR. It only controls application-state storage for that request.

OpenAI says Responses API background mode stores response data for roughly ten minutes so clients can poll, which makes it incompatible with ZDR. Code Interpreter cannot be used with ZDR, and extended prompt caching stores tensors in GPU-local application state, so requests using it are not ZDR eligible. Remote MCP servers are separate services; any content sent to them follows their retention policies.

Conversations, files, vector stores, batches, evaluations, fine-tuning jobs, and other durable resources have their own storage behavior. Many remain until deletion and are listed as ineligible for ZDR. If the product needs them, separate that workflow into a project with the appropriate control, document the data classification, and set deletion or expiry rules. Do not label the entire product ZDR when one branch deliberately creates durable state.

Enforce privacy modes in code

Privacy controls fail when they live only in a dashboard. Give each request a declared privacy mode and reject incompatible features before calling the provider. A small policy layer can make the decision visible:

type PrivacyMode = "zdr" | "stateful";

function assertRequestPolicy(
  mode: PrivacyMode,
  options: { background?: boolean; codeInterpreter?: boolean },
) {
  if (mode !== "zdr") return;
  if (options.background) throw new Error("Background mode is not ZDR compatible");
  if (options.codeInterpreter) throw new Error("Code Interpreter is not ZDR compatible");
}

This helper does not enable ZDR. It prevents your code from combining a ZDR-designated route with features OpenAI documents as incompatible. The provider project still needs approval and configuration. Add tests that enumerate every model call site and fail when a new tool or storage feature bypasses the policy layer.

In a multi-model gateway, store a provider, project class, privacy mode, and feature set in the route configuration. ISH API can keep provider access consistent, but the application still owns its routing rules and privacy claims. Do not copy raw prompts into routing diagnostics.

Audit copies outside the model provider

Start at the client and follow the request in both directions. Inspect browser telemetry, mobile crash reports, reverse proxies, load balancers, API gateways, server logs, job queues, caches, traces, analytics, data warehouses, support exports, and backups. For every system, record the fields captured, access roles, region, encryption, retention period, deletion mechanism, and downstream processors.

Generic HTTP middleware often records request bodies and model outputs because they are convenient during debugging. Replace content with bounded metadata: request ID, model, latency, token counts, tool names, policy decisions, and an application outcome. The agent tracing guide shows how to preserve useful operational evidence without logging the entire conversation.

When content must be retained for a customer-visible history, state that clearly. Encrypt it, scope access by tenant, implement deletion, and keep it in infrastructure covered by the product's privacy terms. ZDR does not require your application to forget a conversation, but your own storage becomes the system of record and must be governed accordingly.

Test the claim before publishing it

Create a canary prompt containing a unique synthetic marker and send it through each production route. Search authorized logs, traces, queues, databases, support tools, and exports for that marker. Confirm that ephemeral paths contain no content and that approved stateful paths expire or delete it as documented. Never use real personal data for this test.

Repeat the exercise when adding a model, tool, endpoint, caching mode, region, or observability vendor. Review OpenAI's endpoint table because eligibility and behavior can change. ISH chat is useful for comparing model behavior with synthetic prompts, while the least-privilege checklist helps keep tool access inside the same data boundary.

The final privacy statement should name its scope: which API project uses ZDR, which routes qualify, which features create state, where your application stores content, and how users can delete it. Engineers can turn each part of that statement into a release test.

Sources

• OpenAI: Offering Zero Data Retention for frontier models
• OpenAI Platform: Data controls and retention by endpoint
• OpenAI API reference: Create a model response
• OpenAI: Enterprise privacy
• OpenAI Help Center: Sharing API feedback and evaluation data