What an AI Operating Model Actually Looks Like

Strategy is the easy part

Most organisations we meet have an AI strategy. It is usually a well written document with a vision statement, a list of use cases and a maturity curve borrowed from a vendor deck. What almost none of them have is an AI operating model.

The distinction matters. Strategy answers what we are trying to win. The operating model answers how work actually gets done once the strategy is agreed: who decides, who builds, who approves, who pays, and what happens when something breaks. Strategy without an operating model produces pilots. It rarely produces production.

Six components that decide the outcome

1. Decision rights. Who can approve an AI use case, and at what value threshold? In most organisations this is undefined, so every idea escalates to a committee that meets monthly. The single fastest improvement available to most executive teams is a published threshold: under this number, a business unit leader decides; over it, the executive decides.

2. Demand intake. AI demand arrives from everywhere at once. Without one intake path, the loudest sponsor wins rather than the highest value problem. A simple queue with a standard one page brief, scored on value and feasibility, changes the mix of what gets built within a quarter.

3. Data ownership. Every stalled AI project we have reviewed traces back to a dataset with no accountable owner. Name an owner per critical dataset, with a defined quality standard, before you commission the model that depends on it.

4. Build and buy rules. Decide in advance which categories you will buy, which you will configure and which you will build. Without that rule, the organisation quietly builds commodity capability at bespoke cost.

5. Assurance. Risk, privacy, legal and security need a proportionate path, not a single heavyweight gate. Tier your review: low risk internal productivity tools move fast, customer facing or safety related systems get the full treatment.

6. Funding and benefits. Fund a portfolio, not projects. Require every use case to name the decision it improves and the measure that will move. If nobody can name the measure, you have a demo, not a use case.

Where StratDo® fits

In our work these six components map directly onto the StratDo® approach. DEFINE sets the problem and the value at stake. DECIDER establishes who holds the decision, and importantly that there is only one decider. DECIDE structures the choice between options rather than defending the first idea. DIRECT converts the choice into intent and OKRs so delivery teams know what good looks like. DO is where the build happens against a plan. REFLECT closes the loop and feeds the next cycle.

The point of the sequence is not process for its own sake. It is that the expensive failures in AI happen at the front, in the choosing, and are only discovered at the back, in the building.

A practical test

Ask your executive team to answer these in one sitting, without preparation:

What are our three highest value AI use cases, ranked by value at risk?
Who is the single decider on each?
Which dataset does each depend on, and who owns it?
What is the approval threshold below which a leader can simply proceed?
What did we learn from the last AI initiative we stopped?

If the room cannot answer, the constraint is not technology, budget or talent. It is the operating model. That is good news, because operating models can be redesigned in weeks.

Where to start

Do not start with a platform selection. Start with a single high value decision that is currently made slowly or badly, and redesign the way that decision is made, with AI as one input among several. Get it into production. Then use the mechanics you built to run the next one. Ten use cases delivered through one repeatable path will beat fifty pilots delivered through none.