Item eight on the board agenda is one line long: "AI organization." A non-executive director who sits on two other boards opens it with the question asked in every boardroom on earth since 2024: "Should we have a Chief AI Officer?" The chief executive looks down the table at the transformation lead, who has spent two years building something that works and has no prepared answer to this. What happens next takes eleven minutes. The chief information officer says AI is fundamentally a technology capability. The chief operating officer says it is fundamentally a process capability. Someone proposes a center of excellence, which everyone agrees to because nobody can object to excellence. A box gets drawn, and that box, drawn in eleven minutes by whoever was in the room, shapes what this organization can do with AI for three years. This lesson is about not letting that happen to you.

The Box Nobody Designed

Org design for AI is where good transformations go to acquire permanent structural problems. Not because the choices are hard, but because of when and how the decision gets made: once, early, before anyone knows what the work involves, usually by whoever was available rather than by method. Then it hardens. A bad process gets fixed in a quarter; a bad org design gets defended for years by everyone whose job it created.

BCG's 10-20-70 rule puts roughly 10 percent of AI value in algorithms, 20 percent in technology and data, and 70 percent in people and process, which makes the org chart the most consequential people-and-process decision you will make: it decides who is allowed to do what. McKinsey's 2025 State of AI survey found 88 percent of organizations using AI somewhere but only about 39 percent able to point to any earnings-before-interest-and-taxes (EBIT) impact, with the high performers (roughly 6 percent) about three times more likely to have fundamentally redesigned workflows. Redesigning workflows repeatedly, across functions, against resistance, is not something a talented individual does. It is something an authority structure permits. That is part of why the failure record stays so consistent: MIT found 95 percent of enterprise generative AI pilots delivering no measurable profit-and-loss return, and S&P Global found 42 percent of companies scrapping most AI initiatives in 2025.

Chapter 5.1 gave you the four standing capabilities every functioning AI operating model contains: discovery (finding and qualifying what to do next), delivery (turning a qualified candidate into a running operation), governance (deciding what is allowed, gated, and accepted), and value tracking (proving what it produced). That lesson stopped short of where those sit on a chart. This one starts exactly there.

The wrong first question

"Do we need a Chief AI Officer?" is the wrong first question, and wrong in an instructive way. It starts with a title, which is a signal about seniority, then works backwards to what that person should do. Organizations that start there spend two years discovering what they built, usually at the moment something needs deciding and nobody can. The right sequence has three steps:

1. What work must happen? The four standing capabilities, plus the in-function work of running redesigned processes.
2. What authority does each piece of that work require? This is the analytical move almost nobody makes, and it is the whole lesson: authority is not one substance, and the four capabilities need four different kinds.
3. What is the characteristic failure mode of each place we could put it? Every structure works somewhere and fails somewhere. Choosing without naming the failure mode you are accepting is not a decision, it is a hope.

Answer those and the chart draws itself, including the Chief AI Officer question, which turns out to be a consequence rather than a starting point. Your artifact is the Org Design Options Table: four viable structures, each with what it is good at, its characteristic failure mode, when it fits, and the migration path out of it. That last column matters, because most organizations pass through two of these, and deliberate movers pay a fraction of what drifters pay.

Work Before Boxes: The Four Authorities

Take each capability and ask not "who owns it" but "what must it be able to do to function at all?" The answers are not interchangeable.

Discovery needs convening authority. Continuous discovery means someone can get a function head's attention, three process owners into a room for ninety minutes, and honest answers about where work is slow and painful. That power is social and positional rather than formal. Without it, discovery degrades into a pipeline made of whoever likes the AI team, the least representative sample of your estate available.

Delivery needs resource authority. Turning a qualified candidate into a running operation means committing named people for a quarter: a transformer, a process owner's time, a subject-matter expert, systems support. If delivery cannot commit them, every use case begins with a negotiation, and negotiations have a cost, a delay, and a failure rate. Programs that look slow are usually not slow at the work; they are slow at assembling permission to start it. The test unit is concrete: 0.6 full-time-equivalent (FTE) of a function's capacity for twelve weeks.

Governance needs decision authority. Governance that can only recommend is not governance. Its function is to say no to a use case, a vendor, or a launch and have the no stick without the sponsor going around it. That comes from named decision rights, budget control, or an executive who reliably backs the call. Without one of the three you have an advisory committee, and advisory committees are how the shadow AI estate grows.

