Where Are You, Really?

Every organization managing AI spend is somewhere on a maturity curve. A few are operating with real-time cost optimization and automated policy enforcement. Most are staring at a single line item on a cloud invoice and trying to explain it to someone who asked a reasonable question about ROI.

The language of maturity models is often vendor-infected: each stage conveniently requires more of whatever the vendor sells. This post tries to be more honest than that. The four stages described here are based on what actually distinguishes organizations that manage AI costs well from those that don't. The transitions between stages are described frankly, including the organizational obstacles that have nothing to do with technology. And the assessment of where most enterprises are is not flattering, but it's accurate.

Use this as a diagnostic, not a roadmap handed to you by someone who benefits from you reaching Stage 4 as fast as possible.

Stage 1: The Darkness

Stage 1 is characterized by one thing above all else: absence of data. Organizations at Stage 1 have deployed AI — sometimes broadly — but have no systematic visibility into where money is going. The defining symptoms:

  • All teams share one or a small number of API keys across providers
  • The monthly invoice is a single aggregate number with no attribution
  • Cost conversations happen reactively, triggered by invoice surprises, not proactively by monitoring
  • There is no designated owner of AI cost — finance doesn't have the technical context, engineering doesn't have the cost accountability
  • Development and production traffic are indistinguishable in the cost data, because there's no cost data to distinguish

Stage 1 is not the result of negligence. It's the result of moving fast and not yet treating AI cost as a first-class operational concern. Most organizations that land here did so because their AI deployment outpaced their cost management infrastructure. They deployed before they measured.

Why Organizations Get Stuck at Stage 1

The most common reason organizations stay at Stage 1 longer than they should is organizational ambiguity about ownership. Engineering says cost visibility is an infrastructure concern. Finance says it's an engineering instrumentation concern. Platform teams say they need product team buy-in to add tagging to application code. The result is that everyone agrees cost visibility matters and nobody ships the instrumentation.

The second sticking point is inertia in shared key configurations. Changing how API keys are structured requires coordination across teams, updates to CI/CD pipelines, and sometimes security reviews for new credential management approaches. The perceived effort exceeds the perceived immediate value, so the change gets deprioritized until a forcing event — a surprise invoice, a budget conversation, a security audit — makes it urgent.

Stage 2: Basic Visibility

Stage 2 organizations have crossed a critical threshold: they can see where money is going at team or application level. The defining characteristics:

  • API keys or instrumentation provide at minimum team-level attribution
  • A dashboard exists — even a basic one — that shows cost by team and by model over time
  • Development and staging traffic is separated from production, reducing the noise in production cost data
  • There is a designated owner of AI cost visibility, even if that owner doesn't have enforcement authority
  • Month-over-month cost changes can be partially explained ("Team X launched a new feature in week 3")

Stage 2 is materially better than Stage 1. It makes basic chargeback possible, allows rough optimization targeting ("the most expensive teams should be doing X"), and creates a foundation for accountability conversations. It does not yet provide the granularity needed for engineering-level optimization decisions.

The Stage 1 to Stage 2 Transition

The transition from Stage 1 to Stage 2 is primarily a technical and organizational effort, in that order. Technically, it requires instrumenting your AI call paths with team and application tagging and building or adopting a system that aggregates and visualizes that data. The technical work is not complicated, but it requires a decision about architecture (key-per-team versus instrumentation layer) and someone to execute it.

The organizational work is establishing that AI cost data matters enough to be a product managed by someone. The typical path: a platform engineering team takes ownership, builds a shared AI client library with built-in tagging, and rolls it out to application teams over one to two quarters. The rollout is the hard part — getting every team to adopt the shared library requires either mandate or strong incentive (usually the combination of visibility into their own costs and some degree of accountability for them).

Organizations that attempt Stage 2 by adopting key-per-team without the instrumentation layer often stall here permanently. They get team-level attribution but can't get finer granularity without rebuilding, and the path forward becomes a larger rewrite than if they'd built the instrumentation layer first.

Stage 3: Workflow-Level Attribution and Cost-Per-Outcome

Stage 3 organizations have moved beyond team-level cost visibility to workflow and outcome-level attribution. This is where AI cost management starts to change the product and engineering conversation, not just the finance conversation.

The defining characteristics of Stage 3:

  • Every AI call is tagged with team, application, feature, and environment — and the tagging is comprehensive, not partial
  • Related AI calls within a user workflow are grouped by trace or session, enabling workflow-level cost analysis
  • Cost-per-outcome metrics exist for primary product workflows: cost to process one document, cost per customer interaction, cost per code review generated
  • Engineering teams review their cost-per-outcome metrics as part of regular engineering work, alongside latency and error rate
  • Model selection and architecture decisions are informed by cost data, not just benchmark performance
  • Anomaly detection alerts when spend patterns deviate from expected trajectory

