Enable, don’t police: how to actually reduce shadow AI

Shadow AI is what you get when the official path is slower than the work. Someone pastes a customer list into a tool the company has never reviewed, because the approved route is a ticket and the quarter is already moving. The instinct to shut that down is understandable. The list might be sensitive. The tool might keep a copy. The output might walk into a board pack with no one able to say where it came from.

Policing it anyway tends to fail. The work does not stop. It moves to a personal account, a phone, a tab that does not show up in the review. You lose the log, the data boundary, and the chance to make the useful part repeatable. A ban that people route around is not a control. It is a story you tell yourself.

The alternative is to enable people inside a path you are willing to stand behind. That sounds softer than it is. It means the capabilities that touch company data are approved once, by the people who own the risk, and then made available to the people who have the problem. IT sets the agenda: which systems may be reached, which data is in bounds, what “good” has to look like before anyone else relies on it. The business builds: the report, the chase, the handoff, the small app that removes a Tuesday afternoon of copying.

Those two jobs are easy to blur, and the blur is how the queue returns. If IT also has to design every workflow, the path is slow again and people leave it. If the business also gets to open new doors into systems, the path is not a path. Agenda and building are different skills. Keep them distinct and the official route can be both governed and fast enough to prefer.

Approve the capability once. A connection to the warehouse, a model you trust, an identity check, a place to put the code. Reviewed once, with the questions a security and data owner actually ask. After that, a team should not need a fresh project to use the same connection for the next workflow. Re-approving the plumbing every time is how the official path becomes the slow path, and how shadow tools win.

“Once” does not mean “forever, unattended.” It means the review is attached to the capability, and it is repeated when the capability changes, not when a new form needs the same read. A new column, a new system, a wider audience: those are reasons to look again. A second team with the same need is not. If every second team restarts the review, you have built a toll booth and labeled it governance.

Give the work a lifecycle that matches how trust actually grows. Draft, while it is still one person’s experiment and the output is not allowed to leave their desk. Shared, when a team is using it and a named owner is accountable for what it does. Certified, when the data, the access, and the behavior have been reviewed and other teams are invited to depend on it. The labels are plain on purpose. People already know the difference between a sketch, a team tool, and something finance will quote. The system should use the same words.

The lifecycle is also how you talk to someone who already has a shadow habit. You do not start by confiscating the tab. You start by offering a draft that can do the same task on data they are allowed to use, with a human still checking the output. Most people are not trying to sneak. They are trying to finish. A draft they can show their manager is a better offer than a warning.

What IT stops doing, in this model, is sitting in the middle of every request as a gate that opens one ticket at a time. What IT keeps doing is harder and more useful: deciding which capabilities exist, watching how they are used, and pulling back anything that should not have been shared. The business stops waiting for a slot on a roadmap before it can fix a process it already understands.

Watching is part of the job, and it should be visible. Who ran it, which source it read, whether the output was shared or stayed a draft. A team that can see that does not need to assume the worst, and a team that cannot see it will eventually swing back to policing. The log is what lets enabling stay a control instead of a hope.

This fits a mid-size company and a large one for different reasons. In a mid-size company the queue is the whole department, and a single blocked analyst becomes a personal account by Friday. In a larger company the same pattern shows up inside a business unit that cannot wait for a central team. Either way, the failure mode is identical. Demand is real. The governed path is slower than the workaround. Enable the path, and the workaround has less to offer.

None of this excuses careless use of customer data. Enabling means the easy way is the safe way, not that every experiment is production. A draft that reads a certified source, runs as the user, and cannot be shared until someone reviews it, is a better control than a policy document and a shadow account.

Measure whether people are building on the path you provided. Count drafts that became shared, and shared work that earned certification, and requests that never had to leave the building to get done. If those numbers stay flat while the work keeps growing, the path is still too slow. Fix the path. The policing will not save you.