Turning off data training and data usage genuinely does cover most of the situations where a large language model (LLM) might build a product on YOUR data. So the honest question isn't "does the toggle help" — it's what's left after you've flipped it. Three things are.

What the toggle does cover: the direct case — your prompts, documents, and data being absorbed into the model and resurfacing for others. If training and data-use are off on a reputable business tier, that routine pathway is closed. The rest of this piece is the residual worth your attention.

Risk 1 — Are the vendors actually trustworthy?

This is a track-record question, not a values one. The frontier models were largely built by scraping vast amounts of data without permission — a practice now the subject of major copyright litigation. And the promises themselves have failed in the wild: in July 2026, xAI's Grok Build was caught uploading entire code repositories to xAI's cloud while its "local-first" privacy toggle did nothing to stop it; the company pledged to purge the data only after the fact. The exposure isn't malice — it's that you're trusting a vendor's word and controls to work, from companies whose history and recent incidents show that word and controls don't always hold.

Risk 2 — "Off" is a promise, not a technical guarantee

Nothing cryptographic stops your data from entering a training run. You're trusting that the toggle does what it says, that no pipeline bug or subprocessor includes it anyway, and that the vendor's definition of "training" matches yours — and you can't verify any of it. There's no way to audit that your data wasn't in a training set, and proving it after the fact is extremely hard, so your recourse is contractual and weak. Even when the vendor behaves perfectly, opt-out is almost always forward-looking, so anything sent before you flipped it may already be absorbed; a thumbs-up/down can pull that conversation back into training; and "we don't train" often still permits adjacent uses (abuse classifiers, safety tuning, "service improvement") that touch the content. Absorption is irreversible — you can't pull a fact back out of model weights. So the residual is low-probability on a reputable business tier, but low-probability, permanent, and unverifiable, not zero.

Retention "off" isn't zero either. Consumer opt-out usually still keeps a floor — commonly around 30 days for abuse monitoring. True zero data retention (ZDR) exists only as a negotiated application programming interface (API) or enterprise arrangement, and even that has carve-outs. The parts you care about most are the ones you can't switch off: legal holds override deletion entirely (the New York Times (NYT)–OpenAI preservation order is the live example), data lingers in backups and logs, and even under genuine ZDR your prompt is decrypted and processed in plaintext at request time — so an insider or breach in that moment still sees it.

The through-line: turning these off collapses the routine pathways but leaves a residual made of (a) trust you can't verify, (b) mandatory floors and legal overrides you can't disable, and (c) plaintext exposure during processing — plus change-risk, where a future terms update or acquisition moves the line under you (as Anthropic's 2025 consumer-terms change demonstrated). For an ordinary sensitive document, "low-probability, short-floor, reputable vendor" is a reasonable risk to accept. For a genuinely irreplaceable asset — the thing that IS your business — "low but irreversible and unverifiable" is often still too much, and the only posture that removes the vector rather than shrinking it is not sending it to a third-party model at all: self-hosted or on-premises (on-prem).

Risk 3 — Compete in ways an LLM can't displace, regardless of your data

This one has nothing to do with any interaction you've had with the model, which is exactly why it's easy to miss. The vendor building what you built happens because the base model is already broadly capable, and because aggregate demand signals — thousands of customers doing similar things — tell the vendor what's worth shipping. The vendor doesn't need your prompt data to do this. So protecting your data does not protect your business here. Durability comes from building where a prompt can't reach: proprietary data you own and others can't get, distribution and customer relationships, regulatory position, and deep workflow lock-in. If your edge is a clever prompt or a thin wrapper, no privacy setting saves it. This is a standing requirement for a competitive business — true even if you never touched an LLM.

Bottom line

The toggle handles most of the "they build on your data" problem. What's left is trust you can't verify, a promise that isn't a technical guarantee, and a competitive threat that doesn't depend on your data at all. The first two are managed with tier choice, contracts, and — for crown jewels — not sending them. The third is won or lost in your strategy, not your settings.

What to actually do:

  • Treat "off" as strong risk-reduction, not a guarantee. Fine for ordinary sensitive data; assume trust, floors, and legal overrides still apply.
  • Keep true crown jewels off third-party models. For the irreplaceable asset, self-host or run on-premises — the only move that removes the vector instead of shrinking it.
  • Use reputable business tiers with a signed data processing agreement (DPA): no-training-by-default plus contractual breach-notice, deletion, and transfer terms.
  • Build moats an LLM can't copy: owned data, distribution, relationships, regulatory standing, workflow lock-in.

(Snapshot as of July 2026; provider policies and incidents evolve.)