Building AI Governance

Executive perspective

The question every leadership team eventually asks is not whether to govern AI, but who decides what it is allowed to do. Without an answer, every new use case becomes a fresh argument, and the organization defaults to either reckless speed or paralysis by committee.

Good governance is not a document. It is a small set of decisions made once, about who holds which rights, so that the hundredth request does not need the same debate as the first. That is what makes governance fast rather than bureaucratic.

Organizations that get this right treat governance as infrastructure: built once, reused constantly, and revisited only when the business changes materially. Organizations that get it wrong rebuild the argument every time, and slow adoption becomes the visible symptom.

Business context

A regional bank might have three AI initiatives running in parallel — a customer service assistant, a document review tool for lending, and a forecasting model for treasury. Each was approved by a different committee, using different criteria, over different timelines. None of them can easily reference how the others were evaluated.

This is the state most enterprises are in today: governance improvised project by project. It works while volumes are low. It stops working the moment AI moves from a handful of pilots to dozens of production use cases spanning departments, vendors and data sources.

A national utility facing this transition typically discovers the cost only when something goes wrong — a system was deployed with access to data nobody remembers approving, or a vendor tool was retired and nobody had documented who depended on it. Governance built in advance prevents both failure modes.

The core insight

Governance is not a policy statement. It is a set of decision rights, assigned to named roles, that determine who can say yes, who can say no, and who can be overruled.

An organization does not have AI governance because it has a policy. It has AI governance because someone specific can say yes or no, and everyone knows who that is.

Most governance failures are not failures of principle. Nobody disagrees that data should be protected or that systems should be reviewed. The failure is structural: no one was ever assigned the right to make the call, so the call gets made informally, inconsistently, or not at all.

The AI Decision Rights Framework

The AI Decision Rights Framework assigns four distinct rights to named owners, each with a defined escalation path. Splitting governance into these four rights, rather than treating it as one undifferentiated approval, is what makes the framework usable in a live meeting.

The four rights

What each right prevents

Approve use prevents duplicated pilots and unclear accountability. Access data prevents scope creep, where a system quietly gains reach into records nobody intended it to see. Grant autonomy prevents the gradual, undocumented expansion of what a system is trusted to do unsupervised. Retire a system prevents the common failure of tools that outlive their purpose and are never formally switched off.

Who should own AI governance in an enterprise

No single role should own all four rights. Ownership should follow existing accountability: business leaders own use, data owners own access, process owners own autonomy, and a governance council resolves cross-functional conflicts. This distributes governance to where the relevant judgment already sits, rather than centralizing it into a bottleneck.

What this looks like in practice

In a hospital network, the right to approve clinical decision-support use sits with a clinical governance committee, while the right to grant autonomy — how much a system can suggest versus decide — sits with the department using it. The two rights are deliberately separated because clinical risk tolerance differs by specialty.

In an insurance carrier, the data access right for claims history sits with the claims data owner, independent of which team wants to build a new AI use case. This means three different teams can request access without three different negotiations over what the data actually contains.

In a logistics company, the retirement right is exercised routinely: a routing tool piloted eighteen months ago is formally decommissioned once a newer system takes over, closing the access it held rather than leaving it dormant.

In a telecommunications provider, the escalation path is what resolves a dispute between a business unit wanting faster deployment and a data owner wanting more review time — the executive sponsor makes the call, and the decision is recorded for future reference.

Executive checklist

• For each active AI initiative, is there a named owner for each of the four decision rights?
• Is there a documented escalation path when two rights holders disagree?
• Are approvals granted once and reused, or renegotiated for every similar request?
• Does anyone track which systems currently hold which data access, across the enterprise?
• Is autonomy granted in explicit increments, or has it expanded informally over time?
• Is there a standing process to retire systems, not just to approve new ones?
• Would a new business unit know exactly who to ask before deploying an AI tool?
• Has governance ever blocked a legitimate use case for more than a week, and if so, why?

Key takeaways

• AI governance is the assignment of decision rights, not the publication of a policy.
• The four rights — approve use, access data, grant autonomy, retire a system — should sit with different owners.
• Escalation paths matter as much as ownership; disagreements need a defined resolution point.
• Retirement is the most commonly missing right, and the most common source of hidden exposure.
• Fast governance comes from clarity of ownership, not from fewer rules.

Continue reading

Next article: Managing AI Risks. Once decision rights are clear, the natural follow-on question is which risks those decisions are actually meant to manage, and how to tell a serious exposure from background noise.