The AI Governance Gap

Building got cheap. Governing didn't. That's the whole problem.

AI collapsed the cost of building software to near zero. The cost of governing it didn't change. That gap is where the next generation of enterprise risk lives, and almost nobody is watching it.

Two years ago, if a finance analyst wanted a tool to reconcile payroll data across three systems, they submitted a request to IT, waited six weeks, and maybe got it. Today that same analyst opens Claude, describes the problem in plain English, and has a working Python script in 20 minutes. No ticket. No review. No one in IT knows it exists.

Now multiply that by every knowledge worker in your organization. That's not a hypothetical I'm constructing for rhetorical effect. I manage infrastructure across 100+ enterprise tenants. I'm watching it happen in real time.

Everyone Is a Builder Now

The shift happened faster than any governance model could track. When building software required writing code from scratch, the barrier to entry was the skill itself. Companies had natural containment — only developers built things, and developers worked inside structures with code review, testing, and deployment pipelines.

AI removed that barrier. Not gradually. Overnight.

The result is shadow AI at a scale that makes traditional shadow IT look trivial. Shadow IT was someone installing Dropbox or spinning up an unsanctioned AWS account. Shadow AI is someone building a customer data pipeline, an automated reporting system, or a script that modifies production infrastructure — and they genuinely believe they've done a good job because the code compiles and the output looks right.

I've watched this pattern play out across environments of every size. Someone builds a personal script. It works. A teammate asks for it. Then the department adopts it. Then it's load-bearing and nobody planned for that. The tool that started as a 20-minute experiment is now processing client data on a schedule, and the person who built it left six months ago.

The people doing this aren't rogue employees. They're trying to do their jobs faster with the tools available to them. The ones who use unsanctioned AI tools aren't careless — they've decided the productivity gain is worth the risk, and they're probably right about the productivity part. The part they can't evaluate is everything else.

The Framework Blind Spot

I spent time with every major AI governance framework. NIST AI Risk Management Framework. The EU AI Act. Microsoft's Responsible AI Standard. ISO/IEC 42001. OWASP AI Exchange. They all do the same thing: they govern the AI system — the model, the agent, the product. Bias, fairness, transparency, safety. Important work, and none of it addresses the problem I'm describing.

When a marketing manager uses Copilot to build a customer segmentation tool, that's not an AI system — it's an application. When an operations engineer builds an Azure compliance audit with AI assistance, that's an internal tool touching production environments. When a finance analyst writes a script that pulls data from three systems and emails a report every morning, that's automation with a blast radius.

None of these fit in existing frameworks because the frameworks assume professional engineering teams building formal AI products. They govern the hammer. Nobody is governing the houses being built with it.

OWASP came closest. In 2025 they created a vulnerability category called "Inappropriate Trust in AI Generated Code ('Vibe Coding')." But that's a vulnerability taxonomy, not a governance model. It tells you what can go wrong. It doesn't tell you who's responsible, what review is required, or when a personal script has quietly become a line-of-business application that 40 people depend on.

The governance models we have were built for a world where only engineers shipped software. That world ended.

The Risks That Keep Me Up at Night

Most executives hear "AI risk" and think about bias in hiring algorithms or hallucinated legal citations. Those are real. But the risk profile of AI-assisted building is different and, in many ways, harder to detect.

Data exfiltration through context. When an AI agent reads your file system to help you write code, it sends that content to an external API. That's not a vulnerability — it's literally how the tool works. Every file the agent reads becomes part of a request to a third-party server. Your DLP tools aren't flagging it because it looks like normal API traffic. It is normal API traffic. The data is leaving anyway.

Cost unpredictability. Give 50 people API access without spend controls and one bad weekend costs more than the annual AI budget. A single runaway agent loop can burn thousands of dollars before anyone notices. I've set hard spend limits on my own usage specifically because I've seen how fast token costs compound when an agent gets stuck in a retry loop.

CLI identity inheritance. This is the one that keeps me awake. When you give an AI agent command-line access, you're not giving it a code editor — you're giving it your identity. Every active session, cached credential, and logged-in service. If you're authenticated to Azure, the agent can spin up resources, delete resource groups, read Key Vault secrets — anything your RBAC allows. Most engineers are over-permissioned for convenience, which means the agent's blast radius extends well beyond the task at hand.

This is fundamentally different from traditional software risk. A badly written script does what you coded it to do. An agent with CLI access does what it decides to do based on a prompt, and the decision space is unbounded. File system sandboxing doesn't help when the agent can run az, kubectl, aws, ssh, or curl.

I spend $200 a month on Claude Code. I've built 11+ applications with it. I run it with my own credentials on my own infrastructure. I know exactly what it can reach — and that knowledge is what makes me cautious, not comfortable. Most people giving agents CLI access haven't done that inventory.

The Economics of Doing Nothing

The executive question is always the same: what does this cost and what does it save?

Here's the cost of doing nothing. Your organization already has employees building AI-assisted tools. Some percentage of those tools handle sensitive data. Some percentage have security vulnerabilities their creators can't identify. Some percentage have become load-bearing — people depend on them daily — and nobody planned for what happens when the creator leaves, the API changes, or the model behaves differently after an update.

The slow bleed is worse than the headline breach number. It's the tools nobody maintains that everybody depends on. It's the redundant builds — three departments each built their own AI-powered reporting tool because none of them knew the others existed. It's the API spend nobody tracks because it's spread across 50 personal accounts. It's the institutional knowledge locked in prompts and agent configurations that walk out the door when someone quits.

The cost of governance is not zero. But the cost of ungoverned AI-assisted building compounds monthly, and the longer you wait, the more load-bearing the ungoverned tools become and the harder they are to bring under management.

What Governance Actually Looks Like

I'm not going to pretend I can deliver a complete framework in a single article. But I know what the shape of it looks like, because I operate on both sides — the infrastructure engineer who finds the bugs and the AI-assisted builder who writes the code.

The core principle is that overhead should scale with blast radius. A personal script that only you use needs different governance than a tool your whole department depends on. The problem is recognizing when something has crossed that line, because nothing starts as a line-of-business application. Everything starts small and drifts.

Governance that works will need at minimum:

• Tiered oversight that matches the review burden to the actual risk — not the same approval process for a personal calculator and a customer data pipeline
• Escalation triggers that catch when a tool has outgrown its tier, because tier drift is the default, not the exception
• A bridge between domain expertise and engineering discipline — the subject matter expert has the knowledge to make AI output correct, but may not have the skills to make it production-grade
• Visibility — you can't govern what you can't see, and right now most organizations have zero inventory of what's being built with AI

The companies that figure this out will move faster than their competitors. They'll empower their people to build with AI while catching the things that need engineering review before they become load-bearing. The companies that don't will keep discovering ungoverned tools the hard way — in breach reports, in compliance audits, in the moment when something critical breaks and nobody knows who built it or how it works.

The tools are not the problem. The absence of a plan is.