Almost every AI operating model conversation I have had this quarter ends in the same place. Somebody draws a box in the middle of the org chart and writes a name in it. A group AI function, owning the models, the shared prompts, the evaluation sets, the vector stores, and the review of anything that reaches a customer.
Then the box goes upstairs and does not come back approved. Not because the executive disagrees with the work, but because a new permanent central function is close to the most expensive thing anyone can ask for, and it arrives while every unit is holding its cost line.
The most useful document I own on that problem is not about AI at all. It is an organisation design, produced for a global payments acquirer and processor, for a unified digital estate: one corporate site and one consolidated social presence, replacing the arrangements several acquired brands had brought with them. Before the work started, the steering group had already ruled that there would be no group marketing function. The management would have to come from the business units that existed.
That ruling is what makes the pack worth reading now. It sets the exact problem an AI capability plan has today, and it was answered on paper without a central team.
What the ruling actually took away
The steering group did not say the units should go their own way. The design is explicit that they needed to work together, that this had to be formalised and managed, and that it spanned strategic direction, the prioritisation of development, adherence to common standards and guidelines, and combined investment. The requirement survived the decision intact.
What did not survive was the mechanism. With no group function there was no budget line, no reporting line and no permanent staff to carry any of it. So the design had to answer a different question from the one most operating model work answers. Not who should own this, but what has to be written down so ownership can be distributed without the thing falling apart. Coordination you cannot pay for with headcount has to be paid for with specification.
The split had to be made at task level, not at team level
The pack does not divide the estate into central work and local work at the level of a department. It does it at the level of individual tasks, and the results inside a single domain sit on both sides.
Content is the clearest example. Global content, content architecture and the guidelines themselves are pan-group. Owning local messages, updating local pages within those guidelines and running local sign-off are not. Analytics splits the same way, with best practice, common measurement method and overall site performance on one side, specific journey analysis and federated tool access on the other. Even governance splits: running the forums and the prioritisation process sits pan-group, holding a seat on those forums sits local.
Commercial ownership was the line the units would not give up, and the design does not ask them to. Stakeholder work found a common view that units should control their own customer journeys and how products are shown, alongside a recognition that some elements are part of the structure of the site itself and need consensus before anyone changes them. Filtering rules are the example given, and they are classified as global content for that reason.
Read that as an AI document and it stops being about websites. A shared retrieval index, a prompt library, an evaluation set and a guardrail list are structural in the same way. A unit changing how its own copilot answers its own users is local. A unit changing what the shared index holds, or what the evaluation set counts as a pass, is not, and if nothing says so in advance you find out when a number moves and nobody can say who moved it.
Governance was built out of people who already had jobs
The role catalogue is the part that surprises people when I put it up.
Eleven roles are defined. Two sit in obviously new territory: a digital leader who shapes the plan and gives the forum enough direction to make investment decisions, and a webmaster owning day-to-day site management and the interface into IT. A third, a programme office role, supports the leader in running the forum and manages prioritisation and the work request process, and the design assumes it comes from the existing change function.
Everything else already existed. The commercial leader, the marketing and social manager, the content publisher, the analytics manager, the architect acting as design authority. Some are marked as modified. None are marked as invented.
That is what a no-central-team design looks like done honestly. The output is not an absence of governance. It is governance assembled from named individuals who keep their day jobs, plus a small number of genuinely new posts, plus a written statement of who owns what. The headcount arithmetic follows: one to two extra full-time equivalents net, a net that already accounts for two existing roles coming out in one unit, with a caution that upgrading some roles carries cost the number does not show.
I would rather hand an executive that page than a request for a department.
Four shapes, and the failure mode you are choosing between
The pack does not land on one answer. It lays out four ways the same tasks and roles could be configured and sets pros against cons for each: a centre of gravity in one lead unit, responsibility shared between units with a thin group layer, the leadership roles concentrated in one place, and leadership distributed by topic.
I will not map individual pros and cons back onto particular shapes, because that page is a diagram and the order its text extracts in is not evidence of which block sat where. What is recoverable is the register of criticisms. Fragmentation and difficulty driving consistency. Duplicated skills, or gaps where skills were assumed. Undue influence by one unit over the others. Accountabilities spread so wide that presenting one story into an investment decision becomes work in itself. And the observation that with no leadership the loudest voice wins.
Every one of those is a live risk in AI adoption right now, and the last one is the most common. A federated capability with no written standard does not stay neutral. It converges on whoever is most confident in the room.
- No group function
- The ruling the design had to work within
- 9 domains
- Task split written pan-group against local, task by task
- 8 of 11 roles
- Already existing in the organisation
- +1 to +2 FTE
- Net headcount effect of the proposed model
Why this reads as an AI governance document
The estate governed here was a website and a set of social channels. Swap the nouns and almost nothing in the logic changes.
Take the working assumptions. Hosting was a vendor arrangement for the next eighteen months or so, with no plan to build deep platform capability internally, first-line support parsing queries and routing them, and development treated as a work request, resourced as necessary. That is the honest shape of most AI estates I see. The internal capability is thinner than the ambition, and pretending otherwise is how governance designs die.
Take the transitional period. The pack proposes one running for a few months past launch, and is candid about why: the model had been presented but not approved, roles were partly in place with gaps and upskilling needed, and momentum had to hold while the permanent structure was agreed. The tasks listed for that window are the ones that matter. Set up the forums. Define the methods, including prioritisation and content workflow. Take on technical ownership and name the liaison points into the vendors. Set up the reporting. Develop the standards, then communicate them.
That is a data readiness and lineage programme wearing different clothes, and it is the work to do before any carefully scoped autonomous experiment is worth running. With the European AI act now having reached political agreement, being able to say who approved a change, against what standard, and where the evidence sits will stop being a matter of taste.
The executive did not remove the need for coordination. It removed the option of buying coordination with headcount, which left one way to produce it: write it down, name who owns each written thing, and put a forum around the parts that cannot be owned alone.
What I would write down first
The design was a recommendation, not an implementation. It was heading to the executive team precisely because it carried people and budget implications, and approval had not been given when the pack was written. Read what follows as the method that survives, not as a proven result.
Sort your AI tasks into what a unit may change alone and what needs consensus, at task level rather than by team. Name the shared objects that are structural, the retrieval sources, the evaluation sets, the guardrails, and put a forum around changes to them. Write the standards as something a unit can use rather than something a centre enforces, because there is no centre. Give every shared object a named owner who has a day job, and accept that this is a real claim on their time. Stand up one prioritisation route so competing requests meet each other before they meet the budget. And keep the new headcount ask small enough to survive contact with the executive.
None of that is exotic. It is the answer this organisation reached about a website, under the same constraint, and it does not wait on a function nobody is going to fund.
Drawn from an operating model and organisation design pack produced for a global payments acquirer and processor: its task split, role catalogue, configuration options, headcount effect and transitional plan. That pack was a recommendation heading for executive sign-off, not a structure in place. Reading it as an AI governance document is ours.
“The executive did not remove the need for coordination. It removed the option of buying coordination with headcount, which left one way to produce it: write it down, name who owns each written thing, and put a forum around the parts that cannot be owned alone.”
Get in touch
Put RealAI’s applied-AI team on your hardest data problem.
We help enterprises move from pilots to production: sovereign models, governed data, and agents you can audit. Start with a value-first assessment.