What not to paste into an AI chatbot

Pasting is fast. That is the whole appeal of an AI chatbot: copy the email thread, the spreadsheet or the error log, ask a question, get an answer. The trouble is that a copy and paste carries everything in the selection, including the parts you did not mean to share.

Here are six kinds of information that should stay out of AI chat tools unless your company has approved a specific tool for them, with the reason for each and a safer way to get the same help.

1. Customer and staff personal data

Names with phone numbers, home addresses, ID numbers, dates of birth, health details, salaries. Once pasted, that data has been shared with another company, under that company's terms, possibly in another country. Data protection laws such as the GDPR and India's DPDP Act 2023 expect you to know where personal data goes and why. A chatbot used on a personal account rarely fits that.

Instead: replace names with roles (Customer A, the branch manager), remove contact details, and describe the situation. The model does not need to know who the customer is to help you word a reply.

2. Passwords, API keys and tokens

These turn up in pasted configuration files, error logs and code snippets more often than anyone intends. A key in a prompt is a key outside your control. If it was a live key, treat it as exposed and replace it.

Instead: delete the value and write a placeholder such as YOUR_KEY_HERE. The question about why the connection fails rarely depends on the key itself.

3. Payment and bank details

Card numbers and bank account numbers in a pasted export or a customer complaint. Card data in particular comes with strict industry rules about where it may be stored.

Instead: cut those columns before you paste a spreadsheet, or keep only the last four digits.

4. Client documents under confidentiality

Contracts, briefs, financials and plans that a client gave you under an agreement that says you will not share them. Whether pasting into an AI tool counts as sharing depends on the agreement and the tool, and the safest assumption is that it does unless the client has agreed.

Instead: summarise the clause or question in your own words, without names or figures, or use a tool your company has approved for client work.

5. Source code from private repositories

Code can contain keys, internal addresses, customer names in test data and the logic that makes your product different. Some companies approve particular coding assistants under business terms; others do not allow it at all. Know which applies to you.

Instead: paste the smallest snippet that shows the problem, with names and values changed.

6. Unannounced plans and numbers

Next quarter's results, a planned acquisition, a price change, a reorganisation. These are often not personal data and not covered by a client agreement, which is why people forget them.

Why the account matters

The same tool can come with different terms depending on how you sign in. Business and enterprise plans often say that your inputs are not used to train the provider's models and are kept for a limited time; free personal accounts often say less, or say the opposite. Terms change, so read the current ones for the plan you actually use rather than relying on what a colleague remembers.

Checking before you paste

Reading every selection carefully works when the selection is short. It works less well for a 300-row export or a long log file. That is where a quick check helps: a scanner that looks for the patterns of email addresses, phone numbers, ID numbers, card numbers and keys, and tells you what it found before you decide.

In Openn Shield, the scanner runs in your browser. You paste the text or open a text file, 21 built-in rules and your company's own confidential keywords check it, and you see what was found and where. The text is never sent to the server. It is pattern matching, so it will miss things written in words and sometimes flag a number that only looks like an ID, but it catches the common slips. See exactly what the scanner covers.