AI operating model: the blueprint every organisation needs

An organisation can have a clear AI strategy, decent data and real skills, and still be unable to deliver anything at scale. The missing link has an unglamorous name: the operating model. It is the set of answers to the boring but decisive questions — who decides, who builds, who runs, who pays, who answers when something goes wrong.

Those questions look secondary as long as you remain in experimentation. They become blocking from the first production release.

Three configurations exist, and choosing between them is not a matter of preference: it depends on the organisation's maturity and the nature of its use cases. The centralised model gathers AI skills in a single team serving every business unit. It guarantees technical consistency and cost control, but quickly creates a bottleneck: the number of projects that team can carry is finite, and the queue grows. The distributed model places AI skills inside each business unit. It brings the technology closer to the need and speeds up cycles, at the cost of a fragmentation paid for later — three different platforms, no reuse, multiplied costs. The federated model combines a central team owning platforms, standards and governance with counterparts in the business units carrying the use cases. It is the hardest to establish and the one most successful organisations converge on.

What distinguishes these models is not the org chart but how three specific responsibilities are allocated: choosing use cases, owning the technical platform, and owning the outcome in production. Organisations that struggle are almost always those where those three sit with three entities that do not talk to each other.

What follows is a recurring pattern, reconstructed from several contexts, not the portrait of one specific company. A mid-sized group creates a central data team of twelve. It quickly delivers convincing results on three use cases. Then demand explodes: every department wants its project. The team, overwhelmed, sets up a prioritisation queue. Eighteen months later, the average delay between a stated need and the start of work reaches seven months. Business units, tired of waiting, start contracting directly with external vendors. Two years on, the organisation runs four different AI platforms, none interoperable, and the central team spends most of its time trying to regain control of systems it did not build.

That is not a competence failure. It is an operating model that did not evolve at the pace of demand.

The point we most often press with executive teams is this: the operating model must be chosen for the next phase, not the current one. An organisation starting out is right to centralise — it does not have the volume to do otherwise. But if it does not prepare the shift to a federated model while things are going well, it will undergo that shift in crisis, at the moment the queue has become politically untenable. At KAIROS Impulse this anticipation is part of the framing work: we do not only design the arrangement for today, we define the thresholds that will trigger its evolution.

The second issue an operating model must settle is funding. As long as AI is paid for from a central innovation budget, business units consume without arbitrating: every project is free to them, so every project is a priority. Shifting to business-unit funding, even partially, transforms the nature of requests. Marginal use cases disappear on their own, without any committee having to refuse them. It is often the most effective governance decision, and the least popular.

Finally comes the question of production ownership, the most neglected of all. A model in production degrades: data shifts, behaviours change, performance drops silently. Who monitors it? Who decides to retrain? Who is called when a model produces a contested decision? In many organisations the honest answer is "nobody in particular". The team that built the model has moved to the next project, and the operations team does not know what it is watching. That is how systems keep running for months, producing increasingly inaccurate results, without anyone noticing.

Three questions test the soundness of an operating model. First, if a business unit wants to launch an AI use case tomorrow, does it know exactly who to approach and through what process? Second, who has the authority to say no to a use case, and is that refusal accepted? Third, for every model in production today, can we name the person accountable for its performance six months from now? If any of those answers is vague, the problem is neither technical nor budgetary. It is organisational, and no tool will solve it.