A request setting can sound broader than it is. Store false may address generated-response storage for a particular API path, but it does not describe every place the workflow sends or retains information. Uploaded resources, monitoring, connected systems and the application's own logs can have different behaviour. A responsible data-handling statement starts with that full map.
The proposed checklist below supports a technical and information-owner review. It does not determine legal compliance or claim that a particular organisation has an approved retention control. The practical output is a set of data-flow questions that must be answered with current documentation, actual configuration and attributable decisions before making a customer promise.
Separate the categories before discussing retention
Source: OpenAI data controls distinguishes abuse-monitoring logs from application state and describes controls and endpoint-specific limitations. It also separates whether API data is used for training from the question of storage. Not used for training is not a statement that no data is retained.
The guide describes approval and eligibility requirements for controls such as Modified Abuse Monitoring and Zero Data Retention. Their endpoint and feature limits still matter. Do not assume an organisation has those controls because the application sends a storage parameter, or describe the control name as a blanket promise across all connected systems.
Use the current official table and feature notes for the exact endpoint and operation. A guide's default or eligible setting may not represent the organisation's actual configuration. Keep the documentation review date and verified account/project evidence with the decision, and route unresolved questions to the responsible owner or provider contact.
Map the actual request path
List the incoming data, preparation steps, model endpoint, enabled tools, stored resources, output destinations and operational evidence. A document workflow may create an original upload, extracted text, model input, a draft summary and an exception task. Each can contain different personal or commercial details.
Distinguish temporary processing from persisted resources, and record when the team can verify deletion or expiration. Do not infer storage behaviour from an interface that hides a file after processing. The information owner needs an actual retention or deletion rule and the implementation evidence that supports it.
Connected tool providers and business systems have their own data paths. Source: OpenAI function calling describes application execution of model-requested functions. If the application sends content to another system, the response-storage flag does not by itself establish that system's retention or access controls.
Check the parameter and feature combination precisely
Record the endpoint, request settings, model/tool features and applicable project configuration. Verify what disabling storage means for that exact path. Uploaded files, persistent conversation or agent features and external tools may involve other state; use the relevant official notes rather than transferring a rule from another endpoint.
Include error paths. A failed request may still appear in application traces or provider monitoring under the applicable process. A retry can produce another record or external action. The absence of a successful model response does not establish that no information entered the workflow.
Keep account, project and regional control questions explicit. This checklist does not promise residency or a particular retention duration. The team should obtain the applicable documentation and verified settings before describing the arrangement to customers or internal reviewers.
Reusable data-flow questions checklist
Use this proposed worksheet before accepting a data-handling statement.
| Question | Evidence needed | Unresolved result |
|---|---|---|
| What enters the workflow? | Accepted field/document inventory and purpose | Reduce scope or clarify before processing |
| Which exact endpoint and features are used? | Actual request/configuration references | No assumption from a generic product label |
| What does the storage setting control? | Current official endpoint and feature notes | Limit the claim to verified behaviour |
| Which monitoring controls apply? | Actual eligibility/approval and project settings | Do not claim an unapproved control |
| What application state exists? | Uploaded resources, sessions or other enabled state | Review each relevant lifecycle |
| Which connected tools receive content? | Tool/provider data-flow and permission records | Assess separately from model storage |
| What local logs/traces exist? | Implemented fields, access and retention | Remove unnecessary content through approved design |
| Are backups or exports created? | Actual destination/lifecycle evidence | Include them in the review scope |
| How is deletion or expiration verified? | Accepted process and observable result | No promise from a hidden UI item |
| Who approves the statement? | Technical, information-owner and specialist decision as needed | Hold broad claims until accepted |
Proposed claim record: [Exact statement, applicable endpoints/features, verified controls, limitations, evidence date and approving owners]
The completion check is that the statement can be traced to the actual data flow and applicable controls. An unanswered row must remain a limitation rather than being replaced by none retained.
Keep output shaping separate from data minimisation
Source: OpenAI Structured Outputs describes schema-constrained responses. A schema can limit the fields in a generated summary, but it does not establish deletion of the original input or provider-side retention. A small output can still have been prepared from a large sensitive document.
Minimisation should be a separate accepted design decision about what the workflow needs to send and store. The technical owner verifies where unnecessary fields can be removed before processing. The information owner decides the purpose and access limits. Do not describe formatting or redaction of the final summary as proof that every upstream copy was removed.
Walk through disabled response storage and other records
Consider a hypothetical document-review application that disables generated-response storage for its selected request path. It also uploads a document resource, records execution metadata and creates a review task in an internal system. The checklist asks about each lifecycle separately. The storage flag alone cannot establish the retention of the upload, local trace or task.
Now suppose a developer confirms that the application logger records only request references, while an exception path includes the full input in an error message. The data-flow review identifies that difference and asks the technical owner to correct or explicitly govern it. A normal-path test does not establish the error-path behaviour.
An ambiguous configuration is another hold. Staff say Zero Data Retention is enabled but cannot identify the applicable project or feature limitations. The review records the claim as unverified and obtains the accepted account evidence. It does not turn a remembered setting into a customer promise.
Duplicate exports or retries should remain visible in the map until their lifecycle is established. A deleted primary record does not automatically prove that every permitted backup or copied output disappeared. The responsible owners determine the actual statement and its limits.
Review the promise and the implemented behaviour
Test the proposed data-flow inventory with synthetic content so the team can inspect logs, resources, outputs and failure paths without introducing customer records merely to discover where they go. Verify actual settings and outcomes under the authorised test scope. Documentation alone describes intended capabilities; implementation readback establishes the tested configuration.
Have the information owner and appropriate specialist assess purpose, access, retention and any customer wording. This article supplies questions, not a compliance determination. Recheck the statement when endpoints, tools, models or storage features change, keeping the earlier decision and revision reason.
Questions about disabling storage
Is not used for training equivalent to no retention?
No. Training use, monitoring and application state are separate questions in the official guide. A correct data-handling statement should identify which behaviour is being described and the evidence that supports it, without combining them into a broader unsupported promise.
Does Zero Data Retention cover every feature automatically?
The official guide includes eligibility, approval and endpoint/feature limitations. Verify the actual configuration and relevant notes before making a claim. The control name does not establish the retention of your application logs, connected providers or every enabled resource.
Can we promise no data is kept after deleting the output?
Only if the accepted evidence genuinely supports that exact scope across the relevant data flow. Deleting one output is not proof about uploads, monitoring, traces, backups or external destinations. Keep the statement limited to verified behaviour and route broader questions to the responsible reviewers.
If your business needs help defining this process, explore Custom AI agents, the wider AI automation services, and our custom-agent workflow guide. The agents and automation comparison and custom AI agent glossary explain the terms. To discuss your records and approval rules, get in touch.