An AI policy settles what is prohibited. Approvals stall because no decision architecture names who approves a use case, at what risk threshold, and who owns the outcome once it runs. Until those three assignments exist, every request the policy neither forbids nor authorizes defaults to escalation or silence, and the technology leader ends up holding a queue of decisions that belong to the executive team.

What An AI Policy Settles, And What It Leaves Open

An AI policy defines the boundaries of acceptable use. It names the data that cannot leave the organization, the tools approved for general use, the disclosures required when AI touches a customer, and the categories of use that are prohibited outright. That work matters. The policy answers the question a general counsel asks: what are we not allowed to do.

The policy is silent on the question an operating executive asks: may we do this specific thing, and who says so. A marketing team wants to run a model over customer conversations to score churn risk. A plant manager wants a vision system to flag defects on a line. Neither is prohibited. Neither is authorized, because a boundary document carries no approval authority for anything inside the boundary. Someone still has to decide, and the policy never says who.

That is the governance gap, and it sits beside the policy. The policy and the decision architecture are two different artifacts, and many organizations have built only the first one.

Where AI Decisions Stall: The Approval Nobody Owns

AI decisions stall at the moment a request arrives that the policy neither forbids nor authorizes, and no one holds the authority to approve it.

Two default behaviors follow. The first is escalation. The request travels upward until it reaches someone who seems senior enough to carry the risk, which in practice means the CIO, the CEO, or a committee that meets monthly, and there it waits. The second default is silence. The team either proceeds quietly with a tool that was never reviewed, or stops asking because the last request took eleven weeks and came back with questions instead of a decision. Both defaults leave the organization with no record of who decided, and in many cases no one did.

The ownership picture at the top shows how diffuse this is. McKinsey's 2025 State of AI survey found that 28 percent of respondents at organizations using AI say their CEO oversees AI governance, 17 percent say the board does, and on average two leaders are in charge at once. The same research found CEO oversight of AI governance among the attributes most correlated with reported bottom-line impact from generative AI. The survey does not reveal whether those leaders have a defined division of authority. It does show that AI governance commonly spans multiple senior roles, making explicit decision rights essential.

The stall is a structural omission. The people asking and the people escalating are both behaving reasonably. The architecture that would let a reasonable request meet a reasonable decision was never designed.

The Three Questions A Decision Architecture Answers

A decision architecture for AI answers three questions, in this order, before the next request arrives.

1. Who has the authority to approve an AI use case? A named role, at a defined level, for a defined scope. In practice: a business unit leader approves use cases that stay inside their function, touch no regulated data, and produce recommendations a person acts on. The approval is theirs, on record.
2. At what risk threshold does the decision path change? The conditions that alter who reviews and who decides: regulated data or customer-facing output adds a functional review to the local approval, and a system that acts without a person in the loop or carries exposure above a set figure routes to a named executive.
3. Who owns the outcome once the use case is running? The executive accountable for what the system does in production: its accuracy, its drift, its effect on the people it touches, and the decision to shut it down. This is the assignment most often skipped.

Each question needs a name attached that survives contact with the org chart. The leader who runs AI and data governance at Adobe described the pattern from the inside this summer: responsible AI teams and governance councils can flag, recommend, and escalate, and they generally cannot stop a deployment, because decision authority sits with whoever is shipping the product. His answer was named owners for every AI system and a steering committee whose escalation authority reports outside the product line. The mechanism varies. The requirement holds: someone owns the decision, in writing.

Answering only the first question moves the bottleneck to a different desk, and an approver with no outcome owner signs off on systems no one is watching.

Why Risk Thresholds Do More Work Than Rules

A risk threshold routes most AI requests to a local owner, adds functional review where the exposure calls for it, and reserves executive attention for the few decisions that warrant it.

The threshold is a short list of conditions, each observable at the time of the request: whether the output reaches a customer or regulator, whether the system touches personal or regulated data, whether it acts on its own or a person reviews its output first, and what the exposure is if it runs wrong for a week. Each condition changes the path in a defined way. A request that clears all four is approved locally. A request that touches personal data keeps its local approver and picks up a privacy review on the way. A request that acts on its own, or carries exposure above the set figure, goes to a named executive with a defined window. Most requests stay on the short path.

Rule-writing as a governance strategy scales in the wrong direction. Every new category of use case needs a new rule, the rulebook lags the requests by a quarter or more, and the people asking learn that the honest path is slower than the quiet one. A threshold does the sorting once, in advance, and holds as request volume grows.

The threshold also gives the technology leader a defensible answer to the question every peer executive eventually asks: why does my request need a review when hers did not. The answer is a published line, agreed by the executive team, applied the same way each time.

The Cost Of Governing By Exception

Governing by exception is expensive, and the cost lands on the technology leader first.

The first cost is latency. When every AI request is a special case, the queue is the governance, and the business reads the delay as IT resistance. The second cost is duplicated evaluation: three functions assess the same vendor tool independently and each escalates separately. The third cost is adoption outside any review. Teams that stop asking keep using, and the organization accumulates AI in production that no one approved, no one owns, and no one can list when a board member asks how many systems are running.

The fourth cost is the one CIOs feel most directly. With no architecture, the senior technology leader becomes the default approver for every request and the default owner of every outcome, with formal authority over almost none of the systems in question. Accountability accumulates in the office that did not make the decision. The pattern is familiar from decentralized technology buying, and AI reproduces it faster.

None of these costs is guaranteed in any single organization. The pattern to watch for is a technology leader spending a growing share of the week on AI approvals, with no corresponding growth in authority over what gets deployed.

What Technology Leaders Bring To The Executive Table

Decision rights for AI are an operating-model design decision, and the executive team owns it.

The CIO is the leader positioned to name the gap, because that office is where the unrouted requests land. The move is to bring the executive team a design. Name the three questions. Propose the threshold conditions that fit this organization. Recommend which roles hold local approval, which reviews each condition adds, and which executive owns what sits above the line. Then ask for the assignment of decision rights, on record, in place of another revision of the policy.

That framing matters, because the executive room hears a request for more governance as a request for more friction. A decision architecture removes friction. It lets a reasonable request meet a reasonable decision within a defined window, with a name on it. Recent research on decision rights drawn from work with more than 100 companies found the common failures are structural: roles set before goals are clear, decision rights treated as a static list written by one senior leader, and hierarchy overriding the roles once assigned. An architecture designed with the executives who will use it, and revisited as thresholds change, is designed to counter all three.

The technology leader designs and proposes. The executive team decides. Holding that line keeps the CIO in the role of architect rather than gatekeeper, the only position from which the governance gap can be closed without the technology leader becoming its permanent occupant.

Close: Build The Architecture Before The Next Request

The next AI request is the wrong moment to design the decision architecture. By then the request is urgent, the business unit is waiting, and whatever gets decided becomes precedent by accident.

The design begins with one focused executive conversation, with three questions on the table: who approves, at what threshold does the path change, and who owns the outcome. The policy already says what the organization will refuse. The architecture says how it decides what it will do.

AI decision rights are an executive design choice, and too many organizations have left them undefined. CIO Mastermind gives technology leaders a confidential peer forum for pressure-testing where approvals stall, how risk should change the decision path, and how to bring a workable architecture to the executive team. Explore the CIO Mastermind peer network.