There is a moment when an employee has a problem and looks for a solution. A text that needs to be finished faster, a dataset that needs to be clearer, a customer who wants an answer today. The IT helpdesk takes too long, or there is no helpdesk. So an account gets created, an extension gets installed, a subscription gets taken out on a credit card that no one checks. Not out of unwillingness. Out of workload.
This is how shadow AI arises. Not as a revolt against policy, but as a practical response to a gap in policy. And it does not disappear on its own, because the reason it arose — a task that goes faster with AI than without — remains as long as the policy offers no alternative. Banning it does not change the task. It only changes whether you know the tool is being used.
An overview of approved software says something about what has been requested and granted. It says nothing about what is being used. Between those two lists there is a gap that grows as AI tools become more accessible: no installation, no procurement process, just a browser and an account. A browser extension with access to your mail falls outside every procurement process and every overview, while the access it has is just as sensitive as an approved system. Anyone who looks only at the IT list is looking at a part of reality and calling it the whole.
The only way to know what is actually being used is to ask. Not as a control question with a sanction at the end, but as a stocktaking with no consequences for those who cooperate. As soon as employees suspect that an honest answer leads to a conversation with a manager, the information does not disappear — it simply goes underground. The same tool keeps running, just less visibly. An organization that wants to know the scale of shadow AI must therefore first arrange the condition under which it gets the answer. That is not a matter of losing trust, it is a matter of sequence: first visibility, only then policy.
Once the stocktaking has been gathered, something usable emerges: a list of tools by role and risk level, not by right or wrong. A tool that rewrites text for internal use carries a different risk than a tool that processes customer data or prepares decisions. Some of these tools arose from individual use that grew into a department standard — see a department with its own subscription — and deserve formalization rather than a ban. Others were set up once for a project that has since been completed, but access is still open; that is the pattern described in a pilot setup that was never switched off. The classification determines what is needed: sometimes nothing, sometimes an adjustment, sometimes incorporation into the existing governance structure.
The goal of this approach is not to point out everyone who started a tool without permission. The goal is to know what is running, who uses it, and what risk is attached to it — so that a director, CIO, or General Counsel can answer that question when it is asked, internally or externally. That requires a consistent way of taking stock that does not stop after one round, because new tools keep appearing. How that stocktaking is built up in practice, including the question of who carries it out and how often, is described in how you build an AI inventory.
The governance structure itself — which rules apply to which risk level, which deadlines and obligations go with it — is a separate subject with its own current content, which is not repeated here. What counts on this page is the mechanism: gaining visibility without shutting down the flow of information, and translating that visibility into a classification that aligns with what the organization has already set up for risk management.
The inventory that exposes shadow AI often does not do so only for individual tools. It also reveals that a supplier has added AI to a system that was already in use, without a separate conversation ever taking place about it — the pattern behind a supplier who built AI into their product — and that sensitive company information is sometimes simply pasted into a public chat window, as described in company data in a free chat window. All these forms share the same origin: a task for which AI works faster than the existing process.
That observation leads logically to another question, separate from approval and risk: which part of the work itself is suitable to be taken over by AI. The FTE TO AI work scan calculates that per task, based on what the work actually entails, and shows where automation can take over a real portion of the time — as a stepping stone to a conversation about what can be planned with that, not as a replacement for the governance question that is central to this page.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.