AI Operating Model: Who Owns, Runs and Fixes AI in Your Company

Most companies that ask me about AI already have plenty of it. Licenses, a prompt library, a pilot or two, maybe an automation someone built on a Friday afternoon. What they don't have is an answer to a boring question: when this breaks on a Tuesday, who notices and who fixes it?

That question is what an AI operating model answers. Not the tools. The agreements around them.

What is an AI operating model?

An AI operating model is the set of agreements that decides how AI work runs in your company: which processes AI handles, who owns each one, who builds and approves it, and how it is monitored and improved.

Think of it as the org chart for your AI processes. Every regular process in a company already has one, usually unwritten. Someone owns invoicing. Someone knows who to call when the invoice run fails. The moment AI takes over part of that process, those answers have to be rewritten, or they quietly disappear.

A working AI operating model covers three things:

1. What AI runs: the list of processes and the layer each one sits on.
2. Who is responsible: owner, builder, approver.
3. How it stays healthy: guardrails, logs, reviews and a rule for when to stop something.

If you are still working out what being built around AI means in the first place, start with my practical definition of AI-native. The operating model is what makes that definition hold up in daily work.

How is an AI operating model different from an AI strategy?

An AI strategy says where AI should create value; an AI operating model says how that work is organized, owned and kept running once it is live.

Most companies have something that looks like a strategy. Very few have an operating model. That gap shows up in the numbers. A June 2025 Gartner forecast says more than 40% of agentic AI projects will likely get canceled before 2028. Its stated causes are spending, fuzzy payoff and poorly managed risk. Two of those three are operating model problems, not model problems.

What are the components of an AI operating model?

A practical AI operating model has six components: process portfolio, ownership, build capacity, guardrails, monitoring and review cadence.

None of these needs a new department. In a 20-person company, as an example, the whole model can fit on one page and involve three people.

The process portfolio is the part people skip, and it is the one I would never skip. Without a list, you can't tell which processes are live, which are half-built and which were quietly abandoned. I use my four adoption layers here too, from people prompting by hand up to systems that run end to end. Each process on the list gets a current layer and a target layer.

Monitoring deserves its own attention too. If a workflow runs without a record of what it did, you will find out it broke from a customer. There is a full breakdown of what to trace and review for AI agents if you want the details.

Centralized, decentralized or hub-and-spoke: which setup fits?

For most small and mid-sized companies, hub-and-spoke fits best: a small central function sets standards, and each team owns the AI processes in its own area.

There are three common setups:

Fully decentralized is where most companies already are without choosing it. Everyone uses their own tools, some of them unapproved. It feels fast until a workflow fails and nobody can say who built it or what it has access to.

Fully centralized sounds safe, but in a growing company it turns the AI team into a bottleneck. Every request waits in line, and the people who understand the process best are kept out of it.

Hub-and-spoke keeps the knowledge where the work is. The hub owns the boring standards: which tools are approved, how data access works, how runs are logged, how a new process gets started. The spokes own the processes and the results.

Who owns what in an AI operating model?

In a working AI operating model the business owns the outcome of each process, a builder owns the workflow, and a named person approves the output that matters.

These are the roles I would name for every live process:

• Process owner. The person who owns the process today. Head of finance for invoicing, head of sales for lead follow-up. They decide what good looks like and they read the results.
• Builder. Whoever builds and changes the workflow. Internal or external, but named. "The agency did it" is not a name.
• Approver. The person who checks the output before it goes out, for as long as the process needs a human checkpoint. Often the owner, sometimes someone on their team.
• Hub lead. One person who keeps the list, the standards and the monthly review. In a small company this is a part-time role.

The most common mistake I see is giving ownership to the builder. The builder knows how the workflow works. The owner knows whether the result is right. When the builder owns it, nobody checks the output against the business. When nobody owns it, it slowly drifts until someone switches it off.

This matches what McKinsey found in its 2025 State of AI research: of the practices it tested, redesigning workflows had the biggest effect on whether companies saw bottom-line impact from generative AI. Redesigning a workflow is impossible without someone who owns that workflow.

How do you build an AI operating model step by step?

You build an AI operating model by starting with one live process, writing down who owns, builds and approves it, and only adding structure as more processes go live.

My order:

1. List what already runs. Every AI tool, workflow and pilot, including the unofficial ones. Note who built it and what it can access.
2. Pick the processes that matter. Not everything on the list deserves to stay. Score the candidates quickly, then rank them and park the rest.
3. Name an owner, a builder and an approver for each. One person per role, per process. If you can't name the owner, the process is not ready.
4. Write one guardrail rule per process. What AI may do on its own, what needs approval, and what it must never touch.
5. Turn on logging and alerts. Every run recorded, every failure sent to the owner.
6. Set a monthly review. Thirty minutes. Go through the list: what to start, what to fix, what to stop.
7. Add structure only when you need it. A shared tool standard at three processes. A part-time hub lead at five. A real central team only when the queue proves it.

Step 7 is where companies over-engineer. A steering committee, a center of excellence and a 40-page governance document before a single process runs on its own. That is backwards. The model should grow with the number of live processes, not ahead of it.

New processes enter the model through a short test first. If that step is unclear, here is how I run a proof of concept that ends in a decision.

What does an AI operating model cost you?

An AI operating model costs you a few hours of agreement-making up front and a short monthly review, plus the discomfort of naming who is accountable.

The honest list:

• Naming people. Saying "you own this" out loud creates accountability. Some people will push back. That pushback is useful information.
• Turning things off. A real portfolio means stopping the pilots that don't deliver. Someone liked each one.
• Thirty minutes a month. Small, but it has to actually happen, every month.
• Less freedom for the enthusiasts. Standards on tools and data access slow down the person who wants to connect everything to everything. That is the point.

What you get back is a company where AI processes have the same standing as every other process: an owner, a record and a way to fix them. That is what separates a company with a lot of AI activity from one that runs on it.

At Arcgent this is part of how we work: we map the real processes first, then design the architecture and roadmap, and every process we build gets a named owner from day one.

Start with one process. Put three names next to it. Review it next month.