What Happens to Text You Paste In
The text leaves your network, arrives at a provider's servers, and is processed there. Most of the public argument is about one part of that journey, which is whether the words end up improving the model. The rest of the trip matters as well, and the answers there are more boring and more relevant to you.
In practice the same paragraph can sit in several places at once. In the request being served. In a conversation history the product keeps so you can scroll back tomorrow. In server logs. In an abuse detection pipeline, which normally holds material for a period so that a human can look at anything flagged. And in whatever the vendor's support tooling captures when an engineer investigates a fault you reported.
Whether a person ever reads it is a separate question from whether it is stored. Both matter. Vendors are usually much clearer about the training question than about the other four, and the other four are the ones your lawyer will ask about.
Consumer Terms and Business Terms Are Different Products
The free consumer app and the paid business tier from the same company can run the same underlying model under completely different rules. That is the most useful fact in this whole subject, because it is what makes a policy enforceable. Which rules apply depends on which door the request came in through, not on who sent it.
Consumer terms commonly allow the provider to use conversations to improve their systems, sometimes with an opt out buried in a settings page that quietly resets when a new feature ships. Business and developer terms commonly do not, and often say so in the contract rather than in a help article. Read the actual terms for the actual tier you are on. Marketing pages and terms of service disagree more often than they should.
The practical consequence is that the same employee, doing the same job, falls under different rules depending on whether they used the account you pay for or the one they set up at home on a Sunday. That is a sign in problem. Sign in problems are solvable.
Retention, and the Setting Nobody Changes
Retention is where the useful controls actually live. Ask any vendor three questions. How long is the input kept, where is it kept, and who inside your company is able to turn that down. Many platforms let you shorten it. Very few customers do, because the default is invisible and shortening it removes a feature somebody in the office likes.
Understand the abuse review window specifically. Providers keep some material for a period so they can investigate misuse, and that window can survive the setting that switches off everything else. Some offer an arrangement with no retention at all, on request or on a particular tier. If your data genuinely warrants that, ask for it and get the answer written into the contract rather than said on a call.
Then check the geography. Where the processing happens and where the logs are stored matter enormously to some businesses and are barely mentioned during the buying process. If you are subject to rules about where records may live, that question decides whether the tool is usable for you at all, and it belongs in the first meeting rather than the last.
Training Is Only Part of the Question
Even with training ruled out contractually, the data has left your building. It is now exposed to everything any hosted service is exposed to. A breach at the vendor. A legal demand served on them instead of on you. A support engineer with production access during an investigation. A misconfiguration in a feature you never turned on.
None of that is unique to this kind of tool. Your email, your accounting system and your file storage carry the same category of risk, and you accepted it years ago, either after weighing it up or without noticing. Apply the same standard here rather than inventing a stricter one, and apply it honestly to the systems you already trust.
The reason this feels different is behavioural. People paste things into a chat box that they would never attach to an email, because a chat box does not feel like sending something to a company. That gap is where most organisations actually get hurt. The vendor's practices are usually reasonable. The difference between what your staff would email and what they will paste is not.
The Use You Have Not Been Told About
Assume it is already happening. Somebody in finance is drafting supplier emails in a personal account. Somebody in support is pasting a customer complaint in to get a politer version back. A developer has installed a browser extension that sends the page they are reading somewhere you have never heard of. None of these people believe they are doing anything wrong, and mostly they are not.
A ban does not stop any of it. It moves the activity onto phones and personal laptops where you cannot see it, and it removes your ability to ask about it, because asking now turns somebody into a rule breaker. Companies that ban this tend to end up with more exposure and less visibility than companies that do not.
You can measure the rough shape of it if you want to. Your network or proxy logs show which domains staff reach and how often. Do that before writing the policy rather than after, because what people are already doing should decide what the policy needs to say.
Give People a Safe Option Instead of a Rule
The most effective control available here is a good enough approved tool. If there is an account your staff can use, sitting under business terms, signing in with the company identity, and working about as well as the thing they were using before, most of the problem disappears without anybody being told off for anything.
Make it genuinely convenient. The same sign in as everything else, available on somebody's first day, no ticket to raise and no approval to chase. Every piece of friction you add sends one more person back to their personal account, and the personal account was the thing you were trying to fix.
Then say plainly what it is for and why it exists. People behave better when they know which tool is sanctioned and what the difference is. Telling somebody that the approved account keeps their draft out of a training set works considerably better than telling them that pasting is forbidden.
Say What May Go In, in Words People Understand
Write the classification using your own nouns rather than abstract categories. Customer names and addresses. Card details. Medical information. Salary and disciplinary records. Unreleased pricing. Source code from a client repository. Anything covered by a confidentiality agreement with a name on it. A list of your actual things beats a paragraph about sensitive data every single time.
Then give each item a rule: freely, only in the approved tool, or never. Three buckets is enough for most companies, and a fourth one starts an argument that never finishes. Put an example beside each bucket, because the examples are the part people remember a fortnight later.
Include the workaround explicitly, because people will need one. Say how to get the help without the data. Describe the problem in general terms. Replace the real names with made up ones. Paste the structure rather than the contents. Staff follow rules they can obey while still finishing their work, and ignore rules that stop them.
Running It Yourself, and When That Is Worth It
You can run a model on your own hardware or inside your own cloud account, and for a small number of businesses that is the right answer. Regulated data that legally cannot leave a jurisdiction. A contract with a customer that forbids third party processing. Material valuable enough that a breach at a supplier would be an existential event rather than an embarrassing one.
Be honest about what it costs. You take on the hardware or the reserved capacity, the updates, the security of the thing, the evaluation, and the people who understand all of that well enough to be woken up about it. The models most companies can practically run themselves lag the hosted ones, so you are paying more for a weaker result in exchange for control. Sometimes that trade is obviously correct. More often it is not.
The middle path suits nearly everyone. Use a hosted service under business terms, turn the retention down, keep a short written list of what may not go into it, give people an approved account that is easy to reach, and put the genuinely sensitive workload somewhere else entirely. You can be finished with that in a few weeks. A private deployment is a project with a budget and an owner.
