Skip to content
Blazej Mrozinski
PL

AI Agent Governance Is a Decision-Rights Mapping Problem

Blazej Mrozinski · · Systems Thinking
AI Agent Governance Is a Decision-Rights Mapping Problem

The most important governance document in my work is a short written protocol that says who decides what between me and the AI. It reads as a list of decisions, and each decision is assigned to me, to the model, or to both of us, based on what I want the system to do when nobody is watching. I edit it whenever something surprises me, and the edits usually follow something that went wrong.

That protocol exists because I run multiple projects across multiple companies with AI as my primary technical partner, and the production scares of my early sessions traced back to its absence. Two of them were SSH lockouts on a live server that took a rescue console to undo. The protocol works for me at the scale of one person plus an AI. What caught my attention in spring 2026 was how cleanly the same structure showed up in writing about how large companies are trying to govern AI agents at the scale of thousands of employees. Toby Stuart’s Harvard Business Review piece on who in the C-suite should own AI is the clearest example I read.

Corporate AI ownership debates almost always frame the question as one about job titles. The CIO says agents are infrastructure. The COO says agents are workflow. The CHRO says agents are workforce. The CFO says they are P&L. The CRO says they are risk. The CDO says they are data. They are all correct, and the meeting still ends with nobody able to make a decision next Tuesday.

Table of Contents

Why the ownership question is the wrong question

Andrew Abbott’s sociology of professions explains why the AI ownership debate inside companies is taking the shape it is. In Abbott’s account, professions form an interdependent system that is constantly contesting jurisdiction. The boundary between what an accountant does and what a tax lawyer does is a settlement. It holds until something disrupts the system, and then it gets renegotiated. Major technological shifts are exactly that kind of disruption.

The same dynamic plays out inside corporate functions. In settled times, the boundary between IT and operations and finance is stable enough that most decisions can be assigned without argument. In unsettled times, the same decisions become turf. Each function has a reason it should own the new territory, and each reason is correct in isolation.

Agentic AI is unsettling that boundary in an unusual way, because an autonomous agent that processes a claim or approves a refund is genuinely a piece of infrastructure, a workflow, a worker, a financial decision-maker, a risk surface, and a consumer of data. The classical division of corporate labor splits each of those concerns under a different leader. The agent does not split.

So when the CEO convenes a meeting to decide who owns AI, every person in the room walks in with a defensible argument. The meeting ends without resolution because the question, as posed, has no answer. The land grab is the inevitable consequence of an unanswerable question. Nobody in the room is misbehaving.

The reframe: assign decision rights one decision at a time

The useful move is to stop asking who owns AI and start asking who owns each AI decision. Decision is the right unit because it is implementable. Handing the COO “AI” leaves everyone guessing on Monday morning. Handing the COO ownership of “what the agent is trying to accomplish in this workflow and how success is measured” has immediate operational meaning.

Once you decompose the problem this way, the room of competing claims turns into a list of complementary ones. The COO or P&L owner naturally owns the question of what agents should accomplish. The CIO owns how to build them, integrate them, and run them safely. The CDO owns what data they can access and under what governance rules. The CRO and General Counsel own risk thresholds and the rules for when humans must intervene. The CHRO owns how human and agent work coordinate, and how the introduction of agents changes the work people do. The CFO owns the budget for inference, the budget for upfront investment, and the measurement of return.

In retrospect this is unsurprising. The same set of claims walked into the room. The change is that each claim now attaches to a specific decision, and the contest for a single chair goes away.

This reframe also clarifies the Chief AI Officer’s job. A CAIO who claims to own AI inherits the same impossible problem the CEO was trying to escape. A CAIO who owns the coordination layer, meaning the map itself, has a defensible job. The map has to be drawn. It has to be maintained. New decisions appear, and someone has to decide where they fit. Existing assignments have to be reviewed when capabilities change. That is a real role with a real jurisdiction. The role works because nobody else is positioned to own it.

What gets revealed when you draw the map

Drawing the decision map exposes things organizations had been avoiding. It surfaces the decisions that nobody actually owns, which were getting made by default by whoever happened to be in the room when the issue came up. It surfaces the decisions that two people both believe they own, which were getting made twice, with each version cancelling the other. It surfaces the decisions that have been made implicitly by configuration choices nobody remembers making, which is how most production systems acquire their character.

The map also forces a granularity most organizations have been resisting. A CIO claiming the technology stack is a slogan. A CIO whose decision portfolio reads as foundation-model selection, API integration standards, the kill switch when agent inference disrupts production latency, and explicitly nothing about the rules under which agents escalate to humans, is something a team can act on. The shift is from one declaration to a portfolio of named decisions.

The granularity also exposes how often decision rights have to be revisited. Every meaningful change in capability dislodges some assignment. A model release that moves from supervised to autonomous on a class of tasks pushes a decision boundary. A new compliance requirement pushes another. The map is a living artifact that needs upkeep for as long as capabilities keep moving, which is why nobody can own AI in the traditional sense, and why someone has to own the maintenance of the map itself.

