One named person should own AI, not a committee. Small companies give the seat to an existing leader plus team champions. Larger ones add a small central team that teaches, then steps back.
A Chief AI Officer fits only when AI is a board-level risk, with real budget. After launch, the team that runs the work owns each automation.
Picture the Monday leadership meeting. Someone asks who owns AI here.
Five people raise a hand. Or nobody does. Same result either way.
The tools are bought. Every team runs its own tests. Nobody can say which tools touch customer data, or who fixes them when they break.
So the debate starts. Do we hire a Chief AI Officer?
Do we build a center of excellence? Or ask each team for a champion?
Here is our answer, up front. Give the AI seat one name. Then pick a team shape by size and stakes.
Build any central team to teach until it is no longer needed. And one rule holds at every size: after launch, the team that runs the work owns the automation.
Running a team of five? You already own AI. Read the handoff rule and skip the rest.
The team shape follows how big you are and how much AI can hurt you
Our rule, set out in this guide.
AI ownership is a seat with one name in it. Not a council. Not a task force.
Gino Wickman builds companies in Traction on what he calls an accountability chart. Every function is a seat, and every seat holds one person.
His test is blunt. When two people share one seat, nobody really owns it.
One person can hold two seats. Two people cannot hold one.
So the AI owner can be your COO, your head of operations or your CTO. The title is optional. The name is not.
Each seat on that chart also carries five main roles. The table below shows the five we write into an AI owner seat, including the weekly cost of AI use.
The US federal government reached the same answer. A federal memo on AI use gave every agency head 60 days to name one Chief AI Officer.
It let agencies pick an existing official, like the chief information officer, if that person has real AI expertise. The owner must sit high enough to meet the agency's top leadership on a regular basis.
If the seat goes empty, the agency has 30 days to report it. The owner also keeps the list of every AI use.
You cannot own what you cannot list. A responsibility chart with one name in the accountable column beats a monthly AI council that owns nothing.
A council meets. An owner decides.

One name, five roles, one weekly number
| Role | What the owner does | What it prevents |
|---|---|---|
| Keep the list | Every AI tool and automation, with the team that owns it | Tools nobody can account for |
| Set the rules | Which data AI may touch, and which uses need review | Customer data in the wrong tool |
| Pick shared tools | Vendors and contracts, chosen with the council | Five teams paying for the same thing |
| Run the handoff | No launch without the three signatures | Orphaned automations |
| Report one number | One weekly number plus AI cost, to leadership | AI as a feeling, not a result |
Seat structure (one name, five roles) from Traction's accountability chart; the five AI roles are ours.
The federal rule: one named owner, fast, and a seat that never sits empty
Source: Office of Management and Budget, Memorandum M-25-21, section 3, April 2025.
One government rule: one named AI owner, fast, close to the top

