You have a pile of documents you'd like an AI to summarise, and a nagging feeling about sending them anywhere. The short answer: decide by the worst realistic thing that could happen to that data, not by whether the model is "local". Use a hosted business or API account for most amber-level material, a local model when the data can't leave your hands, and no AI at all when a local model isn't good enough and redaction isn't possible. Below is a threat-model table, a five-step decision path, and what to check on each vendor, all dated 2026-10-09. This is not legal advice.
What are you actually protecting against?
"Privacy" means different things. Name the threat first, because each option defends against different ones.
| Threat | Example | Which option helps |
|---|---|---|
| Training use | Your text ends up in a future model | Business/API accounts with training off by default; local |
| Human review | A vendor reviewer reads flagged or sampled content | Paid or business terms that exclude review; local |
| Vendor retention | Logs kept for abuse monitoring | Zero-retention agreements (where offered); local |
| Breach at the vendor | Their systems are compromised | Less data sent; local |
| Legal process | A court order reaches the vendor | Local (data isn't there); note it also reaches you |
| Your own mistakes | Wrong file pasted, wrong account | Policy, redaction, approved tools |
| Device compromise | Malware, lost laptop | Disk encryption, access control, not a model choice |
| Contract limits | Client says no cloud AI | Whatever the contract allows |
Two lessons from the table. First, most people's real risk is the sixth row, and no model choice fixes it. Second, local only wins decisively on the first five, so if your concern is rows six and seven, spend the effort on a written policy and redaction.
What are the five options, from least to most private?
- Consumer chatbot, default settings. Easiest. Terms differ per vendor and change; training may be on by default.
- Consumer chatbot, privacy settings tightened. Training opt-out, temporary chats. Reduces one risk. Still retained for some period.
- Business or API account with a hosted model. Different default terms from consumer apps. You choose the account type and read the retention terms.
- Self-hosted model on a rented server. Your prompts don't go to an AI vendor, but the hosting company and your server hardening matter.
- Local model on hardware you control. Data stays on the device, at the cost of model strength and setup.
I'm leaving out confidential computing and other options that need a deeper assessment than a blog post can give.
What do the vendors say about training and retention?
Read on 2026-10-09 from the vendors' own pages. Where I could only get a summarised fetch, I say so; check exact wording yourself, because these change.
| Option | What the page says | Not covered / caveat |
|---|---|---|
| Anthropic commercial (Claude for Work, Team, Enterprise, API, Claude Gov) | By default, inputs and outputs from commercial products are not used for training, except where you submit feedback (thumbs up or down) or otherwise opt in. Feedback conversations can be kept up to 5 years. | Page read via summarising fetch. It points consumer plans to a separate article that I did not read for this post. |
| OpenAI API | Data sent to the API isn't used to train models unless you opt in. Abuse-monitoring logs are kept up to 30 days by default, longer where the law requires or to protect services from harm. Zero Data Retention needs approval and some endpoints still store state. | Summarised fetch of OpenAI's developer docs. ChatGPT consumer and business pages returned HTTP 403 to my tool, so they are not covered. |
| Gemini API, paid | Google states it doesn't use prompts or responses to improve products, and logs them for a limited period for abuse detection, in any country where Google or its agents have facilities. | The retention period isn't given on the page I read. |
| Gemini API, unpaid | Google may use content to improve products, human reviewers may read inputs and outputs, and the terms say not to submit sensitive, confidential or personal information. | Free tiers are the case people forget when prototyping with real data. |
| Ollama cloud features | Ollama's docs say it processes cloud prompts and responses to answer requests and doesn't use them to train models. Details of retention are left to its privacy policy. | I did not read the privacy policy. You can disable cloud features and use only local models, per the docs. |
If you take only one line from this table: a free or unpaid tier is a different product from a paid one, even when it's the same model.
How do I decide? A five-step path
Work down the list and stop at the first step that gives an answer.
- Does a contract, regulator or client forbid sending this data to an AI vendor? If yes: local, self-hosted under your control, or no AI. Check with the person who signed the contract.
- Can you redact it? If names, numbers and identifiers can be replaced and restored later, option 3 usually becomes enough. See what not to paste into ChatGPT for what to strip, and PII redaction before LLM calls for a tested regex and Presidio approach (it still misses names and odd spellings, so check the output).
- Is the residual vendor risk acceptable? Even with training off, content may be logged or retained for a period. If a breach at the vendor would be a serious problem, go to step 4.
- Can a local or self-hosted model do the task well enough? Test it. Take ten real examples (redacted copies are fine), run them through a local model and a hosted one, and compare outputs side by side. If the local model is adequate, use it. Quantised small models save memory at some quality cost, covered in quantization explained, and open-weight models in 2026 lists what's worth trying.
- Is it still too weak? Either split the task (local for the sensitive step, hosted for the rest), accept a business account with a signed data agreement, or do the task by hand.
How private is a local setup, really?
Less than the word suggests. Check these before you tell a client "it never leaves our machine":
- Mode. Confirm you're running a local model, not a cloud variant. Ollama's blog describes models with a
-cloudsuffix, and a web search API that sends queries to Ollama's servers; its docs describe how to disable cloud features. - Network. Watch outbound connections the first time you run it. On Linux,
ss -tpnlists current connections, and a firewall rule that blocks the process is a stronger test than trusting a settings page. I did not run a network capture for this post, so treat this as a method, not a result. - Storage. Chat history, embeddings and logs sit on disk. Encrypt the disk, and decide where backups go. A private model feeding a cloud-synced notes folder isn't private.
- Plug-ins and tools. A local model with a browser tool, email connector or MCP server can still send data out. See the MCP security checklist.
- Users. A shared server needs accounts, access logs and a retention rule.
- Hardware limits. Bigger models need more memory than most laptops have. The Ollama beginners guide shows the setup, and the private ChatGPT with Ollama and Open WebUI sizing post covers a shared server.
What does a worked decision look like?
Illustrative scenarios, not real clients. The point is the reasoning.
| Scenario | Path | Likely choice |
|---|---|---|
| Freelancer drafting marketing copy from public product pages | Step 1 no, data is public | Any hosted tool on a paid account |
| Accountant summarising client bank statements | Redaction hard, identifiers everywhere, professional duties apply | Ask a professional; if allowed at all, local or an approved business tool |
| Developer asking about a bug in company code with API keys in config | Strip secrets, step 2 works | Hosted business account after removing secrets; rotate any key that slipped |
| Clinic admin wanting to summarise patient notes | Step 1 likely yes (regulated health data) | Don't start without advice from a compliance professional |
| Founder analysing own sales spreadsheet | Own data, low external duty | Paid hosted tool is a reasonable choice |
What should I record once I've decided?
One paragraph in your tool register, so the decision survives staff changes:
Task: [description]
Data tier: [red / amber / green]
Chosen option: [1-5]
Reason: [threat from the table that drove this]
Evidence: [vendor page URL + date read, or local setup notes]
Review date: [6 months out]
The decision isn't permanent. A vendor can change its terms, a better small model can arrive, or the data can change. Date it, and look again.
