The AI FinOps Practitioner Is Starting to Look Like an Economist

Enterprise AI has a measurement problem running in an unexpected direction. You can see more of your consumption than ever. Tokens are counted, GPU utilisation monitored, API calls traced, and costs attributed to teams, applications and products. Whether any of that consumption produces economic value is a much murkier picture.

PwC’s 2026 Global CEO Survey covered 4,454 chief executives across 95 countries and territories. More than half, 56 per cent, said their organisations had seen no significant financial benefit from AI to date. Only 12 per cent reported both lower costs and higher revenue. Much of that investment is early, strategic or deliberately experimental, so read the figure as a timing problem rather than a verdict. It tells you that measuring AI expenditure and establishing its economic value are separate disciplines, and that most organisations have only built the first one.

FinOps is moving into that gap. The 2026 State of FinOps found 98 per cent of respondents now manage AI spend, and mature practices are turning towards unit economics, AI value quantification and influencing technology selection instead of hunting another round of cloud savings. The easy reading is that FinOps is expanding into technology investment management. I think that reading is wrong.

Technology Business Management already treats technology as an investment portfolio, and IT Financial Management gives Finance the period-accurate structure it relies on. Neither is failing at its job. The change worth watching is happening in the space between the disciplines, where nobody has clear ownership.

As consumption-priced technology becomes embedded in the production of products and services, you need a way to connect a technical decision with its financial consequences, then connect those consequences with business value, while there is still time to change the decision. That is a technology-economics problem, and it sits across more functions than FinOps can reach on its own.

Cloud created the first crack in the financial operating model

FinOps exists partly because public cloud changed the speed at which technology decisions became financial decisions. An engineer with a console login could stand up capacity in minutes, and a bill could double between one month and the next without anyone signing a purchase order. By the time traditional financial reporting explained the variance, the behaviour that created it had often been running for weeks.

The FinOps Foundation’s 2026 research on the FinOps and ITFM relationship describes the difference explicitly. FinOps operates on near-real-time cost and usage information, potentially at the level of a workload, query, pipeline or token. ITFM produces the period-accurate reporting Finance can plan from, decide on and account against. The audiences differ, the cadences differ, and both are legitimate readings of the same spend.

Consumption-based pricing widens the gap between the two clocks. Cloud was the first large-scale example. AI, SaaS, data platforms and other variable commercial models extend the same problem. The research warns that organisations without an effective bridge between FinOps and ITFM repeat the cycle every time a new category appears, and end up with unattributed expenditure, competing reports and retrospective reconciliation long after the consumption has scaled.

The stakes rise with AI because you now have far more production choices to pick between. A business process can invoke a frontier model, a smaller specialist model, a managed API or self-hosted infrastructure, or combine several. An agent may call external tools, retry a task or invoke another agent. Part of the process might be better handled with conventional software, and another part may still be cheaper with a person. Each choice moves cost, latency, quality, operational risk and future demand. A monthly budget will not help you choose between them, and a token dashboard will not either, since neither carries the cost of the alternatives you are choosing between.

The model with the lowest price can still have the worst economics

The problem becomes clearer at workload level. Suppose one model charges a fifth of what another does per million tokens. On the rate card that settles the comparison. In operation it settles very little.

A business is generally not trying to manufacture tokens. It is trying to resolve an insurance claim, review a document, answer a customer enquiry, produce software or complete some other unit of work. Between the model price and the completed work sit additional context, retries, orchestration, human review, infrastructure and the consequences of failure. A lower-priced model that fails more often can burn substantially more resource to produce the same acceptable result. Waste runs the other way too, and it hides better: workloads sitting on a premium model because that was the default at launch, long after a smaller one could clear the quality bar for most of the traffic.

Aureon’s earlier Token Price Trap analysis argued this, and the FinOps Foundation’s own work now argues something close to it. Its Unit Economics capability describes a progression from resource measures such as cost per token towards outcome measures such as cost per assist, cost per agent action or cost per case deflected. Its token-economics guidance cautions that token consumption is one component of AI economics, and that higher token usage can be economically rational when it produces disproportionately higher value.

