AI Is Turning IT Into a Commercial Technology Company

The CFO has started asking why this quarter’s AI run-rate does not match what was approved at planning, and the honest answer is that the AI IT operating model the organisation is funding was designed for assets, not consumption. Token spend rises whenever a developer ships an agent, whenever a service team enables a copilot, and whenever a customer interaction triggers a retrieval. The cost driver is downstream demand, not upstream architecture, and the funding model has no mechanism for converting that demand into a budget conversation that ends in a decision.

In Brief


  • Token-based AI spend is opex, per-call, and demand-driven — structurally incompatible with the capex, per-asset, supply-driven assumptions inside the plan/build/run IT funding model.
  • The CIO is now running an internal commercial technology company whether the funding model has caught up or not — consumption is happening across the business and the cost is sitting on IT's P&L.
  • A defensible AI IT operating model requires four mechanisms working together: a published service catalogue with consumption pricing, chargeback to consuming business units, product-team funding, and an AI FinOps capability that does for tokens what FinOps did for cloud.
  • Without unit economics reporting at the product level, the next quarterly run-rate conversation will keep being about explaining variance rather than governing demand.
  • The CIOs who put this in place this year will spend the next budget cycle defending value per token. The CIOs who do not will spend it defending overruns.

That is the structural finding. Token-based AI spend is opex, per-call, and demand-driven — and the plan/build/run cycle that has governed IT investment for two decades assumes capex, per-asset, and supply-driven economics. The two cannot hold in the same model. McKinsey’s most recent State of AI survey shows enterprise AI spend now accounts for a material and rising share of technology budgets, with the bulk shifting from experimentation into production workloads (McKinsey, 2025). Gartner’s IT Key Metrics Data confirms that plan/build/run still consumes the majority of IT spend in most organisations (Gartner, 2025). The arithmetic does the rest: a budget line built to amortise stable infrastructure cannot absorb a consumption line that doubles when a popular agent is shipped on a Tuesday.

Opex variability breaks fixed annual budgeting

Most IT budgets are built on a planning rhythm that assumes the cost base is knowable twelve to eighteen months ahead. Hardware refresh cycles, licence renewals, project phases, support contracts — each one falls inside a forecasting tolerance the CFO is willing to live with. The variability that does occur is bounded, and the bounds are visible.

AI consumption is structurally different. International Data Corporation (IDC)’s tracker on enterprise AI spend has put it on a trajectory most CFOs have not yet seen on a single line of their own P&L (IDC, 2025). When a single product team integrates a frontier model into a customer-facing workflow, the per-call cost may be small, but the per-month cost moves with usage — and usage moves with adoption, with model upgrades, and with the design choices of teams who do not see the bill. The CIO inherits the variance at the executive committee table without inheriting the demand decisions that produced it.

This is not a failure of forecasting discipline. It is what happens when a supply-side funding model meets a demand-side cost driver. The organisations doing most things right — capable finance teams, mature project portfolio management, well-run vendor governance — still arrive at the same place, because the model itself has no concept of price-per-call across a portfolio of consuming products. The result is a quarterly run-rate conversation that keeps repeating, and a CIO who is asked to explain variance they have no mechanism to govern.

Plan/build/run cannot hold under AI

The plan/build/run cycle was designed around assets. An asset is planned, capitalised, built, then operated under a run-cost that depreciates predictably. The decisions that drive the cost happen early; the operating cost is largely a consequence of the build decision. Governance is therefore concentrated at the gate.

Token-based AI inverts that. The build decision sets the floor; the operating cost is set later, by every consuming team that integrates the capability into a workflow. A model that costs a few cents per call becomes a six-figure monthly line when a product team puts it into a high-traffic journey — and the team making that decision is not the team holding the budget. The gate is in the wrong place. By the time the spend shows up in run, the decisions that drove it are six months upstream of any committee that could have shaped them.

This is the move the existing model cannot make. Plan/build/run can be tuned, refined, and reported on more frequently — and many organisations are trying that first. The pattern that surfaces, across the engagements where this has been attempted, is that more frequent reporting on a model that cannot govern demand only produces a higher-resolution view of variance. The fix is not faster reporting against the wrong unit. The fix is a different unit.

IT now runs a tech company

The structural answer is to stop treating IT as a cost centre that delivers projects to the rest of the business, and start operating it as an internal commercial technology company that offers products and services on terms the business can reason about. The shift is not rhetorical. It is a set of concrete mechanisms — a published service catalogue, consumption pricing, chargeback to the consuming business unit, product teams as the funding unit, and AI FinOps as the capability that makes the unit economics legible.

The catalogue is the first move. AI capabilities — model access, retrieval pipelines, agent runtimes, evaluation services — are listed as services with a price-per-unit, a service level, and a clear consuming-team interface. Business units choose what to consume, at what volume, with full visibility of the unit cost. The product team that owns the capability is funded as a product, not as a project — which means the team is accountable for the cost-per-unit it delivers, not just for shipping a feature on a date. (For the wider operating-model context — why portfolio funding shifts from project to product, and what that means for governance — see ZXM’s analysis of portfolio discipline without buying SAFe.)

