The AI use in your organisation you cannot see

Shadow AI is generative-AI tooling that employees use outside formal approval and beyond the sight of IT and security. A consumer LLM in the browser, an AI extension in the mail client, a plugin stack on a personal account that reads company documents. No request, no contract, no logging, no data classification. It is not an incident, it is a pattern. And most CIOs underestimate how deep it already runs in the organisation.

Why employees work around governance

It is tempting to frame shadow AI as an enforcement problem. A user who breaks the rules, a department that opts out of policy. In practice I see something else. Shadow AI almost always emerges where the formal route is too slow, too limited or too unclear. The lawyer who wants to summarise a contract. The marketer who wants a first draft. The analyst who wants to explore a dataset. They ask nothing of IT because they already know the answer, or think they do: that takes weeks, it will probably be refused, I will sort it out myself.

That is not a discipline problem. It is a symptom of a missing sanctioned route. When the official path is slower than the shadow path, the organisation chooses the shadow path. Not out of ill will, but under productivity pressure. A ban placed on top of that same situation only pushes the behaviour further out of view. Browser tools and consumer accounts leave no traces in the usual IT monitoring. The work happens on personal devices, in private tabs, with private mail as the hub. You see the output appear in a Teams message or a document, but the route to it stays invisible.

The second consequence of a ban is legally uncomfortable. Under the EU AI Act (Regulation (EU) 2024/1689) your organisation is responsible for the AI use in its processes, even where that use was not sanctioned by you. The Dutch Data Protection Authority has made clear on several occasions that entering personal data into a consumer LLM is regarded as a transfer, with all the GDPR obligations that entails. A paper ban that is ignored in practice is no defence. It is an aggravating circumstance.

Why banning does not work

Three reasons the ban model fails structurally. One: enforcement requires visibility, and it is precisely that visibility which is missing. A DNS block of known AI domains catches the big names, but the market grows faster than your blocklist. Two: the ban does not address the cause. As long as the need for AI support is real and the official route is absent, the behaviour continues. Three: it damages the trust between security and the business. A team handed a ban on something that demonstrably helps it get work done starts to see security as an obstacle rather than a partner. That is a position you do not easily climb back out of.

The NIST AI Risk Management Framework puts it sharply: you manage AI risk by building governance around use, not by holding use back. The premise is that AI tooling becomes part of the organisation, with the same discipline you apply to other data-processing systems. Who may use what, on which data, with which logging, with which escalation route when in doubt. The UK NCSC set out the same principle in its guidelines for secure AI system development in a different way: secure by design means the safe route is also the easy route.

Which governance layer does work

The governance layer that works in organisations consists of five parts. In this order, because each part builds on the previous one.

An acceptable-use policy with categories, not product names. Not "tool X is banned, tool Y is allowed", but a classification by use type. Which data may go into which type of AI system. Public information in a consumer LLM is a different matter from client data in a sanctioned enterprise environment. Categories hold up; product names are out of date within a quarter.

An AI gateway or proxy as the technical implementation of that policy. A single control point through which AI traffic runs, with logging at prompt and response level, with data-loss prevention for sensitive patterns, with version control on models. This is not a filter that blocks everything, this is the sanctioned route. It has to be faster and more usable than the shadow route, otherwise the problem repeats itself.

Data classification as a precondition, not an afterthought. An AI gateway without clear labels on data is a log file without meaning. Which documents are public, which internal, which confidential, which regulated. Without that layer the gateway cannot distinguish between what is allowed and what is not.

An AI asset register that records every system in use. Not only the sanctioned tools, but also what you find through discovery. A register that grows and whose items have an owner, a purpose, a data category and a risk classification. The EU AI Act requires this type of registration for high-risk systems, but as an operational instrument it has broader use.

AI Act compliance as an ongoing process. The regulation phases in obligations through to 2027 and beyond. Prohibited practices have applied since February 2025, transparency obligations for general-purpose AI since August 2025, conformity obligations for high-risk systems follow after that. This is not a project with an end date, this is an operational discipline that has to land in your governance.

The order matters. A gateway without policy is a technical thing without a decision-making framework. Policy without a gateway is paper. Policy and gateway without data classification leave decisions to individual users. And without an asset register you do not know what you are managing.

How to bring it into view

The first practical step is not technology, but a conversation. With the departments that shout loudest for AI acceleration, and with the departments where you suspect it is already happening. Not as an audit, but as an exploration. What work do they want to do faster, which tools have they tried, where did they get stuck. This produces a more honest picture within two weeks than a network scan does, and it builds the mandate for the governance layer that comes afterwards.

Then comes the discovery layer. Logging of egress traffic to known AI API endpoints, a browser inventory of extensions that contain LLM functionality, a check on SaaS tools that have activated AI features without this falling within the original contract scope. Many organisations discover in this phase that their existing SaaS stack already has AI functionality on board that they have not explicitly approved. That is also shadow AI, only baked in.

Only after that come the gateway and the policy. Not the other way around. A policy drawn up without knowing the reality misses its connection to the work that is already happening. And a gateway rolled out without policy gets bypassed by users the moment it gets in the way.

What this means for you as CIO

You hold three roles at once. You are responsible for the AI use in your organisation under the AI Act and the GDPR, including the use you do not see. You are responsible for the productivity AI can deliver, and its absence is a cost as well. And you are responsible for the trust between security and the business, which turns fragile the moment the governance layer is experienced as a brake.

Those three roles call for one answer: a sanctioned route that is faster than the shadow route. Policy in categories, a gateway as implementation, data classification as the foundation, an asset register as a factual overview, AI Act compliance as an ongoing discipline. Not as a project, but as an operational cadence. Only then does shadow AI disappear, not because it is banned, but because the official route has become more usable.

The work your employees want to do with AI carries on, with or without your approval. The only question is whether it happens inside your view or outside it.