A COO is reviewing expense reports. Buried in the line items: a handful of AI tool subscriptions that didn't go through IT, legal, or procurement. She doesn't know who approved them, what data those tools are touching, or whether the workflows built around them are recoverable if the subscriptions lapse.
A week later, a regional sales director demos a workflow for the leadership team. It synthesizes competitor intelligence, drafts follow-up emails, and flags deals at risk of slipping. It's impressive. Nobody in IT or risk knew it existed.
Neither of these is unusual in 2026. They are not edge cases.
The uncomfortable question isn't only whether the tools are approved. It's whether the company can answer for them. If a customer, employee, auditor, or board member asks whether AI touched sensitive data, who used it, for what workflow, and under whose authority, many organizations would not have a defensible answer.
The instinct for most leaders is to respond with a policy: define what is approved, prohibit what is not, and remind everyone that company data has to stay inside sanctioned systems. The policy may be necessary. But it arrives after the fact, and it doesn't tell the leader what is already operating inside the business today.
The Rogue-Employee Frame Is the Wrong Frame
When teams route around official AI approvals, they are usually doing it because the work is real, the official path is slow or absent, and they have found tools that help. The behavior is a signal. It tells the organization that demand for AI-enabled ways to work has outpaced its ability to create a safe approved route.
This is what shadow AI and shadow IT share: both are evidence of organizational friction, not primarily evidence of employee misconduct. The individual who adopted an unsanctioned tool may be the person doing the most productive work on the team.
Shadow AI spreading at scale was predictable once bring-your-own-AI behavior became visible. In Microsoft and LinkedIn's 2024 Work Trend Index, 78% of knowledge workers who used AI at work reported bringing their own AI tools with them. The survey found this practice was slightly more common at small and medium-sized companies than the global average. Bring-your-own-AI was already normalized before most organizations had developed formal governance structures for it.
Treating that pattern as a discipline problem misses the management gap underneath it. The organization has decentralized execution without centralized visibility. People are moving because the business needs movement. Leadership still needs to know where that movement is happening, what data is involved, and who owns the decision.
Why This Is Harder Than Shadow IT
Shadow IT introduced tools outside the official procurement cycle: a project management application, a cloud storage service, a CRM integration. The data risk was largely about where information was stored and who could access it.
Generative AI tools change the risk profile. They don't just store or route data. They read it, interpret it, transform it into outputs, and, depending on vendor terms, retention settings, and model-training configuration, may learn from it. A team using an unsanctioned AI tool to summarize board materials, draft proposals, analyze contract terms, or review financial performance may have moved the substance of that work into a system the organization didn't evaluate, didn't contract, and doesn't govern.
That matters because the executive question changes. It isn't only, "Where is the file stored?" It's, "Can we say whether this material was retained, used for training, exposed through a vendor incident, or recoverable if we need it back?" If the organization can't answer that, it doesn't have control of the workflow.
According to CIO.com reporting on a BlackFog survey of 2,000 workers at companies with more than 500 employees, 33% admitted sharing enterprise research or datasets through unsanctioned AI tools. Twenty-seven percent admitted revealing employee data including salary or performance information. Twenty-three percent had input company financial information. Each category is a data boundary the business may not have intended to cross.
The second challenge specific to generative AI is workflow dependency. Once a team is generating outputs through an AI tool, they adjust their processes around it. They build habits, templates, and timelines that assume the tool is there. When a problem surfaces or when the business tries to shut down the tool, the disruption isn't only about the subscription. It's about the work built around it and the speed advantage that disappears if nothing replaces it.
That makes shadow AI a COO problem as much as a CIO problem. Blocking a tool can break a workflow. Leaving it unmanaged can create data, quality, ownership, and accountability risk. The hard work is not choosing between speed and control. It's making the approved path good enough that the organization doesn't have to choose.
The Cost of Not Knowing
The evidence doesn't need to be read as a universal benchmark to be useful. It is enough that multiple sources point in the same direction: unmanaged AI use is no longer fringe behavior, senior leaders are often aware of it, and the risk has a measurable cost dimension when things go wrong.
In the CIO.com / BlackFog survey, 49% of workers at companies with more than 500 employees admitted adopting AI tools without employer approval. That doesn't mean every company has the same rate of use. It means a mid-market leader should assume the official tool list is incomplete until proven otherwise.
The same reporting found that 69% of presidents and C-suite members and 66% of directors and senior VPs were reported as accepting or approving shadow AI adoption. That turns the issue from a frontline workaround into an executive operating problem. The same leadership team that wants governance may also be rewarding the speed that bypasses it, so the inventory has to work upward as well as downward.
IBM's 2025 Cost of a Data Breach Report adds the risk-cost dimension. IBM found that security incidents involving shadow AI appeared in 20% of the breached organizations studied. IBM also found that organizations with high levels of shadow AI experienced average breach costs USD 670,000 higher than organizations with low or no shadow AI. Those findings should not be treated as per-incident predictions. They should be treated as a warning that unmanaged AI exposure has moved from theoretical risk into measurable operating consequence.
IBM reported that 63% of the breached organizations in its study either lacked AI governance policies or were still developing them. That finding belongs next to the operating reality: the company can believe it is becoming governed while unmanaged use keeps spreading underneath the official plan.
This is the sequencing problem. Before the governance policy is useful, there needs to be an inventory.
Why Policy Alone Cannot Solve It
Policies have their place. They set expectations, create accountability, and give the organization a record when enforcement becomes necessary. A company without any AI policy is harder to defend than one with thoughtful guardrails.
But a policy memo can't tell you which tools are already in use, which workflows depend on them, what data has been shared through them, or which uses are genuinely dangerous versus genuinely productive. A policy delivered after shadow AI has already spread is a statement of intent about future behavior. It doesn't address what is operating today.
The practical problem for most mid-market operators isn't that they lack the right governance language. It's that they lack the inventory to write meaningful policy for. You can't govern what you can't see. Governance built on an incomplete picture of actual use applies to the tools IT knows about, not to the tools that are actually in use.
That is why policy has to follow discovery. The organization needs a named owner, a first-pass inventory, a decision record, and a cadence for review. Otherwise the policy becomes another document describing a version of the business that no longer exists.
The First Move Is an Inventory
A leader who wants to address shadow AI doesn't need a large governance program before starting. The first requirement is a workable picture of what is already happening.
That means answering a concrete set of questions.
Which AI tools are teams using today, regardless of whether those tools were formally approved? The list is almost certainly longer than the official procurement record. Expense reports, browser extension inventories, SaaS admin consoles, and direct conversations with department heads are more likely to surface accurate answers than asking whether employees have followed policy.
What data categories are those tools touching? Research and proposals are different from employee records. Client communications are different from financial summaries. Knowing which tools touch which data categories is the starting point for a rational response, and it is the question any customer, employee, or regulator would ask first.
Which workflows have built a dependency on unsanctioned AI tools? Casual individual use is different from a team workflow that assumes AI availability. A workflow dependency means the tool is now part of how work gets done. Addressing it without a replacement creates a process problem.
Which vendors have quietly added AI features to existing products? This is the most underappreciated category of shadow AI. A SaaS product the organization already uses and trusts may have activated AI capabilities that were not part of the original security evaluation. The tool may be sanctioned, while the AI behavior inside it is not. License renewals, vendor notices, SaaS admin settings, and default feature rollouts deserve a second look through this lens.
Who in leadership is aware of these uses? Senior executives are often not outside the pattern. They may be encouraging it because it produces speed. They may be approving reimbursement because the team is hitting its numbers. The inventory has to account for uses leaders are aware of and tolerating, not just uses operating below the waterline.
None of these questions require a year-long governance transformation to begin answering. They do require a named owner, not a committee that meets once a quarter. Governance is a person, not a committee. That owner might be a COO delegate, a CIO or security partner, a department head, or an accountable operations manager with enough judgment and authority to get honest answers. The title matters less than direct access to department heads, expense data, SaaS settings, and the decision record.
That last point matters. The real friction is often not finding the tools. It is getting honest answers from teams that fear a productive workaround will be taken away without a replacement. If the discovery process feels like a hunt for violations, the inventory will be incomplete. If it feels like a way to protect useful work while setting real boundaries, leaders will get better information.
Triage: Stop, Govern, Redirect, Approve
Once the inventory exists, the decision framework becomes practical.
Some uses should stop. If a team is pasting confidential personnel data or unpublished financial information into a public AI tool with no data retention controls, that use needs to end. The boundary should be explained clearly, not just prohibited. Understanding why it happened usually reveals an unmet workflow need that should be addressed through a different path.
Some uses need governance boundaries applied. Certain AI tools and workflows are not inherently unsafe but are operating without defined data boundaries, output review, or ownership. Adding those structures converts unmanaged use into governed use. This doesn't require a compliance transformation. It requires clarity on what data can enter the tool, who reviews outputs before they carry weight, and who is accountable when something goes wrong.
Some uses should be redirected to a sanctioned alternative. If a team is using a consumer AI tool because the organization's approved tools are harder to access, less capable for the specific task, or simply unknown to them, the problem is not the team. The problem is that the approved path failed to serve the actual need. Redirecting well means naming the approved alternative and making sure it genuinely works for the use case in question.
Some uses should be formally approved. Productive uses that are already operating, that are not touching sensitive data categories, and that are serving real business need may be best addressed by reviewing them, setting appropriate boundaries, and converting them into official workflow. Prohibition is not always the right response when the use is already delivering value and the risk is manageable.
The hardest part of this framework is not the categories themselves. It is applying them honestly, use by use, without defaulting to prohibition for everything or approval for everything. Stopping a productive team's workaround costs political capital. Funding a sanctioned alternative costs money. Asking a senior leader to stop rewarding speed without review costs credibility. That is why this is management work, not a technology cleanup.
The Approved Path Has to Win
There is a principle underneath all of this: if the approved path is slower than the workaround, the workaround becomes the operating model.
Shadow AI spreads not primarily because employees are careless or defiant. It spreads because people have real work to do, and AI tools help them do it. If the official route requires a six-week procurement process, a security review with no timeline, and tool access that needs management escalation, teams will route around it. They have always routed around bottlenecks. The difference now is that the alternatives are more capable and more attractive than any shadow IT workaround ever was.
This is the real governance challenge for operators. Getting the inventory done and completing the triage decisions is the visible work. The durable solution requires that the approved path actually be usable: accessible to the teams that need it, reasonably fast to activate, clear about what data is in bounds and what is not, and designed around the work people are actually doing.
That doesn't mean removing oversight. It means making the sanctioned option the easier option. A governance model that cannot compete with a free browser extension will not succeed as a governance model.
The Questions Worth Asking Before Drafting the Policy
If someone reviewed expense reports, browser extensions, and SaaS product settings this week, which AI tools would appear that are not on the official list?
Which department is most likely to be running an AI workflow that IT or risk does not know exists?
If a customer, employee, auditor, or board member asked today whether AI had touched sensitive data, could the business produce a credible answer?
Which AI tools currently in use could teams not easily work without?
Who owns the decision record for whether each use should stop, be governed, be redirected, or be approved?
These questions are more useful than the current AI policy document. They are also the starting point for a response that addresses the operating risk, rather than one that documents intent about a reality the organization has not yet seen clearly.
What This Means for Operators
The question for a leader today isn't whether shadow AI exists somewhere in the market. The question is whether the organization has a workable picture of its own AI use and a defensible plan for what to do about it.
That plan starts with an inventory, not a policy. It continues with honest triage across the stop / govern / redirect / approve framework. It requires a named owner and a review cadence. It ends with an approved path that is actually faster and more useful than the workaround it is replacing.
Leaders who wait for a complete AI governance architecture before starting the inventory will find that unmanaged use has grown around them in the meantime. The operating risk compounds with time, and so does the workflow dependency.
Before Writing Another AI Policy
The most useful next step isn't another governance document. It is the question that document is supposed to answer.
Where is AI already being used inside this company without a clear owner, an approved data boundary, or a review cadence?
The Shadow AI Discovery Checklist is a first-pass inventory tool for this exact conversation: the tools teams are using, the data those tools touch, which vendor products have AI features active, the workflows that have built dependencies, and the stop/govern/redirect/approve decision record needed to act on what the inventory finds.
Use it as the diagnostic. The next move is the operating-model conversation: who owns the uses, which boundaries apply, which workflows need to stop or move, and how to build an approved path teams will actually use.
Do that before the next policy draft. Do it before the next executive update. Do it before the next incident turns an unknown AI workflow into an urgent investigation.
A company doesn't need perfect AI governance before it starts. It needs a defensible answer to where AI is already working without ownership, data boundaries, or review. Every week that answer waits, the dependencies get deeper.