Who Should Own Enterprise AI Governance?

A demand-forecasting model capable of making high-value inventory decisions is ready to deploy but never ships. Its technical performance is solid, and the business case is obvious. It stalls because no one will own the decision to approve it. Legal sees a risk decision. Risk sees a business decision. The business assumes the CTO owns the technology. The CTO points back to the process owner. Weeks pass, until a frustrated product manager finds a workaround, and an unvetted version goes live through a side door outside the governance process.

This pattern is increasingly common in enterprise AI. When AI governance promises strategy, budget, and corporate influence, multiple business lines may maneuver to claim ownership. But when governance requires approving a specific deployment’s risks or answering for an operational failure, ownership grows unclear. The same business lines can fight over AI before launch and disown it after something goes wrong. In both cases, accountability has emerged by default or force of personality rather than by design.

The resulting bottleneck, including stalled pipelines, proliferation of shadow AI, and paper-only compliance frameworks, points to a missing piece—an operating architecture for the AI governance. Before an executive team can assign an owner to AI governance, it must align on what that architecture is engineered to achieve. To define this, we return to the foundation established in our previous piece, Point-of-View: AI Governance Is Broken, in which we argue that effective AI requires a non-negotiable architecture of three pillars. Each supplies a critical safeguard that the others cannot.

The Three Pillars of Governance

· Front-line involvement. The people who use production AI systems daily are often first to see when outputs are wrong or real-world conditions diverge from design assumptions. They supply judgment that data science cannot. A model team can establish statistical significance, but only domain experts can confirm operational, commercial, or, in healthcare, clinical significance. A threshold can be statistically sound and still be wrong for the business or unsafe for a patient. That distinction often lives on the front line, not in a statistical validation set.

· Cross-functional oversight. A senior cross-functional body must weigh risk against strategic intent. An AI system’s consequences rarely respect functional boundaries, so no single function sees the whole risk surface. Legal sees regulatory exposure engineering may miss; operations sees workflow breakage finance may miss; customer-facing leaders see reputational costs accuracy metrics cannot capture. Its role is to surface blind spots, challenge the owner’s assumptions, and escalate unresolved issues before the system ships. Its authority is to ask hard questions and require answers; the owner’s responsibility is to answer and own the model’s production impact.

· Independent audit. A function should test the system from the outside, red-teaming assumptions and verifying that stated policy matches actual practice. Its defining feature is independence. The front line and oversight body are both, in different ways, invested in the system’s success. Independent audit is the only pillar structurally free to deliver unwelcome findings, because it does not own the outcome it examines. It asks whether the system performs as claimed, whether documented controls operate in practice or only on paper, and whether quiet workarounds have become the real operating procedure. Without it, an organization grades its own work.

In practice, these three pillars mature at different rates. Most organizations have some version of front-line involvement and cross-functional oversight, but genuine independent audit remains rare. Where it exists, it often appears as periodic external red-teaming rather than a standing internal function. Yet assembling all three pillars does not settle the question of who owns AI governance. The problem is that every candidate brings a predictable blind spot, one that follows from the expertise that makes them credible. The General Counsel sees duties, liabilities, and defensible processes. The CTO sees systems, controls, and implementation pathways. And the Chief Risk Officer sees exposure, assurance, and failure modes. Their strengths become the source of their blind spots.

The Five Ownership Models

In practice, organizations often default to whoever holds the most political capital when the question arises. Five patterns recur, each concentrating power differently and under-serving one governance capability.

A Legal-led model prioritizes oversight and documented defensibility. Yet it often under-invests in front-line agility, the speed at which useful AI tools reach production. The implicit goal may quietly shift from managing risk to avoiding risk altogether, and the bar for approval rises until business units begin buying unvetted tools on their own. In this case, rigor can become the engine of shadow AI.

The CTO-led model often inverts the problem. It maximizes deployment speed and technical quality. Yet without non-technical checks, it under-invests in cross-functional alignment, allowing the organization to ship systems that function flawlessly while carrying liabilities no engineer was positioned to see.

A Risk-led model guarantees rigorous audit. Its weakness is proportionality and contact with operational reality. Every tool, however benign, may pass through frameworks built for grave exposures, leaving a low-stakes internal assistant sitting in a months-long queue behind genuine hazards. Rigor without proportion becomes its own form of risk, because users may route around the process entirely.

The CAIO-led model is the most deliberate attempt to give AI governance a dedicated owner, and on paper, it is the most balanced. Unlike the others, the Chief AI Officer does not inherit AI as an extension of a legal, technical, or risk mandate. Its innate challenge, however, can be the absence of authority. A Chief AI Officer may lack the execution power to enforce decisions, devolving into a coordinator who issues thoughtful policies the front line can ignore.

Finally, the Committee-led model often emerges when no single executive has enough authority, appetite, or political cover to own AI governance outright. On paper, it looks reasonable since Legal, technology, risk, compliance, security, and the business all have a voice. That structure can work well as cross-functional oversight (the previously-defined second pillar), where a committee surfaces tradeoffs and recommends actions to a single accountable owner. The failure comes when the committee stops advising the owner and becomes the owner. When the group owns the outcome, no one may own it with enough force to break ties, accept risks, or tell a business unit “no.” The result may include more meetings, artifacts, and circulation for comment, but fewer clear decisions.

Each model carries a different weakness. Yet capable organizations often defend their chosen model fiercely.

Culture Dictates Structure

Both the ownership choice and its defense begin in a company’s culture. Organizations choose AI governance models from within the habits, incentives, and anxieties they already have. A company that defaults to legal caution tends to make AI a legal problem, while a company that worships speed favors a model that keeps approval close to product and engineering. The technology may be new, but the institutional reflexes are not, and in many enterprises, what looks like an AI strategy is simply culture expressing itself through a new technology.

As we argued in AI Risks Don’t Wait for Committees, governance should be an efficient deployment infrastructure. It should let an enterprise move quickly without turning every deployment into a bespoke experiment. Large, regulated enterprises already work this way in finance and legal, with defined owners, controls, and escalation paths that let the organization move at scale without courting catastrophe. Governance-as-infrastructure is familiar to them, but they stumble when they fail to extend that same discipline to AI. Earlier-stage or founder-driven cultures may rely on improvised accountability and treat structured review as an obstacle. When an engineer must seek sign-off before delivery, the instinct in such a culture is to conclude that the company is broken. Often the real problem is badly designed review. Governance done well rarely makes the engineer wait. It clears the low-risk path automatically and reserves human judgment for decisions that warrant it. The goal is to remove the friction that improvised oversight creates by default.

The danger cuts both ways. A regulated insurer that governs AI by improvisation will discover its missing controls the hard way, in an adverse-action complaint or a regulator’s examination. A startup that bolts enterprise-grade review onto every internal experiment will smother the speed that was its greatest advantage. The first under-builds for its risk, while the second over-builds for its stage. To avoid both traps, executive teams should answer four questions about their culture.

In the full article on Substack, we address the Four Tests of AI Governance, Compensating for the Blind Spot, Resolving the Engineering Tension, and Conclusions.