Measuring AI by use case: from cloud budget to decision tool

From the cloud total to AI spend: what the question conceals

The question "how much does AI cost us?" rarely calls for a percentage of cloud spend. An answer such as 1.8 M$ of AI spend against 6 M$ of cloud indicates an order of magnitude, but supports no decision. Executive committees reason in products, margins and risks: they need to know which use cases consume, which create value, which should be stopped or renegotiated.

The obstacle lies less in the data than in its granularity. As long as consumption is not tied to an identified use case, an owner and a cap, AI spend remains a budget line: it can be analysed, it cannot be arbitrated.

Four building blocks that make the spend legible

Cost per use case means tracking the main clusters separately — customer support, document extraction, assisted development — with their monthly trend. This granularity surfaces a drift before it becomes structural, and prevents a fast-growing use case from being hidden by the average.

Unit cost expresses spend in dollars per ticket handled, per document extracted or per useful outcome. It is the most debatable basis for comparing heterogeneous use cases, on one condition: the reference unit must be defined in a stable and documented way, otherwise the series are not comparable from one month to the next.

Coverage refers to the share of consumption that is tagged, capped and assigned to an owner. It is the least rewarding and most decisive block: partial coverage weakens the other three indicators, since what is not measured remains unknown.

Commitments cover active discounts, utilisation rates and expiry dates. A spend item may look variable while it is already constrained by a multi-year commitment; ignoring this leads to reasoning on a marginal cost that does not exist.

What the use case produces

Arbitration rests on a simple comparison: a use case costs 8,400 $ per month; what does it produce in hours saved, in quality or in revenue? The question is meaningful only if value is measured with the same rigour as cost, rather than estimated by the sponsor at review time.

Three families of benefits must be distinguished. Declared hours saved count only if they are reallocated to something else; a quality gain must be observable on an existing indicator; attributable revenue must be traceable to a specific use case. Without an explicit convention, each use case will be defended with different assumptions, and comparison loses its meaning.

Retained savings: reading the calculation correctly

The case reported covers 480,000 $ of spend reviewed over one quarter, with three use cases industrialised, two stopped and one renegotiation. Retained annualised savings amount to 125,000 $ per year, an average monthly equivalent of 10,417 $ per month (125,000 ÷ 12).

The methodological point is essential: this amount is the sum of the decisions taken, not a fraction of the 480,000 $ reviewed. Presenting the review perimeter as savings would be a misinterpretation. An arbitration exercise produces decisions of different kinds — industrialise, stop, renegotiate — only some of which translate into identifiable recurring savings.

Three possible decisions, three different logics

Industrialising assumes a use case whose value is demonstrated and whose unit cost is under control; the decision usually commits additional resources and aims at a lower unit cost through volume or optimisation. Stopping a use case reduces spend immediately, but may interrupt an already adopted practice and create a transition cost that is rarely anticipated. Renegotiating concerns the contract rather than the use case: discount, tier, commitment or expiry, with a deferred and sometimes conditional effect.

The criteria available are therefore less financial than they appear: unit cost, value produced, reversibility of the decision, maturity of the use case, contractual constraints and operational risk. Each criterion can contradict the others, and that is precisely the purpose of arbitration.

The trade-offs to accept are explicit. Stopping a use case may degrade an internal experience with no visible short-term effect on the bill. Renegotiating may jeopardise a future discount if the actual volume is hard to prove. Industrialising a use case without reliable measurement of its value amounts to funding a hypothesis.

Questions to ask before deciding

What proportion of consumption is actually tagged and assigned? Who owns the cap, and what happens when the cap is reached?

What value unit is retained for this use case, and who validated it? Are the hours saved reallocated, and to what?

How much of the spend is already contractually committed, and when can it be reviewed? What would concretely be lost by stopping this use case within thirty days?

These questions are working leads: they do not replace internal data, which alone allows a decision to be made.

Implementation checklist

1. Tie each consumption to a named use case, with an identified owner.

2. Publish a monthly trend per use case, not only a consolidated total.

3. Define a value unit per use case and document it before the review.

4. Measure tagging coverage and present it alongside the amounts, never without it.

5. List active commitments, their utilisation rates and their expiry dates.

6. Distinguish, in reporting, the review perimeter from the savings retained.

7. Record non-financial decisions (use case maintained, scope reduced) on the same footing as savings.