The COO's Guide to AI: Priorities, Owners and Decisions

By Tara Minh · Updated Oct 11, 2026

A COO's job in AI is to decide where AI goes to work in the operation, who is accountable for each use, and who has the right to approve what it does. The technology choices matter less than those three calls. If the COO leaves them vague, they get made by default: by whichever team bought a tool first, or by whoever spoke up in the last meeting.

This guide is for COOs, VPs of operations and the directors who report to them. It covers what the COO should own, how to set priorities, a workable ownership model, a decision-rights table, a first-year agenda and the mistakes that show up most often. For the wider picture of AI across operations, start with the pillar piece, AI in operations management.

Key Facts

• NIST's AI Risk Management Framework treats governance as a cross-cutting function that runs through mapping, measuring and managing AI risk, not a one-time approval (NIST AI 100-1).
• The same framework says roles and responsibilities for AI risk should be documented and clear across the organization, and that executive leadership takes responsibility for decisions about AI risk (NIST AI 100-1).
• Under the EU AI Act, deployers of high-risk AI systems must assign human oversight to people with the competence, training and authority to do it (Regulation (EU) 2024/1689, Article 26).
• The same Act requires providers and deployers to take measures toward a sufficient level of AI literacy among staff who operate AI systems (Regulation (EU) 2024/1689, Article 4).
• A useful working rule: limit year one to three to five use cases, each with one named owner, one metric and one stated stopping rule.

What the COO Should Own (and What to Delegate)

Operations sits where AI touches the most real work: scheduling, routing, inventory, quality checks, vendor handling, back-office processing. That puts the COO in the middle of the decisions, whether or not anyone gave them the title of "AI owner."

The COO should own four things personally.

1. The priority list. Which operational problems get AI attention, in what order, and which are deliberately left alone.
2. The ownership model. For each AI use, one accountable person in the line, not a committee.
3. The decision rights. What AI may decide alone, what needs a person's approval, and what it may never touch.
4. The scorecard. The few numbers that tell you whether AI is making the operation better or just busier.

Everything else can be delegated: vendor evaluation to a procurement or IT lead, data plumbing to a data owner, model testing to a technical lead, and legal review to counsel. Delegating the work is fine. Delegating the accountability isn't. NIST's framework is blunt about this, saying executive leadership takes responsibility for decisions about the risks of developing and deploying AI (NIST AI 100-1). In practice that means your name sits next to the list of AI uses in your operation.

Setting Priorities Across Operations

Most operations teams don't lack AI ideas. They lack a way to say no. Here's a simple screen that works at manager level.

Score each candidate on four questions

• Volume and repetition. Does this happen hundreds of times a month in a similar way? Invoice matching, shift scheduling and ticket triage do. A once-a-year vendor renegotiation doesn't.
• Cost of a wrong answer. If the AI is wrong, is the damage small and reversible (a mislabeled work order) or large and hard to undo (a wrong supplier payment)?
• Data readiness. Is the data this use needs already captured, in one place, in a form a person would trust? If not, the first project is fixing the data. See operational data for AI and data readiness for AI.
• Process clarity. Can your team describe the current process in a page? If nobody agrees how the work is done today, AI will automate the disagreement. Process mapping comes first.

Put the candidates in three buckets

The "Hold" column matters as much as the first one. A written "not now" saves your team from a dozen pilots that go nowhere, and it gives the COO a clean answer when a vendor or a peer pushes a pet project.

A tip on sequencing: pick the first use case where a person still reviews every output. Drafting, summarizing, classifying and flagging are good candidates. Actions that move money, change a customer's account or alter a production schedule come later. The generate versus execute boundary explains why, and the AI pattern risk gradient ranks common patterns from lower to higher risk.

An Ownership Model That Works

AI in operations fails most often at the seams between teams. IT built it, the business uses it, nobody owns the results. The fix is to separate four roles and name a person for each one on every AI use.

The business owner is the accountable one. That's deliberate. If the owner is IT, operations treats the AI as someone else's project, and nobody in the line is on the hook when it gets something wrong.

A RACI matrix is the right tool to write this down. Use it per AI use, not per department, and keep exactly one "A" on each row. NIST's framework asks for the same thing in more formal language: roles and responsibilities for AI risk documented and clear to the individuals and teams involved (NIST AI 100-1).

Central team or embedded?

COOs ask whether to build a central AI team or push the skills into each function. Neither is automatically right. A small central group (two to four people) works well for standards, vendor reviews and shared data work, while the business owner stays in the line. The trade-offs are covered in AI Center of Excellence vs. embedded model. For operations, a hub-and-spoke setup with a small hub and one named champion in each major function is a sensible default.

Decision Rights: Who Decides What

Decision rights are where a COO earns the title. Write down, for each type of AI-involved decision, who decides and who can overrule. This is the same logic as any decision framework, such as the rapid decision-making model, applied to a new kind of actor.

Three rules keep this table honest.

Limits are numbers, not adjectives. "Low-risk invoices" isn't a limit. "Matching invoices under a set amount from vendors with a clean history" is. Whoever sets the limit should be named, and it should be reviewed on a schedule.

Every autonomous action has an owner and an undo. Before an AI step is allowed to act, someone should be able to answer: who is told, how do we reverse it, and how fast?

