AI FinOps: How to Govern Usage-Based AI Spend

AI FinOps is the practice of governing usage-based AI spend, meaning spend that depends on the volume actually used (API calls, tokens, hosted models), by making it visible, attributable and controllable. It rests on four elements: visibility by team and project, cost attribution with tags, budgets with alert thresholds and continuous optimization, with clear roles across technology, finance and business.

Why does usage-based AI spend need specific governance?

A per-seat license has a cost known in advance: number of seats times price. Usage-based spend does not. The cost depends on how many requests are sent, how long they are and which model processes them. A team that is experimenting may generate a modest cost, and the same team, with a prototype moving into production, can multiply it without the budget foreseeing it.

Three traits set it apart: variability (cost changes with adoption and technical choices), decentralization (whoever consumes is not whoever pays) and opacity (without tagging the invoice shows a total, not who it belongs to).

FinOps was born for the cloud, and its principles apply to AI without depending on a specific vendor: get those who build, those who pay and those who decide to work together, to obtain value from spend. For the per-seat side, the reference is how to reduce AI license spend. Here we deal with the usage-based side.

Visibility: seeing spend by team, project and use case

The first goal is knowing where the money goes. Three levels of detail are needed.

• By vendor and model: how much is spent on each service and on which model family.
• By team and project: who consumes. This is the level at which accountability is assigned.
• By use case: which business function the consumption corresponds to. This is the level that allows cost and value to be compared.

The source is the usage and billing data that vendors provide, to differing degrees, through consoles or exports. Check for each vendor which granularity is available. Where data is partial, an internal intermediate layer (a service that routes requests and records them) gives a uniform picture across different vendors.

A useful dashboard shows spend for the period, comparison with budget, end-of-month projection and unit cost per use case. A few indicators are enough to start.

Tags and cost attribution: who pays for what

Attribution turns a total into accountability. It is based on a simple tagging convention applied everywhere.

A minimum set of tags:

• Owning team.
• Project or product.
• Use case, aligned with the company register.
• Environment: development, testing, production.
• Cost center to charge.

Practical rules: every access key or service account belongs to a single team and a single project, because shared keys make attribution impossible. Tagging is mandatory at creation. The share of untagged spend is an indicator to monitor.

If a resource serves several projects, document an allocation rule (by request volume or fixed shares): better approximate and shared than absent.

The use case register, described in the AI use case register, is the natural basis for the use case tag: it links spend and accountability.

Budgets and alert thresholds

A budget without alerts is an intention. Thresholds turn the budget into a control.

Hypothetical example, with invented values for illustration. A project has a monthly budget of €10,000 for AI consumption. The thresholds are:

• 50%: €5,000, informational alert to the team.
• 80%: €8,000, alert to the project owner and to finance.
• 100%: €10,000, alert with a mandatory decision (increase the budget, limit, review).

At the end of the tenth day of a 30-day month, spend is €4,500: no threshold has been crossed. But the linear projection is €4,500 ÷ 10 × 30 = €13,500, which is 35% over budget (€3,500 on €10,000). That is why, besides thresholds on actual spend, you need an alert on the end-of-period projection: it warns you while there is still time to act.

Other good practices:

• Technical limits (spend or request caps) where possible, so that a programming error, such as a loop of calls, cannot consume the budget in a few hours.
• A written escalation procedure: who is notified, who decides, within what time.

Optimization: lowering unit cost without losing quality

Optimization starts from one indicator: unit cost, meaning cost per request, per document processed or per useful result. It is more informative than the total, because it separates healthy growth (more use) from inefficiency (more cost for the same result).

Hypothetical example: a use case processes 40,000 requests in a month with spend of €6,000. Unit cost is €6,000 ÷ 40,000 = €0.15 per request. After an optimization effort the cost falls to €0.12: the saving is €0.03 × 40,000 = €1,200 a month, which is 20% (1,200 ÷ 6,000).

The levers, in general terms:

• Model choice by task. Simple tasks do not require the most capable and expensive model. Define an assignment criterion and verify it with quality tests.
• Length of requests and responses. More concise prompts, context limited to what is needed, responses with a maximum length.
• Reuse of results. Avoid reprocessing the same request several times, where acceptable.
• Switching off what is not needed. Forgotten test environments, abandoned prototypes, keys no longer used.

Every optimization must be validated on quality: a saving that worsens the result just moves the cost elsewhere. That is why unit cost should be read together with a quality or process outcome indicator, following the logic of AI ROI.

Roles and responsibilities in AI FinOps

FinOps is a cross-functional practice. It works when roles are made explicit.

• Developers and technical team leads: tag resources, monitor their own consumption, optimize.
• Platform team or AI center of excellence: defines conventions, tools and technical limits, and manages routing.
• Finance and management control: sets budgets, receives alerts, reconciles invoices and actuals, handles cost allocation.
• Procurement: negotiates terms and spend commitments based on observed consumption.
• Business owner of the use case: answers for the value obtained against the cost.
• Sponsor (CIO or Chief AI Officer): arbitrates priorities.

Cadence: weekly review with the teams on alerts, monthly with finance on variances, quarterly with procurement.

Steps to start AI FinOps

1. Inventory the sources of consumption: accounts, keys, projects, hosted models, vendors.
2. Assign an owner to each source.
3. Adopt the tagging convention and make it mandatory.
4. Build the dashboard with spend, budget, projection and unit cost.
5. Set budgets and thresholds by project, with an escalation procedure.
6. Measure the unit cost of the three most expensive use cases and look for levers.
7. Include consumption in the TCO of the solution: see the hidden costs in AI TCO.
8. Review at a fixed cadence conventions, thresholds and roles.

Where Delphis fits

Delphis is a platform, independent of AI vendors, that connects spend, adoption, impact and regulatory obligations. It reconciles costs with actual usage, so that usage-based spend can be read next to per-seat spend, and helps compare cost with impact measured on bounded processes, with a before-and-after baseline. Data on people stays aggregated by role or department. To see the approach, visit the Cost page.