Data that must not go in

An AI chat box feels like a private notebook. You type, it answers, nobody else is in the room. Yet the moment you press send, the text leaves your computer and is processed on servers run by the provider. Depending on your account settings, it may be kept for a while, read by the provider's safety staff if there is an abuse report, or used to train the next model. We cover those settings in the lesson on data settings and memory. Here we start with a more basic question: what should never be sent in the first place.

There are three kinds of content to recognise before you paste:

• Personal data. Anything that can point to a particular person: name, ID number, address, phone number, face photo, work history, grades, salary. Some personal data is specific under the PDP Law, such as health data, children's data and personal financial data; the list is in the PDP Law basics lesson. For these, the safest answer is often not to send them to a model at all.
• Technical secrets. Passwords, API keys, access tokens, the contents of configuration files, invitation links anyone can use. Whoever holds them can get into a system in your name.
• Other people's property. Client contracts, quoted prices, unpublished financial reports, documents marked confidential. They may not mention a person, but you have promised to keep them safe.

The most useful habit is to stop for three seconds before pasting and reread what you are about to send through an outsider's eyes. The question is simple: if a stranger read this text, would anyone be harmed? If yes, do not send it as it is.

Holding data back does not mean giving up on AI. There is almost always a way to do the same task without the forbidden data:

• Send the shape, not the contents. To build a spreadsheet formula, the model only needs the column names and two made-up sample rows, not the whole payroll.
• Replace secrets with markers. To ask why a configuration fails, write [PASSWORD_REMOVED] where the password was. The model does not need your real password to spot a typo.
• Mask as much as needed. To summarise customer complaints, names and phone numbers can be swapped for codes. How to do that, and where it stops working, is in the lesson on masking data.
• Use a tool your organisation has approved. Some work really needs real data, such as tidying clinical notes. That is not a job for your personal account on a public service; ask which tool your organisation has approved and contracted.

Mistakes still happen: an API key gets pasted along with an error message, or a spreadsheet with employee names is uploaded to the wrong account. When that happens, do not hope nobody saw it. Treat it as a leak.

For a technical secret, the steps are clear: replace (rotate) the key or password right now, revoke the old one, and tell the system's owner. Deleting the message is not enough, because copies may already sit on a server, in history, or in someone's notifications. A replaced key is useless to anyone who copied it.

For personal data, do not try to handle it quietly on your own. Report it to your manager and to your organisation's data protection officer or security team the same day, noting what was sent, to which service and when. Your organisation may have a notification duty with a short deadline under the PDP Law, so every hour counts. A fast, honest report is almost always cheaper than a leak someone else finds later.