OpenAI vs Anthropic Data Policies: Training, Retention, ZDR, Sub-Processors, BAA, Breach SLA — A Neutral 2026 Comparison

**OpenAI** maintains four distinct policy surfaces, and the differences between them are load-bearing for procurement. The consumer privacy policy at https://openai.com/policies/ covers ChatGPT Free and Plus and is the only surface where 'we may use your inputs to improve our models' is the default state. Users can turn this off in Data Controls, but it remains the only OpenAI product where opting out is required rather than automatic. The enterprise privacy commitments at https://openai.com/enterprise-privacy/ govern ChatGPT Team, Enterprise, and the API by default — and explicitly state that customer business data is not used to train models. Reading only the consumer policy and assuming it applies to your API usage is the single most common mistake security teams make.

The API-specific data-usage page at https://platform.openai.com/docs/models/how-we-use-your-data is the authoritative reference for what happens to a single API call: inputs and outputs are retained for up to 30 days for abuse monitoring, then deleted. Fine-tuning data is kept inside your organization and not used for base-model training. The trust portal at https://trust.openai.com/ then provides the live evidence — SOC 2 Type II reports under NDA, the current sub-processor list, GDPR posture, and the transparency report on government data requests. Treat these four pages as one document, not four.

**Anthropic** publishes a parallel set with slightly different structure. The privacy policy at https://www.anthropic.com/legal/privacy covers both Claude.ai and the API at a high level. The commercial terms at https://www.anthropic.com/legal/commercial-terms are the contract-grade document that governs API and Enterprise customers — Section 5 is the section your legal team will read first, covering data ownership, training carveouts, retention, and indemnification. The trust center at https://trust.anthropic.com/ mirrors OpenAI's: SOC 2 reports under NDA, sub-processors, and security documentation. The acceptable use policy at https://www.anthropic.com/legal/aup is enforced uniformly across Claude.ai and API.

The structural difference worth flagging: OpenAI separates 'consumer privacy policy' from 'enterprise privacy commitments' as two distinct documents. Anthropic keeps a single privacy policy and lets the commercial terms carry the enterprise carveouts. Operationally this means an OpenAI procurement review needs to pull two URLs; an Anthropic review needs to pull the privacy policy plus the commercial terms. Neither approach is better — but if your DPO is used to OpenAI's structure and pulls only the Anthropic privacy policy, they will miss the training-opt-out language that actually lives in commercial terms.

Marketing copy to discount on both sides: 'we don't train on your data' is true with caveats. The caveat is abuse monitoring — a small percentage of inputs flagged by automated safety classifiers are reviewed by humans, retained longer than 30 days, and can be used to improve safety classifiers (not the base model). Both vendors disclose this. Neither markets it. If your compliance use case requires zero human review of any input under any circumstances, you need ZDR — and even ZDR has limits we cover in the deep-dive below.

The other marketing claim to verify: 'enterprise-grade security.' Both vendors hold SOC 2 Type II — OpenAI publishes the audit firm and the date range under NDA at https://trust.openai.com/, and Anthropic does the same at https://trust.anthropic.com/. Both hold ISO 27001. The difference is in the sub-processor stack and the optional certifications (HIPAA BAA, ISO 27018, ISO 27701). Get the current attestation letter before signing; do not rely on the marketing badge.

The default training behavior across the six product surfaces splits along a clear line. **ChatGPT Free and Plus** train on user inputs by default unless the user opts out in Data Controls — this is consistent with the consumer privacy policy at https://openai.com/policies/ and has been the default since ChatGPT launched. The opt-out is per-user, not per-conversation, and applies prospectively only. Past conversations are not retroactively removed from training corpora once the model has been trained.

**ChatGPT Team, ChatGPT Enterprise, and the OpenAI API** are explicitly excluded from training by default per https://openai.com/enterprise-privacy/ and https://platform.openai.com/docs/models/how-we-use-your-data. This is contractual, not toggle-based — it is part of the enterprise privacy commitments and the API terms. Customers do not need to opt out; they need to opt in if they want their data used for improvement, and the opt-in is rare. For most procurement reviews this is the most important line in the entire policy: API inputs are not training data unless you affirmatively agree.