Somewhere in that gap, ordinary cost optimisation stops being the right frame. What matters economically is the cost and consequence of alternative ways of producing the outcome, which is a much larger question than the price of two models. Architecture is part of the financial decision now, along with model routing, quality thresholds, failure costs and the possibility that AI is the wrong production method for part of the workflow.

A CTO and a CFO are looking at the same substitution problem from opposite ends. The CTO sees alternative technical production methods. The CFO sees alternative uses of resources with different costs, risks and expected returns. Neither view is sufficient on its own, which is why the decision keeps stalling when the two people never sit in the same room.

One technology investment contains three different economic questions

The industry collapses several decisions into the word “optimisation”. Take one workload and ask three different questions of it.

An Australian financial services firm I worked with over the past year ran an AI enquiry channel handling between five and eight thousand customer enquiries a month. Across one quarter the team cut the cost per resolved enquiry by more than a quarter. What nobody could tell me was what a resolved enquiry was worth. They had a cost per resolution and no value per resolution, which is this article’s argument sitting inside its own best example.

Part of that was resource efficiency. Requests were going to a premium model when a cheaper tier could handle a large share of them to the required quality, and common enquiries were answered from scratch each time instead of from cache. Routing and caching took cost out without anyone reconsidering the workload itself. It had already been chosen, and the only question was whether the resources feeding it were being consumed sensibly.

Most of the saving came from somewhere else, and it was a different kind of question. Enquiries were bouncing to a human because the workflow could not reach a system it needed. The model had been efficient the whole time. The money was sitting in the human handling behind it, so the thing to fix was the architecture and the operating process rather than the inference cost. Ask whether this is an economically sensible way to produce the outcome and you get a different answer from asking whether it runs cheaply.

Then portfolio allocation, which neither of the first two can reach. On the numbers the workload had earned more investment. It did not get it. The next tranche went to a customer portal rebuild. The head of platform told me afterwards that nobody had asked what the portal would cost per interaction or what it would return, because the portal came with a strategic narrative and his workload came with a spreadsheet. He is a partial witness and I would not put much weight on his read of the portal’s merits. The structural problem he described holds regardless: the two proposals were never compared on the same basis, because nobody in the organisation had built a way to do it.

Notice who had to be in the room for each one. The engineers could settle the first from consumption data on a Tuesday afternoon. The second needed Product, because it turned on the value of the outcome once manual handling was counted in. Nobody could answer the third from inside the workload at all, which is why it went unasked.

Run them against your own largest AI workload and see how far you get. What does one unit of its output cost you, counting the human work behind it. Has anyone priced the alternative ways of producing that same output, including not using AI for part of it. And when it last competed for money, what beat it, and was that comparison made on the same basis. In my experience the first question has an owner, the second starts an argument, and the third gets a long pause.

They are related, and they are not a maturity ladder. A portfolio constraint can force an architecture change, scarcity can move unit economics, and a strategic initiative may rationally tolerate poor early workload economics because the first tranche of investment is buying information about an uncertain opportunity. The answers also conflict. A workload can be technically inefficient and still deserve continued investment while its architecture matures, while another sits beautifully optimised (the dashboards love it) and deserves to be retired, because the outcome it produces is no longer worth having.

That has an awkward implication for FinOps, and the Framework got there first. The economically optimal technology bill is higher than the lowest achievable one, and “business value drives technology decisions” has been a FinOps principle from the start. The doctrine is settled. The practice is not, and the portal decision above never ran that test. Good capital allocation sometimes increases technology expenditure, because the incremental value of the extra consumption exceeds its incremental cost. An impressive savings number can quietly destroy value by suppressing a workload that was making money. Cost belongs in the decision as a constraint. Make it the objective and you start optimising the wrong number.

Nobody holds all the evidence

TBM already has a credible claim on the third question. The TBM Council’s current guidance for CFOs describes a discipline that connects general-ledger inputs through technology resources and solutions to business outcomes, improves forecasting and supports investment governance, and positions mature TBM as a partner in scenario planning rather than retrospective reporting. ITFM brings a financial authority most FinOps practices lack, because it ties technology expenditure to budgets, accounting structures, cost centres and formal cycles. Between them they can price a portfolio and defend the number to a board.

