What data does OpenAI store from your API calls? (2026 guide)

If you’re building with the OpenAI API and your application touches personal data — patient records, financial information, legal documents, user communications — you need a clear picture of what OpenAI actually retains. Not what the marketing page implies. What the privacy policy, enterprise agreements, and API documentation actually say.

This guide goes through each retention category as of mid-2026. Where OpenAI’s policies have changed, we note the timing. Where ambiguity exists, we say so.

Default API data retention: 30 days

When you make an API call to OpenAI, your input (the prompt) and the output (the completion) are stored by OpenAI for 30 days by default. This retention is for abuse monitoring and safety purposes — not for training.

This means:

• If you send {"role": "user", "content": "Summarize this patient note: Maria Lopez, DOB 04/15/1962, MRN 48291..."}, that string is stored on OpenAI’s infrastructure for 30 days
• OpenAI employees with legitimate access can review stored inputs and outputs for safety and abuse investigation purposes
• After 30 days, this data is deleted — unless you have a contractual arrangement that specifies otherwise

The 30-day window matters for regulated data. Under HIPAA, any system that stores PHI requires its own safeguards. Under GDPR, storage of personal data requires a lawful basis and a defined retention period.

Zero Data Retention (ZDR): what it covers and what it doesn’t

Zero Data Retention is an opt-in configuration available to eligible API customers (typically enterprise accounts). With ZDR enabled:

• OpenAI does not store your prompts or completions after the API response is returned
• There is no 30-day retention window for request content

What ZDR does not eliminate:

• Metadata retention: timestamps, model name, token counts, request IDs, and error codes are retained for billing, rate limiting, and operational purposes — even with ZDR
• In-flight processing: your data still passes through OpenAI’s inference infrastructure while the request is being processed — ZDR affects persistence, not processing
• Abuse detection: OpenAI’s real-time abuse detection systems still process requests; ZDR affects log retention, not real-time safety checks
• Your own logs: anything your application logs before or after the API call is outside OpenAI’s control

ZDR eligibility is not automatic. It requires an enterprise agreement and may not be available for all model endpoints. Check your current agreement or contact OpenAI sales.

Feature	Default	With BAA	With ZDR
Input/output retention	30 days	Covered by BAA terms	0 days (no content stored)
Metadata retention	Yes	Yes	Yes
Training on your data	No	No	No
Employee access	For safety/abuse review	For safety/abuse review	Reduced (no stored content)
GDPR Art. 44 compliance	Limited	Partially addressed	Still requires SCCs
HIPAA suitability	Requires BAA	Requires BAA + tech safeguards	Stronger posture

Training on your data: the current policy

OpenAI’s policy as of March 2023 (and unchanged since): API data is not used to train OpenAI’s models by default. This applies to inputs and outputs from the Chat Completions API, Assistants API, Embeddings API, and other standard endpoints.

The key exception: fine-tuning data. When you submit a fine-tuning job, you upload training data to OpenAI. That data is:

• Used to train your fine-tuned model variant
• Stored for the duration of the fine-tuning job and your model’s existence
• Not used to train OpenAI’s foundation models (per current policy)

If you’re fine-tuning on data that contains PHI or personal information, the training data itself travels to OpenAI and persists there. A BAA covering fine-tuning data should specify what OpenAI can and cannot do with it after job completion. Most standard BAAs don’t address this with sufficient specificity.

What a BAA actually changes

A Business Associate Agreement establishes the legal relationship between you (the covered entity or business associate) and OpenAI (acting as your business associate). What it changes:

• Breach notification: OpenAI is contractually obligated to notify you of breaches within a defined timeframe
• Permitted uses: OpenAI can only use PHI for the purposes defined in your agreement
• Subprocessor obligations: OpenAI must have appropriate agreements with their subprocessors for your data
• Retention terms: BAA terms may specify or restrict data retention periods

What a BAA does not change by itself:

