Designing an AI Operating Model That Survives Contact With the Business

Chief Transformation Officer (Multinational Services Group)

We are debating whether AI should sit centrally or inside the business units. The technology team wants a centre of excellence, the business heads want their own teams, and the CFO wants to know why we would fund both. How do I resolve this properly rather than politically?

AI Leadership Agent — Operating Model Advisory

Resolve it by splitting the question. Centralisation is not one decision, it is four, and the right answer is usually different for each.

1. Who decides what gets built and funded? Centralise early — scarce capacity should be allocated against enterprise priorities, not local enthusiasm.
2. Who builds? Start central, then federate as standards mature. A business unit that has shipped nothing cannot be trusted with its own delivery yet, and will resent being told so unless the path is explicit.
3. Who runs it in production? Almost always the business unit that owns the process. Central teams make poor permanent operators.
4. Who assures? Independent of both, reporting through risk. Never the builder.

The argument about centres of excellence is usually an argument about control, disguised as an argument about efficiency. Splitting the decision removes the disguise.

Which of those four is generating the most heat in your executive team?

Chief Transformation Officer (Multinational Services Group)

The second one. Our business heads believe a central team will be slow and will not understand their domain. Frankly, based on our shared services history, they have grounds. How do I make a central build function that they will actually want to use?

AI Leadership Agent — Operating Model Advisory

By making it earn demand rather than enforce it. A central function that survives on mandate becomes a bottleneck; one that survives on service quality becomes an advantage.

1. Publish a service commitment: how long from request to first working version, and report against it publicly every month.
2. Embed people. Analysts and engineers sit with the business unit for the duration of a build, not in a separate floor or country.
3. Let business units opt out if they can meet the same standards themselves — and make the standards concrete, so opting out is a real path rather than a trap.
4. Give the central team a platform mandate as its long-term value: shared evaluation tooling, data access, monitoring and reusable components, so the units get faster by using it.

A central AI function should be judged on how much capability exists outside it after two years.

What does your funding model look like — central budget, chargeback, or business-unit funded?

Chief Transformation Officer (Multinational Services Group)

Central for now, with pressure to move to chargeback next year. Is that the right direction, and what does the operating model need to look like before we can make that shift?

AI Leadership Agent — Operating Model Advisory

Chargeback too early kills experimentation, because business units stop asking questions they cannot yet quantify. Move to it once three conditions hold: the central team can deliver predictably, unit economics of a typical build are understood, and there is a shared prioritisation forum so chargeback does not simply mean the richest unit wins.

Before that shift, make the operating model explicit in writing: decision rights, funding routes, standards, escalation, and the criteria for a business unit to take on its own delivery. Ambiguity in an operating model is always resolved in favour of whoever has the most political weight, which is rarely the right answer.

Operating models fail quietly. Nobody rejects them; people simply route around the parts that were never made concrete.

Write it, socialise it, then review it in six months against what actually happened.