Screenshot of Office of Management and Budget Memorandum M-25-21 (April 3, 2025), section 3(a)(i), pages 10 and 11, taken 2026-10-18.
The Deployment Handoff gives AI one named owner and hands every build to the team that runs the work. One name holds the AI owner seat and its five roles. The team shape follows size and stakes: champions and a part-time owner, then a small central team that teaches and plans its own end, then a Chief AI Officer only with budget.
No automation goes live without three signatures: the builder (it works), the business owner (I own it and its number), and the evaluator (its check runs).
Most companies do not need a Chief AI Officer. They need an owner with the authority to say no.
Pick the structure by size and stakes. Here is our rule.
Under about 200 people: an existing leader owns the seat part-time, and each team names a champion. Cheap, fast and close to the work.
About 200 to a few thousand people: add a small central team of two to six. It sets standards and teaches. It does not approve every idea.
Thousands of staff, or a regulated business: a Chief AI Officer earns the seat. Only with a budget and a mandate.
A Chief AI Officer with neither is a press release. A title is cheap. A budget is a commitment.
The title is spreading anyway. An IBM survey of CEOs found 76 percent of surveyed organizations had a Chief AI Officer, up from 26 percent a year earlier.
Here is the part that surprises people. IBM itself has no Chief AI Officer. Its people point to a senior vice president of transformation and operations as the one who does the job.
IBM's own researchers say the role is moving from ownership toward coordination. The company that counted everyone else's Chief AI Officers does not have one.
Three in four surveyed firms report a Chief AI Officer, up from one in four
Share of organizations in IBM's CEO survey with a Chief AI Officer
Source: IBM Institute for Business Value CEO study, IBM Newsroom, May 2026. Survey of CEOs; IBM itself has no Chief AI Officer.
A title without a budget is a press release
| A Chief AI Officer title only | A real AI owner |
|---|---|
| Announced to signal seriousness | Named to make decisions |
| No budget of its own | A budget and a mandate |
| Advises when asked | Can stop a bad idea |
| Owns every AI project | Owns the rules; teams own the builds |
Our rule, set out in this guide.
Central team or every team on its own? You end up with both.
A fully central AI team gets slow. Fully separate teams waste money and repeat each other's mistakes.
Andy Grove saw the same split at Intel. In High Output Management he argues that every large company with one business purpose ends up as a mix of the two.
What does the central side give you? Scale, the power to move people and money where they are needed, and one expert's know-how spread across every unit.
Separate units give you one thing. They stay close to the customer and change fast.
Only one thing. But speed matters so much that most of any company ends up organized close to the work.
His advertising example is the cleanest model for AI we have read. Each division wrote its own ad messages.
A council of the division marketing managers, chaired by the central function, picked the agency and set the shared look. No division hired its own agency.
Swap advertising for AI and you have the answer. Teams decide what to use AI for. A small council picks the vendors, the data rules and the shared tools.
That council is your center of excellence, in our reading. A peer group. Not a gate.
Structure shapes the result, too. Conway's law says a system ends up copying the way its builders talk to each other.
Teams decide the uses; a small council decides the shared parts
| Decision | Who decides |
|---|---|
| Which tasks to automate | The team that does the work |
| Prompts and workflow details | The team that does the work |
| The weekly number for each workflow | The team, reported to the AI owner |
| Vendors and contracts | The council, chaired by the AI owner |
| Data rules and review steps | The council, chaired by the AI owner |
| Shared tools and logging | The council, chaired by the AI owner |
Our split for AI, adapted from Grove's advertising council in High Output Management.
Fully central gets slow; fully separate gets wasteful
| All AI run centrally | Every team on its own |
|---|---|
| One queue for every idea | Five teams buy the same tool |
| Experts far from the customer | Close to the customer, and fast |
| Teams route around it | Nobody sees the whole risk |
| Grows a backlog | Repeats the same mistakes |
Our summary of the trade-off Grove describes in High Output Management.
A central AI team should be built to disappear. If teams still need it after a few months, it failed.
That idea comes from Matthew Skelton and Manuel Pais, in Team Topologies. They call it an enabling team: specialists who coach other teams and do not do the work for them.
The book is about software teams. The pattern fits AI almost exactly. That is our reading, not theirs.
One case in the book shows the method. An enablement team at a large legal firm published a charter with an eight-week window and four numbers it promised to move.
It planned for its own end from day one. About a quarter of its time went to building. The rest went to teaching.
The authors also warn what happens without an end date. The helper team turns into one more silo that every project waits on.
Teams do not wait at a gate. They find the gap in the fence. That is how shadow AI starts.
The book has a bigger case, too. IBM spread new delivery practices to 40,000 developers with a handful of full-timers and some part-timers, who planned to be unneeded within a few years.
A central team that does all the AI work is like a coach who plays every position. The team never learns the game.
The central team publishes an end date before it starts
Our AI version of the enablement charter in Team Topologies (eight weeks, four published metrics).
A quarter of the time building, the rest teaching
Source: an enablement team's estimate, Team Topologies (Skelton and Pais). The 75 percent is the remainder.
Four numbers our AI charter publishes
| Number | Why it matters |
|---|---|
| Workflows live and owned by a team | Shows the work left the center |
| Hours saved per week, measured by the team | Shows the work paid for itself |
| Days from idea to live workflow | Shows the team got faster |
| Share of live workflows with a working check | Shows the work can be trusted |
Our AI version of the four metrics in the Team Topologies charter, which tracked software deployments.
Champions are your community of practice: people from many teams who meet weekly or monthly to share what works. They need hours in writing, or the program is just a pep talk.
The central team works on this full-time. Champions do it beside a day job. Both can run at once.
The day job is the real limit. Everyone already has one.
Three moves beat it. Buy time: champions get 10 to 20 percent of their week, written down, and their manager protects it.
Rotate: a two-quarter tour on the central team turns a line employee into a trained owner. They carry the skill back.
Sequence: automate the champions' own busywork first. The program then pays for its own hours.
Grove had a model for this double life. His process engineer spent 80 percent of her time in one plant and met monthly with her peers from every plant.
In her main job she improved one plant. Through the monthly group she shaped all of them. A good champion works the same way.
Is enthusiasm a plan? No. Pep talks fade. Calendars hold.
When champions stall, look at the work first. Many stuck rollouts are operations problems dressed up as AI problems.
The central team goes deep with one team; champions spread wide
| Central enabling team | Champions (community of practice) |
|---|---|
| Full-time on it | Weekly or monthly, beside a day job |
| One or two teams at a time | Many teams at once |
| Ends when the team stands alone | Runs as long as people show up |
| Builds skill by working beside a team | Spreads what already works |
Based on the enabling team vs community of practice comparison in Team Topologies.
Three moves that give champions real time
Our rule, set out in this guide.
The costliest AI org mistake is a central team that owns every automation forever.
Central builds it. Central ships it. Central maintains it.
Every win turns into upkeep. The upkeep never leaves the center, and the backlog grows until new work stops.
The Deployment Handoff is our rule that nothing goes live without three signatures. The builder signs that it works.
The business owner signs that they own it now, including its number. The evaluator signs that its check exists and runs.
Need that check? Start with how to evaluate AI agents.
If the business team cannot own it, it is not done. Shipped, maybe. Done, no.
Owning a build is not the same as working alone. Traction says the chart shows who owns what, not who may talk to whom. Help should still cross every line.
How to build an AI bottleneck in four easy steps:
1. Hire one AI person. Call them the AI team.
2. Send every idea through their inbox.
3. Let them keep every automation they ship.
4. Act shocked as hell when teams buy their own tools.
That is not an AI program. That is a waiting room.
Nothing goes live without three signatures
Our rule, set out in this guide.
When the center keeps every build, the backlog wins
| Center keeps every build | Team that runs the work keeps it |
|---|---|
| Each win adds central upkeep | Upkeep sits with the people who use it |
| New work waits behind old fixes | The center moves on to the next team |
| Nobody close to the work owns the number | The number sits with the team that moves it |
Our rule, set out in this guide.
A finished handoff: one automation, three signatures, one owner and one number

