Shadow AI isn't a policy gap. It's an inventory gap.

The standard corporate response to AI risk is to write a policy. An acceptable-use document goes around, everyone clicks “acknowledged,” and leadership feels governed. Meanwhile, by most credible estimates, the majority of AI actually being used inside the company is running outside that policy entirely — in browser tabs, personal accounts, and half-built automations nobody registered.

That’s the trap. Shadow AI isn’t a policy gap. It’s an inventory gap. And you cannot govern what you cannot see.

Policy without inventory is theater

A policy is a rule applied to a known set of things. If you don’t know what AI systems exist in your organization, what data they touch, and who runs them, your policy applies to the slice you happen to know about — and the risk lives in the slice you don’t.

Picture the real surface area. An analyst pastes a customer list into a consumer chatbot to “clean it up.” A sales team wires an agent to the CRM through a no-code tool on someone’s personal key. An engineer stands up a RAG system over a folder of contracts to answer questions faster. None of these are malicious. All of them are invisible to whoever signed the AI policy. Each one is a data-exfiltration path or a compliance violation that no document is touching, because no document knows it’s there.

You haven’t deployed an agent in these cases — you’ve deployed an incident with a delay. The delay is just how long it takes for one of those invisible flows to touch the wrong data.

Why inventory is hard — and why it’s the whole job

If inventory were easy, this wouldn’t be a problem. It’s hard because AI usage doesn’t look like traditional software procurement. There’s no PO, no install, no server to find. It’s a browser session and an API key. The adoption is bottom-up and faster than any governance process built for quarterly software reviews.

So the first real governance work isn’t writing rules. It’s building visibility:

• Discover the systems. What AI tools, agents, and integrations are actually in use — sanctioned and not? This is process-discovery work applied to AI itself, and like all process discovery, the documented picture and the real one diverge sharply.
• Map the data access. For each system, what data can it reach? Not what it’s supposed to reach — what it can. The gap between intended and actual access is where the risk concentrates.
• Establish ownership. Every AI system needs a name attached to it. Unowned systems are how shadow AI happens in the first place.

This is unglamorous, and it’s the same move I make in every domain: make the thing legible before you try to control it. You can’t write a meaningful rule for a system you don’t know exists.

Containment is an architecture, not a memo

Once you can see the AI surface, containment becomes an engineering problem with real answers — not a document.

Scoped access over broad access. Most agents are handed far more reach than their job requires because broad access is easier to set up. Scope each system to the minimum data and actions it needs. A drafting assistant doesn’t need write access to production.

A governed access layer. Instead of every agent holding its own credentials to every system, route enterprise data access through a controlled layer. This is exactly what an internal MCP server is for: it gives AI agents governed, audited, permission-scoped access to enterprise data, so “what can the AI reach” becomes one enforced contract instead of dozens of scattered keys. I’ve built this layer; it’s the difference between agents that operate inside a fence and agents that operate on the honor system.

Kill switches and audit trails. Every agent that can act needs a way to be stopped and a record of what it did. If you can’t halt it and can’t reconstruct its actions, you don’t have an agent under management — you have an unbounded liability that happens to be useful today.

Notice none of this starts with the model. Governance, like everything else in this practice, is a process-and-integration problem. The model is the last and smallest part.

The operator read

The organizations that handle AI risk well in the next few years won’t be the ones with the strictest policies. Strict policies on an unknown surface are just confident ignorance. The winners will be the ones who treated governance as an inventory-and-architecture problem: see everything, scope everything, route access through a governed layer, and keep a kill switch on anything that acts.

Write the policy too — but write it second, after you can see what it’s governing. A rule you can’t enforce on a system you can’t see isn’t governance. It’s paperwork.

If you suspect there’s more AI running in your organization than anyone has an inventory of, there almost certainly is. Tell me what’s broken and we’ll start by making it visible.