Value tracking needs independence. This has been building across the program and now becomes an org-chart constraint rather than a principle. Whoever proves what the portfolio produced must not report to the person whose numbers they validate. Not because anyone is dishonest, but because the incentive is structural and everyone can see it, so the number is discounted before it is read. Measurement independence is not a personality trait. It is a reporting line.

The tension that is structural, not personal

These four authorities do not naturally coexist in one box, and the reason is the central problem of AI org design, misdiagnosed as a personality clash almost every time.

Delivery's core need is speed. Governance's core need is independence. Put them in one box under one leader and governance becomes a stage in delivery's process, which is to say a rubber stamp: the gate is chaired by the person whose targets depend on passing it. Put them far apart with no shared context and governance becomes a tollbooth: a queue, a form, and people who have never seen the work deciding about it. Both failures are structural, and neither is fixed by a more reasonable head of governance.

The resolution is to place the tension deliberately. Discovery and delivery belong close together and close to the business. Governance needs written decision rights and a line that does not terminate in the delivery leader. Value tracking sits outside the program, usually in finance. The rest of this lesson is where you put those seams.

Draw the authority before you draw the box. An org chart is not a statement of intent, it is a distribution of four specific rights: to convene, to commit, to refuse, and to count.

The Artifact: The Org Design Options Table

Four structures actually work in enterprises. Each is good at something real, each fails in a predictable way, and each fits a set of conditions. Your job is not to find the best one, because there is none. It is to name the one you are running, name its failure mode out loud, and know your migration path before you need it.

1. The central team

A dedicated AI or transformation function owns all four capabilities: it runs discovery, staffs delivery with its own people, chairs governance, and produces the value numbers. Functions are its customers. Early on this is usually correct: the method gets invented once rather than six times, and the two people who can genuinely redesign a workflow are not diluted across six functions.

Characteristic failure mode: it becomes an internal consultancy that functions resent and route around. Work is done to the function rather than with it, the pilot is nodded through because objecting is impolitic, and nothing is owned. When the central team moves on, the scaled system becomes an orphan whose exception paths and monthly checks belong to nobody, decaying quietly while the scorecard still reports its value. Worse, functions with budget quietly start their own AI work: the shadow estate arriving through the front door.

2. Federated

Each function owns its own AI work, with a small central standards role. The function that will live with the redesigned process builds it, so ownership and business fit are strong and there is no central queue. It fits only where functions have genuinely mature process capability and the standards role has teeth: veto rights on procurement, a mandatory register, and an executive who backs both.

Characteristic failure mode: eleven methods, incomparable measurement, duplicated vendor spend, and governance with no leverage. This is the Level 4 shadow-estate problem in structural form, built on purpose. Every function defines "baseline" differently, so the enterprise number cannot be added up; three functions buy overlapping tools at three price points with three sets of data-processing terms; nobody can tell a regulator how many AI systems you operate. And a standards role with no budget authority and no gate is a person sending emails about a template.

3. Hub-and-spoke

A central hub owns the method, the governance, the value tracking, and the career path. Embedded practitioners (the spokes) sit inside functions, report to the function for their day job, and relate to the hub through a dotted line. It delivers what the other three structures each get half of: method consistency plus business ownership. Most successful mid-to-large enterprises end up here, and knowing that in advance lets you plan the trip rather than stumble into it.

Characteristic failure mode: the dotted line is where accountability goes to die. A practitioner with a function boss who sets objectives and a hub that "provides guidance" spends all their time on function work within two quarters, because that is where their review comes from. The method decays, the hub becomes a support desk, and everyone keeps calling it hub-and-spoke while running federated. It works only under three administrative conditions: the embedded role has explicit split objectives (a written percentage of time and a hub-side deliverable inside the performance review), the hub owns the method, and the hub owns the career path, the strongest soft authority available in a dotted-line design.

4. Embedded, with a center of governance

Delivery is fully devolved and there is no delivery hub; the center retains only governance and value tracking. Once redesign capability genuinely exists in five functions, a central delivery team is a bottleneck rather than an accelerator. It fits only high maturity, where the method is institutionalized: written into standard operating procedures (SOPs), taught in onboarding, owned by process leaders whose titles do not contain the word AI.

