Your team is already using AI you didn't approve

Someone in your company pasted customer data into ChatGPT this week. Not maliciously — they were trying to finish something, and it was faster. They almost certainly did not tell anyone.

This is not a hunch. Shadow AI — employees using AI tools nobody approved — appeared in 43% of AI-related breaches reported this year, and Verizon's 2026 Data Breach Investigations Report found 45% of employees using unapproved AI tools at work. Some research puts it above 80%. In a survey of enterprise executives, 67% believed their company had already suffered a data leak because of it.

Two-thirds think it has already happened to them. Most of them cannot prove it either way, which is the actual problem.

Why the obvious fix fails

The instinct is to ban the tools. Block the domains, send the email, done.

It does not work, and the reason is worth sitting with. People reach for these tools because they are under time pressure and the tool removes friction. Blocking the corporate account does not remove the pressure — it just moves the work to a personal phone, where you have no visibility at all. You have not stopped the behaviour. You have stopped seeing it.

Every serious piece of guidance published this year lands in the same place: enablement beats prohibition. Not because bans are unkind, but because they measurably fail.

What an acceptable use policy actually needs

Most AI policies we see are a page of principles. "Use AI responsibly." "Be mindful of data." Nobody has ever changed their behaviour because of a sentence like that, because it does not answer the question the person actually has, which is: can I paste this specific thing into this specific box, right now?

A policy that works answers four questions in language a busy person can act on.

Which tools are approved. Name them. Not "enterprise-grade AI tools" — the actual products, the actual accounts. If your team has to guess, they will guess in their favour.

Which data must never go in. Also by name. Customer records. Anything with a person's contact details. Unreleased financials. Source code from a client repository. Vague categories like "sensitive information" put the classification burden on the person least equipped to carry it, in the moment they are least inclined to think about it.

What to do when the answer is neither. This is the one everyone omits, and it is the one that determines whether the policy survives contact with real work. If someone has a genuine use case that is not on the approved list, there must be a named person to ask and a realistic turnaround. Without that route, the policy's only available answer is "no", and people route around it.

What happens after a mistake. If the consequence of admitting you pasted something is disciplinary, nobody will admit it, and you will find out from somewhere worse. The organisations that catch these things early are the ones where reporting it is boring.

The part most people skip

Write down what you actually approved and why. Not for auditors — for the version of your company that exists in eight months, when the person who made the decision has moved on and someone asks why a particular tool is on the list.

Almost nobody does this. It takes twenty minutes and it is the difference between a policy that holds and a policy that quietly rots into a document nobody can defend.

If you handle UK or EU personal data

There is a sharper edge here. Pasting a customer's personal data into an unapproved tool is not only a security question — it is a processing activity you have no lawful basis for, no record of, and no way to include in a subject access request.

You cannot tell someone what you did with their data if you do not know which tools it went into. That is not a hypothetical failure. That is the thing you will be asked to answer.

Where to start

If you do nothing else this month: find out what people are actually using. Ask, without consequences attached. The gap between what you think is in use and what is in use is where your risk lives, and it is usually wider than expected.

Then write the four answers down. One page. Specific names, specific data types, a real person to ask, and a way to admit a mistake without it becoming a disciplinary matter.

That is not an AI strategy. It is considerably more useful than most of them — one survey this year found 75% of executives admitted their AI strategy was "more for show" than actual guidance. A page your team can act on beats a strategy deck nobody opens.

---

We run AI development training covering exactly this — building with AI, and the guardrails around it. If you would rather talk through your own situation first, get in touch.

Sources: Verizon 2026 Data Breach Investigations Report (via Nasstar) · IRMCon shadow AI breach analysis · Writer enterprise AI adoption survey 2026 · Adaptive Security shadow AI risks