What Does an AI-Centric Operating Model Actually Change?

An AI-centric operating model changes how your company moves work and makes decisions. A team can ask software to gather context, draft a response, or carry out a permitted action. Leaders still need to decide who sets the rules, who handles exceptions, and who answers for the result. Those choices determine whether AI improves a process after the pilot ends.

Start with a real piece of work

An operating model describes how people, systems, and rules produce an outcome. The clearest way to change it is to follow a case from start to finish. Take a customer asking for a refund. Today, an agent reads the request, opens the order system, checks policy, asks a manager about an exception, records the decision, and tells finance what happened. Each handoff adds time and can lose context.

With AI in the workflow, software can gather the order and policy, draft a recommendation, and place the case in the right review queue. It can record the approved outcome in the customer system. The refund rule, the authority to approve an exception, and the record of who approved it still need owners. Map those steps before choosing a tool. A model's answer alone doesn't tell you whether the whole case reaches a correct and timely outcome.

Set decision rights before permissions

Write down the decisions in the workflow and give each a named owner. The business leader decides what result the process should achieve and which policy applies. The process owner decides when staff must review a case and which exceptions need escalation. The technical team sets access limits and makes sure the system can only take approved actions. Risk or compliance staff review decisions with material customer, financial, or legal consequences.

For the refund example, the system may draft a recommendation from an approved policy. A designated employee approves a refund above the agreed limit. Another person can pause automated actions when the system starts making repeated mistakes. NIST's AI Risk Management Framework calls for clear roles in human-AI work and executive responsibility for AI risk decisions. A written authority map turns that principle into a practical rule for each case.

Redesign the handoffs

When software passes work to a person, the person needs enough context to decide without starting again. The handoff should show the original request, the records and policy the system used, the proposed action, and why the case needs review. It should also show which action has already happened. If staff correct a recommendation, capture the correction and its reason for later testing.

Keep the same care when work moves between teams. In the refund process, customer service owns the conversation, finance owns the payment record, and a manager handles policy exceptions. A shared case record can carry the decision across those boundaries. That prevents a fast first draft from creating a slow reconciliation problem at the end.

Move team boundaries around the work

A central technical team can provide identity, data access, evaluation tools, and monitoring for several workflows. The team closest to a process should define its rules, test realistic cases, and own the result. This split lets specialists reuse common controls while staff with direct knowledge of the work decide what good output looks like.

The balance changes with company size and risk. A small firm may give several duties to the same people. A larger firm may keep platform and security standards central while business teams build and run their own workflows. Microsoft's operating-model guidance compares central, hybrid, and federated delivery and recommends explicit decision rights between shared and business teams. The right choice depends on the work and the team's ability to manage it in production.

Keep a person accountable after launch

Name the business owner who accepts the outcome, the technical owner who maintains the system, and the person who can stop it. Give staff a clear route for reporting bad recommendations or missing information. Review a sample of completed cases, including the cases the system handled without escalation. Update the tests when policy, data, tools, or customer behaviour changes.

Measure completed work: time from request to resolution, correct decisions, corrections, customer complaints, and cost per completed case. Track how much review the system creates. A faster draft that adds more manager work may leave the process no better off. NIST's framework also treats measurement and ongoing management as part of the system's life, rather than a final check before launch.

Make a first design pass

1. Choose a case type. Pick a recurring piece of work with a clear outcome and a team that owns it.
2. Map the current path. Record inputs, decisions, handoffs, exceptions, and the systems that hold the facts.
3. Assign authority. Decide what software may read, recommend, or do; name the person who approves consequential actions.
4. Test the whole case. Compare completed cases with the old process, including staff review, errors, and operating cost.

This approach suits a company with recurring work that crosses systems or teams. If the process has no clear owner or the source records are unreliable, fix those gaps first. The organisation chart may change later; the immediate design choice is how each case reaches a sound decision and who stands behind it.