Where the AI Budget Comes From

Imagine two vendors selling exactly the same AI system to an insurer. It prepares simple claims for a decision and hands the odd ones to a person.

The first vendor sells it as software: $150 per adjuster per month, $90,000 a year for a team of fifty. The second sells it as a replacement for the twenty adjusters the company was about to hire, priced at 40 percent of their salaries: about $1 million a year.

Same system, same claims, same cost to run. One price is eleven times the other, and both can be rational.

The difference is where the money comes from. Every AI purchase is paid from a specific budget line, and that line decides who approves it, what evidence they need, what the vendor can charge, and who loses something if it succeeds. Most AI business cases are written as if the money had no owner. That is a large part of why so many good pilots never become anything.

Money that nobody planned to keep spending

A budget line is a pot of money with a person who answers for it: the CIO's software budget, a department's operating budget, the hiring plan. Each has an owner, a yearly calendar and its own idea of what counts as proof.

Early generative AI money came mostly from a different kind of pot. In a 2024 survey of 600 American IT decision-makers, Menlo Ventures found that 60 percent of enterprise spending on generative AI came from innovation budgets: discretionary funds for experiments, usually held centrally, easy to approve and easy to cut. By mid-2025, an Andreessen Horowitz survey of 100 CIOs put the innovation share of their LLM spending at 7 percent. The two firms measure different things, so the numbers aren't one series. They point the same way.

The money didn't disappear. It moved into permanent lines, mostly IT and business-unit budgets. And permanent money behaves differently. An innovation fund asks for a credible hypothesis. A permanent line asks whether its own number moved.

Scroll sideways to see the whole figure

Five lines matter for AI, and they differ less in name than in two properties.

Size. Innovation money is small. Software budgets are bigger. Venture investors argue that what companies spend on services and on salaries dwarfs what they spend on software; Sequoia's Julien Bek put the ratio at six to one, without citing a source. Nobody has measured it properly for AI, but most finance leaders would accept the ordering.

Who can say yes. A CIO can approve a software tool. A CIO can't shrink another department's hiring plan. The person who can is often the one with the most to lose from doing it. A purchase that needs a budget owner to act against their own interest moves slowly, whatever its return.

That gives you the basic tension of AI buying. The big money sits in the lines that are hardest to move.

What the buyer compares it with

Here is the mechanism, and it's the part most vendors and most buyers get wrong.

A buyer never judges a price in isolation. They compare it with whatever the same budget line pays for today. A tool that helps a worker gets compared with other tools. A system that does the work gets compared with whoever does the work now: an outsourcing contract or a salary.

That comparison sets the ceiling on what a vendor can charge. The economics are old: a seller gets paid up to the buyer's next-best alternative, and no further (Who Receives the Gain?). The budget line is where that alternative gets written down. If the alternative is a $150 software seat, an AI seat priced like a salary won't get approved. If the alternative is a $128,000 employee, a system that replaces one can cost a lot more than any software seat ever did.

The second half of the mechanism is how hard the line is to act on. Sequoia's essay makes the distinction well. Replacing an outsourcing contract with an AI provider is a vendor swap: procurement and a function head can do it. Replacing headcount is a reorganization: it runs through the people whose jobs change, their manager, human resources and finance.

The comparison sets the price ceiling. The owner of the comparison decides how fast anyone can act.

One capability, three purchases

Back to the insurer. The numbers here are illustrative arithmetic, built on public salary data and stated assumptions, and the details are in the notes below the article. They're there to show the shape.

The claims team has fifty adjusters. A class of simple claims, 24,000 a year, could be prepared by an AI system, with a person handling exceptions and spot-checking a sample. Done by people, those claims take about twenty adjusters. Each adjuster costs the company around $128,000 a year once benefits, supervision and equipment are added to pay; that's the fully loaded cost.

Running the AI system well costs about $300,000 a year, or about $12.45 a claim. That includes the model's tokens, the human time on exceptions, integration, a person who owns and evaluates the system, and hosting and access reviews. The tokens, the part everyone argues about, are under 2 percent of it. Most of the cost of running AI properly is people and plumbing.

Now sell that same capability three ways.

A. Software seats, paid from IT. $150 a seat for fifty adjusters is $90,000. The buyer also pays for integration, an owner and its own staff's time on exceptions, about $354,000 all in. The system frees roughly nineteen adjusters' worth of time, worth about $2.5 million at full cost. But that's only a saving if the capacity actually leaves, through attrition, a hiring freeze or moving people to other work. The purchase breaks even if about two people's worth of time turns into real savings. The seat price says nothing about whether that happens.

B. A service per claim, paid from the outsourcing budget. Suppose the insurer already sends these claims to an outside firm, a business-process outsourcing provider, at $65 a claim from its rate card. The AI vendor offers to handle them for $38. With half a person to oversee the vendor, the buyer pays about $976,000 against $1.56 million today. The saving is $584,000, 37 percent, and it's written in a contract.

C. A digital worker, paid from the hiring plan. Suppose instead that volume is growing and the plan has twenty new adjusters for exactly these claims. The vendor prices the system at 40 percent of a loaded salary per person replaced: $1.03 million. The twenty hires would have cost $2.56 million a year, plus recruiting and training. The saving is about $1.77 million in the first year.

Scroll sideways to see the whole figure

Three things follow, and each matters more than the headline ratio.

The alternative sets the price, whatever the cost. In B and C the vendor keeps about two thirds of what it charges above the cost of running the system. Competition would erode some of that. In A the price looks tiny because the buyer carries the integration, the owner and the exceptions, and the vendor promises no result at all. The three prices include different amounts of work and different amounts of risk.

