Every prompt you send to ChatGPT, Claude, Gemini, or any other chatbot is a disclosure of three things: the work you are trying to do, the proprietary material that work involves, and often the people affected if it succeeds. The good news is that the major AI labs now publish precise defaults for what they do with that disclosure. The bad news is that those defaults are not what most users assume they are.
This guide is a practitioner’s map of AI privacy in 2026. It separates the five things people conflate when they say “privacy” (training use, conversation retention, human review, telemetry, and integration-side leakage), audits the actual defaults at OpenAI, Anthropic, Google, Microsoft, Apple, and Meta with citations to the labs’ own documents, and ends with a six-step defensive playbook you can deploy this week. If you write prompts for a living — copy, code, research, customer data, legal drafts, anything you would not want on a billboard — this is the article to read before you send another one.
What “AI Privacy” Actually Means: Five Distinct Things People Conflate
When a user says “I don’t want my data used by AI,” they usually mean one of five different things. Most AI privacy failures come from conflating them.
- Training use — whether your prompts and outputs are incorporated into the next version of the model. This is the highest-stakes form of “use” because it is irreversible: a sentence that is once memorized is forever part of a 400-billion-parameter distribution.
- Conversation retention — how long the provider stores your transcripts in identifiable form after the chat ends. Retention ranges from 30 days to indefinite, and is the gap where breach risk lives.
- Human review — whether a person at the lab will read your conversation, typically as part of training-data labeling or abuse investigations. This is the gap where confidentiality-of-work risk lives.
- Telemetry and metadata — the request-level data the provider always collects regardless of policy: timestamps, IP addresses, device fingerprints, token counts, error rates, and aggregate usage patterns. Useful for billing, necessary for safety, often unencrypted in transit within the provider’s internal tooling.
- Integration-side leakage — the surface that is not in the provider’s privacy page at all: connectors, browser extensions, MCP servers, retrieval pipelines, and prompt-injection channels that route your data to places you did not intend. This is where OWASP’s #1 LLM risk lives.
When a vendor tells you “we don’t use your data,” the next question is always which of the five they mean. The lab’s defaults differ in each category, and most policy pages collapse all five into a single “privacy” claim. The rest of this article works through each category against the major providers, then gives you a defensive playbook.
The Provider-by-Provider Audit: What Each Lab Logs by Default in 2026
The numbers below are the public defaults as of August 2026, taken from each provider’s own documentation. Where defaults differ by tier (free consumer vs. paid API vs. enterprise), I note the tier in the row. If you have not seen your provider’s policy updated since 2024, treat this section as the canonical map.
OpenAI: API vs. ChatGPT — Two Different Defaults
For the OpenAI API, the default is clean: OpenAI’s data controls documentation states that “data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us).” The same page documents a 30-day retention window for abuse-monitoring logs, with explicit exemption language for legal-hold extensions. Zero-data-retention endpoints are available for eligible customers via the data-residency and zero-retention programs.
For ChatGPT (the consumer product), the situation is layered. Free and Plus users have “Improve model for everyone” enabled by default, which routes a subset of conversations into the training pipeline. The opt-out lives in Settings → Data Controls → “Improve model for everyone,” and once disabled, your chats are excluded. ChatGPT Team, Enterprise, and Edu tiers have training disabled by default, regardless of settings. Memory in ChatGPT is a separate channel: when enabled, the assistant retains facts across sessions and stores them indefinitely until you delete them. Memory is opt-in but easy to forget is on.
Anthropic: The Most Stringent API Default
For Claude API customers, the rule is unambiguous. The Anthropic Commercial Terms state in Section C: “Anthropic may not train models on Customer Content from Services.” Customer Content is defined as Inputs and Outputs together, and the section assigns all rights in Outputs back to the customer. This is the cleanest default in the industry.
For Claude.ai (the free consumer product), the Anthropic Privacy Policy (effective July 8, 2026) confirms that consumer conversation history is “automatically deleted from our back-end within 30 days,” with training opt-in controlled via the consumer settings. Free-tier Claude.ai does allow a 30-day window of stored chat history for the user-facing chat experience; deletion happens on the back end but the surface history may persist in backups for longer, as is standard for cloud infrastructure. Enterprise customers on Claude for Work have the same no-training guarantee as API customers and operate under Anthropic’s published trust and compliance commitments (SOC 2 Type II, ISO 27001, HIPAA-eligible configurations).
Google Gemini: Consumer vs. Workspace Tiers
Google’s Gemini Apps Privacy Hub (last updated August 10, 2026) covers the consumer product: Gemini app, gemini.google.com, and Gemini in Google Messages. The hub documents what is collected (conversations, location with permission, feedback) and what is not (Gemini does not use consumer chat history to train foundation models outside the opt-in experimental channels).
For Google Workspace customers, the Gemini data governance documentation is more specific: Workspace Gemini does not use customer data (emails, documents, chats) to train foundation models outside the tenant boundary. Human review is opt-in for Workspace. Data residency and EU Data Boundary options apply. This is the right tier for any business that has not negotiated a separate data-protection addendum.
Microsoft Copilot: Enterprise Service Boundary by Default
Microsoft Copilot’s privacy documentation makes a sharp distinction between the consumer Copilot (formerly Bing Chat) and the paid Microsoft 365 Copilot tier. For Microsoft 365 Copilot, prompts and responses are processed within the Microsoft 365 service boundary; content is not used to train foundation models for paid enterprise tiers. The free Copilot tier has more permissive defaults and may use conversations for model improvement; this is the right tier to avoid for sensitive work.
Apple Intelligence and Private Cloud Compute: The Architectural Argument
Apple’s approach is architecturally different from the rest of the field, and worth understanding on its own terms. The Private Cloud Compute white paper describes a system where Apple Intelligence runs on-device by default; when a request exceeds on-device capacity, it is routed to PCC servers that are stateless, cryptographically attestable, and built on custom Apple Silicon with non-volatile disks cryptographically erased on shutdown. Apple publishes the PCC software images so independent researchers can verify the runtime matches the documentation. This is not a “we promise we won’t use your data” claim — it is a “we architected the system so the data cannot persist” claim.
For practical purposes: if you are already in the Apple ecosystem and your workload fits on-device (summarization, drafting, Shortcuts automation, image generation in supported formats), Apple Intelligence is the lowest-friction privacy posture in the industry. If you need a frontier model on Apple silicon, you are routing through PCC and inheriting Apple’s audit posture. See our on-device AI 2026: Apple, Gemini Nano, and Qualcomm breakdown for the full Apple vs Android on-device comparison.
Meta AI and the Long Tail
Meta AI (the assistant in WhatsApp, Instagram, Facebook, and at meta.ai) defaults to training-data use for consumer prompts. Opt-out exists in the AI settings but is opt-out, not opt-in, which is a meaningful difference in a regulated context. For any work you would not want on Meta’s servers, route through a non-Meta provider’s API with explicit zero-retention configuration.
The long tail of AI products — Grok, Mistral Le Chat, Perplexity, You.com — varies widely. Perplexity retains search queries and AI responses; Grok retains conversations and trains on them by default; Mistral has separate consumer (Le Chat) and API tiers with different defaults. The rule is the same for each: read the policy page, identify which of the five categories the product touches, and confirm the default matches your threat model.
How to Read Any AI Provider’s Privacy Page in Five Minutes
Most AI privacy pages are written for compliance teams, not practitioners. The fastest way to extract what you need is to ask five questions in order:
- Does this product train on my inputs and outputs? Look for explicit “we do not train” or “we may use” language, then check whether the statement applies to your tier (consumer vs. paid vs. enterprise).
- How long is my conversation retained in identifiable form? Look for “30 days,” “indefinite,” or “until you delete.” Anything longer than 30 days for free-tier consumer products is normal; anything shorter is unusually strict.
- Is human review enabled by default? Look for “we may review conversations for abuse” or “human reviewers may access.” Find the opt-out control.
- What telemetry is collected regardless of policy? Look for “automatically collected” sections covering IP, device, timestamps, token counts. This is the floor of what every provider has.
- What is the breach notification commitment? Look for “in the event of a security incident” or “we will notify.” A 72-hour notification window is the GDPR standard; anything longer is a red flag.
If the page does not answer one of these five questions in plain language, treat that gap as a default that works against you. The provider’s silence is not your protection — it is the absence of one.
The Defensive Playbook: Six Patterns That Actually Reduce Exposure
The list below is ordered from cheapest to most expensive. Each pattern is independently useful; you can deploy any one of them in under an hour.
1. Use the API, not the consumer chat
For OpenAI, Anthropic, Google, and Mistral, the API tier has stricter training and retention defaults than the consumer product. Routing your work through the API means you inherit those defaults rather than the consumer defaults. The cost is integration work (you need a key, a script, or a UI like Typing Mind or Open WebUI); the benefit is a documented no-training posture and the ability to negotiate enterprise terms.
2. Use ephemeral or temporary chat modes
OpenAI offers Temporary Chat (no retention, no training, no Memory use); Anthropic offers ephemeral session settings; Google’s Gemini has incognito-style modes. These modes cost nothing and remove the conversation from any retention surface. Use them for one-off sensitive queries.
3. Redact before you paste
The cheapest pattern: replace identifying details with placeholders before you paste. Use [CLIENT_NAME], [REVENUE_2025], [EMPLOYEE_ID], and a back-substitution step after the model returns. This costs nothing and survives any provider default. For repeated work, write the substitution table in a local file the model never sees.
4. Choose enterprise tiers for team work
If you work on a team that handles regulated data — financial, health, legal, customer PII — the consumer product is not the right tool. Enterprise tiers (ChatGPT Enterprise, Claude for Work, Workspace Gemini, Microsoft 365 Copilot) all have stricter defaults and contractual protections. The cost is procurement friction and a per-seat license fee. The benefit is a signed DPA, contractual breach commitments, and an audit trail.
5. Negotiate zero-retention endpoints for the highest-stakes work
OpenAI offers zero-data-retention for eligible customers; Anthropic’s commercial terms make Customer Content opt-out of training by default; Google provides customer-managed encryption keys for Workspace. These are the right tier for processing customer data under a BAA or DPA. If your usage does not justify a custom negotiation, the next pattern is the right fallback.
6. Run local LLMs for the most sensitive work
If your workload fits a model you can run on your own hardware — and in 2026 that is a much wider range than it was two years ago — you can guarantee zero data leaves your machine. The next section covers the trade-offs honestly.
Local LLMs in 2026: When On-Device Inference Is Worth the Trade-off
Three open-source projects define the local-LLM stack. Ollama is the easiest install — one binary, a model pull command, and a local API at localhost:11434. LM Studio is the friendliest desktop UI — model search, parameter sliders, an OpenAI-compatible local server. llama.cpp is the underlying C/C++ inference engine that powers both. Inference runs entirely on-device; no prompt leaves the machine unless you explicitly point the tool at a remote endpoint.
The trade-offs are real. Model quality on local hardware lags the frontier by 6 to 18 months: an M-series Mac or a workstation with 24 GB of VRAM will run a 30-billion-parameter model that performs roughly at GPT-4-mini level. For many tasks — drafting, summarizing, transforming structured data, code review — that is enough. For tasks that need the current frontier — long-context reasoning, agentic tool use, complex instruction following — it is not. The honest answer is to mix: local LLMs for the most sensitive work, API endpoints for the rest. See our 2026 local LLM setup guide for a working Ollama + LM Studio comparison, and the 2026 frontier model benchmark for where local models still lag the API.
The other trade-off is memorization. A model that has been trained on a corpus containing your company’s data, your competitor’s leaked documents, or your customer’s support tickets will memorize some of it. If you ingest a model that was pretrained on data you would not want it to know, you inherit that knowledge. The mitigation is to use models with documented training corpora and published “unlearning” policies — and to run them on hardware you control rather than uploading sensitive prompts to a hosted playground. For a working setup that keeps every prompt on your laptop, see our sister-publication guide to running a private ChatGPT clone on your laptop in 10 minutes with Ollama + Open WebUI. A model that has been trained on a corpus containing your company’s data, your competitor’s leaked documents, or your customer’s support tickets will memorize some of it. If you ingest a model that was pretrained on data you would not want it to know, you inherit that knowledge. The mitigation is to use models with documented training corpora and published “unlearning” policies — and to run them on hardware you control rather than uploading sensitive prompts to a hosted playground.
Prompt Injection: The Privacy Threat Your Provider Cannot Stop
Even with perfect provider defaults, your AI assistant can leak data through a channel that is not in the provider’s privacy page at all: indirect prompt injection. The seminal paper is “Not What You’ve Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection” by Greshake et al. (arXiv 2310.12815). The mechanism is simple: when your assistant retrieves third-party content — an email, a web page, a document — that content can carry hidden instructions that hijack the assistant into exfiltrating data you have access to. The attacker does not need to touch the provider’s servers at all; they just need to be in your retrieval surface.
OWASP’s Top 10 for LLM Applications ranks this as LLM01 — Prompt Injection — the highest-severity category. The defense is at the integration layer, not the model layer: treat all retrieved content as untrusted input, separate “data” from “instructions” in your prompt template, and run untrusted content through a permission boundary before it reaches the model. This is one reason enterprise tiers matter: they ship with these defenses integrated; consumer products generally leave the burden on the developer.
If you build anything that combines a model with retrieval — RAG over internal docs, AI agents that browse, MCP servers that fetch from external APIs — indirect prompt injection is a privacy threat you cannot ignore. It does not matter how good the provider’s defaults are if the attacker can speak to the model through your data. For a worked look at the integration-side surface, see our OpenAI Agents SDK practical guide and the Microsoft agent governance toolkit review.
What GDPR and the EU AI Act Actually Require (And Don’t)
Two pieces of EU regulation define the floor for AI privacy in 2026. The General Data Protection Regulation (Regulation 2016/679) defines personal data broadly enough to cover prompts containing identifying details; Article 6 (lawful basis), Article 17 (right to erasure), Article 22 (automated decision-making), and Article 30 (records of processing) all apply when an AI system processes personal data. The right to erasure (Article 17) is the most actionable: you can require any provider to delete your data, subject to legal-hold exemptions, and most major labs publish a workflow for it.
The EU AI Act (Regulation 2024/1689) is the risk-tiered horizontal regulation that took effect on a phased timeline starting in 2024. Article 5 lists prohibited practices; Article 10 requires high-quality training datasets with appropriate governance; Article 13 mandates transparency when an AI system interacts with people. The AI Act is enforced by national authorities in each member state; the European AI Office coordinates cross-border cases.
The honest framing for practitioners: GDPR gives you the right to demand deletion and to require a lawful basis for processing. The AI Act adds transparency obligations for providers, which improves the documentation surface but does not directly reduce your exposure. If you process EU personal data through an AI system, both apply to you, and your provider’s terms-of-service need to be compatible with both.
What to Do This Week: A Concrete Checklist
If you read this far, you have one hour of work to deploy the highest-leverage patterns. Spend five minutes on the audit; spend fifty-five on the hardening.
- Five-minute audit: Open each consumer AI account you use (ChatGPT, Claude.ai, Gemini, Copilot, Meta AI). For each, locate the data controls and confirm: training opt-out is on, Memory is off (where applicable), chat history retention is set to the shortest window the product allows.
- Fifteen-minute hardening: Move your highest-sensitivity work from the consumer product to the API. Use Temporary Chat / ephemeral modes for one-off sensitive queries.
- Twenty-minute hardening: Install Ollama or LM Studio on your laptop. Pull a 7B-or-larger model you trust. Run a non-trivial prompt entirely on-device. Decide whether the quality is enough for the work you do most often.
- Fifteen-minute hardening: Write a redaction table for the data you handle most often. Use placeholders for client names, financials, employee IDs, and any identifying detail you would not want on a billboard. Train yourself to paste through the redaction layer.
- Ongoing: If you build any system that combines a model with retrieval or tool use, treat indirect prompt injection as a first-class threat. Separate instructions from data. Audit the retrieval surface for adversarial content. Apply the OWASP LLM01 mitigation patterns.
AI privacy in 2026 is not a single setting — it is five overlapping mechanisms, each with its own default, each with its own defensive pattern. The major labs publish precise defaults; your job is to know which ones apply to your usage and to harden the surfaces you actually expose. The cheapest first move is to turn off training and Memory in every consumer account you use, route sensitive work through the API, and run the most sensitive work locally. The hardest move is to treat retrieval content as untrusted input — but that is the only mitigation that survives a sophisticated attacker.
The frontier is moving fast. Provider policies change; new products land with weaker defaults; new regulations tighten the floor. Bookmark this article; come back in three months; re-run the audit. The providers are doing their part. Your part is to verify, not to trust. For the broader context, see AI safety research from Anthropic, the Anthropic frontier safety roadmap, and the 2026 frontier model benchmark — three pieces that shape what “privacy” actually means in the API tier.
Frequently Asked Questions
The five questions practitioners ask most often when they hit this topic for the first time, with the short answers and the longer reasoning behind each.
Does ChatGPT train on my conversations?
By default, free and Plus ChatGPT users have “Improve model for everyone” enabled, which routes a subset of conversations into the training pipeline. Open the Settings → Data Controls panel and disable “Improve model for everyone” to opt out. ChatGPT Team, Enterprise, and Edu tiers have training disabled by default regardless of the setting. The OpenAI API is also no-train by default; you would have to explicitly opt in to share data.
Does Claude train on what I send?
For Claude API customers: no. The Anthropic Commercial Terms explicitly state that “Anthropic may not train models on Customer Content from Services.” For Claude.ai free-tier consumers, consumer conversation history is auto-deleted from Anthropic’s back-end within 30 days, and training opt-in is controlled in user settings. Enterprise customers on Claude for Work inherit the API no-training guarantee with the additional SOC 2, ISO 27001, and HIPAA-eligible configurations published in the Anthropic Trust Center.
Is Gemini in Google Workspace safe for business data?
Yes, with the right configuration. Workspace Gemini does not use customer data — emails, documents, chats — to train foundation models outside the tenant boundary. Human review is opt-in for Workspace. Data residency and EU Data Boundary options apply for European customers. This is materially different from the consumer Gemini app, which has different defaults. If you handle regulated data on Workspace, the right move is the paid Workspace tier with the data governance settings verified by your security team.
Are local LLMs good enough for real work?
For drafting, summarizing, transforming structured data, and code review: yes, with a 7B-30B parameter model on a recent M-series Mac or a workstation with 24 GB of VRAM, you can match GPT-4-mini quality and route zero data off your machine. For long-context reasoning, agentic tool use, and complex instruction following: the quality gap is 6-18 months behind the frontier. The honest answer is to mix: local LLMs for the most sensitive work, API endpoints for the rest, and never route regulated data through a consumer chat product.
What is indirect prompt injection and should I worry about it?
Indirect prompt injection is when third-party content your assistant retrieves — an email, a web page, a document — carries hidden instructions that hijack the assistant into exfiltrating data you have access to. OWASP ranks it as LLM01, the highest-severity category in its Top 10 for LLM Applications. If you build any system that combines a model with retrieval, RAG, or tool use, this is a first-class threat you cannot mitigate at the provider level — the defense has to live at the integration layer. Treat all retrieved content as untrusted input; separate “data” from “instructions” in your prompt template; audit the retrieval surface for adversarial content.