Ask ten enterprises who owns AI governance and you’ll get ten different answers.
We’ve had this conversation across financial services, healthcare, retail, energy, and technology companies over the past several months. The pattern is consistent: everyone agrees that AI governance matters. Nobody agrees on who owns it. And in most enterprises, the honest answer is that nobody does — not in any meaningful, accountable sense.
This is not a criticism. It’s a structural problem that reflects how quickly AI has moved, and how few organizational playbooks exist for a technology that simultaneously touches security, cost, compliance, developer experience, and business strategy.
| The governance gap we’ve written about in this series isn’t primarily a technology gap. It’s an ownership gap. And until it’s resolved, even the best-designed governance framework will stall. |
What We’re Hearing
Across the organizations we’ve spoken with, AI governance ownership falls into roughly five patterns — plus a sixth that sits at the board level. Each is rational given the organization’s structure. Each has a meaningful blind spot.
| Who Owns It | What They Govern | What Gets Missed |
| CISO | Security posture, data leakage, access controls, compliance | Cost attribution, developer productivity — the business layer |
| VP Engineering | Developer tooling, model access, build pipelines, developer productivity | Runtime agent governance, security controls, regulatory exposure |
| CTO | AI strategy, model selection, architecture standards | Day-to-day enforcement — strategy without execution is a policy on paper |
| VP IT / Platform | Infrastructure, tooling procurement, access management | Application-layer AI behavior, prompt governance, agent permissions |
| AI Lead / Head of AI | Model evaluation, use case prioritization, AI roadmap | Security, compliance, and cost — AI leads are rarely given enforcement authority |
| Board / GC | EU AI Act compliance, liability exposure, reputational risk | Everything below the boardroom — they set the mandate but rarely see the controls |
None of these patterns is wrong. Each reflects a reasonable instinct about where AI governance fits. But they share a common failure mode: each owner governs the part of AI they already understand, and leaves the parts they don’t to someone else.
The result is an organization where AI governance exists in fragments. The CISO has a data handling policy that developers don’t know about. The VP of Engineering has model access rules that security hasn’t reviewed. The CTO has an AI strategy document that nobody is enforcing. The AI lead has a use case roadmap that doesn’t mention permissions or audit trails.
| Fragmented governance is not governance. It’s the organizational equivalent of a policy layer with holes — the holes are exactly where the risk lives. |
Why This Happened
AI governance doesn’t map cleanly onto any existing organizational function because AI itself doesn’t map cleanly onto any existing infrastructure category.
It’s not just a security problem — it’s also a cost problem, a productivity problem, a compliance problem, and a business risk problem simultaneously. Every existing function has a claim on part of it. Nobody has a mandate to govern all of it.
This is exactly what happened with cloud governance in the early 2010s. Cloud spending touched finance (unexpected costs), security (data sovereignty, access controls), IT (infrastructure management), and engineering (developer velocity). Nobody owned all of it. The organizations that eventually got cloud governance right were the ones that created a deliberate ownership model — often a FinOps function, sometimes a Cloud Center of Excellence — with a cross-functional mandate and actual enforcement authority.
Kubernetes governance followed the same pattern. Platform engineering teams eventually emerged as the natural owner — not because they were the most obvious choice, but because they were the ones building the infrastructure layer that everything ran on. Kyverno gave them a policy engine with actual enforcement authority, not just advisory oversight.
AI is now in the same early stage. The ownership model hasn’t settled. The organizations that figure it out first will have a structural advantage over the ones that wait for industry consensus.
The Four Failure Modes
Based on what we’ve seen, fragmented AI governance ownership tends to fail in four specific ways:
- The policy exists but isn’t enforced.
The CISO publishes an AI usage policy. Developers don’t know about it, or know about it and work around it because there’s no technical enforcement layer. Policy without enforcement is documentation, not governance.
- The enforcement exists but isn’t auditable.
The platform team enforces model access rules at the API layer. But there’s no audit trail that maps those enforcement decisions to a compliance framework. When the auditor asks, the answer is “we have controls in place” but not “here is the evidence.”
- The audit trail exists but nobody queries it.
Logs are being written. Nobody is looking at them. The governance layer is producing evidence that nobody is using to make decisions. This is the most common failure mode — and the most dangerous, because it creates the illusion of governance without the substance.
- The cost is attributed but not acted on.
Finance can see AI spend by team. But there’s no process to act on anomalies. A team that doubles its Claude spend in a month gets a surprised look from their manager, not a pre-call enforcement action. Visibility without accountability is not cost governance.
What Good Ownership Looks Like
The organizations making the most progress on AI governance have one thing in common: a single team with a cross-functional mandate, technical enforcement authority, and accountability for outcomes across all four governance layers.
In most cases, this lands with platform engineering — the same team that owns Kubernetes governance, pipeline security, and infrastructure policy. This makes sense for two reasons:
- They already own the infrastructure layer where AI governance needs to be enforced — the LLM gateway, the Kubernetes cluster, the CI/CD pipeline
- They already have the policy-as-code tooling — and in many cases, the Kyverno expertise — to extend governance to the AI layer without building from scratch
But platform engineering ownership only works if the mandate is genuinely cross-functional. Security has to be at the table when policies are defined. Finance has to be in the loop on cost attribution. The AI lead has to align use case rollout with the governance framework. The CISO has to have audit access to the trail.
What doesn’t work is any single function trying to own AI governance unilaterally. The CISO who governs AI without engineering’s buy-in will get workarounds. The VP of Engineering who governs AI without security’s input will miss the compliance exposure. The CTO who publishes an AI strategy without enforcement mechanisms will find it ignored.
| AI governance ownership is not a technology question. It’s an organizational design question. The technology is the easy part. |
The Question Worth Asking
At the end of every conversation we have with enterprises on this topic, we ask a simple question:
If something went wrong with an AI agent in production today — it accessed data it shouldn’t have, it made a decision that caused harm, it generated a cost spike that hit the CFO’s radar — who would own the response?
In most enterprises, the answer involves a long pause and then a list of people who would all be involved. Not a single owner. A committee that would form in response to an incident.
That’s not a governance model. That’s an incident response plan masquerading as one.
The enterprises that are getting AI governance right have answered that question before the incident happens. They know who owns it. They have enforcement authority. They have an audit trail. And they have a process for acting on what the audit trail tells them.
The window to build that before the incident is still open. But as AI agents move from experimentation to production — as we’ve outlined throughout this series — that window is closing faster than most organizations realize.
We built the policy engine that governs Kubernetes at scale in thousands of enterprises. The same ownership challenge — and the same policy-as-code solution — now applies to AI. If you’re working through the ownership question in your organization and want to compare notes, we’d like to talk.
| We’re working with a small number of enterprises on exactly this challenge. If you’re in the process of figuring out who owns AI governance in your organization — or if you already know and want to compare approaches — reach out at nirmata.com or DM on LinkedIn. |
Read the remaining posts in this series: The AI Governance Gap · What Good AI Agent Governance Looks Like · Your Developers Are Using AI. Your Governance Layer Isn’t. · From Experimentation to Governed Production.
