Shadow AI is the use of AI tools inside an organisation without approval, oversight or a record that it is happening. It is almost never an act of defiance. It is somebody with too much to do finding something that helps, and it is a signal about demand rather than about discipline.
The first response is usually a ban. Bans move the behaviour onto personal phones and personal accounts, where the organisation can no longer see it, measure it, or limit what goes into it.
Shadow AI is any use of AI tools for work that sits outside the organisation’s approved list and its visibility. It covers a public chatbot used to draft a document, a browser extension summarising a meeting, an AI feature switched on inside a tool the organisation already pays for, and code written with an assistant that nobody declared.
The last two are the ones that catch people out. A large share of shadow AI is not a new tool at all. It is an AI capability quietly enabled inside software the organisation approved years ago, before the capability existed.
Because the tools work and the approved alternative either does not exist or is worse. The person reaching for one is far more often trying to work faster than trying to get round a control.
That framing matters because it determines whether the response works. Treat it as a compliance failure and you will write a policy. Treat it as unmet demand and you will procure something, which is the only response that has ever changed the behaviour.
In March 2023, engineers at Samsung’s semiconductor division pasted proprietary source code, a defect-detection algorithm and notes from an internal meeting into ChatGPT. There were three separate incidents within about twenty days of the tool being permitted. In May 2023 the company issued a memo, reported by Bloomberg, banning generative AI tools on company devices and warning that breaches could lead to dismissal.
The case is usually told as a story about careless staff. Read the detail and it is not. These were capable engineers at one of the most security-conscious manufacturers in the world, working in a division where confidentiality is the product. They had been told the tool was permitted. Nobody had told them what could go into it, and there was no internal equivalent that kept the data inside the company.
Twenty days is the number worth sitting with. It is roughly how long it takes for a useful tool to become part of how people work, and it is far shorter than a procurement cycle.
Bans reduce visible use and rarely reduce actual use. The tool moves to a personal device, a personal account and an unmanaged browser, where the organisation cannot log it, cannot apply retention rules and cannot tell what data left.
A ban also has a second cost that is harder to see. It removes the organisation’s ability to find out what people were using AI for, which is the most valuable information available at this stage of adoption. The tasks staff reach for AI to do are a free, continuously updated list of where the organisation’s processes are painful.
There is a narrow case where a ban is correct, which is a specific class of data that must not leave under any circumstances, enforced technically rather than by instruction. That is a control on data, not a ban on a category of tool, and the difference is what makes it enforceable.
Less than you would expect, and more than most organisations look for. Four sources give a usable picture without deploying anything new.
Network and proxy logs show traffic to known AI services from managed devices. Identity provider logs show sign-ins to third-party applications using work accounts, which catches tools adopted through single sign-on. Expense and card data shows individual subscriptions, which is where team-level adoption usually appears first. And the administrative console of your existing software suite shows which AI features are enabled and who has used them.
None of that covers personal devices. That gap is permanent and it is the reason the answer is supply rather than surveillance.
Run the check before designing the response. Organisations that do it usually find the use is broader, more mundane and more useful than they assumed, which changes what they decide to build.
A sanctioned alternative works when it is good enough that people prefer it, available quickly enough to matter, and clear about what may be put into it.
Three things determine whether it gets used. It has to be at least as capable as what people are already using, because a worse tool loses to a browser tab. It has to be available to everyone who needs it rather than to a pilot group, because a waiting list is a reason to use something else. And it has to be obvious what may be put into it, in one sentence, at the point of use rather than in a policy document.
The data handling question sits underneath all three, and it is a genuine decision rather than a formality. An enterprise or API tier from one of the large providers, on the right contract and configured carefully, keeps inputs out of model training and gives you retention controls. For the most sensitive categories of data, some organisations will conclude that the processing itself needs to stay inside their own infrastructure. Which of those is right depends on the data, and we set out how to make that decision in our piece on self-hosted or hosted AI.
We run models both on hosted services and on our own cleared infrastructure. For most organisations a properly contracted hosted service is the right answer. For a minority of workloads it is not, and it is worth knowing which you have before you buy.
Not the tools. The documents.
Work starts arriving in a house style nobody set. Reports become uniformly well-structured. Meeting notes appear faster than anyone could type them. Code review comments become notably more thorough. None of that is a problem in itself, and all of it means AI is already inside the workflow, which means the questions about what data it sees are already live.
The second tell is a paper trail that has gone quiet. If nobody has ever asked you whether they can use a tool, that is not evidence they are not using one.
Run the four checks in the visibility section above and write down what you find, without attaching consequences to it. You are collecting a demand list rather than building a case.
Then look at the top three uses and ask what it would take to provide a sanctioned equivalent for each. Usually two of the three are straightforward and the third is the one that needs a real decision about data.
If you want help working out which of those uses can sit on a hosted service and which need to stay on your own infrastructure, that is a conversation we have most weeks.
Both, and treating it as only the second produces a policy that changes nothing. The security exposure is data leaving without a record. The compliance exposure is being unable to say what personal or confidential information was processed, by whom, and under what terms.
Check network and proxy logs for traffic to known AI services, identity provider logs for third-party sign-ins with work accounts, expense data for individual subscriptions, and the admin consoles of software you already own for AI features that have been switched on. None of it covers personal devices.
Rarely. A block removes visibility without removing use, and it delays the only response that works, which is providing something sanctioned. Restrict specific categories of data technically, and move quickly on an approved tool.