Governance isn’t one thing

The word “AI governance” gets used to mean very different things depending on who’s saying it. HR uses it to mean acceptable-use policy. Security uses it to mean data controls and vendor risk. Legal uses it to mean liability and compliance. IT uses it to mean access management and audit trails.

A useful way to separate them: policy answers what the organization is allowed to do; risk answers what could go wrong; control answers how you enforce both. And sitting beside all three is a fourth layer that’s often missing entirely — value measurement, which answers whether any of the AI investment is producing a return worth the cost and the risk.

The vendor fragmentation problem

Anthropic, OpenAI, Microsoft, and Google have all built meaningful enterprise controls into their AI services. They’re real, and they work within the scope of each product. The problem is that each vendor’s control plane covers only that vendor. Which means the security team’s actual job is: log into the Claude admin console, log into the OpenAI admin console, log into the Microsoft admin console, and somehow produce a unified picture of what the organization’s AI usage actually looks like.

Per-vendor governance is the AI equivalent of managing your AWS, Azure, and GCP bills in three separate consoles and wondering why you can’t see your total cloud spend. The problem isn’t that each console is bad. It’s that you need a layer above them.

What a real governance layer looks like

The right mental model isn’t to replace vendor controls with something centralized — it’s to sit a governance layer above them. Each vendor remains responsible for access, retention, and audit within its own service. The governance layer gives the organization a single inventory of all AI systems in use, unified visibility into usage and cost across providers, and a control point that can enforce policy regardless of which tool is being used.

The FinOps layer is usually missing

Even organizations with reasonable security governance often have no answer to the question: what are we actually getting for this? Token-based pricing, model-per-task billing, GPU compute for fine-tuning, RAG pipeline infrastructure — AI spend accumulates in ways that are genuinely hard to track against business outcomes.

FinOps practice applied to AI isn’t about cutting spend. It’s about making spend legible. Which workloads justify cloud model pricing. Which workloads could run on local infrastructure at a fraction of the cost. Which use cases are producing measurable value versus which ones are running because someone thought they should.