AI Spending – Manage to Accelerate

By Florian BEAURAIN

Florian Beaurain is Group FinOps Leader at EDF and an Expert Advisor at Hubadviser. He leads FinOps strategy at Group level, a practice built from scratch, certified by the FinOps Foundation and now supported by a global community of around twenty practitioners. This guide extends the Hubadviser webinar held on July 7, 2026, hosted alongside Ismail Charkaoui, co-founder of Hubadviser.

FinOps applied to artificial intelligence

By Hubadviser – Practical guide

EXECUTIVE SUMMARY

Many CIOs are currently hitting the brakes on AI: OPEX overruns, pressure from the finance department, unpredictable costs. This is a strategic mistake, but an understandable one: without a management tool, slowing down is the only rational option. This guide argues the opposite: financial governance is not what slows AI down, it is what earns you the right to accelerate. The CIO who can tell the executive committee “here is what each use case costs, here is what it delivers, here are my safeguards” is the one who secures budgets and carries weight in decisions.

The Uber case, widely covered by the business press in 2026, illustrates what happens without this kind of governance: the company reportedly burned through its entire annual AI budget in a single quarter, for lack of fine-grained consumption tracking. This guide proposes another path.

This guide is designed for CIOs leading IT departments of roughly 20 to 100 staff, whether within mid-sized companies, the public sector, or larger organizations outside global corporate groups, all facing the same AI cost-control challenges.

1. FinOps: the discipline that earns you the right to accelerate

FinOps, a blend of Finance and DevOps, is an operational, collaborative discipline aimed at maximizing the value created by technology, enabling real-time, data-driven decisions, and giving every stakeholder ownership through close cooperation between IT, Finance and business teams. The FinOps Foundation framework is organized around 4 domains and 22 measurable capabilities, backed by a maturity model.

Note the wording: maximizing value, not minimizing spend. A well-run FinOps practice doesn’t say “no” to use cases: it makes the “yes” defensible in front of the finance department. That is the whole difference between a CIO who suffers budget arbitration and one who drives it.

Long confined to public cloud, the scope of FinOps has expanded considerably. FinOps Foundation data shows the scale of the movement:

  • 98% of FinOps practices now cover AI usage
  • 90% include SaaS and vendor environments
  • 64% cover licensing
  • 57% private cloud
  • 48% in-house datacenters

Two families of levers, fully applicable to AI

Rate optimization : reducing the amount paid for a needed resource, by acting on price:

  • Long-term commitments: Reserved Instances, Savings Plans, Committed Use Discounts, with up to 70% discounts over 1 to 3 years.
  • Contract negotiations: volume discounts, Enterprise Agreements.

Indicator: lower monthly bill at constant scope.

Usage optimization : preventing a cost from occurring in the first place, by acting on usage:

  • By design: serverless architectures, ARM/AMD processors from the design stage.
  • Rightsizing & auto-scaling: matching capacity to actual need.
  • Spot / preemptible instances: up to 90% savings on batch and analytical workloads.

Indicator: gap between forecasted trajectory and actual spend (Forecast Accuracy Rate).

For a CIO, the consequence is structural: cost governance can no longer be thought of silo by silo. AI, SaaS, licensing, private cloud and datacenter all belong to the same approach. The levers proven on classic cloud remain valid for AI, provided you add a dedicated governance layer.

2. FinOps for AI: the token changes the rules of the game

The central metric of AI consumption is the token, the unit used to represent text processed and generated by models. It marks a break from classic cloud: spend becomes a function of the context passed in, the use cases, the reasoning requested, and scale. The result: volatile, hard-to-predict spend, with consumption patterns that don’t fit existing frameworks, a stack of costs, high sensitivity to model choice, and shifting pricing grids.

The answer is not to slow down usage, but to raise the level of rigor: where cloud was governed through monthly reviews, AI consumption requires near real-time monitoring. And a shift in focus: the question is no longer “how much are we consuming?” but “why are we consuming, and what business value does it produce?”

The arbitration triptych: performance, cost and business value

Every use case should be assessed against three pillars: the expected level of performance (reasoning quality, speed, multimodality), the cost of the model used, and the business value generated. It is this ratio, not the prestige of the model, that determines whether a use case is properly sized. This value-driven governance logic is championed internationally by the Tokenomics Foundation (Token Economics), launched under the Linux Foundation and the FinOps Foundation.

The indicators to bring under control

  • Cost per request / per inference, specifying model, version and associated volumes;
  • Cost per use case, per user, per project or per entity, the granularity that enables chargeback;
  • Budget compliance rate (soft limits) and forecast variance;
  • ROI and productivity gains, in monetized time or business value generated;
  • Technical optimization indicators, such as the cache hit ratio.

Key takeaway: the ultimate goal is to correlate what the entire stack represents in cost terms with the business value it delivers. Better visibility, not just into consumption, but into value.

Use this week: the 3 questions to ask your CFO

  1. “If our AI consumption doubles next month, how many days will it take us to find out, and who decides what?”
  2. “Which AI use case would we accept to cut tomorrow, and on what objective criterion?”
  3. “For which use case can we demonstrate ROI today, with figures to back it up?”

If none of the three finds an answer in under a minute, the rest of this guide is your priority for the quarter.

3. The economics of AI: think in ratios, not in euros

Vendor pricing grids change every month or quarter: reasoning in absolute prices means being out of date before you’ve even made a decision. What stays stable: the orders of magnitude between model classes and the mechanics of the token. And the real cost always exceeds the model’s bill, since it includes data, orchestration, observability, security and operations.

Understanding the token, the unit behind the bill