This is the move that lets the CIO speak the language the CFO is asking to speak. A per-call price published in a catalogue, multiplied by consumption volumes attributable to named business units, produces a forecast that holds — because the units of analysis match the units of cost. The CFO no longer asks why the run-rate moved. The business unit that drove the consumption sees the cost directly, and the conversation moves from explaining variance to governing demand.

Chargeback makes governance real

A service catalogue without chargeback is a price list nobody pays. Chargeback — the mechanism that moves the cost of AI consumption from IT’s central budget to the P&L of the business unit that triggered it — is what converts the catalogue from an exercise in reporting into a governance instrument. The business unit choosing to embed a copilot in a customer journey now sees the per-call price land in its own monthly numbers. The product team running the capability is funded for the value it generates, not just for the cost it absorbs.

The FinOps Foundation’s FOCUS specification has done the analogous work for cloud — defining a common data format so that consumption can be reported, allocated, and governed across providers and consumers in the same units (FinOps Foundation, 2025). The AI FinOps body of practice that is now forming inside the same community is doing the same work for tokens, inference, and model-served capabilities. The maturity gap is real, but the precedent is clear: cloud governance worked when consumption became visible at the team that drove it, with a unit of analysis the consuming team could act on.

The chargeback design that holds has three properties. The cost allocation is transparent at the consuming-team level, not aggregated to the division. The unit of analysis matches the unit of decision — a price per call, per token, per agent run, not a quarterly true-up. And the consuming team has the ability to govern its own consumption, which means the catalogue must publish elasticity options: cheaper models for non-critical use, batch endpoints for asynchronous work, caching tiers for repeated retrievals. Without those options, chargeback creates resentment rather than governance.

What IT must build this year

The capability set the CIO is now accountable for assembling is small in number and demanding in design. Four pieces sit at the centre, and each is a discipline the existing IT organisation has either none of or a partial version of.

The first is a product management function for the AI service portfolio. Each capability in the catalogue is owned by a product team with a price, a roadmap, a service level, and a defined consuming-team interface. This is not a renamed project team. The accountability is for ongoing service economics — adoption, unit cost, value generated for the consuming business unit — not for delivery of a one-off scope.

The second is an AI FinOps capability. The FinOps Foundation’s emerging AI guidance frames this as the discipline of unit economics for AI: cost-per-call, cost-per-agent-run, cost-per-business-outcome, reported in a way the consuming team can act on (FinOps Foundation, 2025). It is the same shift cloud FinOps required a decade ago, and it requires the same combination of finance fluency, engineering literacy, and operational discipline. Few IT organisations have this in place; the ones that do are running the most defensible budget conversations of the cohort.

The third is demand governance. IBM’s Institute for Business Value has shown that the executive teams most confident in their AI investment governance are also the ones with the clearest mechanisms for shaping demand — deciding which business problems get AI capacity, at what cost-per-outcome, and with what trade-offs against alternatives (IBM Institute for Business Value, 2023). Demand governance is what converts a catalogue from a passive price list into an active portfolio choice. Without it, the CIO funds whatever the business asks for and explains the bill afterwards. (For the principles that underpin defensible AI governance design at board level, see ZXM’s article on AI governance without accountability design.)

The fourth is unit economics reporting at the product level. The reporting line that matters to the CFO is no longer “AI spend this quarter”. It is “cost per business outcome, by product, by consuming unit, with trend”. That report is only producible when the catalogue, the chargeback mechanism, and the FinOps capability are all in place — which is why it is the last to arrive, and the one that proves the operating model holds.

The CIO who puts these four pieces in this year takes a defensible position into the next budget cycle. The conversation with the CFO shifts from explaining the variance on a single AI line to governing the unit economics of a portfolio. With the executive committee, approving an AI budget is replaced by approving the products the organisation is willing to fund at the price they will run at. And the business stops hearing “we cannot afford this” and starts hearing “here is what it costs, here is what it delivers, and here is the price you are choosing to pay”. (For a related view on how AI operating-model decisions get made by default rather than by design, see the linked analysis.)

That is what running IT as an internal commercial technology company looks like. The shift is happening to the role whether the funding model has caught up or not — the only question is whether the model the CIO is defending at the next quarterly review is the one being broken, or the one being built.

References

About the author

Receive insights on strategy, leadership, and transformation.
By subscribing you agree to our Privacy Policy
© 2026 Zen Ex Machina (ZXM) Pty Ltd. All rights reserved. ABN 93 153 194 220

Discover more from Zen Ex Machina

Subscribe now to keep reading and get access to the full archive.

Continue reading

agile iq academy logo 2022-05-05 sm

Enter your details

search previous next tag category expand menu location phone mail time cart zoom edit close