Example page built for this article with a made-up brand. Names, dates and numbers are illustrative.
AI needs a leader's support, but a strong leader alone does not get results.
The Accelerate research team found this in software teams. Teams with the weakest leaders, the bottom third, were half as likely to rank as high performers.
The surprise was at the top. Teams with the strongest 10 percent of leaders were no more likely to be high performers than everyone else.
Why? Leaders get results through what their teams do every day. Those daily practices do the heavy lifting.
ING, the Dutch bank, shows the shape in the same book. A squad of five internal coaches coached the leaders, and those leaders coached their own teams.
The chapter's advice is plain. Do not hand the change to a large consulting firm. Grow your own coaches, even if outside help gets you started.
We apply that to AI, and this part is our reading. The owner's job is to make good practice easy, not to be the best AI user in the building.
Leaders open the door. Teams still have to walk through it.
Weighing outside help? Read AI consultant vs in-house team before you sign.
Weak leaders hurt; strong leaders alone do not save you
| Finding | Where it comes from | How sure |
|---|---|---|
| Teams with bottom-third leaders were half as likely to be high performers | Accelerate, surveys of software teams | Survey research, software only |
| Teams with top 10 percent leaders were no more likely than average | Accelerate, same surveys | Survey research, software only |
| Five internal coaches coached leaders, who coached their teams | ING case, Accelerate chapter 16 | One company's account |
| Applying it to AI ownership | Our reading | Our inference, not the book's finding |
Sources: Forsgren, Humble and Kim, Accelerate (IT Revolution); chapter 16 by Steve Bell and Karen Whitley Bell.
Paste the prompt below into your preferred AI. It asks about your size, your risks and who runs AI work today.
Then it names the seat, picks the team shape and lists every live automation that still needs an owner.
It never invents names or numbers. You bring the facts. It brings the structure.
Paste into your preferred AI. It asks five questions, then gives you the owner, the team shape and a list of unowned automations.
Act as an operations advisor. Help me decide who owns AI at my company, using the Deployment Handoff method. Ask me these one at a time, with the example. If I answer several at once, skip ahead. 1. How many people work here, and in what industry? (Example: 140 people, home services) 2. Does any AI use touch regulated or risky ground, such as health, money or customer data? (Example: call recordings with customer phone numbers) 3. Who runs AI work today, and for how many hours a week? (Example: our ops manager, about 5 hours) 4. Which leaders could own the seat? Give each one's role, AI skill, and whether they meet the top team every week. (Example: COO, uses AI daily, yes) 5. List every AI tool and automation in use, and the team that uses each. (Example: call summaries, sales team) Rules: - One name per seat. Never a committee. One person may hold two seats. - An existing leader may own the seat if they know AI well and meet top leadership regularly. - The seat's five roles: keep the list of every AI use and its owner; set the data and review rules; pick shared tools and vendors; run the handoff; report one weekly number and the AI cost. - Under about 200 people: an existing leader part-time, plus one champion per team. About 200 to a few thousand: add a central team of 2 to 6 people that teaches and does not approve every idea. Thousands of staff, or regulated: a Chief AI Officer, only with a budget and a mandate. - Any central team gets a written charter: an end date (start with 8 weeks per team), four published numbers, and most of its time spent teaching. - Champions get 10 to 20 percent of their week, in writing. - Every live automation needs three signatures: builder (it works), business owner (I own it and its number), evaluator (its check runs). Any missing? List it as unowned. - Never invent names, hours or numbers. Ask me. Answer in this format: AI owner: [name, role, why] Seat roles: [five lines] Team shape: [model, and why] Central team charter: [end date, four numbers] or "not needed yet" Champions: [team, name, hours] Unowned automations: [list] Next three actions: 1. 2. 3.
1. Write one name in the AI owner seat, with its five roles. Tell the whole company who it is.
2. List every AI tool and automation in use. Put a team's name next to each one.
3. Pick the first automation with no owner. Run the three-signature handoff on it.
Back to that Monday meeting. Next time someone asks who owns AI, one hand goes up.
Want to see where ownership sits among the other things to get right? Our AI maturity model scores it as one of six. The next problem is the rules your owner will enforce.
A title is a nameplate on a door. An owner is the person who answers when something breaks.
Bring one question from this article. We will tell you what we would do, whether or not you hire us.
Book a 15-Min Chat →