AI changes the work. Your operating model has to follow.

A target operating model is usually drawn as boxes and lines: the organisation chart, the core processes, the systems underneath and the governance on top. Strip away the slideware and it answers one question: how does strategy become the work people actually do on a Tuesday afternoon?

Most TOMs in use today were designed on one core assumption: people do the work, in sequence, handing it from one team to the next. AI breaks that assumption. Increasingly some of the work is done by an assistant, a workflow or a model. Decisions that took a week of handoffs can be made in minutes. And the hard part of many roles moves from doing the task to checking the output, deciding on its validity and handling the cases the system can’t.

A TOM drawn before that shift is a map of a country whose borders have moved. I’ve worked on operating models from growing businesses to global corporates and the same challenges turn up at every size. So do the same fixes.

AI doesn’t just change what happens inside the boxes. It changes what happens between them.

What to watch

The bolt-on

An “AI centre of excellence” appears as a new box on the old chart, squeezed in to satisfy the mantra that ‘we are an AI-first organisation’. Requests flow in from across the business, a backlog forms and within a year the centre of excellence has become another ticket queue. I’ve seen data, BI and AI teams each running their own queue for the same internal customers, with nobody owning the outcome across all three.

The headcount exercise

The redesign starts from a savings target and works backwards to roles. The first people to go are often the ones who quietly handle the exceptions, which are exactly the cases AI handles worst. Headline cost falls on paper, then the experience erodes: rework, complaints and workarounds drive costs elsewhere and organisations scramble to win back unhappy customers.

The technology-first model

A platform is chosen, then the operating model is retrofitted to suit it. Teams end up organised around a tool rather than around the customer journeys and outcomes the tool was meant to improve.

Governance theatre

Every AI idea goes to a steering group, a risk forum and an architecture board before anyone is allowed to try it. It feels safe. In practice it slows the low-risk work to a crawl while the genuinely risky work happens anyway, in personal accounts nobody sees.

The orphaned pilot

The pilot has a sponsor, a budget and a launch event, but no one who will own it on a wet Monday six months later. After the immediate hype, pilots without a run and adoption owner are the most common reason AI never makes it into daily work.

What AI changes in each layer of the TOM

• Process and work design. Work breaks into tasks and some tasks move to an assistant or a workflow. The exception queue becomes the real job, so design around the exceptions, not just the happy path.
• People and roles. Roles shift from doing to directing, checking and deciding. New accountabilities appear: journey owners, data owners for priority journeys and a named service owner for every AI capability in production.
• Decision rights. Your delegation of authority probably says nothing about software. A bounded agent acts within limits, much like a new colleague does. Someone has to set those limits, sign them off and review them.
• Data and technology. Data quality stops being an IT topic and becomes an operational one. If the data behind a journey isn’t owned, the AI built on it will confidently get things wrong, at great speed.
• Governance and risk. Controls need to be proportionate to the pattern – I call it appropriate governance: light for an assistant a person checks, heavy for an agent that acts autonomously. Release gates and run ownership become part of the model, not a project afterthought.
• Performance and value. Measures move from activity to outcomes. Benefits are tracked with Finance and the running cost of AI services sits in the business case from day one.

What to do

1. Start from the journeys and the work, not the org chart

Map the handful of journeys that matter most and the work that actually happens in them, including the workarounds and exceptions. The structure should follow the work, not the other way round.

2. Classify the work

For each step, decide whether it is human-led, AI-assisted with a person reviewing or AI-run with a person handling exceptions. The least autonomous pattern that does the job usually gives you the simplest operating model too.

3. Design a minimum viable operating model

Treat the TOM like a product, not a reorganisation. Design the smallest model that lets one priority journey run well with AI in it: who owns it, who decides, who runs it, how value is measured. Prove it, then extend it. A one-page model that works beats a hundred-page design nobody can follow.

4. Name an owner for everything that goes live

Every AI capability in production needs a service owner who accepts the monitoring, the incidents, the access and the running cost. If nobody will put their name to it, it isn’t ready to go live.

5. Borrow proven patterns, sized to your maturity

You don’t need to invent an operating model from scratch. When I designed the target model for a PE-backed technology distributor, we deliberately borrowed proven patterns: a commerce-style delivery engine organised around outcomes and speed, with fintech-grade controls for trust, audit and resilience. The aim is enough structure to deliver, and no more.

6. Sequence it, and keep it alive

A TOM for AI isn’t a single reorganisation. It matures alongside the capability: make the data trustworthy, make delivery repeatable, then scale where the value is proven. AI capability changes faster than org charts, so review the model every quarter: which work has moved, which roles have changed, which controls are no longer proportionate.

SME or corporate: same questions, different answers

The questions don’t change with size. Who owns the outcome? Who decides? How does work flow between teams? What changes is how much structure you can afford and how much you can’t afford to be without.

In an SME or scale-up

• Speed is your advantage, so protect it. Don’t import corporate governance. Decision rights should fit on a page, not in a manual.
• One leader may own several journeys. That’s fine, as long as it’s explicit and someone can say no.
• Buy and configure before you build. The tools you already license, plus a trusted partner, usually beat a new internal team.
• Founders are the hidden operating model. If every exception still goes to the founder, AI will speed up everything except the bottleneck.

In a corporate

• Set standards centrally, deliver in the journeys. A central platform, patterns and controls; delivery owned by the teams closest to customers.
• Watch the middle layer. The risk is rarely the strategy or the front line. It’s the approvals, forums and handoffs in between.
• Adoption needs a network, not a memo. In one large multi-site business, Copilot use grew from 25 superusers to more than 200 regular users because colleagues learned from colleagues.
• Regulators and auditors will ask who decided. Make sure your model can answer for automated decisions as clearly as human ones.

In a PE-backed business

• Design for the value creation plan, not the org chart. The model needs to deliver measurable value inside the hold period.
• Make benefits auditable. If the AI story is going into the investment case, the numbers need a baseline, an owner and Finance’s agreement.

Signs your operating model needs redesigning for AI

• Your AI centre of excellence has a backlog rather than an outcome.
• Pilots have sponsors but no service owner for production.
• Your delegation of authority is silent on automated decisions.
• Roles and job descriptions are unchanged after new tools went live.
• Several teams claim the same benefit… and Finance believes none of them.
• Nobody owns data quality for your most important journeys.

If AI is changing the work, the operating model has to change with it: deliberately, in sequence and designed with the people who do the work. Otherwise the organisation chart says one thing and Tuesday afternoon says another.