The short answer: public and internal data can go into an LLM almost always, confidential data only in an environment with contractual no-training and no-retention terms, and restricted data never enters a prompt at all except in masked form. The operating rule is least-necessary exposure – send the model only what it needs to answer the question. The 2026 numbers explain the urgency: roughly 35% of the corporate data employees put into AI tools is classified as sensitive, up from 27% a year earlier and 11% two years earlier.
The real problem is not the technology, it is the usage already happening
In most organisations the debate about “whether to adopt AI” happens in a boardroom while employees are already pasting. 2026 surveys indicate that roughly 80% of employees use AI tools their IT department has not approved, and about 63% of them have already pasted sensitive material – source code, customer records, financial data or strategy documents – into a personal chatbot account.
The worrying detail is account ownership. When the paste comes from a personal account it sits outside every organisational control: no log, no control over retention, and no way to delete after the fact. According to the same reporting, roughly 82% of pastes into AI tools originate from personal accounts.
The price tag: organisations with high levels of unsanctioned AI use absorb an average of about $670,000 in additional breach costs, and 97% of organisations reporting an AI-related breach had no proper AI access controls in place. At the same time, only about 37% of organisations have any policy for detecting or managing such usage.
The practical conclusion: a blanket ban does not work, it only pushes usage underground. What does work is a clear classification policy paired with an approved alternative that is actually convenient.
The four classification tiers and what is allowed in each
Most enterprise classification policies use four tiers: public, internal, confidential and restricted. The table below translates them into a practical decision when facing a language model:
| Tier | Examples | What is allowed with an LLM |
|---|---|---|
| Public | Marketing content, published product specs, released reports | Allowed in any tool, including public ones |
| Internal | Procedures, internal decks, process documentation | Allowed only in an approved enterprise tool |
| Confidential | Customer data, price lists, source code, forecasts | Only where contractual no-training and no-retention terms apply |
| Restricted | Health data, payroll, personal identifiers, trade secrets | Never enters a prompt. Masked or summarised form only |
The most important distinction is between confidential and restricted, and it is where most organisations get confused. Confidential data causes commercial damage when it leaks, so a good contract is sufficient. Restricted data causes regulatory and personal damage, and there a contract is not enough, because the exposure cannot be undone after the fact.
The two techniques that solve most cases
Anonymisation removes or irreversibly obscures personal identifiers. Use it when there is no need to link the answer back to a specific person, for example when analysing trends across support tickets.
Pseudonymisation replaces identifiers with reversible tokens. A customer name becomes CUST_4471, and when the answer returns the system maps it back. This is the technique that lets you work with real customer data without sending names outside.
The rule of thumb covering both cases: least-necessary exposure. Send the model only what is required to answer, and omit classified items from external prompts entirely. In most cases it turns out the model needs the structure and the context, not the names.
What must appear in the contract with your AI vendor
The difference between “confidential data is allowed” and “it is not” is almost always decided in the contract, not in the technology. If an employee pastes confidential input into a public LLM, that data may be logged, retained or used to improve the service unless the provider is contractually bound otherwise. Three clauses to verify:
| Clause | What it says | Why it matters |
|---|---|---|
| No training | Your input is not used to train models | Without it your data may surface in another user answer |
| No retention or limited retention | Prompts are deleted after a defined window | Shrinks the exposure window if the vendor suffers an incident |
| Processing location and sub-processors | Where data is processed and who else touches it | Determines which regulations apply and what may be transferred |
How to implement this without a six-month programme
Step 1: a living inventory. Map sensitive data types by class – personal identifiers, health data, intellectual property and financial data – and assign each an owner, a source system and a retention policy. This is not a theoretical exercise; it is the list every future decision rests on.
Step 2: an approved alternative that is convenient. Before banning anything, provide an enterprise tool that actually works. If the approved alternative is slow or clumsy, employees return to the personal account and the policy stays on paper.
Step 3: enforcement at the data layer. Redact personal identifiers automatically on the way into the prompt, and apply the same check to the output. Enforcement that relies on employee training alone does not survive the first quarter.
Step 4: one rule everyone remembers. “If you would not email it to a different customer, do not paste it into a chat.” It is not legally precise, but it is understood and applied, and that is what counts.
The link to your knowledge base: once you move from manual pasting to a system that answers from your own documents, classification becomes a technical filter rather than a behavioural rule. We covered this in the guide to building an enterprise RAG knowledge base, particularly the section on enforcing permissions at retrieval time.
And if you are weighing infrastructure investment against tool savings, run the numbers through unit economics: the cost of a single incident typically covers years of an approved environment. Full guidance through this process sits under our AI implementation practice.
Frequently asked questions
Can customer data be entered into ChatGPT?
Not into a personal account or a public version. Customer data is confidential, so it may only be entered in an enterprise environment with contractual no-training and no-retention terms. Without such a contract, enter only a masked version in which names and identifiers have been replaced by tokens.
What is the difference between confidential and restricted data?
A confidential leak causes commercial damage, so a solid vendor contract is sufficient. A restricted leak – health data, payroll, personal identifiers – causes regulatory and personal damage that cannot be undone after the fact. Restricted data therefore never enters a prompt.
Is a blanket ban on AI tools a solution?
No. 2026 surveys show roughly 80% of employees already use unapproved tools, and about 82% of pastes come from personal accounts. A ban without a convenient approved alternative simply moves usage into an area with no logging and no control.
What is the difference between anonymisation and pseudonymisation?
Anonymisation removes identifiers irreversibly and suits trend analysis. Pseudonymisation replaces identifiers with reversible tokens so the answer can be mapped back to the person it concerns. Use the latter when you need to act on a specific customer.
Which clauses must appear in an AI vendor contract?
Three: no use of your input for model training, deletion or limited retention of prompts within a defined window, and a clear definition of the processing location and the sub-processors that touch the data.
Continue reading
The EU AI Act Timeline Moved. The Deadline That Matters Did Not. – Classification decisions now carry a regulatory deadline attached to them.