The top-down failure mode

Decision-rights maps fail predictably when they are imposed from the top of the company without contact with where AI work is actually happening. The version that comes back from a strategy off-site is usually a clean diagram with crisp boxes. The version that survives implementation looks like the strategy diagram covered in handwritten annotations.

The reason for the gap is that AI work, especially the parts that are creating real value, rarely lives where the org chart says it should. Software engineers are using AI for legal research. Marketing managers are using AI for analytics. Operations leads are building automations that touch finance. The decisions being made in these workflows are often the ones with the highest stakes, because they cross functional boundaries the official map has yet to notice.

A top-down map that ignores this reality looks like governance and acts like fiction. The work continues. Decisions continue to get made by whoever is closest to the keyboard. The map describes what should happen, the company runs on what does happen, and the gap between the two is the cost of governance theater.

Why the workers building shadow AI tools are telling you something

The version of corporate AI rollout that works tends to start somewhere unexpected. It starts by reading the use of consumer AI tools on personal laptops as a demand signal. Employees who are running ChatGPT or Claude on personal laptops next to their corporate machines are doing free product research. They are showing the company exactly which tasks the official tools leave unsolved, exactly which workflows are bottlenecks, and exactly which user populations are willing to put up with friction to get value.

A company that suppresses that signal loses the information. A company that listens, deploys a secure environment quickly, and then makes access to it deliberately scarce and competitive ends up with a peer-driven population of advanced users who are building tools for each other, sharing patterns that work, and producing capability the central program could never have specified in advance. The clearest case I have read is BBVA’s, written up in Harvard Business Review in April 2026.

The decision-rights map for that kind of company looks different from the strategy off-site version. The map starts where the work is. It assigns decisions about specific high-value workflows to the people who already understand those workflows, and it gives the central function the job of setting guardrails while the people closest to the work pick the targets. The theory of governance underneath reads as “the CIO owns the rails, and the work decides where the rails go.” The familiar alternative, where the CIO owns AI and pushes it down the org chart, is the version that produces the annotated diagram.

How this works at the scale of one person and one AI

The corporate version of this story is legible to me because I have been running it at much smaller scale and watching the same forces operate.

The protocol I mentioned in the opening is structurally a decision-rights map. It assigns decisions explicitly between me and Claude. Some decisions are mine: product direction and priorities, the final pick on big architectural calls, anything touching SSH or authentication, anything irreversible on a production server. Some decisions are Claude’s: routine technical choices such as code style in a draft, file organization inside a project, picking the cleaner of two equivalent implementations, naming things. Some decisions are split. On an architectural call, Claude lays out two or three options with their tradeoffs and recommends one, and I pick. Some decisions have explicit halt conditions. Anything dangerous on a server means stop, explain the risk, let me prepare backups, and wait for my go-ahead. One assignment is worth spelling out: safety verification sits with Claude, because I cannot evaluate individual server commands, so the party that can check them owns the check.

That structure is the corporate decision-rights map at N = 1. It does the same things. It surfaces the decisions that were getting made by default. It exposes the granularity I had been avoiding. It is a living document, edited every time something surprises me.

One example from April 2026. I shipped a 30-commit machinery change across a personal site, then reverted all 30 in a single revert because the work was meant to live on a paused branch, away from production. That story sounds like a process failure, and at one level it is. At another level it is exactly what the decision-rights map is designed to allow. The AI moves fast on the kinds of decisions that belong to it. I retain veto on the kinds of decisions that belong to me. Branch placement for paused work was a decision that should have sat on my side of the map, and the map did not say so clearly enough. Making that assignment explicit is the step that prevents the same class of mistake from recurring.

That is the same loop a company runs when it adds a new responsibility to its CAIO’s coordination role after an incident. The shape of the work holds across scales. The names change, and the protocol stays the same.

Starting points for your first decision-rights map

If you are at the early stages of doing this in an organization, three things are worth pulling forward.

The first is to start from the work. List the decisions AI is currently making in your operation, including the ones being made by employees with consumer tools on personal laptops. Whatever map you draw later has to fit reality, and reality lives in the work, where the strategy deck rarely looks.

The second is to write decisions at a level someone can act on. “AI strategy” names a domain. “Whether agents can autonomously approve refunds under $50” names a decision. The first is a budget line. The second is something the next person in the seat can carry out without asking what was meant.

The third is to designate someone to own the map. The map needs maintenance. New capability changes it. New incidents change it. Without a designated owner the map becomes a document that everyone agrees with and nobody updates, which is worse than having no document, because it produces the appearance of governance with none of the substance.

The deeper point underneath all of this is that asking who owns AI suggests there is a single answer. The truthful answer is that AI ownership is plural, that it lives in specific decisions made in specific contexts, and that the work of governance is to make those decisions visible and assigned. That work happens at every scale where AI does meaningful work, including the scale of one person and one model. The protocol I keep on disk and edit whenever something surprises me is the smallest possible version of the same artifact a Fortune 500 company needs to draw. The structure is the same. The only thing that changes is how many people sign it.