What shadow AI actually is, and why it's showing up in every company right now

Shadow AI is employees using AI tools their company never approved, vetted, or in most cases even knows about, to get real work done with real company data. It's not a hypothetical. According to Microsoft and LinkedIn's 2024 Work Trend Index, 78% of AI users at work bring their own AI tools rather than using anything IT issued. That's not a fringe behavior. That's the default.

The pattern is consistent across the companies we work with. A claims adjuster pastes a redacted-but-not-really-redacted case file into ChatGPT to summarize it faster. A finance analyst runs a vendor contract through Claude to check terms because the legal review queue is three weeks deep. Nobody asked permission because there was nothing to ask permission for: no sanctioned tool existed that solved their actual problem. IBM defines shadow AI as AI systems used inside an organization without IT's knowledge or governance, and that definition is accurate, but it undersells the mechanism. This isn't rebellion. It's people filling a gap the company left open.

The search volume backs up how fast this has become a boardroom topic rather than an IT footnote. "Shadow AI" queries are up sharply year over year, and the people searching for it aren't developers looking for a framework. They're the same COOs, compliance officers, and heads of operations who now have to explain to a board or an auditor why nobody can say where the company's client data actually went.

What shadow AI actually risks in a regulated business

The real cost of shadow AI isn't the subscription fee nobody approved. It's data you can no longer account for, compliance exposure you can't defend in an audit, and a total absence of the audit trail regulators now expect. Once client data, health records, or financial statements go into a personal ChatGPT account, you have no idea what that provider retained, what it trained on, or where it lives. For a firm subject to HIPAA, SOC 2, or a state AI law, that's not a theoretical risk. It's the exact gap an examiner will find first.

Palo Alto Networks' framing of shadow AI risk covers data leakage and unmanaged model access well, and it's worth reading if you want the full taxonomy. But most of that content stops at "this is risky," without connecting it to what a regulator or plaintiff's attorney will actually ask for: a record of what data went where, and under what authority. If your only answer is "we don't know, employees were using their own accounts," that's a governance failure, not a technology one.

State-level AI law is closing this gap fast. Colorado's AI Act, for one, puts new obligations on companies deploying "high-risk" AI systems, and shadow AI use inside your company counts even if you never bought or built anything (our breakdown of what Colorado's AI Act actually requires covers the compliance mechanics). If your team is unknowingly running consequential decisions through consumer AI tools with no documentation, you're exposed the moment a regulator asks who approved it. For the deeper technical picture of how models leak data and what to check for, our LLM security guide goes further than this post can.

Why detection and blocking tools don't actually fix the problem

Buying a scanner to detect shadow AI treats the symptom, not the cause, and the demand that created the problem doesn't go away when you block it. It just moves somewhere harder to see. Most of the top-ranking content on this topic right now comes from cybersecurity vendors (Splunk, Zscaler, Darktrace, Obsidian Security) selling exactly this kind of visibility tooling. Their advice is sound as far as it goes: inventory what's running, flag unsanctioned endpoints, alert on anomalous traffic. None of it is wrong.

But detection answers "where is this happening," not "why is this happening." If your finance team is pasting contracts into a personal AI account because contract review takes three weeks through the normal process, blocking that account doesn't fix the three-week bottleneck. It just means the same person now does it from their phone, on their own data plan, completely off any log you'll ever see. We've watched this pattern repeat: a company locks down corporate devices, and unapproved AI use simply migrates to unmanaged personal devices where there's no DLP tool watching at all. The underlying need was never addressed. The visibility just got worse.

This is the piece almost nobody selling detection tools will say out loud: shadow AI is evidence of unmet demand inside your own operation. You can't scan your way out of a need you haven't diagnosed.

The real cause: nobody diagnosed what people actually needed AI for

Shadow AI shows up wherever a company hasn't figured out, workflow by workflow, what its people are actually trying to do with AI and built or bought something that fits. That's a diagnosis gap, not a compliance gap, and it's the same gap that shows up in every failed AI rollout we've seen, whether the failure is "employees went rogue with ChatGPT" or "we bought an enterprise AI seat license nobody uses."

We saw a version of this dynamic play out with a utility client, C&G Energy Services, whose billing process was leaking over $1M a year in revenue before anyone touched a model. The fix, once we broke the workflow into pieces, turned out to be mostly process automation and system integration, not AI at all (full detail in the case study). The diagnosis mattered more than the model. Shadow AI has the same lesson buried in it: the fix your team actually needs might not be a chatbot subscription, it might be an integration nobody built, or a workflow tool nobody bought, or an internal system that just needs to be faster.

The practical version of this diagnosis, done in a week, not a quarter, looks like:

• Ask department heads directly what their teams already use ChatGPT, Claude, or Gemini for. You'll get specific, workflow-level answers if you ask specific questions instead of "are you using AI."

• Pull whatever visibility you already have, corporate card statements for AI subscriptions, network logs for AI domains, browser extension inventories, and cross-check against what people admit to.

• Name the two or three workflows where usage is heaviest. In our experience it's almost always document summarization, drafting (emails, contracts, reports), or some form of research and lookup.

• For each of those workflows, decide: sanction an existing tool with proper controls, buy a purpose-built product, or build something narrow that fits the actual workflow. This is the build-vs-buy decision most companies skip entirely (our guide to buying versus building AI walks through how to make that call without guessing).

