Enterprise AI Spend: Reading the Surveys, and the Bottom-Up Model

Two surveys of enterprise AI spending, published in the same month, can differ by a multiple. Neither is necessarily dishonest. They are measuring different things, and the differences are entirely in the methodology that gets summarised away in the headline.

Why the published numbers disagree

Before any question of accuracy, there is a question of definition. Does “AI spend” include the salaries of the engineers building it? The cloud capacity the workloads run on, which was already in the infrastructure budget? Licences for software that recently added AI features and did not change price? Consulting to integrate it? Each inclusion decision moves the total by a large factor, and any two surveys making different choices are not comparable even if both are perfectly executed.

Then the sampling. Who was asked, how were they found, and who declined? A survey distributed through a vendor’s customer list measures that vendor’s customers. A survey of executives measures what executives believe about budgets they do not personally operate, which is systematically different from what is spent — particularly where teams are expensing tools directly and no central figure exists.

Seven questions to ask of any figure

• What was counted? Get the inclusion list. If it is not published, the number cannot be compared to any other number.
• Who answered, and how were they selected? Sampling frame first, sample size second. A large sample from a skewed frame is confidently wrong.
• Was it budget, intent, or actual spend? Planned spending, approved budget and money that left the building are three different quantities, and forward-looking intent is the least reliable.
• Who paid for the survey? Not a disqualification, but it predicts which definition was chosen when a judgement call arose.
• Is there double counting? A spend figure that includes both the platform bill and the applications built on it counts the same money twice.
• What is the denominator? Spend per employee, per revenue dollar or per IT budget is comparable across periods; an absolute total is not, when the population of respondents changed.
• Did the definition change between waves? A growth rate produced by a widening definition is not a growth rate. This is the most common way a chart shows a trend that is not there.

If a figure survives all seven, it is worth quoting — with its date and its source attached, because it will be stale within a year.

The bottom-up cost model

A more useful exercise than reading someone else’s total is building the cost structure of one use case, because the shape generalises and the shape is the surprising part:

Total cost of ownership over T months =

  C_build                       one-off
  + T * C_run                   recurring

C_build:
  discovery and use-case definition
  data access, permissions, plumbing
  integration with the system of record
  evaluation set construction
  security, privacy and legal review
  change management and training

C_run:
  inference and other metered services
  monitoring, evaluation reruns, incident handling
  ongoing prompt and pipeline maintenance
  support for the humans using it
  periodic re-approval and audit

The structural claim, which does not need a survey: the model API line is one item on a list of eleven, and it is rarely the largest. This is not special pleading about AI — it is what enterprise software has always looked like, where licence cost is a minority of programme cost and integration plus change management dominate. There is no reason for this technology to be exempt, and the widespread focus on the per-token price is a focus on the item that is easiest to look up rather than the item that decides the outcome.

The consequence for a buyer is uncomfortable: a fifty percent reduction in inference cost may move total programme cost by a few percent. Whether it moves anything at all depends on the ratio between C_run inference and everything else, which is a property of your own architecture and is worth computing before an optimisation project is funded — the method is in the inventory of non-inference costs.

Adoption is the term that decides it

Now the benefit side, where a single term dominates everything:

monthly benefit = N * a * h * w * q

  N  people the tool is available to
  a  adoption: fraction who actually use it
  h  hours saved per adopting person per month
  w  fully loaded hourly cost of that person
  q  realisation: fraction of saved hours that turns
     into something of value rather than into slack

Assume N = 500, h = 6, w = $70:

  a = 0.15, q = 0.5 :  500*0.15*6*70*0.5 = $15,750
  a = 0.50, q = 0.5 :  500*0.50*6*70*0.5 = $52,500
  a = 0.80, q = 0.8 :  500*0.80*6*70*0.8 = $134,400

Cost, meanwhile, barely moves with a. Licences and
inference scale with usage, but C_build and most of
C_run do not.

Benefit is roughly linear in adoption; cost is roughly fixed in it. That asymmetry is the entire explanation for why pilots stall. A pilot with low adoption has paid nearly all of the cost and collected a fraction of the benefit, so it looks like a failure of the technology when it is a failure to get the tool used.

The q term is the one finance departments insist on and technologists resent, and they are right to insist. Hours saved that do not turn into output or into fewer hours paid for are not a benefit that appears anywhere. Any business case quoting hours saved without a realisation factor is quoting a number that cannot be found afterwards.

Measuring your own

• Instrument adoption before quality. Weekly active users as a share of licensed users, per team. It is the term with the most leverage and it is trivial to collect.
• Attribute inference cost per use case, not per department, so that a programme’s cost can be compared to its own benefit rather than to a total.
• Count what shadow spend exists. Individually expensed subscriptions are real spend and are absent from central figures. That they are missing is one reason surveys disagree, and it applies to your own internal number too.
• Re-run the case at renewal. Both terms move: the price of inference falls, and adoption either grew or did not. A case approved once and never revisited stops describing the programme within a year.

One consequence to expect: cost per task falling does not reduce the bill if the number of tasks rises to fill the room, which is the rebound effect covered in the elasticity condition. Budget accordingly.