MODULE 4 · LESSON 2
Free — no login requiredSign in to track progress, save quiz attempts and enrol in the full course.
Sign in to track progress / enrolModelling the Cost, Including the Parts Nobody Quotes
Three cost buckets
Build. Everything up to the system working: discovery, data extraction and cleaning, labelling, model work, integration, testing, change management, and the internal time of everyone involved — which is real money and is routinely excluded because it does not appear on an invoice.
Run. Everything that recurs: licences or API usage, infrastructure, monitoring, the human exception path, support, and periodic retraining.
Change. Everything triggered by the world moving: source system upgrades, new document formats, process changes, model or vendor changes, regulatory shifts.
Most cases model the first bucket, mention the second, and forget the third entirely.
What is genuinely new about AI running costs
Traditional enterprise software has a licence that is roughly flat. You pay per seat or per year, and using it more is free.
Generative AI inverts that. Costs are typically metered by usage — priced per unit of text processed, usually called tokens, covering both what you send and what comes back. Three consequences follow that catch managers out:
Success increases cost. Higher adoption means more usage means a larger bill. This is the opposite of the software economics everyone's instincts are calibrated on, and it means an enthusiastic rollout can produce an unbudgeted invoice.
Cost per unit is largely under your control, and mostly decided at design time. How much context gets sent with each request, whether whole documents are passed or only relevant sections, whether results are cached, which size of model handles which task. These are engineering choices with direct financial consequences, which makes them worth asking about.
Prices move, in both directions. Per-unit prices have fallen substantially and repeatedly, while capability has risen. Do not build a case that only works at today's prices, and equally do not assume a price will hold.
Because prices change faster than any course can track, do not memorise numbers — learn the calculation:
Cost per case ≈ (input units + output units) × price per unit
Then: cost per case × volume = monthly run cost. Ask your technical team or vendor for a measured cost per case from a real sample, not an estimate. If they cannot produce one, they have not measured it, which is itself the finding.
The costs vendors leave out
Not usually dishonesty — the quote covers what the vendor supplies. These are yours:
The exception path is a permanent operating cost
Worth separating out, because it is the one most often treated as temporary.
If a system handles 80% of cases, someone handles the other 20% — forever, not just during a transition. That capacity has to be in the run bucket. And the exceptions are the hard cases, so they take longer per item than the average case did before.
A worked check: 40,000 invoices a year, 80% automated. 8,000 exceptions annually. If an exception takes twelve minutes rather than the six minutes an average invoice took, that is 1,600 hours of permanent exception handling against a gross saving of about 3,200 hours. The net benefit is roughly half the gross, and a case that omits this is overstating by a factor of two.
This is also why the hundred-case sample matters financially and not just technically. The size of the hard pile is your permanent operating cost.
Cases are usually presented on year one, which flatters projects with high build costs and punishes projects with high run costs. Both distortions matter.
A simplified shape for a document-extraction project:
| | Year 1 | Year 2 | Year 3–5 (each) | |---|---|---|---| | Build | High | — | — | | Licences / usage | Part year | Full year | Full year, rising with volume | | Exception handling | Part year | Full year | Full year | | Monitoring and ownership | Low | Full | Full | | Change and retraining | — | Some | Recurring | | Benefit | Part year, low adoption | Full year, higher adoption | Full year, mature adoption |
Three things this reveals that a year-one view hides:
Year one usually looks bad and should. Build cost lands, adoption is still climbing, and benefit is partial. A project judged solely on year one will be killed just before it starts working — which is a real and common failure of governance rather than of the project.
Year two is the honest test. Full costs, full year, adoption approaching mature levels. If the case does not work in year two, it does not work.
The change bucket is what kills long-lived AI systems. It is invisible in year one, appears modestly in year two, and recurs indefinitely. A system nobody budgets to maintain degrades until someone declares the technology disappointing — when what actually happened is that the world moved and nobody was funded to follow it.
Present the case over at least three years, show the year-two position as the test, and put an explicit annual figure against change. A number you had to invent is more useful than a blank, provided you label it as an estimate.
Why do generative AI running costs behave differently from traditional software licences, and what follows for a manager?
The three cost buckets
Click to flipBuild (up to working), run (recurring), and change (triggered by the world moving). Most cases model the first, mention the second and forget the third.
Click to flip backCost has three buckets — build, run and change — and cases routinely model only the first. AI run costs are metered by usage, so success raises the bill and cost per case is largely set by design decisions worth asking about. Treat the exception path as a permanent operating cost sized by your hundred-case sample, since it can halve the net benefit. And present at least three years, because a project judged on year one gets killed just before it starts working.