Someone handed you the AI spend problem. Maybe it came as a question from finance after a surprising invoice. Maybe it came from the CISO after a compliance review. Maybe it came from your own CTO who looked at the engineering budget and noticed that AI API costs had become a material line item with no clear owner.
Whatever the trigger, you now have a problem that didn't have a clear operational home six months ago and still doesn't have a clear playbook today. This post is that playbook — written for the Head of AI Platform, Director of AI, or engineering leader who has been handed the problem and needs to know where to start.
Why AI FinOps Is Different From Cloud FinOps
Before getting into the operational structure, it's worth being precise about what makes AI spend management different from the cloud cost management practice that most engineering organizations already have or are adjacent to.
Cloud FinOps works because the cost units — compute hours, storage GB, data transfer — are well-defined, the attribution mechanisms (resource tagging) are mature, and the optimization levers (right-sizing, reserved capacity, scheduling) are well-understood. The Cloud FinOps Foundation has published frameworks. Dozens of tools exist. The practice is established.
AI FinOps has none of that maturity yet. The cost unit (the token) is unfamiliar to finance and only partially controllable by engineering. Attribution requires instrumentation at the application level, not just tagging at the infrastructure level. The optimization levers — model selection, prompt compression, caching, batching — are engineering decisions with cost implications, not infrastructure decisions with cost implications. The practice is being invented in real time.
This matters because borrowing the cloud FinOps framework wholesale will leave you with gaps. You need something built for the specific characteristics of AI spend.
The Three-Role Model: Who Owns What
Effective AI FinOps requires clear ownership across three functional areas. In most organizations, these won't be dedicated roles — they'll be responsibilities added to existing ones. Clarity matters more than headcount.
Engineering: Instrumentation and Attribution
Engineering owns the data layer. Specifically, engineering is responsible for ensuring that every AI API call is tagged with enough metadata to trace it to its origin: which application, which team, which feature, which use case. Without this, all other FinOps work is forensic archaeology rather than operational management.
Concretely, this means:
- Issuing API keys at an appropriate level of granularity (per application or per team, not one key for everything)
- Tagging API calls with application, team, and environment identifiers
- Collecting token counts and model names at the call level and routing them to a cost monitoring system
- Building cost projections into the launch gate for any new AI-backed feature
- Instrumenting for anomaly detection, not just reporting
This is not a finance responsibility. Finance cannot instrument your applications. Attribution is an engineering deliverable.
Finance: Budgets and Forecasting
Finance owns the planning layer. Their responsibilities in an AI FinOps framework include setting and maintaining AI spend budgets at the team or product level, building forecasting models that account for AI's consumption-based pricing, chargeback or showback to business units, and the variance analysis when actuals deviate from forecast.
The gap finance usually has is that they're trying to forecast consumption-based AI spend using the same models they use for headcount or SaaS subscriptions. Those models don't work. AI spend scales with product usage in ways that are nonlinear and hard to predict without engineering input on expected volume, average prompt length, and model selection.
The handoff between engineering and finance is the cost projection: engineering produces a per-request cost estimate and a volume forecast, finance translates that into a budget. That handoff needs to happen at feature launch and re-occur quarterly at minimum.
Platform: Tooling and Policy
The platform team — or the AI platform function, if you have one — owns the infrastructure and governance layer. This includes deploying and maintaining the tooling that makes cost visibility possible, defining and enforcing key management policies, building and operating the approved tool registry, and creating the processes that enable fast governance without bureaucratic drag.
Platform is also the team that identifies and implements cost optimization opportunities: model routing, caching strategies, batching, prompt optimization. These are technical levers that finance can't operate and that individual engineering teams often lack the time or visibility to pursue. Platform can look across all AI usage and find optimization patterns that are invisible at the team level.
The Meetings That Have to Happen
AI FinOps is a cross-functional practice, which means it requires coordination infrastructure. Three recurring meetings are the minimum viable operating cadence.
Weekly: Engineering Cost Review
A short operational review — 30 minutes is sufficient — covering spend for the previous week versus forecast, any anomalies or unexpected spikes, and new features or experiments that are going to affect next week's numbers. Attendees: AI platform lead, engineering leads for teams with significant AI spend. Output: any anomalies escalated or explained, forecast for the coming week.
Monthly: Cross-Functional Budget Review
The monthly review brings in finance. Agenda: actuals versus budget for the month, attribution by team and product, forecast for the next 90 days, and any budget adjustments that need to be made. This is also where new features in the pipeline get cost-reviewed before they launch. Attendees: AI platform lead, finance partner, engineering leadership, product leadership if AI features are product-facing.
Quarterly: Strategic Review
The quarterly review is the right forum for strategic questions: Is our model selection still optimal? Are there architecture changes that would materially reduce cost? Are we getting value relative to spend — is the ROI on AI investment holding up? Are there vendor relationship conversations to have? This meeting should produce decisions, not just information exchange.
What Tooling Exists Today
The AI FinOps tooling landscape is young but not empty. Here's an honest assessment of what's available:
Provider Dashboards
Every major AI API provider — OpenAI, Anthropic, Google, Amazon — has a billing dashboard. These are adequate for basic visibility into a single provider account but do not aggregate across providers, do not provide real-time alerting, and do not offer attribution below the account level unless you've built that yourself.
Use them as a cross-check, not as your primary cost visibility tool.
Cloud Cost Management Tools
AWS Cost Explorer, Google Cloud Billing, Azure Cost Management can give you visibility into cloud-hosted AI services (Bedrock, Vertex, Azure OpenAI). They're stronger for infrastructure-level attribution but have the same gap as provider dashboards when it comes to application-level attribution — you'll know the total for a service, not which features or teams drove it.
Purpose-Built AI Cost Management Platforms
This is the category that addresses the cross-provider aggregation and application-level attribution gap. Platforms like Oberhahn are designed specifically to centralize AI spend data across providers, enforce attribution at the key level, surface anomalies in near-real-time, and give both engineering and finance the view they need without requiring custom instrumentation work for each provider integration.
The tradeoff is implementation effort versus capability. A purpose-built platform requires an initial instrumentation investment but replaces a significant amount of custom tooling that you'd otherwise have to build and maintain yourself.
What You Have to Build Yourself
Regardless of what tooling you adopt, there are things you'll need to build or configure internally:
- Application-level attribution (tagging every API call with the right metadata)
- Key management policies and issuance workflows
- Launch gate cost review processes
- Chargeback or showback reporting aligned to your internal budget structure
- Anomaly alert thresholds calibrated to your actual usage patterns
No vendor solves all of this out of the box. Your instrumentation layer is always going to be custom to your applications.
The First 90 Days: What to Prioritize
If you're starting from zero, here is a sequenced 90-day plan that builds toward a functioning AI FinOps capability without trying to do everything at once.
| Phase | Focus | Deliverable |
|---|---|---|
| Days 1-30 | Inventory and baseline | Complete list of AI tools in use, spend by provider, current key structure |
| Days 31-60 | Attribution and monitoring | Per-application keys, tagging instrumentation deployed, alerting configured |
| Days 61-90 | Process and governance | Launch gate cost review process, monthly cross-functional review established, budget owners assigned |
The sequence matters. You cannot build useful budgets without baseline data. You cannot do useful attribution without the key structure in place. Governance processes built on top of bad data produce false confidence, not actual control.
The Metric That Matters
When you've built a functioning AI FinOps practice, there is one metric that tells you whether it's working: cost per unit of value delivered. Not total spend, not spend per model, but cost per API call per user, cost per document processed, cost per customer interaction handled — whatever the value unit is for your specific AI applications.
Total spend will grow as you scale. That's not a problem if value is growing proportionally. Cost per unit of value is the metric that distinguishes efficient scaling from expensive inefficiency. Building toward that metric from day one — even if you can't measure it precisely yet — will orient your AI FinOps practice toward what actually matters.
The organizations that get AI cost management right are the ones that treat it as an operational capability, not a finance exercise. Engineering owns the data. Finance owns the planning. Platform owns the infrastructure. Everyone is accountable to the value metric. That structure is not complicated, but it requires deliberate design — it won't emerge on its own from a collection of well-intentioned teams.