Stage 3 is where ROI conversations become grounded. You can now answer: is the cost of this AI feature justified by the value it generates? That question requires knowing both what it costs (cost-per-outcome) and what it produces (product-level outcome metrics). Stage 3 provides the cost side of that equation.

The Stage 2 to Stage 3 Transition

The transition from Stage 2 to Stage 3 is harder than Stage 1 to Stage 2. It requires two things that are independently difficult and must be combined: distributed tracing for AI calls (so related calls within a workflow can be grouped), and joining cost data with product outcome data (so cost-per-outcome can be calculated).

Distributed tracing for AI is not technically exotic — it hooks into the same trace infrastructure used for other service observability. But it requires discipline in trace ID propagation across service boundaries, and it requires that every team's AI calls participate in the tracing scheme. In large, decentralized engineering organizations, getting universal trace coverage is an ongoing effort, not a one-time project.

Joining cost and outcome data requires agreement on what an "outcome" is — which is a product question with organizational implications. Different stakeholders define success differently. Reaching alignment on cost-per-outcome metrics often requires more cross-functional work than the technical integration itself. This is where Stage 3 transitions stall most often: not for technical reasons but because the organization hasn't aligned on what it's trying to optimize for.

Stage 4: Real-Time Optimization and Automated Policy Enforcement

Stage 4 represents an operational maturity that very few organizations have reached. The defining characteristics:

  • Cost monitoring is real-time, not batch — anomalies are detected within minutes, not at month end
  • Policy enforcement is automated: spend caps trigger alerts or model downgrades automatically, development environments are rate-limited by policy rather than by manual configuration
  • Model routing is dynamic — traffic is routed to cheaper models when quality thresholds permit, based on real-time quality monitoring and cost targets
  • Budget allocation adjusts based on actual usage patterns, not annual headcount projections
  • Engineering teams receive cost feedback in their development workflow — cost impact of changes is visible before deployment

Stage 4 is not a destination that all organizations need to reach on the same timeline. For organizations with small AI footprints, Stage 3 is sufficient. Stage 4 becomes necessary when AI spend is large enough that the savings from real-time optimization and automated policy enforcement justify the infrastructure investment.

The Stage 3 to Stage 4 Transition

The Stage 3 to Stage 4 transition is primarily an automation problem. You have the data (from Stage 3). Now you need to act on it programmatically rather than through human review cycles. This requires building policy enforcement infrastructure — the ability to define spend rules and have them execute automatically — and integrating real-time cost signals into your existing engineering feedback loops.

The organizational challenge at this stage is different from the earlier transitions. Automated policy enforcement requires engineering teams to trust the policies — to accept that automated model downgrades or rate limiting will behave predictably and not create incidents. Building that trust requires a track record of reliable policy execution and a clear process for teams to request policy exceptions. Organizations with low trust in centralized platform decisions struggle here, because the policies feel like constraints imposed by a function that doesn't understand the specific workload.

A Diagnostic: Where Is Your Organization?

Rather than a self-assessment survey, try answering these questions directly:

  1. Can you name the three most expensive AI features in your product stack today? (If no, you're at Stage 1.)
  2. Can you break down AI spend by team without manual estimation? (If no, you're at Stage 1.)
  3. Do you have a cost-per-outcome metric for any primary product workflow? (If no, you're at Stage 2 at best.)
  4. Does spend anomaly detection alert your team before the monthly invoice? (If no, you're at Stage 2 or 3.)
  5. Does your model routing change automatically based on cost and quality signals? (If yes, you're approaching Stage 4.)

Most enterprises that have been deploying AI for one to three years are at Stage 1 or early Stage 2. This is not a failure — it reflects how fast AI deployment has outpaced management tooling. But it is a gap worth closing deliberately, because the organizations reaching Stage 3 are making better investment decisions, running more efficient operations, and building the institutional knowledge needed to maintain cost discipline as AI spend grows.

Moving Forward Without Getting Distracted

Maturity models are useful for diagnosis and directional planning. They are easy to misuse as justification for large, speculative infrastructure projects when the next increment of value is actually small and achievable.

The practical guidance: focus on the transition one stage ahead of where you are. If you're at Stage 1, your entire job is getting to basic team-level attribution. Don't design the Stage 3 workflow attribution system before you have team-level tagging in place. Each stage builds on the prior one, and skipping ahead increases the likelihood of building attribution infrastructure that doesn't reflect how your organization actually works.

Oberhahn is built around this progression — designed to get organizations to Stage 2 quickly with minimal infrastructure burden, and to provide the instrumentation and policy infrastructure needed to move through Stage 3 and beyond without custom-building every component. The progression itself is not novel. What's novel is how much organizational friction can be eliminated when the tooling is purpose-built for it rather than assembled from general-purpose observability and billing components.

Find your stage. Move one stage forward. The AI FinOps problem is solvable — but only if you stop treating it as a finance problem and start treating it as the engineering discipline it actually is.