TL;DR
- One kind of resistance is loud: the expert who does not trust the model. The other never shows up in a meeting at all, because the person who could not wait simply built something themselves.
- AI is the first enterprise technology where the gap between a sanctioned deployment and someone with a browser tab is essentially zero.
- A roadmap with five items in an organization with forty problems does not stop the other thirty-five. It just moves them out of sight.
- The hard part of fixing it is not tooling. It is sequencing, because you are paving the road while the cars are driving on it.
Last week we talked about why users resist AI. An underwriter who has spent 20 years eyeballing equipment across categories, spotting label problems, cross-referencing auction data against economic signals, all while copying data into a spreadsheet, will push back when you tell them a model can do it better. You will hear that pushback. It shows up in meetings. It slows rollouts. You can plan around it. That argument is set out in Users resist. But why?
The resistance you never hear
There is another kind of resistance that never shows up in a meeting. A product manager builds a forecasting app on a free-tier platform over a weekend. A finance analyst pipes quarterly data into a chatbot to generate board summaries. An ops lead connects an API to a scheduling tool nobody in IT has heard of. Everyone is using AI. The rollout metrics look great. But none of this is running on anything you sanctioned, secured, or can see.
The industry has started calling this "shadow AI."
Why this is not shadow IT
Companies have dealt with unsanctioned tools for decades. Someone installs Dropbox. Someone signs up for Slack before IT approves it. The blast radius of any one rogue tool was small and usually knowable.
AI changed a specific thing: the range of what one person can build unsupervised got dramatically wider. A vibe-coded attendance tracker is harmless. A vibe-coded tool that pulls inventory data through an unvetted API and feeds reorder recommendations to a regional manager is not. Both were built on a Saturday afternoon. Both look the same from the outside. You cannot tell which is which, because none of them are visible.
What we walked into
We are working with one of our partners right now on exactly this problem. When we came in, the org had not been reckless. They had a roadmap. They had prioritized use cases. The things on the roadmap were being done properly.
But the roadmap had five items on it. The org had forty problems. The people with the other thirty-five did not wait. They built solutions themselves. Dashboards, automations, small tools, each one solving something real. No shared data catalog underneath. No way to trace what data flows where. No deployment standards. No one person who could see the whole picture.
These were not rogue employees ignoring policy. These were capable people doing reasonable things in the absence of a better option. And this is the thing worth pausing on: AI is the first enterprise technology where the gap between a sanctioned deployment and someone with a browser tab is essentially zero. ERP did not do this. SaaS did not really do this. The barrier to building something that touches live business data and produces outputs people act on has collapsed. The roadmap was built for a world where that barrier still existed.
The gap the roadmap left open
The typical AI rollout scopes for the approved use cases and builds the infrastructure to support them. That is the right first step. The part that gets missed is what happens at the edges.
What we are building with this partner is the layer underneath: shared data foundations, lineage, visibility into what has been deployed and where. The hardest part, we found, was not the tooling. It was sequencing. You are trying to put a foundation under things people have already built and are actively using. You cannot take them offline. You cannot start clean. You are paving the road while the cars are driving on it. The same problem, seen from the codebase rather than the org chart, is The Brownfield Tax.
If your AI rollout only serves the roadmap, the rest of the org will serve itself. That has always been true of technology. What is new is how much they can build, how fast, and how far from your line of sight.
Two people telling you the same thing
Last week the underwriter pushed back because the AI had not earned his trust. This week the product manager did not push back at all. She went and built something on her own. The underwriter is telling you the tool is not ready. The product manager is telling you the process is not ready. Both are telling you something about the same rollout. One is loud about it. The other, you find out later.
Enjoy your Sunday!
Where Moative fits
Moative does this layer for mid-market operators: the shared data foundation, the lineage, and the visibility into what is already running before anything new is added on top. We start from what people have built rather than from the roadmap, because the roadmap is the part you can already see. In healthcare revenue cycle management the shadow layer is usually a set of spreadsheets that quietly decide how claims get worked, and they are load-bearing long before anyone documents them.
Frequently asked questions
What is shadow AI?
Shadow AI is any AI tool or workflow built and used inside a company without going through sanctioned review: a weekend forecasting app, a chatbot fed quarterly financials, an automation wired to an unvetted API. It differs from earlier shadow IT in how much one person can now build that touches live business data.
How is shadow AI different from shadow IT?
Scale of what a single person can produce. An unapproved file-sharing tool had a small and knowable blast radius. An unapproved tool that pulls live inventory data and generates reorder recommendations does not, and it takes about the same effort to build.
Why do employees build their own AI tools?
Usually because the roadmap does not reach their problem. A roadmap with five items in an organization with forty problems leaves thirty-five people to solve their own, and the barrier to doing so has fallen to roughly zero. It is capable people acting reasonably, not policy violation.
What are the risks of unsanctioned AI tools?
The specific risks are data flowing to places nobody can trace, outputs that people act on without anyone having checked the logic, and no deployment standard behind any of it. The compounding risk is invisibility: harmless tools and consequential ones look identical from the outside.
How do you govern AI tools employees have already built?
Not by switching them off. The workable order is to build the shared data foundation, lineage and deployment visibility underneath what already exists, then bring tools onto it one at a time. The difficulty is sequencing rather than tooling.
Should we expand our AI roadmap to cover more use cases?
Expanding the list helps less than it appears, because the list will always be shorter than the problem count. What closes the gap is infrastructure that makes self-built tools visible and safe, so the organization serving itself is not the same as the organization going dark.
