Prepare your organisation for Enterprise AI with Versatile Consulting
AI Operating Model: Designing How Humans and AI Work Together
Most organizations now have AI tools. Far fewer have redesigned how decisions get made, where human judgement sits, and who is accountable once machines perform part of the work. That redesign is the operating model.
Versatile designs AI operating models for organizations that have moved past experimentation and need the work itself restructured around it.
What Is an AI Operating Model?
An AI operating model is the design of how an organization’s work, decisions and accountabilities are arranged when artificial intelligence performs part of that work. An AI operating model specifies which tasks are executed by AI, which remain with people, how work passes between them, and who is accountable for the result.
An AI operating model is not a tool selection, a technology stack or a set of use cases. Tools determine what an organization can automate. An AI operating model determines how the organization actually runs once it does.
Five things get defined:
- Work allocation — which tasks sit with AI, which stay with people, and on what basis.
- Handoffs — where work passes between machine and human, and what travels with it.
- Decision rights — what AI may decide alone, what needs approval, what stays human.
- Accountability — who answers for an AI-assisted outcome when it is questioned.
- Roles and capabilities — which roles change, and what people need to be able to do that they could not do before.
A target operating model describes the destination for an organization as a whole. An AI operating model applies the same discipline to one condition: part of the work is now performed by machines, and the organization was not designed for that. Both are built with the same method — see our approach to target operating model design.
Control and auditability sit alongside this work rather than inside it. How AI decisions are governed, evidenced and reviewed is covered in auditable, human-governed AI.
Why AI Programmes Stall After the Pilot
- AI produces output that nobody is authorized to act on without a person redoing the work.
- Different teams have reached different conclusions about what AI is permitted to do, and none of them is written down.
- Approving AI-assisted work takes longer than producing it manually used to.
- The same argument about permissions, risk and ownership is repeated for every new use case.
- Nobody can say which role answers for an AI-assisted outcome that turns out to be wrong.
Enterprise AI adoption stalls at the transition from pilot to operation. A pilot succeeds under conditions the organization does not normally provide: a small team, a contained process, and direct access to the people who can approve exceptions. Scaling removes all three at once. The pilot did not fail — it was never operating under the conditions production imposes.
Four constraints appear at that transition. None is technical.
What an AI Operating Model Redesigns
Designing an AI target operating model means making four decisions explicit that most organizations currently make by default, one use case at a time. Made deliberately and once, they hold across every use case that follows.
1. Work allocation: what AI does and what people do
The allocation question is not which tasks AI is capable of performing. It is which tasks the organization is prepared to have performed without a person in the middle. The second question is answered by consequence: how reversible the outcome is, how visible an error would be, and how much the judgement involved depends on context the model cannot see.
Allocation done well produces a defensible line rather than a list. New use cases are then classified against the line instead of being relitigated one at a time.
2. Handoffs: where work passes between people and machines
Most of the value lost in AI-assisted processes is lost at the handoff. Output arrives without the context needed to act on it, or arrives to someone who has to reconstruct the reasoning before they can approve it. Both convert an automated step into a slower manual one.
A handoff is designed when three things are specified: what triggers the pass, what information travels with the work, and what the receiving side is expected to do with it — verify, approve, act, or escalate.
3. Decision rights: what AI may decide alone
Decision rights determine whether an AI operating model produces speed or produces review queues. Three positions cover most cases: decisions AI executes autonomously, decisions AI prepares for human approval, and decisions that remain entirely human regardless of what the technology can do.
The third category is a deliberate choice, not a limitation. Some decisions require an accountable person for reasons that have nothing to do with capability — regulatory exposure, contractual commitment, or the fact that someone must be answerable to the person affected by it.
4. Roles and structure: what the organization looks like afterwards
AI changes the shape of roles before it changes the number of them. Work that was junior-heavy becomes review-heavy. Coordination roles that existed to move information between teams lose their reason to exist. Supervisory spans widen because output volume no longer tracks headcount.
An AI organizational structure that reflects this is designed rather than discovered. Left undesigned, roles absorb AI informally and job descriptions drift away from the work people actually do.
Accountability is not a fifth decision taken after the other four. Accountability is what the other four produce. An organization that has not decided work allocation, handoffs, decision rights and role design deliberately does not have an accountability gap — it has an operating model that assigns accountability by accident.
Human–AI Collaboration: Designing the Working Relationship
Human–AI collaboration is the arrangement by which people and machines contribute to the same piece of work. Effective human–AI collaboration is a design outcome, not a cultural one: it depends on whether each side can see what the other did, whether the human retains the ability to disagree, and whether the work is structured so that disagreement is cheap enough to be exercised.
Most organizations treat this as an adoption problem and address it with training. Training explains how to use the tool. It does not establish what a person is supposed to do when the tool is confidently wrong, whose judgement prevails, or what happens to the person who overrides the machine and turns out to be right.
Augmentation, not substitution
An AI-augmented workforce is one where the capability of a role has changed, not one where the role has been partially replaced. Substitution removes a task and leaves the rest of the job untouched; augmentation changes what the whole role is for. A reviewer who now checks machine output rather than producing the work is not doing less of the same job — they are doing a different job, one that demands judgement at a rate the previous job never required.
Roles designed as substitutions tend to hollow out. The interesting work goes to the machine, the residual work goes to the person, and the person stops developing the expertise the review step depends on.
Where the human keeps authority
Human–AI teaming works when the conditions for overriding the machine are known in advance. When they are not, one of two failure modes appears: either people defer to output they have no basis to trust, or they check everything and the organization pays for the technology twice.
Retaining authority requires three things to be true. The person can see enough of how the output was produced to judge it. They have the standing to reject it without escalation. And rejecting it is not treated as a failure of the programme. The third condition is the one most often missed, and it determines whether the first two are real.
Building the judgement the model cannot supply
Every AI-assisted process depends on human judgement at some point, and that judgement is usually built by doing the work the machine now does. This is the structural problem inside human–AI collaboration: the tasks that develop expertise are frequently the first ones automated, and the capability erodes on a delay long enough that nobody connects the two.
Organizations that handle this well decide deliberately which work stays human in order to keep a capability alive, rather than allocating purely by efficiency. That decision belongs in the operating model, because it is the only place where it can be made once rather than defended repeatedly.
When AI agents act rather than advise
An agentic AI operating model is required when AI takes actions rather than producing output for a person to act on. The difference is structural, not technical: assistive AI keeps a human in the loop by default, because someone must do something with the result. AI agents remove that default. With agents, human involvement exists only where it has been deliberately designed in.
For organizations deploying AI agents in the enterprise, this inverts the burden. Oversight stops being a by-product of how the work already flows and becomes something that has to be actively built, and every place it is not built is a place the organization has decided, usually without noticing, that it does not need any. Accountability follows the same shift: an agent performs sequences, and by the time an outcome is questioned the person who authorized the first action did not see the fourth. The practical allocation criterion becomes reversibility rather than capability — what it costs to undo what the agent did, not how well it did it. Accuracy is measured on average; reversibility is paid case by case.
What "AI-first" and "AI-native" actually mean for an established organization
An AI-native operating model is one designed on the assumption that AI performs part of the work, rather than one adapted after the fact. For a company founded in the last two years, that is a description. For an established organization it is an aspiration that needs translating, because the existing structure was designed under different assumptions and most of it will not be rebuilt.
The translatable version is narrower and more useful: an AI-first operating model is one where a defined set of processes is rebuilt from the starting assumption of AI involvement, while the rest is retrofitted. The work is deciding which processes belong in the first set — and that decision is made by asking where the current design is a constraint, not where the technology is impressive.
How We Work With You
An AI transformation roadmap is only useful if it survives contact with how the organization actually decides things. The work below is sequenced so that each stage produces something the organization can act on independently, rather than a set of recommendations that only make sense once all of it is finished.
1. Map — Establishing where the structure constrains AI
We map how work, decisions and accountabilities are currently arranged in the areas where AI is deployed or intended, and identify where the existing design — not the technology — is what limits the result. This is done against the organization’s real decision rules rather than its documented ones, because the gap between the two is usually where AI programmes stall.
You get: a current-state map of the processes in scope, showing where work is allocated between people and AI today, where decisions are actually made rather than where the org chart says they are, and the three to five points at which the existing design — not the technology — is limiting the result.
2. Design — Designing the target arrangement
We design the four decisions set out above — work allocation, handoffs, decision rights and role design — for the processes in scope, and establish the accountability that follows from them. The design is made specific enough to be operated, not general enough to be agreed with. Where an effect of the redesign is structural, we establish it in advance; where it is genuinely uncertain, we define how it gets tested rather than debated.
You get: the target AI operating model — allocation logic with the reasoning behind the line, a designed handoff for each point where work passes between people and machines, decision rights sorted into the three categories, and the role and accountability changes that follow from them.
3. Embed — Making it operate
A design that is handed over is a design that gets reinterpreted. We work with the people who will run the model to put it into operation, resolve the cases the design did not anticipate, and establish how new use cases are classified against the model rather than treated as fresh decisions each time.
You get: the model operating across the processes in scope, the classification logic your own teams use to place new use cases against it without coming back to us, and named ownership for each decision category.
We take on eight to twelve transformation engagements a year and work embedded with your leadership team rather than from a distance. An AI operating model engagement typically runs, at least, a full year and is led by a senior practitioner throughout — the person who designs the model is the person who helps you operate it.
Who This Is For
This work suits organizations at a particular point: past experimentation, with AI deployed somewhere real, and with the results falling short of what the technology demonstrably does. It is structural work, and it assumes the technology decisions are broadly made.
Where we are usually brought in
- After a successful pilot that has not scaled — the capability is proven and the organization cannot get it into operation.
- Before committing to enterprise-wide deployment — the structural implications are wanted before the spend, not after it.
- When AI adoption has happened informally — teams are using AI in ways leadership cannot see, and a deliberate position is needed rather than a retroactive policy.
- When agents are being introduced — software that acts rather than advises requires oversight to be designed in, and the existing controls assume a person is in the loop.
How this differs from AI strategy and AI implementation consulting
| AI strategy consulting | AI operating model design | AI implementation consulting | |
|---|---|---|---|
| Answers | What should we pursue with AI, and why? | How does the organization run once AI performs part of the work? | How do we build and deploy it? |
| Produces | A prioritized set of opportunities and a business case | Work allocation, handoffs, decision rights and accountability | Working systems, integrations and models in production |
| Usually triggered by | AI is on the agenda and nobody has framed it | A pilot works and will not scale | The design is agreed and needs building |
| Takes as settled | Nothing | What the organization wants from AI | How the work will be arranged around it |
| Delivered by | Strategy firms and advisory practices | Organizational design consultants | Systems integrators and technology partners |
We work as an independent AI transformation consultant. We do not resell technology, we are not a systems integrator, and we have no commercial interest in the size of the deployment. That independence matters here specifically, because the honest answer to an allocation question is often that a task should stay human.
Where we are not the right fit
- Organizations that have not yet deployed AI anywhere and are deciding which tools to buy.
- Engagements that need models built, integrated or maintained.
- Situations requiring an AI policy document without any intention of changing how the work is arranged.
Where This Fits
An AI operating model is one part of a larger question about how an organization is designed to operate. Three related pieces of work sit alongside it:
- Target operating model design — the same discipline applied to the organization as a whole, rather than to the specific condition of machines performing part of the work.
- Change management consulting — how an organization gets from its current arrangement to the designed one, including the people and structures the transition affects.
- Leadership and succession planning — whether the organization has the leadership capability to run the model it has designed, and the continuity to keep running it.
Our approach to operating model design draws on the Knowledge Network Operating Model (KNOM). Which sets out how organizations coordinate work when the structure is networked rather than hierarchical.
About Versatile Consulting
Saket Bivalkar
Managing Partner. Meet the Versatile Consulting team.
Saket Bivalkar is the founder and Managing Partner of Versatile Consulting and leads its AI operating model work. He writes on what changes structurally when machines perform part of the work — whether AI adoption requires restructuring at all, why AI programmes stall in telecoms, and how hybrid human and AI teams should be organized. His operating model engagements are in regulated industries across Europe, the Middle East and Asia, including a transformation spanning 63 countries.
Frequently Asked Questions
How is an AI operating model different from a target operating model?
Do we need to restructure the organization to adopt AI?
How do you decide which tasks go to AI and which stay human?
What changes when AI agents perform part of the work?
What is the difference between AI readiness and an AI operating model?
Who should own the AI operating model internally?
Book an exploration call
If your strategy has changed and your organization has not, an exploration call is a structured conversation about where the current model is constraining delivery — and whether a redesign is the right response.