How to Budget for AI When You Can't Predict Usage
Usage-based pricing makes AI budgets guesswork. Here is a structure that survives the guessing.
Erin Moore
Fractional Chief AI Officer
Budget AI in three buckets — run, prove, and reserve — rather than as a single line, because the three behave completely differently. Run is predictable and defensible. Prove is deliberately spent to learn. Reserve exists because usage-based pricing means your forecast will be wrong in a direction you cannot predict.
The three buckets
Run (roughly 60%). What it costs to keep working systems working: licences, maintenance, the internal time to operate them. This is the bucket that quietly grows every year and the one an AI audit usually finds fat in.
Prove (roughly 30%). Money set aside to test things that might not work, with the explicit expectation that some will not. Naming this bucket matters — it makes a failed experiment a budgeted outcome rather than a mistake, which is what keeps people willing to run them.
Reserve (roughly 10%). For usage overruns and the one opportunity that appears mid-year. Without it, every surprise becomes a re-forecast.
The percentages are a starting point, not a rule. A company with no working AI systems yet should weight prove far more heavily.
Handling usage-based pricing
The honest problem with per-token or per-task pricing is that you are committing to a number nobody has measured. Three things help:
- Instrument before you commit. Run a bounded pilot and measure the actual driver — requests, documents, minutes — before signing an annual deal.
- Cap it contractually. A ceiling with a renegotiation trigger is usually available and rarely offered.
- Model the bad case explicitly. Not the expected case. If the bad case is unaffordable, the pricing is wrong for you regardless of how attractive the expected case looks.
This is one of the seven lines in AI total cost of ownership, and the one that most often turns a good business case bad.
What to hold back
Do not spend the whole year's budget in the first quarter, however good the pipeline looks. AI tooling changes fast enough that something materially better than your current shortlist will exist in six months, and a fully committed budget cannot act on it.
Defending the budget
The number that makes an AI budget defensible is not the spend — it is the baseline you committed to measure it against. Walk into the conversation with what you spent, what it returned against a stated baseline, and what you stopped. That is the same four-number structure as reporting AI to the board, and it is the difference between a budget that survives scrutiny and one that gets cut on instinct.
Frequently asked questions
How should we budget for AI? Split it into run, prove and reserve rather than one line. Run keeps working systems working, prove funds experiments expected to sometimes fail, and reserve absorbs usage overruns and mid-year opportunities.
How do we budget for usage-based pricing? Instrument the actual driver in a bounded pilot before committing, negotiate a cap with a renegotiation trigger, and model the bad case rather than the expected one.
What percentage of budget should go to experiments? Around 30% for a company with some working systems, considerably more if you have none yet. The point of naming the bucket is that a failed experiment stays a budgeted outcome.
How do we defend an AI budget? With spend, measured return against a baseline you stated in advance, and a list of what you stopped. A portfolio with no cancellations reads as unmanaged.
Further reading
Tagged with:
Ready to Automate Your Business?
Let's discuss how AI automation can deliver measurable ROI for your organization in 90 days or sooner.