A few months ago, during a governance assessment at a mid-size financial services company, I asked a simple question: “Who owns AI governance here?”
The CISO said the CTO owned it because AI is a technology decision. The CTO said the data team owned it because AI is fundamentally a data problem. The head of data said compliance owned it because the regulatory exposure is the real risk. Compliance said they were waiting for the CTO to define what needed governing before they could write the policies.
Four leaders, four confident answers, zero ownership.
This was not a dysfunctional organization. These were experienced, well-intentioned people who had successfully governed cloud adoption, data privacy, and security operations. They had frameworks, review boards, and quarterly audits, none of which covered AI. The gap was structural, not one of awareness: AI governance does not fit cleanly into any single team’s existing mandate, so it sits in the space between mandates, owned by everyone in theory and nobody in practice.
The shadow governance problem
If you think this pattern is limited to formal AI programs, consider what happens in the spaces leadership does not see.
I have seen marketing departments spin up AI-powered content generation tools with their own budget and executive sponsorship, no security review, no data classification, no IT awareness until the invoice showed up three months later. In one engagement, a product team had deployed a dozen AI agents across their workflow, most of them redundant, some calling each other in loops, burning through inference costs that nobody was tracking because the bill landed in a shared cloud account. At another company, a business unit ran its own identity provider for over a year without IT knowledge, different authentication policies, no connection to HR systems for offboarding. When we asked how they managed access revocation, the answer was “we don’t, honestly.”
If a department can run parallel identity infrastructure without anyone noticing, they are already running parallel AI tools. The same organizational dynamics that create shadow IT create shadow AI, except shadow AI makes decisions, generates content customers see, and accesses data that traditional shadow IT never touched.
The governance gap I described in Post 13 was about organizations deploying AI without governance frameworks. This post is about what happens next: organizations that know they need governance but cannot agree on who builds it, who enforces it, and who is accountable when it fails.
Why traditional governance models break for AI
Traditional IT governance works because responsibilities map cleanly to organizational boundaries: the network team governs the network, the security team governs access controls, the data team governs data quality. Each domain has a clear owner, a clear scope, and a clear escalation path.
AI breaks this model because it is inherently cross-functional. A single AI agent might:
- Access sensitive customer data (data governance)
- Make decisions that affect revenue (business governance)
- Generate content that represents the company (brand and legal governance)
- Use third-party models with their own terms of service (vendor governance)
- Run on cloud infrastructure with cost implications (FinOps governance)
- Introduce security vulnerabilities through its tool access (security governance)
No single team’s mandate covers all of these. And when governance requires coordination across six teams, the default outcome is that nobody coordinates and everyone assumes someone else is handling it.
This is not a new problem in principle. Cloud governance faced the same cross-functional challenge a decade ago. But cloud governance had a forcing function: the bill arrived monthly, and someone had to own it. AI governance lacks that single forcing function. The costs are distributed, the risks are probabilistic, and the failures are often invisible until they become incidents.
The governance tooling paradox
The industry is responding. OWASP published its Agentic Security Initiative Top 10 in early 2026, the first peer-reviewed framework specifically for AI agent security. Mend.io released an AI Security Governance Framework covering asset inventory, risk classification, and maturity models. Microsoft built Entra Agent ID for managing AI agent identities with conditional access and lifecycle management. AWS published AgentCore Identity for equivalent agent identity frameworks.
The tooling exists, but the governance architecture to make it work does not.
Here is the paradox: Microsoft built real governance tooling for AI agents (Entra Agent ID provides conditional access, identity protection, and lifecycle management), but in April 2026, Silverfort researchers discovered that the Agent ID Administrator role itself had a critical scope overreach. A user assigned that role could take over any service principal in the tenant, not just agent identities. Ninety-nine percent of tenants had at least one privileged service principal exposed.
The governance tooling for AI agents was itself ungoverned. The role meant to manage agent identities was built on the same service principal primitives as applications, and nobody had properly defined the boundary between them.
The structural problem is broader than any single vendor: when you build governance tooling without first answering “who governs the governance?”, you create a new layer of unowned risk.
What ownership actually looks like
After working through this problem across multiple engagements, we have converged on a model that works. Nothing revolutionary about it, honestly. The approach is borrowed from how mature organizations govern cloud infrastructure, adapted for the specific cross-functional nature of AI.
The core principle: governance ownership is assigned per category, not per system.
Instead of asking “who owns AI governance?” (a question too broad to answer), you decompose AI governance into specific categories and assign each one to the role best positioned to define, review, and enforce it.
Here is what that looks like in practice. These categories are intentionally organizational rather than technical: they map governance responsibilities to the teams already capable of enforcing them.
| Category | Owner | What they govern |
|---|---|---|
| Security baseline | Security Lead / CISO | Encryption, access control, secrets management, agent identity |
| Compliance constraints | Compliance Officer / Legal | Regulatory requirements, data residency, audit trails |
| Architectural guardrails | Chief Architect | Integration patterns, model selection, infrastructure boundaries |
| Coding standards | Engineering Lead | Code quality, testing requirements, review processes |
| Operational readiness | SRE / Platform Lead | Monitoring, alerting, incident response, rollback procedures |
| Cost guardrails | FinOps Lead | Token budgets, model tier routing, cost anomaly detection |
| AI/GenAI-specific guardrails | AI/ML Lead or Responsible AI Owner | Hallucination controls, bias monitoring, human-in-the-loop requirements |
| Reliability | SRE / Platform Lead | Availability targets, failover, graceful degradation |
| Performance efficiency | Engineering Lead / Architect | Latency requirements, caching strategy, resource optimization |
| Sustainability | Cloud Operations | Resource efficiency, right-sizing, carbon-aware scheduling |
If your organization doesn’t have a dedicated role for every category, the principle still holds: assign the closest existing leader and let the scope grow with the practice.
Each category has a severity model: Mandatory (no exceptions, violation blocks deployment), Required (exceptions need documented risk acceptance signed by an approver), and Recommended (best practice, deviation noted but not blocked).
The critical detail is the review cadence. Each category owner reviews their guardrails quarterly, confirming they remain relevant, severity levels are appropriate, and new organizational requirements are incorporated. Without the cadence, the framework becomes stale documentation. With it, governance evolves alongside the technology.
From theory to practice: what changed
One organization we worked with, a financial services company with about 2,000 employees, had been stuck in the governance vacuum for eight months. They had an AI strategy document, an executive sponsor, and a cross-functional committee that met monthly. Nothing was getting enforced.
The committee’s problem was structural: it had authority to recommend but not to enforce. Recommendations went back to individual teams, who prioritized them against their existing backlogs. AI governance always lost to feature delivery.
We helped them shift from a committee model to a category ownership model. The CISO did not own “AI governance.” She owned the security baseline category, with specific guardrails she defined, a severity level she assigned, and a quarterly review she ran. The engineering lead owned coding standards, the compliance officer owned regulatory constraints, and each person knew exactly what was theirs to define and enforce.
Three things changed immediately:
First, decisions got faster. When a team wanted to deploy a new AI agent, they did not need to schedule a committee meeting. They checked the guardrails document. If their design complied, they proceeded. If it conflicted with a Mandatory guardrail, they knew exactly who to escalate to and what the exception process looked like. Their first agent deployment under the new model was approved in under a week, down from the six-week committee cycle they had been stuck in.
Second, accountability became concrete. When an AI agent accessed customer data without proper classification, the conversation went straight to specifics: the data governance guardrail in category 2 was violated, the compliance officer is the category owner, here is the exception process that should have been followed. Blame disappeared because the structure made the next step obvious.
Third, the framework scaled without scaling headcount. This is the paradox one security practitioner articulated perfectly: “If we have to do AI risk evaluation at the scale the business wants to deploy use cases, we’d need to add so much headcount in security that we’d lose any gains.” Category ownership solves this because each owner governs their domain using the expertise they already have. The security lead does not need to understand model architecture. The architect does not need to understand regulatory compliance. Each person governs what they already know, applied to AI systems.
The vendor pricing signal
There is a revealing signal in how vendors price AI agent governance. Microsoft’s executive Rajesh Jha described AI agents as “seat opportunities,” meaning each agent needs a software license the same way each employee does. The pricing model reveals whether vendors treat agents as headcount or as systems, and the economic incentive is to sell more seats, not to help you govern them. Ownership complexity grows with every new agent you deploy.
Your governance framework cannot depend on vendor tooling alone. Ownership, severity, review cadence, and enforcement architecture must come from the organization.
The community is building the primitives
What gives me confidence this model works is that the community is independently arriving at the same patterns. Developers are building action denylists for MCP agents (what agents cannot do) and governed PR workflows (human approval gates for agent-initiated changes). The OWASP Agentic Security Initiative formalizes what practitioners have been discovering through production pain: agents need governance architecture, not just capability.
These are the building blocks of AI governance as code. Action denylists define what agents cannot do. Governed PRs require human approval before agent-initiated changes reach production. Combined, they give organizations a way to grant agents autonomy within boundaries, which is exactly what the category ownership model enables at the organizational level.
The convergence is happening from both directions: top-down (organizational governance frameworks) and bottom-up (developer-built governance primitives). Organizations that connect both will govern AI effectively. Those that only have one will either have governance that cannot be enforced (top-down only) or enforcement without strategic alignment (bottom-up only).
What this means for your organization
If you are reading this and recognizing the ownership vacuum in your own organization, here is where to start:
Do not form another committee. Committees recommend. Owners decide. The shift from “cross-functional AI governance committee” to “category owners with defined scope and authority” is the single highest-leverage change you can make.
Start with three categories, not ten. Security baseline, AI/GenAI-specific guardrails, and cost guardrails cover the highest-risk areas. Add categories as the organization matures. Trying to govern everything simultaneously guarantees you govern nothing.
Make the guardrails document the source of truth. Every AI deployment, every agent configuration, every model integration should reference this document. The AI tools themselves should validate against it before deployment. Guardrails that exist only in a policy PDF nobody reads are dead on arrival.
Enforce the quarterly review. Governance that does not evolve becomes an obstacle. The quarterly review is where category owners confirm their guardrails still match reality, adjust severity levels based on incidents, and incorporate new requirements. Skip the review and the framework dies within two quarters.
A final reflection
The question “who owns AI governance?” is unanswerable in its current form. It is like asking “who owns cloud?” The answer is: it depends on what aspect of cloud you mean, and the organization that tries to assign a single owner to all of it will fail.
AI governance ownership is an architecture decision, not an org chart decision. You design it the same way you design system architecture: by decomposing a complex problem into bounded domains, assigning clear ownership to each domain, defining the interfaces between them, and establishing the cadence at which the whole system is reviewed.
Closing the governance gap comes down to three questions answered concretely: who owns each piece, what authority do they have, and how do they exercise it. Strategy documents won’t get you there. Named owners with defined scope will.
The vacuum is the vulnerability, and the only way to fill it is with structure.
Ricardo