**Anthropic Claude.ai** does not train on user inputs by default for accounts created in the current default state. The privacy policy at https://www.anthropic.com/legal/privacy explains the consent posture, and account settings allow users to manage training preferences. Note that Anthropic's posture here has evolved over time — older accounts may have different defaults than newer ones, and the privacy policy should be re-read by individual users who created accounts more than a year ago.

**The Anthropic API and Enterprise tier** do not train on commercial customer inputs per the commercial terms at https://www.anthropic.com/legal/commercial-terms. The carveout language in Section 5 is symmetric to OpenAI's API posture: inputs and outputs from API calls are not used to improve base models. The exception, identical to OpenAI's, is abuse monitoring — flagged content may be reviewed by humans and used to improve safety classifiers, not base capability.

Fine-tuned model data deserves its own line. On the OpenAI API, fine-tuning training data is segregated to your organization and not used to improve base models per https://platform.openai.com/docs/models/how-we-use-your-data. The resulting fine-tuned model weights are also private to your org. On the Anthropic API, the equivalent guarantee applies — fine-tune data and resulting weights are customer-controlled. Neither vendor's fine-tuned models are visible to other customers, and neither vendor uses your fine-tune training data to improve base models.

The opt-out mechanics differ in one practical way worth noting. OpenAI's per-organization data-sharing settings are configured in the OpenAI console and apply org-wide. Anthropic's are configured per-workspace and per-API-key in the Anthropic console. If you operate multiple business units under one OpenAI org, you may need to split orgs to get differentiated policies. If you operate under one Anthropic account, you can usually get per-workspace differentiation without restructuring.

Both vendors retain API inputs and outputs for up to 30 days by default for abuse monitoring. The OpenAI API documentation at https://platform.openai.com/docs/models/how-we-use-your-data states this explicitly: 'OpenAI retains API inputs and outputs for up to 30 days to provide the services and to identify abuse.' The Anthropic equivalent commitment lives in the commercial terms at https://www.anthropic.com/legal/commercial-terms and the trust center at https://trust.anthropic.com/. Thirty days is the floor, not the ceiling — flagged content can be retained longer pending human review.

Zero Data Retention is the procurement lever for both vendors. With ZDR enabled, API requests are processed in memory and the inputs and outputs are not persisted at rest after the request completes. OpenAI offers ZDR on the API and ChatGPT Enterprise to qualified customers, configurable per-endpoint, per https://trust.openai.com/. Anthropic offers ZDR on enterprise contracts per https://trust.anthropic.com/. ZDR is not on by default in either case — you request it, you justify the use case (typically regulated industry, financial services, healthcare, or high-sensitivity workloads), and you get it approved per-endpoint.

What ZDR does not cover, on either vendor, is the abuse-monitoring escape hatch when a request trips a safety classifier. If a single API call is flagged by automated systems as a potential terms-of-service violation, that specific call may still be reviewed by humans even on a ZDR-enabled account. Both vendors disclose this; neither will commit to zero human review under any circumstances. If your compliance posture requires that, you are looking at a self-hosted open-source model, not a hosted API.

On consumer surfaces — ChatGPT Free/Plus and Claude.ai — there is no ZDR option. Chat history is retained until the user deletes it, with retention windows for flagged content extending beyond 30 days. This is why most compliance teams ban consumer ChatGPT for any work touching customer or employee data and route those workloads to ChatGPT Enterprise or the API instead. The right policy is not 'ban AI'; it is 'use the right surface.' See zero-data-retention LLM options for the cross-vendor walkthrough.

Retention for fine-tuned models is a separate question. Both vendors retain fine-tuning training data for as long as the fine-tuned model exists. If you delete the fine-tune, the training data is deleted within the standard SLA. Both vendors will commit to a documented deletion process on enterprise contracts — get the SLA in writing in your DPA, typically 30 days for soft delete and 90 days for hard delete from backups.

Deletion-on-request SLA matters more than headline retention numbers for GDPR Article 17 right-to-erasure requests. OpenAI commits to fulfilling deletion requests within a documented window per https://trust.openai.com/, typically 30 days for production data plus an additional period for backup expiration. Anthropic's commitment per https://trust.anthropic.com/ is structurally similar. For both vendors, ZDR-enabled API traffic generates no retained data to delete in the first place, which is the cleanest GDPR posture.

