Who Owns the AI Agent? Three Ownership Models, and What Each One Breaks

Only 21% of organisations report a mature governance model for agentic AI. Meanwhile 74% expect to be using agents by 2027. That gap is not a technology problem. It is an org chart problem, because AI agent ownership sits unassigned between IT, the business unit and security, and those three functions want different things.

The short answer

Who owns an AI agent? Three models work in practice: a central AI office that owns every agent, a platform team that owns the rails while business units own the agents, or ownership tiered by each agent's autonomy level. All three fail unless a named person, not a department, is accountable for each agent.

What "owning an agent" actually means

The word ownership hides four separate decision rights. Organisations argue about the word instead of the rights. Separating them is most of the work.

The first right is build. Someone specifies the agent, writes it and decides when it ships. The second is run. Someone is paged at 3am, holds the credentials and can stop it. The third is risk acceptance. Someone signs that this agent may act on customer records without a human checking each action. The fourth is budget. Some cost centre absorbs the token bill, and the incident.

Those four rights can sit in four different places without anything going wrong. The condition is that the handoffs are written down. Trouble starts when two of them are assumed by nobody. Risk acceptance is the one most often left blank. It is the only right that carries no upside for the person holding it.

The middle column reflects patterns described in the surveys cited below, not a count. No public dataset breaks agent decision rights down by function.

Notice what is missing from that table. There is no row for the model provider or the orchestration framework. Those are procurement decisions. They are easier to settle than the four rows above, which is why teams spend months on them instead.

The evidence that ownership is where agents fail

Three 2026 surveys point at the same seam from different angles. None of them was designed to.

Deloitte's State of AI in the Enterprise 2026 covers 3,235 IT and business leaders across 24 countries. It found 21% with a mature governance model for agentic AI, against 74% who expect to be using agents by 2027. A separate Deloitte survey of 501 US senior leaders, fielded April to June 2026, found 39% calling themselves prepared on risk, security and governance. That was the fourth lowest readiness area measured.

Gartner reached the same place from the control side. Its analysts argue that one governance standard across every agent is itself the cause of failure. Shiva Varma, a Senior Director Analyst, put it directly. Enterprises treat agent governance as "binary, either locked down or fully trusted, and that is the root cause of failure."

The IBM figure is the one worth sitting with. Chief AI officer prevalence rose from 26% to 76% in a single year. That is one of the fastest C-suite additions on record. Over the same period the readiness numbers barely moved. A title is the cheapest available response to an accountability gap, and it is the one most companies reached for first.

This is not an argument against the role. IBM also reports 5% higher return on AI investments at companies with a chief AI officer, and 79% of CEOs decentralising decision making. Those two findings sit awkwardly together. You cannot centralise accountability and decentralise decisions without saying which of the four rights moved.

Model 1: the central agent office owns everything

One team holds all four rights for every agent. It usually reports to a chief AI officer, or sits inside a centre of excellence. Business units request agents. The central office builds, runs, signs and funds them.

Where it works

This model is correct more often than its reputation suggests. It fits regulated industries and small agent estates. It fits any company where the binding constraint is consistency rather than throughput. Ten agents built by one team share an evaluation harness, a logging standard and one incident process. That is worth a great deal.

It also fits the first year honestly. With three agents in production, an operating model is overhead. I would not stand up a formal centre of excellence below that number.

Where it breaks

It breaks by becoming a queue. Every request enters one backlog, and the backlog grows faster than the team. Business units then do what people always do when a central function slows them down. They build outside it.

Gartner names both halves of this failure. Applying the same controls indiscriminately produces "over-restriction of simple agents, which slows delivery and drives shadow development, or under-restriction of more autonomous agents, which increases operational, security and compliance risk." The first half is the centre of excellence failure mode in one clause.

The second break is subtler. A central team can judge whether an agent is well engineered. It usually cannot judge whether the output is correct. Correctness lives in the domain. An agent summarising claims files is checked properly only by someone who reads claims files, and that person does not work in the central office.

Model 2: the platform owns the rails, the business unit owns the agent

The second model splits the four rights along a hard line. A platform team owns identity, credentials, logging, the evaluation harness and the ability to stop any agent. The business unit owns what the agent is for, whether it works, and the bill.

Where it works

Above roughly 10 agents across more than two domains, this is the only model I have seen scale. It removes the queue. A business unit needs no permission to build, only rails that already enforce the controls. My view is that the platform model is the only one that survives 20 agents.

It also puts the correctness judgement where the domain knowledge is. The platform team never decides whether a refund was justified. It guarantees that the refund was logged, attributable and reversible. That is the part which generalises, and the identity half of it is harder than it looks, as the piece on non human access and agent identity sets out.

Where it breaks