What they cannot do is explain why last Tuesday’s consumption moved. FinOps can, and it carries the engineering context to say which lever would move it back. Product owns the definition of the outcome and the demand behind it, Engineering owns the production choices and their quality implications, and Corporate Finance holds the authority to allocate capital. Each holds information the others need to price a decision.

The same research reaches a practical conclusion about making the relationship work. Organisations that succeed leave the functions where they are and build permanent bridges between them: shared identifiers and terminology, consumption forecasts handed from FinOps into ITFM before period close, new consumption categories classified at contract time, and a common financial narrative. Where that bridge is missing, the research reports parallel reports, disputed savings and conflicting explanations arriving at the moment an executive needs a decision. A technology finance leader at a global manufacturer, quoted anonymously in the research, puts it more bluntly: drawing a hard wall between FinOps in operations and ITFM in finance is “effectively a design for failure”, because each discipline holds information the other needs to produce a trusted picture of technology cost and value.

Nationwide Building Society shows the logic working. Tim Wright’s technology cost function unified FinOps, ITFM/TBM and Software Asset Management under a single structure spanning cloud, on-premise and software, and is now extending that model to AI. One organisation proves nothing universal, but it does show integration moving past the conceptual diagram into operating accountability, which is more than most of the industry has managed. The reporting line matters less than whether a decision keeps its economic meaning as it crosses between the functions on it.

Technology economics needs two clocks

Technology economics runs on two clocks. The consumption clock moves with deployments, transactions, agent calls and architecture changes, and its signal can shift hourly. The financial clock governs budgets, forecasts, accounting treatments and formal investment decisions, and needs reconciled numbers across the estate. Connecting the two is the work. Most organisations choose between them instead, which is why Finance and Engineering so often arrive at a review holding numbers that disagree. The first two questions live on the consumption clock and the third lives on the financial one, which is part of why the third gets asked later, in a different meeting, by people who were not in the room for the first two.

Financial consequences now get determined earlier in the technology lifecycle. The 2026 FinOps survey ranks pre-deployment architecture costing as the second most-requested tool capability that does not yet exist, and the Foundation’s new Executive Strategy Alignment capability expects major decisions to weigh cost, risk, delivery timing, quality and expected outcomes together, not total spend alone.

Consider a three-year AI infrastructure commitment. ITFM can model it, Finance can assess it against the plan, and TBM can place it in the portfolio. None of that resolves the demand assumption underneath it. FinOps consumption data provides the trajectory, though historic run rate alone will not settle it. Product has to explain the adoption expectations, Engineering the architecture changes that could move consumption, and Procurement the contractual flexibility. Five people have to agree on a number none of them owns, before anyone signs. Technology economics has to surface those assumptions while the commitment can still be changed.

Where the analogy earns its keep

Calling a FinOps practitioner an economist is provocative and, taken literally, wrong. The emerging capability is multidisciplinary. The questions arriving in the job, though, are recognisably economic ones.

What one more unit of consumption produces is marginal value, and the Foundation’s token-economics guidance is a marginalist argument at heart: spend more tokens where the incremental value exceeds the incremental cost. Whether a cheaper model, a different architecture or a human process could produce the same outcome is substitution, which is what the customer-service example turned on. Why the workload with good economics still missed out on the next dollar is opportunity cost. And budgets, quotas and chargeback rules are incentive design: they exist to change what engineers do before they deploy.

Tokenomics gives the clearest example. Raw token consumption is useful operational telemetry. Once you start allocating token budgets, governing model access or comparing the value created by alternative uses of AI capacity, you have moved from measurement into resource allocation, and the skills those two activities need are not the same.

The institutional version of that shift arrived on 4 August 2026, when the Linux Foundation launched the Tokenomics Foundation with 30 founding members including IBM, Oracle, SAP and JPMorganChase. Its remit, in close partnership with the FinOps Foundation, is to define open standards for the economics of AI: token value metrics, cost-to-serve measurement and frameworks linking AI spend to business outcomes. A standards body is early evidence of institutional demand, not proof that a profession has changed. It does show large buyers expecting to price AI capacity rather than simply book it.