Sub-processor lists are the procurement question that derails the most deals, because they are also the question security teams check last. **OpenAI**'s primary infrastructure sub-processor is Microsoft Azure — confirmed in OpenAI's published documentation and at https://trust.openai.com/. Additional sub-processors include Cloudflare for edge networking, Stripe for billing, and various standard SaaS vendors. The full current list is published on the trust portal and updated when changes occur. For most enterprise customers, Microsoft Azure is already an approved sub-processor, which makes OpenAI procurement smoother than it might otherwise be.

**Anthropic**'s primary infrastructure sub-processors are Amazon Web Services and Google Cloud Platform, per the trust center at https://trust.anthropic.com/. This is structurally different from OpenAI's Azure-only posture and matters in two directions. If your security team is uncomfortable with Microsoft as a sub-processor (rare, but it happens in highly regulated industries with Microsoft-competitive workloads), Anthropic on AWS is the alternative. If your team is uncomfortable with Google Cloud, that complicates Anthropic procurement until you can confirm which AWS-only configurations are available.

The HIPAA BAA story diverges meaningfully on the consumer side and converges on the enterprise side. OpenAI does not sign BAAs for ChatGPT Free, Plus, or Team — those products are not HIPAA-eligible. OpenAI signs BAAs for ChatGPT Enterprise and the API on request per https://openai.com/enterprise-privacy/. Anthropic does not sign BAAs for Claude.ai consumer accounts. Anthropic signs BAAs for the API and Enterprise tier on request. Healthcare buyers should plan to be on the API or Enterprise SKU exclusively, and should never let staff route PHI through consumer ChatGPT or Claude.ai.

EU data residency is the GDPR question that drives the most contract negotiation. OpenAI offers EU residency commitments on ChatGPT Enterprise and the API for qualified customers per https://openai.com/enterprise-privacy/, processing on Azure EU regions. This was not always the case — EU residency on OpenAI is a 2024/2025 capability that has matured, and the trust portal documents the current scope. Anthropic offers EU residency on enterprise contracts, processing on AWS EU regions. Both vendors will commit to a specific region in the DPA; do not accept 'EU' as the contract language, get the specific AWS or Azure region.

Breach notification SLA is, in both vendors' standard DPA, 'without undue delay' with a GDPR-style 72-hour target where applicable. The exact language is in the DPA, not the public privacy policy — request the current DPA template before signing. Both vendors will negotiate breach-notification language for large enterprise contracts; smaller contracts get the standard template. The standard template is reasonable on both sides; the negotiable points are whether notification triggers on confirmed breach versus suspected breach, and what categories of incidents qualify.

Government request transparency is published by both vendors. OpenAI's transparency reporting lives on the trust portal at https://trust.openai.com/ and covers law enforcement requests, national security requests where disclosure is permitted, and the volume and disposition of each category. Anthropic publishes equivalent reporting at https://trust.anthropic.com/. Both vendors commit to providing notice to customers when legally permitted before disclosing customer data in response to government requests. Both vendors will challenge requests they consider overbroad. Both vendors disclose that gag orders prevent disclosure in a small percentage of cases — this is true of every US-headquartered vendor and should not be treated as a differentiator.

Both vendors publish usage policies that govern what you can do with their models. OpenAI's Usage Policies live at https://openai.com/policies/usage-policies/ and Anthropic's AUP lives at https://www.anthropic.com/legal/aup. The substantive prohibitions overlap heavily: no CSAM, no weapons-of-mass-destruction uplift, no targeted harassment, no political manipulation campaigns, no impersonation of real persons, no spam at scale, no fraud, no unauthorized practice of regulated professions. Read both before integrating; they are short documents and the substance matters.

OpenAI also publishes a Model Spec that describes intended model behavior — what the model should refuse, what it should hedge on, what it should answer directly. This is distinct from the AUP and is a useful reference for developers building on top of OpenAI models, because it explains why the model behaves the way it does. Anthropic publishes an equivalent set of behavior documents including the Constitutional AI principles and the Claude character documentation. Neither document is contractually binding the same way the AUP is, but both inform how the model treats edge cases.

Enforcement is where the two vendors diverge in tone and practice. OpenAI's enforcement model is largely automated for consumer surfaces and uses a combination of automated classifiers and human review on enterprise surfaces. Account suspensions on the API surface typically come with notice and a remediation pathway for enterprise customers; consumer suspensions are faster and the appeals process is more constrained. Anthropic's enforcement is structurally similar but tends toward more conservative refusal behavior in the model itself — the Claude model is more likely to refuse edge-case requests than the GPT models, which shifts enforcement from account-level action to per-request refusal.

