What an AI interaction costs

The AI line item has reached board level, and it usually arrives as one number: what we are spending. That number provokes exactly one conversation — is it too much? — and answers nothing. A total cannot be governed. It cannot tell you which use cases are earning their keep, whether the economics are improving, or what happens to the bill if adoption doubles. The unit that can be governed is the cost of an interaction: everything consumed to produce one governed outcome. For a customer-service assistant, one resolved enquiry. For a document pipeline, one processed document. For a decision-support model, one decision informed. Attribute the spend to the unit and the conversation changes from "is the bill too big?" to "is this interaction worth what it costs?" — a question a board can actually answer. Most unit-cost calculations flatter the answer, because they count inference alone. An honest number includes the whole chain: the model calls, including the retries and the guardrail checks; the retrieval and orchestration around them; the share of the evaluation harness that keeps quality measurable; the monitoring that keeps it observable; and the human review time that sits inside the loop for anything that matters. On real workloads the flattering number and the honest number can differ by multiples — and decisions made on the flattering number are decisions made on fiction. For a regulated enterprise there is a further discipline, and it mirrors cloud cost management: attribute the governance premium explicitly. Evaluation, monitoring, human review, and audit-trail capture are the cost of operating AI under obligations — the same way redundancy and DR are the cost of operating platforms under them. When the board can see cost-of-control and cost-of-capability as separate lines, two things follow. The governance spend stops being invisible overhead vulnerable to quiet cutting. And a use case whose economics only work without the governance is exposed for what it is: a use case whose economics do not work. The number matters most as a trend. Unit cost falling as volume grows and prompts, models, and retrieval are tuned is the signature of a healthy use case. Unit cost flat or rising while volume grows is a signal to re-examine the design — or the use case. And the trend only means anything against the other side of the ledger: the value of the interaction. Cost per resolved enquiry is interesting; cost per resolved enquiry against the cost of resolving it the old way is a business case. Getting to the number is an engineering exercise, not a finance project. The platform already knows most of it: token counts, call logs, retry rates, evaluation runs. What is usually missing is attribution — tagging each call with the use case it serves — and an owner who publishes the number monthly. Teams that treat unit cost as a platform metric, visible on the same dashboard as latency and error rate, get the discipline almost free. Teams that treat it as a quarterly analysis exercise get a stale estimate and an argument. This is what unit economics buys: kill-or-scale decisions grounded in evidence, business cases that survive finance review, and vendor conversations conducted in the unit the business actually consumes. It also changes the model conversation: when a smaller, cheaper model clears the evaluation bar for a use case, the unit economics say so immediately — and when it does not, the premium for the larger model is a recorded decision rather than a default. A practical place to start: pick one production use case and instrument it end to end — every model call, every retry, the evaluation share, the human minutes. Produce one honest number and its trend. Take it to the next board conversation instead of the total.