How to Build an AI FinOps Function Before Your CFO Forces You To

The pattern is familiar enough that it's become a cliche. An AI platform team scales up a few production workloads, token volumes climb, and then one quarter the cloud bill shows a line item nobody budgeted for. The CFO calls. The engineering lead pulls together numbers from six different dashboards. The numbers don't add up. An emergency task force forms.

That task force is your AI FinOps function. It just got formed in the worst possible way — reactively, under pressure, without the instrumentation it needs to answer the questions it's being asked.

This post is for teams that want to build it the right way, before the emergency. Here's what the function needs to look like, who should own it, what it needs to do on an ongoing basis, and how to stand it up without a reorg.

Why the Reactive Pattern Produces Bad Outcomes

When an AI FinOps function forms under CFO pressure, a few things are almost always true:

• The first deliverable is a retrospective cost report, assembled from incomplete data, that tries to explain a number that has already been spent.
• The team has no instrumentation in place, so every piece of analysis requires manual work from multiple engineering teams who have other priorities.
• The recommendations that come out of the process are blunt — spend caps, model downgrades, feature freezes — because there's no task-level data to support surgical optimization.
• The organizational dynamic is adversarial: finance wants to cut, engineering wants to build, and there's no shared framework for making tradeoffs.

A proactive AI FinOps function avoids all of these failure modes. It builds the instrumentation before it's needed. It develops the shared framework before there's a crisis. It earns credibility by bringing cost context into product decisions, not by issuing post-hoc cutbacks.

What an AI FinOps Function Actually Does

Let's be concrete about scope before discussing structure. An AI FinOps function is responsible for four things:

1. Visibility

Attribution of AI spend to products, use cases, teams, and task types. This requires instrumentation across every surface that makes LLM API calls, a data pipeline that aggregates that telemetry, and a reporting layer that makes it accessible to the right stakeholders. Visibility is the foundation — without it, nothing else is possible.

2. Cost-per-Task Benchmarking

Converting raw spend into business-relevant metrics: cost per support ticket, cost per document processed, cost per code suggestion, cost per query. These metrics enable comparisons across model versions, prompt strategies, and architectural approaches. They also create the shared language between engineering and finance that makes optimization discussions productive.

3. Optimization

Identifying and executing cost reduction opportunities: model routing, prompt efficiency, caching, batching, context window management. The key word is executing — not producing a list of recommendations and handing it to another team, but owning the process through to implementation. This requires engineering participation, which is why ownership structure matters.

4. Governance

Setting and enforcing standards for how AI spend is tracked, budgeted, and approved. This includes instrumentation requirements for new AI features, budget thresholds for use-case-level spend, and a process for evaluating and approving new model adoption or significant prompt changes that affect cost.

Who Should Own It

The wrong answer is: Finance alone, or IT alone, or the AI platform team as a side project.

Finance alone can't own it because the optimization levers are technical — prompt engineering, model selection, caching architecture. A finance team without engineering partnership will produce spreadsheets that nobody can act on.

IT alone can't own it for similar reasons. Traditional IT cost management is about infrastructure procurement and allocation. AI costs are driven by application-layer decisions that the infrastructure team doesn't control or fully understand.

The AI platform team can't own it as a side project because it will become invisible the moment there's a production incident or a roadmap crunch. Cost optimization competes with feature delivery for engineering time, and it will lose every time unless it has dedicated ownership and organizational standing.

The right answer is a cross-functional function with a dedicated lead. In most organizations at the stage where this matters, that looks like:

• A dedicated AI FinOps lead (an existing role expanded, or a new hire — more on this below)
• A named partner in Finance who owns the budget-side of the relationship
• A named partner on each major AI product team who owns instrumentation and optimization execution for that surface

The AI FinOps lead doesn't have to be a large team. In many organizations, one person with strong technical and analytical skills can run the function effectively, with time-boxed contributions from the product team partners. The key is that the lead has dedicated bandwidth and organizational mandate — it's not a committee that meets monthly and produces nothing.

Step-by-Step: Standing It Up Without a Reorg

Step 1: Appoint the Lead (Week 1-2)