Characteristic failure mode: method decay without a hub maintaining it, and a center that becomes a compliance function disconnected from practice. Methods are not self-sustaining: without an owner the gate standard drifts function by function, baseline discipline erodes first because it is the least fun part, and within two years you are federated with a governance committee attached. Meanwhile the center, with no delivery involvement, loses the context that made its decisions credible.

Migration: the trigger and the mechanics

Most organizations start central, and most should. The mistake is staying central past the point where central is the constraint, then migrating in a panic during someone else's reorganization.

The trigger is specific: when the central team's queue becomes the enterprise's constraint. Concretely, when qualified demand exceeds concurrent capacity by roughly two to one for two consecutive quarters, and the excess is real (charters written, sponsors committed) rather than enthusiasm. Every extra month of central-only delivery is then measurable value not captured, and, worse, functions start solving their own problem, which they will do with a vendor and without you.

The mechanics have three rules. Embed before you devolve: put practitioners into functions while the hub still owns delivery accountability, because devolving accountability before capability exists hands your program's reputation to people who have never run a gate. Move the method with the people: a practitioner arriving with no templates, gate standard, or baseline library invents local versions within a quarter, and local versions are how federated happens by accident. Keep governance central through the transition: devolving delivery and governance at once blinds you at the moment most things are changing.

Reporting Lines, Chiefs, and the Roles Themselves

Where it reports, taught as consequences

The reporting-line debate is usually a contest of preferences, each executive explaining why AI conceptually belongs to them. It is more useful as a contest of consequences, because every line biases the program's behavior predictably.

Two rules beat any debate. First: the reporting line should follow where the organization's bottleneck is, not where AI conceptually belongs. If nothing integrates and pilots die on systems boundaries, put it under technology and accept the framing bias, because the bias is cheaper than the bottleneck. If processes are undocumented and nothing gets adopted, put it under operations or transformation. If nobody believes the numbers, tighten the value-tracking line into finance rather than moving the whole function. The conceptual argument ("AI is a technology, therefore IT") is the least useful input available: true of everything, predictive of nothing.

Second: say the reason out loud when the decision is made, and put it in the charter. One sentence: "This function reports to the chief operating officer (COO) because our binding constraint is process ownership and adoption, not integration; we will revisit if that changes." That sentence costs nothing and converts a permanent political fact into a reviewable decision. Bottlenecks move; reporting lines almost never do, because nobody remembers why the line was drawn, so changing it looks like criticism rather than a response to a condition.

The Chief AI Officer question, answered properly

Now the board's question. A dedicated senior AI role (Chief AI Officer, or CAIO) earns its existence under three conditions, any one of which can be sufficient.

1. The work requires cross-functional authority no existing executive holds. If the agenda spans functions reporting to three executives whose only shared boss is the chief executive, every decision escalates to the CEO, and a role that can decide below that line pays for itself.
2. Regulatory or risk exposure needs a single accountable owner. If you will run systems under the EU AI Act's high-risk Annex III obligations from December 2, 2027, or a regulator has begun asking who is accountable for automated decisions, a diffuse answer is itself the finding. Accountability living in a committee is accountability a supervisor will not accept.
3. AI is genuinely strategic to the business model rather than operational. If the product changes, the pricing changes, or what you sell is different because of AI, that is a strategic agenda, and strategic agendas get executives. "We will run the existing business more efficiently" is operational, and belongs to whoever owns operations.

