Following the paragraph

The journey of one paragraph

You paste three paragraphs of a client's contract into a chat box and press enter. Here is what happens, in order, in a typical commercial service.

The text leaves your device over an encrypted connection and arrives at the provider's servers, usually in a region you did not choose. It is written to a request log — this happens before any model sees it, because logging is how outages get diagnosed. The text is tokenised and processed, and the response is generated. Both the input and the output are stored in your conversation history, so the interface can show it to you tomorrow. Both are typically also retained in an abuse-monitoring store, often with a different retention period, and often accessible to a different group of staff. If the service uses a third-party model, an analytics provider, an error-tracking tool or a cloud host, copies may exist with each of those subprocessors. If your text triggered a safety classifier, it may be routed to a human review queue.

That is at least four copies in three organisations, from one paste. None of this is sinister. It is how any internet service works. But "I asked a question" and "I created several durable copies of a client's contract in another jurisdiction" describe the same act, and only the second is accurate.

Three statements that sound alike

Companies make three quite different promises and users hear them as one.

"We do not train on your data." The most common enterprise commitment, and the narrowest. It says your text will not be used to update model weights. It says nothing about storage, retention, staff access, subprocessors or disclosure to authorities.

"We do not retain your data." Much stronger, much rarer, and usually qualified — zero-retention modes typically exist only on business API tiers, must be enabled deliberately, and are sometimes incompatible with features you want, such as conversation history or file uploads.

"Your data is encrypted." Almost always means encrypted in transit and at rest, on disks the provider controls, with keys the provider holds. It protects against interception and stolen hardware. It does not prevent the provider reading it, because the provider must decrypt it to process it. End-to-end encryption, where the provider cannot read the content, is fundamentally hard to combine with running a model on that content, and claims to the contrary deserve close reading.

Consumer and business tiers are genuinely different

This is one of the few places where paying changes the substance rather than the volume.

Consumer tiers commonly train on conversations by default, with an opt-out somewhere in settings. Business and enterprise tiers, and most paid APIs, contractually exclude training, offer shorter retention, provide a data processing agreement, and let you pick a processing region. If you are handling anyone else's information in your work, the tier matters more than the model.

Worth knowing: turning off training in a consumer product often also turns off conversation history, because the same store backs both. People turn it back on within a week for convenience, which is worth anticipating rather than discovering.

Legal process and breaches

Retained data is reachable in two ways that have nothing to do with the provider's intentions.

Legal process. Subpoenas, court orders and law enforcement requests. Providers publish transparency reports counting these. Notably, a US court order in 2025 required one major provider to preserve output data it would otherwise have deleted, as part of a copyright case — which is a useful reminder that a stated deletion policy can be overridden by litigation you are not party to.

Breach. Any store can leak. The 2023 incident where a caching bug briefly exposed fragments of other users' conversation titles and some billing information is a small example of a general class.

The practical consequence is the same in both cases: the only text guaranteed not to be disclosed is text you did not send.

What to do with this

Four habits.

Know your tier. Check whether the account you use for work trains on your inputs, and whether retention is zero, thirty days, or indefinite. This is ten minutes of reading, once.

Reduce before you send. Most tasks do not need the identifiers. Replace names with letters, shift dates by a constant, round or perturb amounts where the pattern rather than the value matters. The model helps you just as well with "Client A" as with the real name.

Separate accounts. Personal exploration and client work in the same history is how the client work ends up in the consumer tier.

Assume the log outlives the conversation. Delete removes it from your view. Whether it removes it from the abuse store, the backups and the subprocessors depends on the policy you have not read, and generally takes longer than the interface implies.