This is the most important step and the one most organizations skip. Identify a person who will own AI FinOps as a primary responsibility. This is usually an existing ML engineer or senior platform engineer who has context on how AI workloads are built and can interface credibly with both product teams and finance. Give them a clear mandate, protected time, and a sponsor at the VP level or above.

Step 2: Audit Current Visibility (Weeks 2-4)

Before building anything, understand what you have. Map every surface in your stack that makes LLM API calls. For each one, answer: What metadata is currently being logged with each call? Can we attribute that spend to a team, product, and use case? How complete is the coverage? Most organizations discover that coverage is 20-40% at best — a significant amount of spend is flowing through paths that have no attribution at all.

Step 3: Instrument the Gaps (Weeks 4-10)

Close the attribution gaps you found in the audit. This means working with each product team to add the required metadata to their LLM calls: at minimum, team ID, product surface, use case, and model. Set this as a hard requirement for all new AI features going to production. Establish a timeline for backfilling existing features. Build the aggregation pipeline that collects this telemetry centrally.

Step 4: Establish Baseline Metrics (Weeks 8-12)

Once attribution coverage is sufficient, establish baselines: total monthly AI spend, spend by team and use case, cost per task for major task types, token volume trends. These baselines are your before state. Every optimization effort will measure against them. They're also the data you'll bring to the next budget cycle, which changes the nature of the conversation with finance entirely.

Step 5: Build the Governance Layer (Months 3-4)

Write the charter. Define the instrumentation requirements for new AI features. Create the budget framework for use-case-level spend. Establish the process for evaluating model changes. Get these documented, reviewed, and adopted — not as a bureaucratic exercise, but because without them, the function relies entirely on informal influence rather than organizational structure.

Step 6: Run the First Optimization Cycle (Months 4-6)

With baselines established and governance in place, run the first structured optimization cycle. Pick the three highest-cost use cases and run model evaluation, prompt efficiency analysis, and caching feasibility assessments on each one. Execute the ones that clear your quality bar. Report the results.

The Charter: What It Should Say

A one-page AI FinOps charter covers five things:

Tooling List

The tooling stack for an AI FinOps function has three layers:

Instrumentation Layer

This is how you capture metadata at the point of every LLM call. Options range from a lightweight internal wrapper library that your teams call instead of the provider SDK directly, to a proxy layer that sits between your applications and the LLM APIs and captures telemetry automatically. The proxy approach is higher infrastructure overhead but better at catching attribution gaps from teams that don't follow instrumentation standards.

Analytics Layer

A data warehouse or analytics database where your LLM call telemetry lands and gets aggregated. This can be your existing data warehouse if you have one. The key requirements are that you can query by team, use case, model, and time range, and that you can join call-level data to task-completion events to compute cost-per-task metrics.

Governance Layer

Budget alerting tied to your attribution data (not just raw invoice data), anomaly detection for cost-per-task drift, and dashboards that make the relevant metrics accessible to product team leads and finance partners without requiring them to write SQL. Platforms like Oberhahn are purpose-built for this layer — they handle the aggregation and governance tooling so you can focus on the optimization work rather than the data infrastructure.

What Success Looks Like at Six Months

A successfully bootstrapped AI FinOps function at the six-month mark should be able to say:

• We have attribution coverage above 90% of total AI spend.
• We can report cost-per-task for our top five use cases by volume.
• We have a model evaluation process that has been run at least once on a production workload.
• We have instrumentation requirements documented and enforced for new feature launches.
• We have a finance partner who can produce the AI spend budget line without calling the engineering team for help.

None of this requires a large team or a major reorg. It requires a clear mandate, a dedicated lead, and the organizational will to treat AI cost as an engineering concern before a finance emergency forces you to.

The Cost of Waiting

Every month you wait to build this function, you're accumulating spend without attribution, deploying features without cost baselines, and making model and architecture decisions without the data to evaluate their financial consequences. When the CFO call eventually comes, the cost isn't just the overspend — it's the disruption of the reactive scramble, the organizational trust lost, and the blunt optimization measures that a well-run function would have replaced with surgical ones.

Build it now. The setup cost is low. The ongoing cost is low. The cost of not having it is not.