AI operating model articles

Most stalled AI programmes are not blocked on technology. They are blocked because nobody can say who decides whether a system is allowed to touch customer data. Nobody owns the outcome once the pilot team moves on, either.

The glossary entry defines the term and names three questions: who chooses the work, who reviews it, and who runs it. If any of them answers with a team name instead of a person, the work will drift until someone senior gets nervous and stops it.

Choice comes first, and it is mostly a filter. A candidate process needs volume, a measurable outcome, and a tolerable failure mode. Volume, because a system used twice a week never accumulates enough signal to improve. A measurable outcome, because a metric you have to survey for cannot gate a release. A tolerable failure mode, because the first version will be wrong sometimes and you need to know what that costs.

Review comes second. It should be boring and written down: what evidence a launch needs, who signs, and what evidence would stop it. In practice this is a short checklist attached to the register entry, not a governance ceremony. The point is that the answer exists before someone needs it at eleven at night.

Ownership comes third and is the one that gets skipped. A pilot that reaches production without a named internal owner becomes shadow infrastructure: nobody updates it, nobody watches its cost, and its failure surprises everyone. Handover is a deliverable, and it only counts once someone is actually watching the dashboard.

This is also why fractional works for companies of this size. You need the decisions made properly once, written down, and handed to someone inside the company. You do not need a permanent executive to maintain four documents and a review checklist. An engagement that does not end has usually replaced an operating model rather than built one.