A token is the unit models use to break down text: a short word counts as one token, a long word as two or three. Every exchange is billed in two parts: submitted tokens (the input: the question and its context) and generated tokens (the output: the answer). Generating costs 3 to 4 times more than submitting, because the model produces its answer token by token, the most computationally intensive step, whereas reading the context is processed in a single pass. Concrete example: for the same question, asking for a one-page summary rather than a ten-page report divides the output cost by ten.

Four habits that directly affect the bill:

  • Limiting unnecessarily long outputs by specifying the expected length in the prompt itself;
  • Favoring concise answers whenever the use case allows it;
  • Monitoring use cases that generate large volumes of text (drafting, meeting notes, code);
  • Embedding consumption KPIs per use case along with associated governance (quotas, output formats).

The reference grid: three classes, a 1-to-30 ratio

Model classCost ratio (output)Target use caseAssignment rule
Light / fastClassification, extraction, simple high-volume tasksDefault for everyone: the model you move away from only with justification, not the other way around
Mid-range≈ 3–5×General-purpose production, internal assistantsAssigned by population or by mapped use case
Premium (reasoning)≈ 10–30×Complex tasks, agentic workflows, advanced reasoningArbitrated case by case, on demonstrated real need

Orders of magnitude as of July 2026: output ≈ €0.25–4.60/M tokens (light), €0.75–13.75 (mid-range), €11–27.50 (premium); input ≈ €0.05–0.75 / €0.40–2.75 / €1.85–4.60 per M tokens. These amounts move fast; the ratios, much less so.

Three ways to access models

  • Via API, the natural entry point: pay-as-you-go per token, negotiable discounts on commitment (typically above $50k/year), choosing inference regions that meet your regulatory requirements;
  • Via hosted GPU, to amortize the resource: the cost per token becomes (GPU amortization + network + storage + operations) ÷ tokens produced; GPU pricing is negotiable (around €2.75/hour for an H100 as of today) and optimizations such as vLLM maximize utilization;
  • On-premises (datacenter), for sovereignty and compliance, factoring in the current GPU shortage; counter-intuitively, the fully amortized cost over 3 years can turn out lower than the API approach for certain usage profiles.

4. Multi-model and routing: the end of the single LLM

A direct consequence of this grid: a mature organization does not manage “one LLM”, it manages a portfolio of models. This requires an up-to-date map crossing three dimensions: populations (who uses it?), use cases (for what purpose?) and authorized models (with what performance and cost class?).

Risk #1 identified: letting entire populations use a premium model on a daily basis, up to 30 times more expensive than a light model, for tasks a fast model would handle just as well. The sound rule: light by default, premium on justification, never the other way around.

From static routing to dynamic routing

The first level of maturity is static routing: the appropriate model is fixed for each use case according to the performance/cost/value triptych. The next level is dynamic, programmatic routing: calls are routed in real time based on measured latency, or even on time of day. A critical use case keeps a fast model during peak hours; less sensitive use cases switch to cheaper models.

Light models catching up with frontier models

Two families coexist on the market. Light models (for example GPT-4o mini, Claude Haiku or Mistral Small) are designed to be fast and handle large volumes at lower cost: they work very well for sorting, extraction or classification. Frontier models (for example GPT-5.5, Claude Opus or Gemini Pro) carry the highest level of reasoning available at any given time: they excel at complex tasks, but cost 10 to 30 times more on output.

We are increasingly seeing the end of subsidized pricing, with price convergence between providers and the performance/cost ratio of light models catching up with that of frontier models on well-defined use cases. In practice: what only a frontier model could do a year ago, a light model now does almost as well, for a fraction of the price. The “always the biggest model” reflex therefore becomes a little more costly, and a little less justified, every quarter.

Open source as a strategic fallback

On one side, proprietary models (OpenAI’s GPT, Anthropic’s Claude, Google’s Gemini) are only accessible via the provider’s API, under its terms and its jurisdiction. On the other, open models such as Llama (Meta), Mistral (Mistral AI) or DeepSeek publish their weights: any organization can host them on its own infrastructure and run them without depending on a single provider.

Key takeaway: we have already seen certain models cut off overnight, and there is no guarantee against export controls being activated tomorrow on widely used models. Having an open-source model as a fallback alternative to your production model really matters.

Beyond cost, this dependency represents a business continuity risk, particularly sensitive for the public sector and operators of vital importance, where it overlaps with sovereignty requirements. But this choice comes with a technical price: hosting an open-source model requires skills that calling an API does not, such as MLOps or securing GPU infrastructure. For a mid-sized IT department, the right compromise is often to entrust this hosting to a partner or a hyperscaler rather than fully internalizing it: what matters is keeping control over the choice of model and the ability to switch quickly.

Want to learn more?

You now have the conceptual framework: the token, model classes, the end of the single LLM. You know where the real optimization levers lie. But this is where the gap widens: understanding the principles is one thing. Taking action is another.

The rest of the guide gives you exactly that.

First, a seven-layer grid that structures your entire cost architecture, from GPU all the way to business workflows. Not to impress, but to know where to act when the bill drifts, and where to start as early as Monday morning.

Next, the “minimum viable” setup: a 90-day plan calibrated for an IT department of 20 to 100 people, also calibrated for the public sector. Zero greenfield fantasy, zero requirement for in-house experts. Simply: what should you see in the first 30 days, measure in the next 30, and arbitrate the month after.

And above all, the 10-question self-assessment that positions you honestly. Not to grade you, but to tell you: “Here is where you stand, here is your first high-impact step.”

Download the rest. That’s where you finally decide who pays for what, and why.