How to build a governance response that doesn't kill productivity

A governance response that works starts by classifying what people are already doing, not by banning tools outright, because banning tools without replacing the workflow just pushes usage further out of sight. The goal is to bring the behavior into the light and give it a sanctioned path, not to eliminate the behavior.

Ground the policy in something a regulator or auditor will recognize. The NIST AI Risk Management Framework is the closest thing the US has to a standard reference, and it's useful precisely because it's about mapping risk to specific use cases rather than issuing a blanket rule. Structure your policy the same way:

• Classify data sensitivity per workflow (public, internal, client-confidential, regulated) rather than applying one rule to every use of AI.

• Name which tools are sanctioned for which classification, and route the ones that touch regulated or client data to an approved, contracted, or self-hosted option instead of a consumer login.

• Put the policy in writing, with examples specific to your business, not a generic acceptable-use template. "Don't paste client PHI into any AI tool that isn't X" is enforceable. "Use AI responsibly" is not.

• Set up lightweight logging for sanctioned tools so you have the audit trail you didn't have before. This is the piece detection vendors get right, just applied to tools you actually chose.

Once you've replaced a shadow workflow with a sanctioned agent or system, the governance question shifts from "how do we stop this" to "how do we control what we built," which is a different and more mature problem to have. Our framework for governing enterprise AI agents covers what to control once you're past this stage: access, approval thresholds, and audit logging for systems you own.

When self-hosting is the right call: regulated data and shadow AI

For genuinely regulated data, health records, legal case files, financial account details, the fix isn't to trust a public LLM vendor's privacy terms and hope for the best, and it isn't to ban AI outright either. It's to run a sanctioned model on your own infrastructure with zero data retention, so the workflow people actually need gets solved without a single byte leaving your control.

This is the option almost none of the current shadow AI content mentions, because the companies writing it sell detection software, not AI systems. But it's the most direct fix for the regulated-data version of the problem. We built exactly this for a medical-legal operations firm, Preferred Med Network, automating document intake, case assignment, and appointment management end to end on infrastructure they control, saving roughly $300K a year while keeping every piece of client data inside their own environment (details in the case study). Nobody there needed to paste a case file into ChatGPT, because the sanctioned system was faster than the workaround.

That's the actual test of whether governance is working: is the sanctioned path faster and easier than the shadow one. If it isn't, people will keep going around it no matter what the policy says.

What a realistic 90-day shadow AI response looks like

You don't need a year-long transformation program to get ahead of this. A workable sequence runs in three phases.

Days 1 to 30: audit. Interview department heads, pull whatever logs and expense data you have, and name the top three to five workflows where unapproved AI use is concentrated. Don't try to inventory everything; the long tail almost never matters as much as the two or three high-frequency workflows.

Days 31 to 60: policy and pilot. Write the classification-based policy described above, get it signed off by legal and compliance, and pick the single highest-volume workflow to replace with a sanctioned tool, whether that's an approved enterprise AI seat, a narrow internal build, or a self-hosted model for anything touching regulated data. Ship the pilot to the team that was already doing this workaround the most.

Days 61 to 90: measure and expand. Track actual adoption of the sanctioned replacement against continued shadow use (exit surveys, spot checks, or renewed log review). If adoption is low, the replacement doesn't fit the workflow yet, go back and fix that before rolling out to the next department. Governance that isn't adopted isn't governance, it's a document nobody reads.

If you're working through this decision, this is exactly what our Discovery phase maps out before we build anything, and we're happy to compare notes. For a broader view of what a diagnosed, owned AI strategy looks like across an organization, our enterprise AI page covers the full scope.

Frequently asked questions

Is using ChatGPT at work considered shadow AI?

Yes, if IT and compliance haven't reviewed and approved it for the data being used. A free or personal ChatGPT, Claude, or Gemini account counts as shadow AI the moment company or client data goes into it without a contract, data retention terms, or an audit trail behind that use. The tool itself isn't the issue; the lack of sanctioning and oversight is.

What are the biggest risks of shadow AI for a regulated business?

Data leakage into a vendor's systems with unknown retention terms, compliance exposure under HIPAA, SOC 2, or state AI laws like Colorado's, and the absence of any audit trail showing what data went where. For regulated industries, the third risk is often the most damaging in practice: you can't defend a decision to an examiner if you can't show how it was made.

How do you stop employees from using unapproved AI tools without banning AI outright?

Replace the workaround with a sanctioned tool that's faster than the shadow version, not a policy that just says no. Audit what workflows people are already solving with consumer AI, classify the data involved, and build or buy an approved path for each. Banning access without a replacement just pushes the same behavior onto personal devices you can't see at all.

What's a real example of shadow AI causing a data or compliance problem?

The common pattern we see is an employee pasting a contract, case file, or financial statement into a personal AI account to save time on a slow internal process. There's no vendor agreement covering how that data is stored, no logging of the exchange, and no way to prove to a regulator or client what happened to that information afterward.

What's the difference between an AI governance policy and blocking shadow AI tools?

Blocking tools restricts access; governance decides, workflow by workflow, what data can go where and under what controls. A governance policy grounded in a framework like NIST's AI RMF gives people an approved path for the work they're already doing, while blocking alone just removes the path and leaves the underlying need unaddressed.