It breaks when the platform does not exist yet. Declaring a federated model before building the rails is the common expensive mistake here. Federated without a platform simply means nobody. Controls that were meant to be centralised are now absent everywhere, instead of present in one place.

The second failure is an incentive mismatch that tooling does not fix. The business unit captures the upside of an aggressive agent. The blast radius of a bad one is enterprise wide. Left alone, that asymmetry pushes every tenant toward more autonomy than the company would choose centrally. The counterweight is a named risk owner measured on something other than the agent's output. It also needs monitoring that survives the honeymoon period, covered in the piece on agent drift and the dashboard that stays green.

Model 3: ownership tiered by the agent's autonomy level

The third model stops asking who owns agents. It asks who owns this agent. Ownership escalates with what the agent can do, using a classification set at design time and re-checked at every material change.

Gartner's version separates two properties that are usually conflated. Autonomy is what an agent does without a human. Scope is the data and permissions it reaches. Its four levels run from observe, which is read only, through advise, then act with approval, then autonomous execution inside guardrails.

Levels follow Gartner's published four-level model. The ownership column is our allocation, offered as a starting default rather than a standard.

Where it works

It fits mixed estates, which is nearly everyone by the second year. A read only agent that drafts a summary and an agent that issues refunds should not pass the same review. One standard for both forces you to pick which of the two you are wrong about. Tiering matches the cost of control to the size of the consequence.

It also makes the approval question concrete. Level three works only if the approver has time to approve properly, an argument set out in the piece on human in the loop architecture. An approval step nobody reads is a level four agent wearing a level three label.

Where it breaks

Agents climb the levels quietly. A level two adviser gets a write tool added in a sprint. The classification is not revisited, because nothing in the release process asks. Six weeks later the agent is level four and the org chart still names a team lead.

The fix is mechanical. Tie classification to a code change rather than to a review meeting, so a new write scoped credential triggers reclassification automatically. I think tiering is the right default. I also think most companies will implement it badly, because the trigger is the part that gets cut for time.

The rule all three models share: name a person, not a department

Whichever model you pick, one control carries most of the weight. Each agent has a single named human who accepts its residual risk. That name is written somewhere an auditor could find it.

For high risk systems in the EU this is law, not good practice. Article 26(2) of the EU AI Act says deployers "shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support." The wording is deliberate. Not a committee, not a function, and not a person without the authority to stop the thing. The wider set of duties is set out in the EU AI Act transparency checklist.

The same test works outside that scope and outside Europe. If you cannot name the person who would be paged when an agent acts wrongly tonight, the agent has no owner. The diagram does not change that. What the named person does day to day is a real job now, described in the piece on hiring an agent ops engineer.

How to choose, and what each choice costs you

The decision turns on two numbers you already know. How many agents you run, and how many distinct domains they touch. Ambition does not belong in the calculation.

The third row is an overlay rather than an alternative. The real choice is between the first two, with tiering applied on top of whichever you pick. Spend your attention on the last column, because each of those signs appears months before the incident.

Cost ownership should follow risk ownership. If a function head signs for an agent, the token bill should land in that function's budget. The return should be measured there too, which is the argument in agent payback by function. Split those two and you get agents nobody will defend and nobody will switch off.

Where this argument is weakest

Three problems with what you have just read, stated before someone else states them.

Three models is a simplification

Real organisations run hybrids, and the hybrids are often sensible. A company may centralise customer facing agents and federate internal ones. That is neither model one nor model two. Treat the three as reference points for a conversation, not as a taxonomy anyone should defend.

The evidence is survey evidence

Every number here comes from a self reported survey or an analyst prediction. "Mature governance model" is defined by the respondent. Technology leaders made up 55% of one Deloitte sample, which tilts what counts as maturity. The Gartner 40% is a forecast about 2027, not a measurement of anything. Nobody has published a controlled comparison of ownership models against agent outcomes.

The case for leaving ownership vague

There is a real argument on the other side. Premature structure kills experimentation. A company with two agents that convenes a governance board has bought overhead it cannot yet use. Ambiguity is cheap and reversible early. So the honest version of this post's claim is narrower than its title. Ownership stops being optional when an agent can write to a system of record, and most companies cross that line without noticing. The other ways pilots die are catalogued in the piece on agent pilot failure modes.

Frequently asked questions

Where to start this week

Two exercises. Both take an afternoon, and neither needs budget.

First, build the four column list. One row per agent in production. One column each for who built it, who runs it, who signed for the risk and whose budget pays. Do it from memory, without asking anyone. The blank cells are the finding, and most of them will sit in the third column.

Second, run the reclassification test on one agent. Take the most autonomous agent you have. Check what it could do on the day it shipped against what it can do now. If those lists differ and nothing was re-signed in between, you know which model you are actually running.

Related reading