This guide was prepared with AI assistance using the linked documentation. Code examples are illustrative; verify them against your environment and current API documentation before use.
Start with one request
Follow a single customer document from upload to answer. It may pass through your browser, application server, file storage, model API, retrieval system, logs, and a third-party connector. Each place can have its own access rules and retention period.
Draw that path before selecting a retention setting. A setting on one API call cannot delete copies held by your own services or another vendor.
Use a table that includes the specific system, the team responsible, the access rule, and the verification date. An inventory with unnamed owners is difficult to maintain after a handoff. Review it when an integration is added, when a provider changes a feature, and when the applicable retention agreement changes.
Distinguish three kinds of storage
Separate your application's records from provider application state and provider abuse-monitoring logs. Their purposes and controls differ. For OpenAI, the data-controls documentation lists endpoint and feature-specific behavior, including where approved retention arrangements apply.
Do not treat Zero Data Retention as a universal switch for every feature. Eligibility and exceptions vary. For example, remote MCP servers are third-party services and their handling is governed by their own policies.
Record the organization and project involved in each data flow. Two projects in one product can have different settings or approvals, and a later configuration change can alter the answer. The inventory should point to the owner who can verify those settings rather than assume that a checkbox in your UI changes provider-side behavior.
Use a simple inventory
For every copy, name its owner, purpose, access boundary, deletion mechanism, and expected lifetime. Include derived material such as vector indexes, cached context, transcripts, and support attachments.
The sample is a worksheet, not a statement that these particular retention periods apply. Replace the unknown values only after checking your own systems and agreements.
Include the lifecycle of each derived record. A searchable chunk might contain personal information from the original file even if its filename contains no personal information. An answer copied into a support ticket or a downloaded report creates another copy whose deletion process belongs in the map.
Data: uploaded policy document
Store: application object storage
Owner: document service
Access: tenant and role checked on read
Retention: defined by the customer contract
Deletion: object plus derived search index
Evidence: deletion job and audit recordCheck asynchronous features separately
Background responses are stored temporarily to support polling, including when a request uses store=false. The provider's guide describes how retention differs with explicit storage and applicable data controls. That is a different lifecycle from a synchronous request.
Prompt caches also have model-specific settings and lifetimes. Check the current guidance for the model, project policy, and region. Do not infer a deletion deadline from a cache minimum lifetime.
Do not treat an asynchronous response identifier as a complete retention policy. Record where the identifier is stored, who can retrieve the result, how long your application keeps it, and what happens if a user requests deletion while a job is still running. Check current provider documentation for the selected feature.
Minimize what enters logs
A useful operational log can record a request ID, status, latency, model, and usage without storing an entire prompt. If a support workflow needs payload access, make that an explicit, restricted feature with a documented retention period.
Remove credentials from traces and error reports. When sending a safety identifier, follow the provider's guidance for a stable privacy-preserving identifier rather than sending a raw email address.
Prove the deletion path
Test deletion with synthetic data: upload a document, create its derived search entry, request deletion, and verify both the source and the index are no longer accessible. Also inspect backups, exports, logs, and external integrations for copies that follow a different schedule.
A retention map should be reviewed by the people responsible for security, privacy, and operations. It is an engineering record, not a substitute for legal advice or a provider agreement.
A useful test has a clear owner and a clear end condition. The person running it should check access as the original user and as a different tenant, confirm that the derived index is updated, and record any backup or external system that remains subject to a different schedule. Repeat the test when the ingestion or deletion pipeline changes.
Follow a file through deletion
For a policy-search assistant, start with the upload, then list its derivatives: extracted text, search chunks, embeddings, answers, review exports, and diagnostic traces. Deleting the source does not necessarily remove those copies.
Assign an owner and deletion mechanism to each store. If a backup or third party follows a different lifecycle, record the restriction rather than promising immediate deletion everywhere. Verify with synthetic data and an account that should have lost access.
Sources and further reading
Documentation reviewed November 9, 2026. Verify current model support, limits and pricing before implementation.