Oversight needs authority, not just a name. A reviewer who can't stop a process or who is measured only on throughput will rubber-stamp. The EU AI Act puts this in legal terms for high-risk systems, requiring deployers to assign human oversight to people with the necessary competence, training and authority, and the necessary support (Regulation (EU) 2024/1689, Article 26). You don't need to be in the EU to borrow the standard. The deeper treatment of reviewing AI recommendations is in AI-assisted decisions in operations, and the review design itself is covered in human-in-the-loop.

A First-Year Agenda

Here's a four-phase plan that fits a normal operating calendar. Adjust the timing to your own budget cycle.

Quarter 1: Inventory and rules

• List every AI tool already in use in operations, including the ones staff adopted on their own. Shadow use is common, and you can't govern what you haven't seen.
• Name an accountable executive (usually you) and a small working group: operations, IT, legal or compliance, HR and finance.
• Draft a one-page AI use policy covering what data may go into which tools, what needs approval and who to ask.
• Run the priority screen above and produce the three-bucket list.
• Start a lightweight AI risk register with one line per use.

Quarter 2: One or two pilots with real owners

• Pick one or two "Start now" uses. Assign the four roles for each.
• Capture a baseline before launch: cycle time, error rate, rework, cost per transaction, whatever the process owner already tracks. Without a baseline, you can't tell success from noise.
• Document the workflow, including the human review step, in an SOP so a new hire could follow it.
• Set a stopping rule in advance, for example: "If error rate exceeds the manual process for two consecutive weeks, we pause and review."

Quarter 3: Review, fix, decide

• Compare results to the baseline. Read a sample of actual outputs, including the bad ones.
• Decide each pilot's fate in writing: scale, fix, or stop. Stopping is a legitimate and useful result.
• Start the groundwork for the "Prepare" bucket, usually data cleanup and process documentation.
• Train the people who review AI outputs. The EU AI Act's literacy duty is a useful prompt even outside Europe: providers and deployers must take measures toward a sufficient level of AI literacy among staff who operate AI systems (Regulation (EU) 2024/1689, Article 4).

Quarter 4: Scale carefully and reset the plan

• Extend what worked to a second site or team, one step at a time.
• Move one use up the decision-rights table only if the data supports it, for instance from "recommended" to "bounded autonomous."
• Refresh the priority list, retire what didn't earn its place, and set next year's three to five commitments.
• Brief the executive team and the board on results in plain language: what runs, what it changed, what went wrong, what you learned.

A Worked Example (Hypothetical)

Take a regional distributor with three warehouses. The COO's priority screen turns up a long list, and she ends up with this:

• Start now: AI-drafted summaries of daily exception reports (late inbound shipments, stock mismatches). A shift supervisor reads and edits them. Low cost of error, high repetition.
• Prepare: Demand forecasting. Sales history sits in two systems with different product codes. The first project is a clean product master, owned by the inventory control manager.
• Hold: Automated carrier switching. A wrong call hits customer deliveries immediately and the rules are inconsistent across sites.

She names the head of fulfillment as business owner of the summaries, the operations excellence lead as process owner, and gets IT to assign a technical steward. The stopping rule: if supervisors correct more than a set share of summaries for two weeks running, the pilot pauses. None of this requires a large budget. It requires four names, three buckets and one rule.

What to Measure

A short scorecard beats a long dashboard. Pick measures that capture both gain and harm.

• Outcome: cycle time, throughput, cost per transaction, on-time delivery, whatever your operation already reports.
• Quality: error rate, rework, exceptions per thousand transactions, compared with the manual baseline.
• Control: share of AI outputs edited or rejected by reviewers, incidents, overrides, and time to detect a problem.
• People: reviewer workload, training completion, and whether frontline staff say the tool helps.
• Coverage: how many AI uses have a named owner, a documented workflow and a stopping rule. Aim for all of them.

The last measure is the COO's own: a use without an owner is a liability, not a project.

Common Mistakes

Letting IT or a vendor own the outcome. Technical stewardship is a job. Business accountability is a different job, and it belongs in the line.

Starting with the tool. A tool demo is a poor way to pick a priority. Start from the operational problem and the data.

Too many pilots. Ten parallel experiments with no owners teach you nothing. Three to five with clear owners teach you a lot.

No baseline. If you didn't measure before, every result is an anecdote.

Fuzzy autonomy. "The AI handles routine cases" with no number attached will be stretched the first time volume spikes. Write the limit down.

Ignoring the people. Supervisors and planners who feel replaced will route around the tool or use it badly. Involve them in design, and tell them plainly what changes in their roles. The wider organizational side is in change management and what AI transformation means at C-level.

Treating governance as paperwork. A policy nobody reads is worse than none. NIST describes governance as something infused throughout mapping, measuring and managing risk, not a gate at the start (NIST AI 100-1).

Where to Go Next

If you do one thing this month, write the list: every AI use in your operation, one accountable name next to each, and a one-line statement of what it may decide alone. That page is the foundation for everything else. Then work through the data and decision pieces in this collection, starting with operational data for AI and AI-assisted decisions in operations, and use AI tools for business operations when you're ready to look at the tool side.