For procurement, the enforcement question is: if our integration triggers a false positive on the safety classifier, what is the remediation path. Both vendors have enterprise-tier escalation paths to the trust and safety team. Both vendors will not automatically suspend enterprise accounts for first-time policy violations; they will reach out, document the issue, and work toward remediation. Neither vendor will commit in writing to a specific number of violations before suspension, because doing so would defeat the purpose of having an AUP.

Where enforcement differs operationally: OpenAI offers a programmatic moderation API at https://platform.openai.com/docs/guides/moderation that lets you pre-screen user inputs against OpenAI's safety classifiers before sending them as prompts. Anthropic does not currently offer an equivalent standalone moderation API as a primary product, though Claude itself can be prompted to act as a classifier. If your application requires pre-screening user inputs to a stricter standard than the model's own refusal behavior, OpenAI's moderation API is the cleaner integration in 2026.

Section 5 of OpenAI's commercial terms (or the equivalent in your master services agreement) and Section 5 of Anthropic's commercial terms at https://www.anthropic.com/legal/commercial-terms are the data, IP, and indemnification sections your legal team will spend the most time on. Both vendors commit to customer ownership of inputs and outputs subject to standard service-provider carveouts. Both offer some form of copyright indemnification on enterprise contracts for output that allegedly infringes — OpenAI brands this as Copyright Shield. Get the indemnification scope and caps in writing; the marketing language is broader than the contractual language.

The most important framing for any data-policy comparison: the product surface drives the policy, not the vendor brand. ChatGPT Free and Claude.ai consumer have more in common with each other than ChatGPT Free has with the OpenAI API. Both consumer surfaces train on inputs absent opt-out (OpenAI by default, Anthropic by configuration), both lack ZDR, both lack BAA, both lack contractual EU residency commitments, and both retain chat history indefinitely until user deletion. If your team uses consumer chat for work data, you are not protected by the enterprise commitments your contract specifies for the API.

ChatGPT Team is structurally closer to the API and ChatGPT Enterprise than to ChatGPT Plus — it inherits the no-training-by-default commitment and adds workspace admin controls. But Team does not unlock ZDR or BAA. If you bought ChatGPT Team because it looked like the enterprise tier on the marketing page, re-read the commitments: Team is the right product for general-purpose knowledge work in a small company, not the right product for regulated workloads.

ChatGPT Enterprise and the OpenAI API are the two surfaces that unlock the full enterprise commitments — no training, ZDR on request, BAA on request, EU residency on request, contractual breach SLA, government-request notice commitments. If you are buying OpenAI for any regulated use case, you are buying one of these two SKUs. Choosing between them is a build-vs-buy question: Enterprise gives you the ChatGPT product experience for end users; the API gives you raw model access for integration into your own product.

Claude.ai is structurally similar to ChatGPT Plus — consumer-grade, no ZDR, no BAA, retention until user deletion. The Anthropic API and Enterprise tier are the regulated-workload surfaces. Anthropic does not publish a 'Team' tier with the same characteristics as ChatGPT Team — small teams typically buy the API and integrate it themselves, or use third-party Claude wrappers that provide a workspace UI on top of the API.

The procurement implication: your AI usage policy should specify the surface, not the vendor. 'Employees may use the OpenAI API and ChatGPT Enterprise; consumer ChatGPT is prohibited for work data' is a coherent policy. 'Employees may use OpenAI but not Anthropic' is not — it confuses brand with surface. The right policy lists approved surfaces and approved use cases, and is enforced by SSO and DLP, not by reputational risk.

If you are buying both vendors (which is increasingly common for redundancy and model-specific strengths), align on a consistent surface posture. Use OpenAI API plus Anthropic API for engineering integrations. Use ChatGPT Enterprise plus an Anthropic Enterprise equivalent for end-user productivity. Do not let half your org use OpenAI API and the other half use Claude.ai — that is a compliance gap waiting for an audit finding.

The procurement checklist for either vendor has roughly the same nine line items, in order of how often they fail diligence reviews. First: training-opt-out commitment in the DPA, not just the marketing page. Both vendors will provide this on enterprise contracts. Second: 30-day default retention with documented ZDR option, and ZDR enabled per-endpoint where required. Third: HIPAA BAA on request for healthcare workloads, with the specific covered entity language. Fourth: EU data residency commitment with the specific region named (Azure West Europe, AWS eu-west-1, etc.).

