What You Should Never Put Into an AI Tool

The useful thing about AI tools is that you can paste anything into them. That is also the problem.

Most data incidents involving AI are not sophisticated attacks. They are an employee pasting something into a chatbot to get help with it, which is exactly what the tool invites you to do.

Here is a practical list of what should not go in, and more usefully, how to work out where your own line sits.

The clear no list

Credentials of any kind. Passwords, API keys, access tokens, connection strings, private keys. Never, in any tool. If a key has been pasted into a chat window, treat it as compromised and rotate it. This sounds obvious and it is one of the most common findings when companies audit their AI usage.

Payment card details. There is no legitimate reason for a card number to enter a chat interface, and doing so may put you outside your card processing obligations.

Health information. Special category data under GDPR with a higher bar for lawful processing. Employee sick notes, medical certificates, anything about someone's condition.

Other special category data. Racial or ethnic origin, political opinions, religious beliefs, trade union membership, biometric and genetic data, sex life or sexual orientation. Extra care regardless of the tool.

Anything under a confidentiality obligation you cannot verify covers the tool. Client material under NDA, unpublished deal information, another company's trade secrets. If a contract says information stays within your organisation, sending it to a third-party processor may breach it, whatever the security of that processor.

Identifiable third-party data with no lawful basis. Uploading a customer list to a general tool to "analyse it" is a processing activity, and it needs a basis and a data processing agreement.

The it-depends list

This is where most real decisions sit, and the answer turns on which tool.

Customer names and contact details. Fine in a business tool you have a DPA with and where the processing is covered by your register. Not fine in a free consumer chatbot with no agreement.

Internal financial data. Same distinction. A tool contracted for your business is a processor. A free tool you signed up for personally is not.

Employee data. Contracts, salaries, performance notes. Needs a proper business tool and a lawful basis, not a general assistant.

Draft strategy and unpublished plans. Lower legal risk, real commercial risk. Depends how much you trust the vendor's retention and training position.

How to work out where your line is

Three questions settle most cases.

Is there a contract? Under GDPR, any vendor processing personal data for you needs an Article 28 data processing agreement. If there is no DPA, do not put personal data in. That single rule resolves a large share of the ambiguity.

Is training on your data excluded in writing? Many vendors say on their homepage that they do not train on customer data. Considerably fewer say it in the contract. Check the contract, because that is the version that binds them.

Where does the data actually go? Read the sub-processor annex in the DPA. It names every third party that touches the data and where they sit. For AI tools this matters more than usual, since inference frequently runs through providers in the United States even when the product is European and the storage is not.

Vendors that publish this properly make the assessment easy. Mirage Cloud, for example, publishes a sub-processor annex naming its model and voice providers with locations and transfer safeguards. Whether that is acceptable for a given data type is your call, but at least it is a decision made with information rather than a guess.

The rule that actually gets followed

Elaborate policies do not get read. One sentence does.

Something like: if it contains a password, someone's health information, or a client's confidential material, it does not go into an AI tool. If it contains personal data, it only goes into the tools on our approved list.

Then maintain the approved list, which is short, and make sure the tools on it have DPAs.

Two supporting habits:

Redact before pasting. Most of the time you want help with a structure or a problem, not with the specific names. Replacing real identifiers with placeholders costs seconds and removes the issue entirely.

Use business accounts, not personal ones. Business tiers generally carry different data handling terms, and business accounts can be administered, audited and revoked when someone leaves. Personal accounts cannot.

The part people forget

Prompts are not the only channel. Uploaded files, connected integrations and browser extensions all move data too, and integrations move it continuously rather than once.

When you connect an AI tool to your email, your drive or your accounting system, you are granting standing access to everything in it. That is often exactly what you want, and it is a bigger decision than any single paste. Check what permissions you are granting, whether they include write access, and how to revoke them.

In one line

Assume anything you put into a tool could be read by someone at the vendor. Then decide whether you are comfortable. For most business work with a properly contracted vendor, you will be. For credentials, health data and other people's confidential material, you will not be, and that is the whole list.