When none holds, two failure modes follow predictably. A senior role with no delivery authority becomes an evangelist: capable, visible, structurally unable to cause anything, so it produces the only outputs available to it, which are strategy documents, vendor relationships, and internal talks. A senior role duplicating the COO's or chief information officer's (CIO's) accountability creates a permanent boundary dispute: overlapping remits do not merge, they negotiate continuously, consuming the cross-functional energy the role was created to supply.

The honest alternative, right for most organizations, is an empowered transformation or readiness lead reporting to an executive who already holds the authority the work requires. It is faster to establish, easier to unwind or upgrade, and it borrows convening and resource authority from someone who has it rather than manufacturing it from a title. It converts cleanly too: if a condition later becomes true, you elevate someone with delivery credibility instead of hiring a stranger with an external profile.

The roles, defined by accountability rather than title

Titles travel badly between organizations; accountability statements do not. Here is what the chart actually contains, each role defined by the sentence that would be read out if something went wrong.

• Readiness / transformation lead. Accountable for the portfolio delivering value, the method being maintained, and the queue being honestly prioritized. Full time above roughly three concurrent efforts.
• Delivery transformer. Accountable for one use case getting from charter to running operation with gates genuinely passed and handover accepted. Full time, one per two concurrent efforts.
• Embedded process owner. Accountable for the redesigned process working after handover: exception paths, monthly checks, people. Part of an existing job, never a new one.
• Governance secretary. Accountable for a current register, complete gate packs, and every decision written down with its reasoning. Roughly 0.2 FTE at monthly cadence.
• Value analyst. Accountable for baselines existing before pilots start and for realized value being defensible to someone hostile. Roughly 0.5 FTE, reporting outside the program.
• Data steward. Accountable for the fitness of the data a domain's use cases rely on: definitions, quality, lineage, access. Named per domain, part-time.
• Champion network coordinator. Accountable for the friction stream of candidate problems and for turning champions into practitioners. Roughly 0.1 to 0.2 FTE, the highest-return fraction of a role here.

Size these from your operating model's arithmetic, not from benchmarks. Do not ask what percentage of headcount comparable companies allocate to AI; that number is unknowable and inapplicable. Ask how many concurrent efforts you intend to run, and the rest follows: transformers at one per two efforts, function capacity at roughly 0.6 FTE of process-owner and subject-matter time per effort, governance at 0.2 FTE, value tracking at 0.5 FTE, discovery at 0.2 FTE. If the total is unaffordable, run fewer efforts rather than staffing them at half strength, because a half-staffed effort usually delivers no value, slower.

Three Quarters to Hub-and-Spoke: A Worked Example

Return to the enterprise from Level 4: a 2,400-person business-to-business services and distribution company, six functions, one scrapped year of AI spending in its history, and now a converted operating model. All numbers below are illustrative and rounded.

Year one: central, by necessity, and correctly. One transformation lead and two delivery transformers owned all four capabilities, with a 0.5 FTE analyst on value tracking and the compliance manager on governance at 0.2 FTE. Nobody chose this from a menu; it was what could be staffed. It was also right: no function had redesign capability, and the method had to be invented once rather than six times.

Year two: the constraint appeared where the theory said it would. The central queue supported five concurrent efforts. Qualified demand, meaning charters written and sponsors committed, ran at nine, two quarters running. The lead did the arithmetic that matters: four qualified efforts not started, at an illustrative 60,000 dollars of annual run-rate value each, is roughly 240,000 dollars a year sitting in a queue. Meanwhile two functions had opened vendor conversations directly, which is what functions do when the queue outlasts their patience.

Quarters one to three: the migration, run deliberately. Four embedded practitioners were recruited, all from within functions and all from the champion network. Internal recruits arrived already trusted and already knowing their processes, at an illustrative 15,000 dollars in backfill and training against an estimated 40,000 dollars and three months of ramp for an external hire who would still have to earn credibility from zero.

Split objectives were written before anyone moved: 70 percent function delivery, 30 percent method and hub contribution, with hub-side deliverables named in the performance review (a gate pack meeting the standard, a documented method improvement, a quarterly practitioner-forum contribution) and the objective set signed by the function head. This administrative detail decides whether hub-and-spoke works, and it took one afternoon. The hub kept the method, the career path, governance, and value tracking, and gave away one thing: day-to-day delivery.

The value analyst moved to report into finance, structurally rather than cosmetically: objectives set by the finance director, no input from the transformation lead on the review. The effect showed up at the next quarterly review, when the chief financial officer (CFO) cited the realized-value number in their own board slide without qualification. The same number, from the same person under the old line, had been called "the program's estimate" a quarter earlier.

The board's CAIO question was answered with a reasoned no. The three conditions were tested in the open. Cross-functional authority: the COO already held five of six functions, so no gap. Regulatory exposure: real, but not yet high-risk under the EU AI Act's Annex III timetable, with a review point set for when classification work completes. Strategic to the business model: honestly, no. So the answer was a no with an alternative attached: the transformation lead's remit was formally expanded under the COO, the reasoning written into the charter, and a revisit trigger set if regulatory exposure grows or the agenda becomes product-facing.

The outcome. Concurrent capacity rose from five efforts to eight with no increase in central headcount: the four practitioners were funded from function budgets, backfilled at junior level, and represented roughly 2.8 FTE of net new enterprise capacity for an illustrative 190,000 dollars. The queue shrank from four waiting to one. And the next two use cases came from functions that had previously gone to vendors, not because they were told to, but because the practitioner sitting next to them was faster than a procurement cycle.

The failure story: the title without the authority

A different company, a similar moment, a different answer. A 6,000-person financial services group appointed a Chief AI Officer with a strong external profile: keynote reputation, impressive network, genuine expertise. The role came with a team of three, a modest budget, and a line into the chief executive alongside the COO and CIO. It came with no delivery resource and no gate authority.

For eighteen months it produced what a role with only visibility can produce: a group AI strategy presented twice, vendor relationships, a speaker series, a published principles document. Meanwhile actual AI work happened in three places: the contact center bought a summarization tool, credit operations ran a document-extraction pilot with a systems integrator, and marketing had used generative tools for eight months without telling anyone. None asked permission or shared method, baselines, or vendor terms. When the CAIO's team asked credit operations to route its pilot through governance, the request was received politely and treated as advisory, because it carried no budget and no consequence.

In month nineteen a reorganization arrived for unrelated reasons and the role was dissolved: the team absorbed into technology, the CAIO gone elsewhere, and the organization left with a conclusion that will cost three more years. The conclusion was "AI leadership doesn't work here." The diagnosis is more precise. The work required convening, resource, and decision authority; the role was given visibility, which is none of the three. Visibility gets you into rooms. It does not let you commit a person, start an effort, or make a no stick. They did not fail to find the right leader. They drew a box and forgot to put anything in it.

What to Do Monday Morning

Five moves, none requiring a reorganization, all doable in a fortnight.

1. Map your four capabilities to the authority each requires, before drawing any boxes. One page, four rows: discovery to convening, delivery to resource, governance to decision, value tracking to independence. Every gap you find is something that is currently not happening, and you will recognize the symptom.
2. Name which of the four structures you are actually running, and its characteristic failure mode. Not the one on the slide, the one in practice: if your practitioners are absorbed by day jobs, you are federated with a hub-shaped diagram. Then say the failure mode out loud in the next leadership meeting, which makes it something people watch for rather than something that happens to you.
3. Check the value-tracking reporting line. Does the person who proves the value report, directly or indirectly, to the person whose numbers they validate? If yes, fix that first. It is the cheapest structural change available and it changes how every number you produce is received.
4. Write split objectives for any dotted-line role you have: an explicit percentage, a named hub-side deliverable, and a signature from the function head. If you cannot get the signature, you have learned something important about whether the dotted line exists.
5. State why your reporting line is where it is, in one sentence, in the charter. Name the bottleneck it was chosen to address and the condition that would justify revisiting it. That is how a political fact becomes a reviewable decision.

Key Takeaways

• Sequence the decision correctly: what work must happen, what authority it requires, what failure mode each structure carries, and only then what title anyone holds.
• Map each capability to its authority: discovery needs convening, delivery needs resource, governance needs decision, value tracking needs independence, and the four do not naturally coexist in one box.
• Treat the delivery-versus-governance tension as structural: co-located, governance becomes a rubber stamp; too far apart, it becomes a tollbooth, and goodwill fixes neither.
• Use the Org Design Options Table to choose consciously among central, federated, hub-and-spoke, and embedded-with-center-of-governance, accepting a named failure mode rather than hoping you have none.
• Plan the migration before the queue forces it: watch for qualified demand at twice concurrent capacity for two quarters, embed before you devolve, move the method with the people, and keep governance central.
• Choose the reporting line by where the organization's bottleneck sits rather than where AI conceptually belongs, and write the reasoning down so it can be revisited when the bottleneck moves.
• Apply the three conditions before creating a Chief AI Officer, and default otherwise to an empowered lead under an executive who already holds the authority.
• Remember what an org chart is: a distribution of the rights to convene, commit, refuse, and count, which makes a box without authority a person with an impossible job.