Fifth: sub-processor list with notice-of-change commitment, typically 30 days before adding a new sub-processor. Sixth: breach notification SLA in the DPA, typically 72 hours from confirmed breach with reasonable definitions of 'confirmed.' Seventh: deletion-on-request SLA for GDPR Article 17 requests, typically 30 days for production plus an additional period for backups. Eighth: government request notice commitment where legally permitted. Ninth: audit rights — typically a SOC 2 Type II report on request rather than direct audit, but enterprise customers can sometimes negotiate audit rights for sensitive workloads.

What to skip: do not ask for source code escrow, do not ask for the vendor to indemnify you against all possible model outputs, do not ask for ZDR on consumer surfaces (they do not offer it), do not ask for HIPAA BAA on ChatGPT Plus (they do not offer it), and do not ask either vendor to commit to never updating their models or sub-processor list (they will not). These asks burn cycles and signal to the vendor that you are not ready to procure.

Copyright indemnification has become a standard request and is reasonable to negotiate. OpenAI's Copyright Shield and Anthropic's equivalent indemnification language cover claims that model outputs infringe third-party copyright, subject to standard carveouts (you must not have intentionally prompted infringement, you must accept the vendor's defense, etc.). Get the scope and dollar caps in writing in the master services agreement. The marketing language tends to be broader than the contract language.

Insurance certificates are reasonable to request. Both vendors carry cyber liability, errors-and-omissions, and general liability insurance at levels appropriate for enterprise software vendors. Get certificates of insurance with your organization named where required, and verify the carrier and policy limits. This is standard SaaS procurement hygiene; both vendors will provide certificates.

Use the AI tools GDPR compliance guide as your DPO's pre-procurement checklist before the first vendor call. The goal of the first call should be to confirm vendor capability against your checklist, not to discover what the vendor offers. If your DPO walks in with a structured ask, both OpenAI and Anthropic enterprise teams will move faster — they have answered these questions hundreds of times and prefer working with prepared buyers.

The recurring procurement question: if our compliance posture requires zero data ever leaving our environment, can we just self-host Llama, Mistral, or one of the open-weights models. The answer in 2026 is: yes for some workloads, no for most. Self-hosting on your own infrastructure eliminates the data-leaves-the-perimeter problem entirely — no sub-processors, no abuse monitoring, no retention questions, no breach SLA dependence on a third party. For workloads where this is a hard requirement, self-hosting is the right answer.

The cost is capability and operational burden. The current open-weights models are competitive with last year's GPT-4 and Claude on many tasks, but they trail the latest frontier OpenAI and Anthropic models on long-context reasoning, tool use, and edge-case handling. If your workload requires the top of the capability curve, self-hosting means accepting a measurable quality gap. Operationally, you need GPU infrastructure, model-serving expertise, monitoring, security patching of the inference stack, and ongoing model evaluation. A reasonable internal team is two to four engineers full-time at steady state.

Where self-hosting wins clearly: high-volume, well-defined workloads with strict data-residency requirements. Document classification for highly regulated industries, internal code search inside an air-gapped environment, summarization of sensitive customer data in a region where neither OpenAI nor Anthropic offers residency. These are the canonical self-hosting use cases and they justify the operational burden.

Where the hosted API wins clearly: variable-volume workloads, capability-frontier workloads, and workloads where the operational burden of running inference at scale exceeds the cost of the API. For most knowledge-worker productivity tools and most engineering integrations, the OpenAI or Anthropic API is the right answer — and the data policy commitments are sufficient for the vast majority of regulated workloads as long as you choose the right SKU and turn on ZDR where needed.

Hybrid is the pattern that works at scale: hosted API for the capability frontier and variable workloads, self-hosted open model for the high-volume, well-defined, residency-constrained workloads. Both vendors support this pattern willingly — neither is going to push you toward an all-API posture if your compliance team requires otherwise. The procurement conversation gets easier, not harder, when you walk in with a clear surface-by-surface plan rather than a yes/no decision.

The cost calculator at zero-data-retention LLM options walks through the decision tree per workload. The most common mistake is assuming self-hosting is cheaper than the API at any volume — for many workloads, the GPU cost plus engineering cost exceeds the API cost until you cross a meaningful volume threshold. Model the all-in cost honestly before committing.