• ZDR eligibility: a BAA does not automatically enable zero data retention — these are separate contractual arrangements
• Technical safeguards: your HIPAA technical safeguard obligations (§164.312) remain your responsibility regardless of the BAA
• Training policy: OpenAI’s general training policy applies; a BAA doesn’t add additional training restrictions beyond what their standard policy already provides
• EU data residency: data still processes through OpenAI’s US infrastructure unless you have a specific regional arrangement

The Embeddings API: often overlooked

The Embeddings API converts text into numerical vectors for use in semantic search and retrieval-augmented generation (RAG) systems.

When you call the Embeddings API:

• The input text is sent to OpenAI for processing
• The same 30-day default retention applies
• The returned embedding (a vector of floats) is opaque — but the API call that generated it contained your original text

Teams building RAG systems over healthcare or legal documents often focus on the security of the vector store without considering that every document chunked and embedded went through OpenAI’s infrastructure as plaintext. If those documents contain PHI or personal data, the embeddings API calls are subject to the same HIPAA and GDPR requirements as any other API call.

The minimum necessary principle applies here too: you don’t always need to embed full documents. Embedding only the clinically or legally relevant portions reduces both your compliance surface and your embedding costs.

Your own logs: the more common exposure

A counterintuitive finding when auditing AI systems: your own infrastructure is often a bigger data risk than your AI provider.

Common sources of unintended PHI retention in AI applications:

Application logs: Most web frameworks log request bodies at DEBUG level. If your application server logs the request to your AI feature, and that request contains a patient note, you now have PHI in your application logs — with whatever retention, access controls, and security your log management system provides (often: indefinite retention, broad access, minimal encryption).

API gateway logs: If your API gateway or load balancer logs request bodies (some do by default), PHI in prompts is captured there.

Proxy and middleware logs: LLM observability tools (LangSmith, Helicone, Portkey) that sit between your application and OpenAI log prompts and completions by design. These tools have their own privacy policies and data retention practices. Routing PHI through them without a BAA is a compliance gap.

Browser and mobile client logs: If prompt construction happens client-side and the client logs to a crash reporting service, patient data can end up in Sentry, Datadog, or similar tools without any HIPAA controls.

Database query logs: If your RAG system logs which documents were retrieved and those documents contain PHI, your database query log is a PHI store.

Auditing your own logging pipeline is frequently more productive than negotiating ZDR with OpenAI.

Cross-border processing and GDPR

Unless you have a specific regional arrangement, OpenAI processes API data in the United States. For EU-based organizations handling personal data of EU residents, this triggers GDPR Chapter V restrictions on cross-border transfers.

OpenAI provides Standard Contractual Clauses (SCCs) in their data processing agreements for EU customers. SCCs are currently the primary legal mechanism for US-bound transfers after the Schrems II invalidation of Privacy Shield.

SCCs are a legal mechanism, not a technical one. The data still moves to the US. For organizations under strict data residency requirements — public sector, healthcare in certain EU member states, financial services — SCCs may be insufficient.

The architecturally clean solution to the cross-border problem is identical to the PHI problem: if personal data is intercepted and pseudonymized before the API call, the tokens that cross the border contain no personal data. GDPR Chapter V transfer restrictions apply to personal data — pseudonymized tokens that cannot be re-identified by the recipient fall outside that scope.

The practical conclusion

OpenAI’s data handling for API customers is more privacy-conscious than most people assume: no training on your data by default, 30-day retention, ZDR available. The risks are real but manageable — and they’re often better managed by controlling what reaches OpenAI than by optimizing the contractual terms of what OpenAI does with what it receives.

If your application passes PHI to OpenAI, the 30-day retention window, the employee access for safety review, and the US-based processing are all legitimate concerns. The remediation for each of them is the same: intercept PHI before the API call, pseudonymize it, and pass tokens instead of identifiers.

Privedge runs this interception at the Cloudflare edge — before the OpenAI call, on infrastructure you control. Patient names, dates, and identifiers become tokens. OpenAI receives and retains anonymized content. Your BAA, ZDR configuration, and 30-day retention window become secondary considerations rather than primary risks.

See how the HIPAA compliance architecture and GDPR compliance approach work in practice.