How COOs Should Think About AI Budgets (It's Not an IT Line Item)

The budget structure problem

When AI spend sits in the IT budget, it competes against infrastructure refreshes, software licenses and security tooling, all of which have established approval rationales. AI does not fit neatly into any of those categories, so it tends to get scoped conservatively, approved for a proof of concept rather than a production system, and handed off to IT to "figure out" without clear operational ownership of the outcome.

This is how an AI budget gets approved at $80,000 for a project that realistically needs several times that to reach production. Nobody acts in bad faith. The person who approves the budget has no way to estimate what production-grade work costs, and the person who built the estimate padded it hoping to negotiate upward. Nobody owns the outcome from the operations side, so nobody has a strong incentive to size the budget correctly.

What belongs in an AI operations budget

A production AI system has five cost categories. Most budget conversations cover one or two of them:

• 1.Build cost. The development work to design and implement the system. This is what most budgets capture. Depending on complexity, anywhere from tens of thousands of dollars to a few hundred thousand.
• 2.Data preparation. Cleaning, normalizing, and structuring the data the AI needs to work with. Almost always underestimated. On an invoice automation project it can take a fifth of the total cost or more.
• 3.Inference cost. The ongoing API spend for running the model. Predictable once you know your volume, but often missing from initial budgets because it is a recurring cost that nobody modeled. A system processing 10,000 multi-page documents a month at $0.003 per page costs a few hundred dollars a month, which is usually fine. A system running 2,000 long agentic sessions a month can cost ten times that, depending on context length.
• 4.Human oversight. The time your team spends reviewing AI outputs, handling exceptions, and correcting errors in the early months. This is an operational cost that rarely makes it into the AI budget, but it is real. Plan for a quarter to half of one person's time for the first six months of a new system.
• 5.Maintenance and iteration. AI systems need ongoing adjustment: prompt tuning, threshold recalibration, new edge cases, and integration updates when upstream systems change. Budget 15–20% of build cost annually.

The single most common budget mistake: approving category 1 (build cost) and expecting the rest to figure itself out. It does not. The data preparation and human oversight costs in particular tend to land in operational budgets as unplanned spend after the project is already live. Budget all five categories upfront, or the project will appear to go over budget even when it is running as planned.

How to think about ROI without using vendor math

Vendor ROI models are built to justify the purchase, not to reflect what you will actually experience. They tend to use the highest plausible automation rate (80%), the highest plausible hourly rate for the labor being replaced ($85/hour), and the most optimistic timeline for reaching that rate (month one).

A more honest calculation uses three inputs:

• →Actual current cost of the process. Forget the theoretical hourly rate. What does the process cost you today, including the people who handle exceptions, the errors that require rework, and the approval delays that create downstream costs?
• →Conservative automation rate at month 6. Not month one. Not peak. Month six, after the calibration work is done and the exception handling is tuned. For invoice processing, a clean supplier master supports a much higher rate than a messy one, and the messy one stays low until it is cleaned up.
• →The value of what freed capacity actually does. If the AP clerk who processes fewer invoices manually will spend that time on higher-value exception resolution, the ROI is real. If they will just do less work, you need to account for that in the model.

The COO as the right budget owner

Operational AI budget ownership means the COO or relevant VP of Operations drives the budget request, not IT. IT provides the technical implementation capacity. The operations function owns the outcome and therefore owns the justification.

This matters for several reasons. First, operations owns the current-state cost data needed to build an honest ROI model. Second, operations will define the success criteria: "exception rate is below 8% by month four," say, in place of "the system is deployed." Third, the human oversight cost in the early months will come from operations headcount, so operations needs to plan for it.

The practical mechanism: create a cross-functional project team with an operations lead as the accountable owner, IT as the implementation partner, and a shared budget that reports against operational KPIs rather than technical deliverables. The milestone is not "system goes live." The milestone is "manual processing rate below target X."

One thing I would argue with most CFOs about

The standard financial framing of AI investment is cost reduction: the same headcount does more, or fewer people are needed. That framing is correct for some use cases and badly wrong for others.

In procurement and supply chain, the value of AI is often not cost reduction but decision quality improvement. An AI system that flags a supplier payment term that does not match the contract, or that identifies a purchase pattern suggesting inventory buildup before an order cycle, creates value that does not show up in headcount savings. It shows up in better decisions: avoided costs, captured discounts, tighter terms.

If you model AI investment only against headcount reduction, you will systematically under-fund systems that provide decision support and over-fund systems that do volume processing. Balanced portfolios of AI investment include both types. The budget framework needs room for both ROI models, including the one that does not fit a cost-reduction story.