We’ve spent the last several months talking to CISOs, VPs of Engineering, and Chief AI Officers at enterprises across financial services, healthcare, and technology. Every one of them is thinking about AI governance. Almost none of them are thinking about the same problem.
The VP of Engineering wants to know why AI spend doubled last quarter and which teams are burning budget on frontier models for tasks that don’t need them. The CISO wants to know what data is leaving the organization through AI tools and whether autonomous agents have more access than they should. The Chief AI Officer wants model documentation, bias assessments, and a paper trail that satisfies the audit committee.
They’re all describing AI governance. They’re describing three completely different problems.
That conflation — by vendors, by analysts, by the press — is making it harder for enterprises to buy the right things, allocate budget correctly, and understand what’s actually urgent. This post is an attempt to draw the map.
The Three Problems Hidden Under One Label
Here’s the framework we use when we talk to customers. Three distinct governance problems, three different buyers, three different urgency levels:
| Problem | What it governs | Primary buyer | Urgency |
|---|---|---|---|
| Model Governance | AI models — bias, fairness, explainability, regulatory classification | Chief AI Officer, Risk & Compliance | Long-term (regulatory) |
| User & Developer Governance | People using AI tools — shadow AI, acceptable use, spend visibility | CISO, IT | Near-term (procurement) |
| Agent Runtime Governance | Autonomous agents acting in production — tool calls, data access, decisions | VP Engineering, CISO | Immediate (production risk) |
Model Governance
Model governance is the oldest of the three problems. It asks whether the AI models an organization has built or procured are behaving as intended — are they fair, are they explainable, do they carry the right documentation for regulatory scrutiny.
The EU AI Act is the primary urgency driver here. It classifies AI systems by risk level and imposes specific documentation, oversight, and accountability requirements on high-risk applications — hiring algorithms, credit scoring, medical diagnostics. Organizations building or deploying those systems need a way to assess, document, and demonstrate compliance.
This is fundamentally a compliance and documentation problem. The tools in this space offer model cards, bias detection frameworks, audit trails for model development decisions, and regulatory alignment tools. The buyers are Chief AI Officers, model risk teams, and compliance functions. The sales cycles are long.
What model governance doesn’t do: it tells you whether a model should be deployed. It says nothing about what that model does once it is.
User and Developer Governance
The second problem emerged as AI tools proliferated faster than enterprise procurement could respond. Developers started using GitHub Copilot, Claude Code, Cursor, and a dozen other tools — sometimes with approval, often without. Sensitive code went to external AI services. Customer data went to models with unclear retention policies. Budget appeared on corporate cards with no attribution, no approval, no policy framework.
This is a shadow AI and acceptable use problem. The buyers are CISOs and IT leaders. The tools in this space focus on detecting unsanctioned AI usage at the network or identity layer, enforcing acceptable use policies, and building visibility into which tools employees are using.
The core technical approach is detection and access control — you identify what AI services people are accessing, block what isn’t approved, and create a registry of sanctioned applications.
What user and developer governance doesn’t do: it covers humans using AI tools. It does not govern autonomous agents that are running inside your approved infrastructure, using approved credentials, calling approved services — and still doing things you didn’t intend.
Agent Runtime Governance
This is the newest problem and, for most enterprises moving AI into production, the most urgent.
When an organization moves from AI tools to AI agents — from humans using AI to AI acting autonomously — the governance problem changes in kind, not just degree. An agent isn’t a tool a developer picks up and puts down. It’s a system that makes decisions, calls external services, reads and writes data, chains actions across multiple systems, and runs continuously, often without a human in the loop.
Think about what an autonomous agent might do in a single session: retrieve customer records, call an external API with that data, write results back to a production system, trigger a downstream workflow, and escalate its own access when it hits a permission boundary. Each of those steps is a governance decision point. Who authorized this agent to access that database? Which external calls is it allowed to make? What stops it from doing something it wasn’t designed to do?
This is what we mean by agent blast radius — the scope of potential impact from an autonomous agent operating with overpermissioned or ungoverned access. A misconfigured human user creates a bounded problem. A misconfigured agent can traverse systems, chain actions, and create compounding failures in seconds. The blast radius isn’t linear. It’s exponential.
Agent runtime governance requires controls that sit in the execution path — something that evaluates what an agent is trying to do at the moment it tries to do it, before the action executes. Not a dashboard. Not a post-hoc log. Something in the critical path that can allow, deny, or hold for human review.
That infrastructure barely exists yet. This is the least represented problem in the vendor landscape — and the fastest-growing source of production risk.
Why This Matters for Buying Decisions
The conflation of these three problems has real consequences for how enterprises spend money and time.
A CISO evaluating “AI governance vendors” ends up comparing model risk documentation platforms against shadow AI detection tools against agent enforcement systems — without a framework for understanding why they’re different problems or which is most urgent for where their organization actually is.
Budget gets allocated to the wrong layer. A model governance platform doesn’t protect you when an agent starts calling production APIs it shouldn’t. A shadow AI detection tool doesn’t help when the agent is running inside your approved infrastructure with approved credentials.
And the most urgent problem for enterprises that are already deploying agents — runtime governance — gets the least attention, because it’s the newest and most technically demanding.
The right questions to ask before any AI governance purchase:
Where is your most immediate exposure? If agents are already running in production or staging, agent runtime governance is urgent now. If regulatory compliance for models you’ve built is the presenting problem, model governance comes first. If ungoverned developer tool usage and spend visibility is the gap, start with user and developer governance.
Which of the three problems does this vendor actually solve? Push past the platform narrative. Ask for a specific demo of the capability that addresses your problem. Most vendors have genuine depth in one area and surface-level coverage of the others.
Who owns each problem inside your organization? The three-problem framework at least gives different teams — engineering, security, compliance — a clearer sense of which layer they’re accountable for and which vendor conversations belong to them.
In the next post, we’ll look at how the cloud security market navigated an almost identical fragmentation problem a decade ago — and how it resolved. The pattern tells you a lot about where the AI governance market is headed, which layer becomes the acquisition magnet, and how to position your organization ahead of the consolidation that’s already beginning.
Next in the series: The Cloud Security Playbook for AI Governance
