Pasting a document into a chat assistant is not the same kind of act as searching for something. This separates what happens to that text — the request, the retention, the human review, the training set — and gives the questions that distinguish a service that cannot read your input from one that merely says it will not.
An upload, not a query
A search query is a few words you would happily say aloud in a lift. It is a pointer to something that already exists, and the interesting content is what comes back, not what you typed.
A document pasted into an assistant is the opposite. The contract, the patient note, the codebase, the unpublished draft — the substance is what you sent, not what you received.
People treat these as the same act because the interface is the same act: a text box, a cursor, a button. That is a design property, not carelessness on anyone's part. Nothing in the interface marks the moment where a question becomes an upload, so the distinction has to be held in the user's head, and mostly it is not.
Where it actually goes
The visible path is simple enough. The text leaves the browser under transport encryption, crosses the network, arrives at an inference service, and is held at least long enough to produce a reply. If that were the whole path there would be little to discuss.
It is the parts either side that matter. Requests are logged, and logs of this kind commonly capture inputs and outputs rather than only timestamps, because that is what makes a malfunction diagnosable. Abuse detection systems read the text, by design — that is their function. Error traces capture whatever was in scope when something failed, which is frequently the input. Retention windows exist for debugging, and they are measured in days or months rather than seconds. Infrastructure sits underneath all of it: storage, caches, managed services, each with its own access model.
None of this is sinister. It is what running a service at scale requires. But it means a promise not to train on your data is a statement about one of these paths and silent about the others.
Three different questions asked as one
Most privacy conversations about assistants are three questions wearing one coat.
Will this be used to train a model? Whether the text ends up influencing the weights of some future version.
How long is it kept, and who inside the company can read it? Whether it sits in a log for ninety days, and whether an engineer debugging an incident, or a reviewer handling a safety flag, can read it while it does.
Could it come back out? In someone else's answer, in a support ticket, in a disclosure obligation.
For anyone holding genuinely confidential material, the second matters most, and it is the one that gets least attention. The first dominates the conversation because it is the easiest to answer cleanly: it is a single sentence, it costs a vendor almost nothing to promise, and it is binary. Retention and access are messy, involve trade-offs, and do not reduce to a sentence.
What "we do not train on your data" does and does not cover
It is a real commitment and worth having. It means your material does not become part of the general capability of a model that other people query. That is not nothing.
It typically says nothing about how long the text is retained. Nothing about whether a human reviews conversations that trip a safety classifier. Nothing about logs held by infrastructure sitting between the browser and the model. Nothing about what happens when a company is acquired, or when it receives an order it must comply with — a question that is legal rather than technical, and that no engineering promise resolves.
These are ordinary realities rather than bad faith. The point is only that the promise has edges, and the edges are where confidential material actually lives.
The questions worth asking
Applicable to any assistant, including one built by someone you like.
- What is the retention period for inputs and outputs, and can it be set to zero?
- Can a person at the company read a given conversation, and through what process?
- Is the text used for abuse detection, and is that governed separately from training?
- Where is inference performed, and does anything leave that boundary?
- What happens on account deletion — erased, or retained under another policy?
A vague answer to the first two is itself an answer. For material that is privileged, regulated, or somebody else's, treat it as a refusal.
The arrangement that removes the question
There is one structural answer, and it is not a clever configuration: inference where the plaintext never leaves a boundary you control. Locally, or on infrastructure you operate.
The costs are real and worth stating rather than glossing. Capability is lower. Latency is worse. Somebody has to run it, and that somebody is you. For most work, most of the time, that trade is not worth making, and pretending otherwise helps nobody.
It becomes worth making at a fairly specific boundary: legally privileged material, patient data, unpublished research, and source code belonging to someone who did not agree to this. In those cases the question is not which vendor to trust. It is whether the text should be leaving at all.
Close
None of this is an argument for not using the tools. It is an argument for being able to sort your own inputs into two piles: the ones you would be relaxed about reading back in a disclosure bundle, and the ones you would not.
The first pile is most of them. The second pile is the one worth a moment's thought before the paste.