Somebody in your business is already pasting company documents into a chatbot. Contracts, price lists, customer complaints, staff records. They are doing it because it saves them an hour, and nobody told them not to.
This is worth addressing directly, without either panic or a blanket ban that everyone quietly ignores.
What actually happens to what you paste
It depends entirely on which tool and which account, which is why blanket statements in either direction are wrong.
Free consumer tools have historically reserved the right to use submitted content to improve their systems, with settings that may or may not be on by default. Paid business tiers generally commit not to train on your data, and say so in the contract. The gap between these two is the whole issue.
Beyond training, the text is transmitted to and stored on servers outside your control, for some period, under a policy you did not negotiate. Even where it is never used for training, it exists somewhere else.
The practical question is not whether AI tools are safe in the abstract. It is which account your staff are using, and what they are putting into it.
The categories that should never go in
Anything covered by a confidentiality agreement. If you signed an NDA with a client, pasting their documents into a third-party service is plausibly a breach, regardless of what the tool does with it. This is a contractual problem before it is a technical one.
Personal data about identifiable people. Staff records, customer lists with contact details, anything medical or financial about an individual. Nigeria's data protection framework places obligations on you as the handler of that data, and "our staff pasted it into a website" is not a defence.
Credentials and keys. Passwords, API keys, bank details, database connection strings. This happens most often when somebody pastes a configuration file or an error message to ask what is wrong, without reading what else is in it.
Unreleased commercial information. Tender pricing, acquisition discussions, anything where early disclosure has a cost.
What is generally fine
Public information. Your own marketing copy. Generic questions that do not carry your data. Redacted or invented examples that have the same shape as your real problem.
That last technique is the useful one, and it is underused. If you want help restructuring a contract clause, you rarely need the actual client name, the actual figures, or the actual dates. Replace them, get the help, put the real values back yourself.
A policy people will actually follow
Bans do not work here, because the tools are too useful and the enforcement is impossible. Aim for a short rule that fits in someone's head.
Something like: business accounts only, never paste anything you would not email to someone outside the company, replace real names and numbers with placeholders, and if you are unsure, ask before pasting.
Write it down. Say it out loud in a meeting. Then provide a business account so that following the rule is not also a decision to work more slowly. Most policy failures here are really provisioning failures -- staff use the free tool because nobody gave them anything else.
The provisioning part
If these tools are genuinely useful in your business, pay for the business tier for the people who use them. It is not expensive relative to the hours it saves, and it moves you from a consumer agreement to a commercial one with actual commitments about your data.
Keep the accounts owned by the business, not by individuals. The same principle that applies to your domain and your Google listing applies here.
Where the real risk usually is
Not in the dramatic scenario where a competitor somehow retrieves your strategy from a model. That is largely hypothetical.
The realistic risks are duller: a confidentiality clause breached because nobody thought about it, personal data handled carelessly, a credential pasted into a public tool and never rotated, or an answer that was confidently wrong being acted on because it looked authoritative.
That last one is not a security problem at all, but it does more damage more often than the rest combined. Which is the subject of a separate discussion about checking output before using it.