Point of View
The Price Was Agreed Once. The Bill Is Decided Every Day.
With usage-priced AI, part of the bill can be shaped inside the build rather than settled entirely at purchase. Choices about what the tool reads, how often it runs, and how much it re-checks set the running cost. Approval at sign-off may govern access without fully governing what the system will cost to run.
When software charges by use, the running cost is shaped by choices made during the build, which puts cost inside the design conversation where the approval step was never built to look.
The software line used to be forecastable. Then a quarterly review turns up a charge nobody signed off on, from a tool whose licence has been under contract at a fixed annual price since an earlier budget cycle, with the AI work behind it billed by what it processes. Nothing was bought. Somebody connected it to the shared inbox.
Where the charge actually came from
Say the licence was approved in an earlier budget cycle at a fixed annual price, and that part of the contract has not changed since. The AI work it does is metered separately, by what it reads and answers. What changed is where it points. It now works on messages as they arrive, including the newsletters, the delivery notifications, and every reply on a thread that was settled in the first one.
Looking for the purchase order behind that charge can come up empty, because there may not be one. The decision that moved the number happened in a build conversation about which messages the tool should look at and when it should look at them. Nobody framed that as spending. It still was.
What the approval step is still checking
Many business software purchases were easier to forecast because the main cost was set by seats, tiers, or an annual contract. You negotiated seats, you knew the annual figure, and finance could plan around it. Under fixed pricing, a rising software line usually traced back to a purchase or a renewal, so that is where the controls were put. Many approval processes were built around that assumption, and they still sit at the front door checking a number that may no longer govern the bill.
Usage pricing can move an important part of that lever into the operating design. The signature still decides access, and the amount gets produced afterwards by how the thing is wired and how much work it is given. The demo that got it approved showed what the tool could do, which is a different question from what it costs to run every day in your business.
The spending decisions happen during the build
Inside a usage-priced build there are choices that look purely technical and also set the rate. Whether the tool reads every incoming message or only the ones flagged for attention. Whether it runs the moment something arrives or on a schedule. Whether it re-reads a whole document in full or only the part that changed. Whether it checks its own work a second time before passing it on.
Each of those is a judgment about accuracy, speed, and how much checking is enough, and each one can also affect the per-item cost. The person weighing them is often a developer or an operations lead working from a brief about quality and turnaround. If nobody showed them the pricing, and nobody said that this part of the design sets the running cost, they are left to decide on the information they were handed. The question gets settled whichever way the thing is built, whether or not anyone names it as a spending decision.
Some of that volume may not need the expensive part at all. Plenty of what gets routed to a model is closer to a rule than a judgment, and a rule can sort it first. That is an architecture question in the sense that matters here: what should exist, what the technology carries, and what it is allowed to touch.
A build that works costs more than one that does not
This inverts an old instinct. Under seat pricing, heavy use made the deal look better. Under usage pricing, greater use can raise the bill. A tool nobody uses may stay cheap. A tool that works and gets used heavily can become more expensive.
That makes a rising number hard to read. If the case was built on the headcount it would save, a climbing bill can read as failure even when the work landing on the other side of it has grown. Common responses include tighter spend alerts, a monthly usage review, and a hard cap on the account. Each of those works on the number after the fact, which leaves the rate itself where it was set, inside the build.
A more useful number may be cost per unit of work, not just cost per month: what one answer, one processed document, or one handled request costs, and what it was worth to the business. Without that, you are comparing this quarter’s total to last quarter’s total and calling the difference an overrun.
So put one question at the start of the next build, before anything gets wired: what makes this get more expensive, and who is deciding that? If the answer is a person who has never seen the pricing, you have found one place where your software budget is being shaped. A quarterly surprise read as a finance failure is often a design decision nobody knew they were making. Approval alone will not control a cost that is being shaped in the build.
How we architect AI systems
How we architect AI systems
About the author
Missy Ross
Missy Ross is the Founder and AI Architect of Vero Dawn, an AI architecture and solutions company that helps businesses see what could work better, determine the right solution, and bring it to life. Before founding Vero Dawn she spent 21 years in internal audit across banking and manufacturing, at Audit Director level.