Shadow AI
The tools your staff already use that nobody approved. The useful response is to bring the use into the light, not to pretend it is not happening.
Shadow AI is staff using unapproved AI tools for work. Banning it rarely works, because the need that drove people to it remains; the answer is an approved route and honest reporting.
If you run operations or risk in an organisation of any size, you probably already have this: people using AI tools you did not sanction, on work you care about. This page is written to that situation rather than the term. It rests on a small number of solid sources rather than the vendor commentary that fills this topic.
What is shadow AI?
It is the AI version of shadow IT: staff using tools for work that the organisation has not approved and often does not know about. A consumer chatbot for drafting, a browser extension nobody vetted, a personal account used on work data. The BCS on the risks of shadow AI describes four categories of risk and treats shadow AI as carrying potentially greater risks than shadow IT.
The reason it matters more is that AI tools take in data and produce output that people act on, so an unapproved tool can leak information and shape a decision at the same time.
How does it show up?
Quietly, and usually from good intentions. Someone finds a tool that saves an hour and starts using it; a team standardises on it without telling anyone; work data ends up in a service the organisation never assessed. It rarely announces itself, which is why the first sign is often an output nobody can explain the origin of.
The data exposure is the sharp edge. The NCSC on the risk of public large language models is clear that sensitive information should not be entered into public large language models and that providers can retain and access what is submitted, so shadow use of those tools is where confidential data most easily walks out.
Why does banning it rarely work?
Because a ban treats the symptom. People reach for these tools to get work done, and forbidding them does not remove the need that drove them there. The BCS on the risks of shadow AI argues against outright bans on the basis that employees will innovate regardless, and favours collaborative governance instead.
The NCSC on shadow IT makes the same point about shadow IT: unsanctioned adoption is normally a sign that staff are struggling to use the sanctioned tools, so it reads as a signal of unmet need rather than only indiscipline. A ban that ignores the need pushes the use further out of sight.
What should you do instead?
Give people a sanctioned way to do the thing they reached for the shadow tool to do, and an easy route to ask for a new one. Name clearly what must never go into an external tool, and make reporting a shadow use safe rather than punitive, so you find out about it while you can still act.
Then treat what surfaces as information about where your approved tools fall short, and close that gap. That is the difference between a policy that drives the behaviour underground and one that brings it into view.
What should the policy say about it?
Three things: the approved tools and how to request a new one, the data that must never go into an external tool, and the route to report a shadow use without penalty. Keep the approved-tools list live, because a stale list is itself a cause of shadow AI.
The acceptable use guide covers the staff-facing rules, and the generator turns your answers into a draft with these decisions marked for you. The policy skeleton gives you the headings if you prefer to start from those.