The saving's reliability differs more than its size. In B the saving appears on an invoice. In C it appears as a hire that never happens: real money, but invisible in the accounts unless someone wrote down the plan beforehand. In A it appears as freed time, and freed time tends to get absorbed by other work rather than banked (Where the Saved Time Goes). A is the easiest to approve and the easiest to end up with no saving.

Each approver wants different proof. The CIO in A wants the security review passed, the integration confirmed and adoption numbers from a pilot. The services buyer in B wants a precise definition of a handled claim, audit rights and a way out of the contract. The CFO in C wants the agreed hiring baseline, the cost per accepted claim tracked over time, and a named executive who owns the changed plan. One slide deck can't serve all three.

Pricing follows the line

Once you see this, vendor pricing stops looking arbitrary. Pricing tends to copy the shape of the buyer's alternative. A seat price fits when the comparison is other software. A price per unit fits when the comparison is a contract with a rate card. A price tied to a salary fits when the comparison is a hire.

Usage pricing sits in between and suits a department head who wants cost to track volume. In a16z's 2025 interviews most CIOs still preferred it, and they worried that outcome pricing lacks clear outcomes, predictable costs and a fair way to attribute results. The claims example shows why that worry is reasonable: the whole service contract rests on defining what counts as a handled claim and who audits the count (Output, Outcome and Value).

For a founder, this is a choice of business, more than a choice of price list. Selling into the labor or services line means a different buyer, a different proof, and often taking on a services company's risks, including the cost of failure landing on your own margin.

Where pilots die

The budget calendar explains a lot of failed AI programs that look like technology failures.

Annual budgets are set months before the year starts. Model prices and capabilities change inside the year. A pilot paid from the innovation fund can start any Tuesday. The permanent line it needs may only open at the next planning cycle, months away.

So pilots tend to die at the seam between the two kinds of money, for reasons that are structural rather than technical. The pilot proved the system works on chosen cases, while the permanent line wants its own measure to move against a baseline nobody recorded. The owner of that line often wasn't part of the pilot. The calendar leaves a gap in which the pilot has no money and its champion may have moved on. And nobody was asked, at the start, which line would pay if it worked.

A pilot proves the system works. A permanent line asks whether its own number moved.

Budgets are also standing

There's one more thing a budget is, and business cases rarely mention it. It's power.

The head of claims whose twenty planned hires disappear runs a smaller organization. The CIO who pays for the seats takes on a cost and a risk, while the saving lands in operations. Nobody volunteers for that arrangement.

My reading of the incentives leads to three practical conclusions. If IT pays and operations saves, you need a rule for moving budget with the saving, or IT will eventually refuse to carry it. Avoiding future hires is far easier to approve than removing current jobs, which makes the hiring plan the least contested way into the labor budget, provided the baseline is written down before the system arrives, because a hire that never happened leaves no trace. And whoever presents the result gets the credit, so agree on the measure before the result exists (Measuring AI Impact Without Fooling Yourself).

When AI really is just software

The obvious objection: AI is an IT purchase like any other, and the budget line is a bookkeeping label.

It's right more often than investors like to admit. In Menlo's 2025 breakdown, copilots are 86 percent of horizontal application spending and coding tools more than half of departmental spending. Those are products that help individual workers, whose benefit is spread thin and which nobody frames against a salary. AI features bundled into software a company already licenses need no new line at all. For those, the IT budget is the correct home, and its proof is the right proof.

The objection fails where the product does the work and the real alternative is a person or a contract. The IT line can't book a headcount saving or sign a services contract, so the purchase either gets stuck or gets approved for a benefit nobody collects. In the claims example, the cheapest option, A, is precisely the one whose return depends on a decision outside the IT budget's authority.

Both views hold. "AI is software" describes the product. The budget line describes what the buyer gives up to get it.

The heavier purchases also bring heavier paperwork. A seat tool reads what one user opens. A service that handles whole claim files needs standing access to the insurer's core systems, a data processing agreement for the personal data, a third-party risk review, and an exit path. In Europe, whoever counts as the deployer of a high-risk system under the AI Act takes on duties of oversight, monitoring and log-keeping. None of this is a reason to avoid the bigger lines. It's a reason to budget months, not weeks, for getting into them.

What to do

Name the line before the pilot starts. Write down which budget will pay if the pilot works, who owns it, and what that owner's measure is today. If nobody can answer, you're running an experiment with no destination.

Ask what the buyer compares it with. For a buyer, that tells you which saving is real and who collects it. For a vendor, it tells you your price ceiling, and whether you're really selling software or a service.

Match the proof to the approver. Security and adoption for IT. A unit definition, audit rights and an exit for procurement. A recorded baseline and a named owner for finance.

Write the counterfactual down. If the saving is a hire avoided, record the plan before the system arrives. Otherwise, in a year, nobody will be able to show it happened.

Fund the work in steps that end in a decision. Each stage should finish with someone choosing to scale, revise or stop, with the next stage's money already identified (Designing an AI Program That Ships).

The capability is the same in every version of this story. What changes is whose money it replaces, and that decides almost everything else.

Check yourself

Why can the same AI system sell for $90,000 or about $1 million a year?

A buyer compares the price with what the same budget line pays for today, a software seat in one case and a salary in the other. The next-best alternative sets the ceiling.

Why do pilots tend to die at the seam between innovation money and permanent money?

The pilot proved the system works, but the permanent line wants its own measure to move against a baseline nobody recorded. Its owner often wasn't in the pilot, and the calendar leaves a funding gap.

Why is the software-seat version the easiest to approve and the easiest to end with no saving?

Its benefit is freed time, and freed time tends to get absorbed by other work. It only becomes a saving if the capacity actually leaves.