Be careful with the language, though. Credits and quotas on their own are just an allocation mechanism. Once internal prices, scarcity or transferable entitlements start to move demand, the system begins to behave like a market, and understanding that behaviour matters as much as calculating the cost.

Uncertainty changes what good capital allocation looks like

A technology-economics model also has to handle something traditional optimisation largely avoids: the future is uncertain. An experimental AI workload may look uneconomic at low scale. It may need excessive human review, the architecture may be immature, and user behaviour may be unknown. None of that makes the investment irrational, because early investment can buy information.

A July 2026 paper by Foster Provost and Panos Ipeirotis at NYU Stern tackles this by decomposing an AI investment into value if successful, likelihood of success and investment required. Their argument is useful because precise ROI estimates create false confidence when nobody yet knows whether the product will work. Better, they suggest, to structure the decision around the value of the opportunity and stage the funding as evidence improves. Those three variables are a way of answering the third question when the evidence is thin: value if successful is what Product has to price, likelihood of success is what a small opening commitment is there to test, and investment required is the part FinOps can observe rather than assume. It is a preprint, so treat it as an emerging framework rather than settled practice.

Portfolio economics, taken seriously, is more than ranking projects by current ROI. Some investments deserve staged funding because they buy information about a large opportunity. Some deserve immediate scaling because the evidence is already strong. Some should be held until a particular risk or dependency clears, and some should stop. Scale or kill is too coarse. How much capital should you expose at the current level of uncertainty, what evidence unlocks the next tranche, and what would cause you to withdraw? A CFO will recognise that logic and a CTO should too. FinOps improves it by replacing the theoretical consumption assumptions with observed ones.

Automation makes the boundary more consequential

Automation is arriving first at the question the engineers could already settle on a Tuesday afternoon. Parts of traditional cloud cost analysis are becoming easy to automate. AWS’s FinOps Agent, currently in public preview, investigates cost anomalies to likely root cause, answers natural-language cost questions, produces scheduled reports and surfaces optimisation opportunities. AWS positions it as a way for engineers to get answers directly while central FinOps teams spend their time elsewhere.

One product in preview settles nothing, and cost management contains plenty of judgement that will stay hard to automate. The direction is clear enough though. As the mechanical work of finding, explaining and routing cost information gets cheaper, being good at producing that information stops being a differentiator. Retrieval gets cheaper every quarter. Deciding whether a variance is waste or successful growth does not. So is weighing one production method against another, modelling demand, and walking an executive through a trade-off they would rather not make.

Vendors are automating the bottom of the job while consumption pricing moves the financial decisions upstream, into architecture and procurement. The part that shrinks is the middle, where most FinOps practitioners currently spend their week: producing and explaining cost information. Resource efficiency is being automated. Workload economics and portfolio allocation are not, because both need a value for the outcome, and no billing feed carries one.

The limits of the claim

Any argument about a profession becoming more strategic risks turning into a land grab, and that would weaken the case here. FinOps should defer wherever another discipline holds stronger authority or better information, which is most of the time. Its own ground is narrow and worth holding: the place where consumption behaviour, technical decisions and near-real-time economics meet.

The opportunity is to make the interfaces explicit enough that a decision can move through the organisation without changing economic meaning each time it crosses a boundary. That is harder than collaboration, and it needs the bridges described earlier, agreed decision rights and a deliberate hand-off between the two clocks, and AI extends the same requirement into Product, Engineering and business leadership.

Transformation without ownership

The capability connecting those views is technology-economics decision support. It needs a name and an owner more than it needs a department, and most organisations have given it neither.

For FinOps, the standard of usefulness changes. Cost visibility and optimisation still matter, but the higher-value question is whether FinOps can make technical consumption economically legible to everyone else making the decision. It asks for a practitioner who can still trace a billing anomaly, and who can also discuss marginal value with Finance, substitution with Architecture and opportunity cost with executives.

The job now requires economic thinking. Whether the profession develops it will decide something fairly stark: whether FinOps stays the function that explains technology expenditure, or becomes one of the disciplines that improves the decisions creating it.

Work through the three questions

Those three questions are what Aureon’s Technology Economics Decision Framework is built around: the evidence each one needs, and the hand-offs between them, before an expensive choice becomes hard to reverse. If you would rather work through it with someone, talk to us.