Kennisbank

How do you prevent a department from having its own subscription?

A marketing team needs a writing assistant. A financial analyst wants a tool that summarizes spreadsheets. None of them wait for a procurement process that takes months. There's a credit card, an email address, and within ten minutes there's a subscription that the department pays for itself, manages itself, and uses itself. The IT department knows nothing about it. There's no reason to report it, because nothing wrong has been done — a problem has simply been solved.

How it arises

Most shadow AI doesn't start with an attempt to circumvent rules. It starts with a task that needs to go faster, a deadline that doesn't wait for an approval process, and a tool that's accessible without anyone else's involvement. The department that subscribes to it doesn't see it as an IT decision. It feels like an office supply, no different from a software license everyone already used before there was a central procurement policy. The fact that a language model processes company data, reads customer information, or generates draft text that goes external isn't a governance question for the user. It's simply work.

The same dynamic plays out with a supplier that built AI into its product without a separate conversation ever taking place about it: the functionality appears in an update, no one signs off on it, and the organization uses it before anyone has established who is responsible for it.

Why it doesn't disappear on its own

An announcement that unauthorized tools are not permitted changes little. The department that has the subscription experiences it as a solution that works, not as a risk that needs to be reported. A ban without an alternative produces two outcomes: the subscription goes underground, or the team stops using it and the work slows down again. Neither is what an organization wants.

Add to that the fact that such a subscription is rarely a one-time decision. It becomes part of the workflow, linked to other tools, used in processes that have since become dependent on it. What begins as a trial becomes a fixed part of how the team works — exactly the pattern also visible with a pilot setup that was never switched off: no one decided to make it permanent, but no one decided to stop it either.

What punishing it doesn't achieve

The reflex to track down shadow AI and confront the user backfires. Anyone who knows that reporting leads to a reprimand doesn't report. The subscription keeps existing, just less visibly. The department becomes more cautious about what it reports, not more careful about what it uses.

What does work is asking questions without a sanction attached. A team that uses a tool to speed up a task usually has a reason for it that the organization wants to know: a process that's too slow, a task that's becoming overloaded, a need that the existing offering doesn't cover. See how this is described for employees who use a tool no one has approved — the point of engagement isn't the violation, but the need behind it.

What an organization can do about it

The first step isn't enforcement, but inventory: which tools exist, who uses them, for what task, and with what data. That doesn't happen through the IT list — that registers what has been approved, not what is being used. It happens by asking, in a way that carries no threat.

Once there's visibility into what's running, classification can follow: what role does the tool play, what risk level fits it, and what form of oversight is appropriate. Not every subscription a department has taken out itself constitutes a problem. A tool that rewrites public text falls into a different category than a tool that processes customer data without anyone knowing where that data goes. The distinction between those categories is exactly what human oversight in practice is about: not every use requires the same degree of control, but every use requires that its existence be known.

After that comes a governance structure that connects to what already exists — not a new process alongside the existing risk framework, but an extension of it. An organization that treats AI risk separately from the rest of its risk management runs the risk that the second system gets ignored, as described in a second process alongside the existing one that gets ignored. The approach that survives is the one that connects to what the organization is already doing to manage risk.

The question that remains

A subscription that a department has taken out itself is usually a signal that something needs to move faster than the current process allows. That question — which part of the work can be accelerated, and where that can happen in a structured way instead of unseen — is exactly what the work scan from FTE TO AI answers. The work scan calculates, per task, which portion of the work can be taken over by AI, so that the need that led to a shadow subscription gets a place within a process the organization does know and does manage.