OpenAI vs Anthropic API in a privacy policy: how each provider handles user content as of 2026
A side-by-side of OpenAI's and Anthropic's API privacy postures — training opt-out defaults, retention windows, regional availability, DPAs — with example processor entries for each.
If your indie app uses an LLM API, the choice of provider has a few privacy ripples that show up in your privacy policy, your processor list, and your DPA file. This post compares OpenAI and Anthropic’s published positions as of access date 2026-05-25.
High volatility. Both providers have updated their published policies multiple times since 2023. Re-read the linked pages before publishing your own policy.
TLDR
| Topic | OpenAI (API) | Anthropic (API) |
|---|---|---|
| Training on API inputs by default | No (since March 2023) | No (per Anthropic’s commercial terms) |
| Retention window for API content | Up to 30 days by default; zero-data-retention available for eligible API customers | Up to 30 days by default; zero-data-retention available for eligible customers |
| EU data residency | API regions evolving | API regions evolving |
| Sub-processors | Listed in OpenAI’s Trust Portal / DPA | Listed in Anthropic’s DPA |
| Primary policy page | https://openai.com/policies/privacy-policy | https://www.anthropic.com/legal/privacy |
| API data usage page | https://openai.com/policies/api-data-usage-policies | https://www.anthropic.com/legal/commercial-terms |
| DPA | https://openai.com/policies/data-processing-addendum | https://www.anthropic.com/legal/dpa |
The structure of the disclosure is the same for both: name the entity, link the policy, describe what your app sends, describe the purpose, note the retention default. Where the providers diverge — retention windows, zero-data- retention availability, regional residency — your wording diverges with them.
OpenAI
Primary sources (verify before publishing):
- Privacy policy (accessed 2026-05-25)
- API data usage policies (accessed 2026-05-25)
- DPA (accessed 2026-05-25)
What OpenAI’s docs state about API inputs and outputs (paraphrased — read the source):
- API inputs and outputs are not used to train OpenAI’s models by default since March 2023.
- API content may be retained for up to 30 days for abuse and misuse monitoring, with shorter or zero-data-retention available under certain conditions.
- OpenAI publishes a list of sub-processors.
Example processor entry:
OpenAI, L.L.C. processes user inputs sent to OpenAI’s API on our behalf for the purpose of generating responses inside [feature name]. As of [access date], OpenAI’s published API data-usage policies state that API inputs and outputs are not used to train OpenAI’s models. API content may be retained by OpenAI for up to 30 days for abuse and misuse monitoring. See https://openai.com/policies/api-data-usage-policies.
Anthropic
Primary sources:
- Privacy policy (accessed 2026-05-25)
- Commercial terms (accessed 2026-05-25)
- DPA (accessed 2026-05-25)
What Anthropic’s docs state about API inputs and outputs (paraphrased — read the source):
- API inputs and outputs are not used to train Anthropic’s models for the commercial customer (per Anthropic’s Commercial Terms in effect on access date).
- API content may be retained for up to 30 days for safety review, with shorter retention available for eligible customers.
- Anthropic publishes a list of sub-processors.
Example processor entry:
Anthropic, PBC processes user inputs sent to Anthropic’s API on our behalf for the purpose of generating responses inside [feature name]. Per Anthropic’s Commercial Terms in effect on [access date], API inputs are not used to train Anthropic’s models. API content may be retained by Anthropic for up to 30 days for safety review. See https://www.anthropic.com/legal/privacy.
A side-by-side: what to write where
| Disclosure surface | What it says |
|---|---|
| Privacy policy, “Processors” section | Identity + link, as above. |
| Privacy policy, “What we collect” section | The category of input (“the text or image you send to our AI feature”) + the purpose (“to generate a response”). |
| Apple Privacy Details | User Content — Linked to user, used for App Functionality. |
| Google Data Safety | Messages (Other in-app messages) or App info (Other actions) — Collected and shared. |
| GDPR processor list | Name the entity (US) + reference SCCs in the DPA. |
| Cookie banner | N/A — server-side API calls don’t set cookies. |
Common mistakes
- Forgetting to mention the provider at all. “We have an AI feature” is not enough — name the API provider.
- Implying you train models with user inputs when you don’t. Both providers’ commercial defaults are no-training; reflect that.
- Saying “we don’t store your prompts” when the provider does retain them for 30 days by default. Be precise.
- Switching providers without updating the policy. When you swap OpenAI for Anthropic, the policy needs the swap reflected on every disclosure surface.
FAQ
What about open-source self-hosted models? If you run the inference yourself (e.g., a local Llama or self-hosted qwen-2.5), there is no third-party processor to name — but you still describe the AI feature’s data handling internally and may still need to disclose hosting providers (Vercel, Cloudflare, etc.).
Do users have a right to deletion of AI inputs? Under GDPR Art. 17, in most cases yes. You will need a path to delete the user’s stored inputs from your own systems; the provider’s retention is on their side and is governed by your DPA.
Does the choice affect Apple / Google forms? Not materially — both providers show up the same way on the platform forms (User Content / Messages). The difference is in the processor list and the DPA reference.
Related reading
S-013, S-022, S-023, S-024. Each source row is listed in the full disclosure matrix .
Open the Indie App Privacy Disclosure Matrix for a side-by-side view of which platforms expect which disclosures for the services in your stack.