The Governance Gap That's Costing You Right Now
Walk into most enterprises with significant AI spend and ask a simple question: who owns AI financial governance? You'll get one of three answers. The first is a long pause followed by "engineering, mostly." The second is a longer pause followed by "finance, I think, but they're not really involved in the tooling decisions." The third — the rarest and most honest — is "nobody, really. It's in between."
That gap — between engineering's operational ownership of AI systems and finance's nominal ownership of the budget — is where most enterprise AI overspend lives. It's also where compliance risk accumulates, where cost accountability goes undefined, and where the organizational capacity to make rational AI investment decisions fails to develop.
This isn't a new problem. Technology spending has always created jurisdictional ambiguity between the people who operate systems and the people who pay for them. Cloud computing had this problem acutely in the early 2010s. The response was FinOps — a dedicated function and practice that bridges engineering and finance on cloud cost management. SaaS proliferation created a parallel need that procurement functions eventually grew to address.
AI requires the same solution. The function doesn't exist yet in most organizations. This post makes the case for building it and gives you a practical starting point.
Why AI Is Different From Cloud and SaaS
Some organizations assume that existing FinOps or procurement functions can absorb AI governance as a natural extension of their scope. This is sometimes true in early stages but breaks down as AI spend matures. The differences that matter:
AI Costs Are Outcome-Coupled
Cloud costs scale with infrastructure utilization — compute, storage, network. That utilization can be optimized somewhat independently of what the infrastructure is producing. You can right-size a server without knowing much about the application running on it.
AI costs scale with workflow execution. Every dollar of AI spend is the direct result of a business process consuming model capacity. Understanding whether that spend is appropriate requires understanding the business process — what it costs to execute manually, what quality the AI output needs to achieve, what the cost per workflow should be. That requires domain knowledge that traditional FinOps functions don't carry.
The Vendor Landscape Is Radically Different
SaaS procurement involves negotiating contracts with software vendors on a defined pricing model. There are established playbooks. AI spend involves a combination of API-billed model costs (often with dynamic pricing that varies by model and version), cloud infrastructure costs for hosting and orchestration, and internal labor costs for development and maintenance. The procurement motion is different, the evaluation criteria are different, and the negotiation leverage points are different.
The Build vs. Buy Decision Is Continuous
Most SaaS categories have a settled build-vs-buy landscape. For AI, nearly every capability involves an ongoing decision: do we use a commercial model API, fine-tune an open-source model, or build something custom? This decision recurs at different cost-benefit equilibria as model capabilities evolve and pricing changes. Governing it requires technical literacy that sits outside traditional procurement or FinOps scope.
What AI Financial Governance Owns
The function needs a clear mandate. Based on what mature AI programs have learned — usually through hard experience — the core ownership areas are:
| Domain | What It Includes | Who It Touches |
|---|---|---|
| Budget framework | Annual AI budget structure, team allocations, contingency reserves | Finance, Engineering leadership |
| Spend policy | Approved models, cost per workflow thresholds, escalation rules | Engineering teams, platform owners |
| Vendor management | Model provider contracts, pricing benchmarks, relationship ownership | Procurement, Engineering |
| Measurement and reporting | ROI tracking, cost per workflow metrics, board-level reporting | Finance, Executive team |
| Controls and enforcement | Budget enforcement tooling, anomaly response, access governance | Platform engineering, Security |
| Portfolio review | Quarterly review of AI deployments by value vs. cost | Business unit leaders, Finance |
This is deliberately broader than a pure finance function. AI financial governance is an integrating function — it connects financial accountability to engineering operations to business outcomes. No existing function owns all of this, which is precisely why the gap exists.
Who Should Lead It
The most common mistake in standing up this function is placing it fully in finance or fully in engineering. Neither has the full skill set. The strongest leaders for AI financial governance typically combine:
- Fluency in financial modeling — not accounting, but the ability to build and defend ROI models, manage budget cycles, and communicate in the language of finance
- Technical credibility — enough depth to understand model costs, architecture tradeoffs, and the difference between a well-designed and poorly-designed AI integration
- Organizational reach — the ability to operate across functional lines and hold accountability for outcomes they don't directly control
This profile most commonly exists in engineering leaders who have spent time in business-facing roles, or in technically-literate finance leaders who have worked closely with product or platform teams. It does not typically exist in pure finance analysts or pure infrastructure engineers.
For organizations that don't have this profile available internally, the near-term pragmatic approach is a joint leadership model: a technical co-lead from engineering and a financial co-lead from finance, with a shared mandate and clear decision rights. This creates friction, but it's better than leaving either function fully in charge of something they're only partially equipped to manage.
How to Stand It Up Without a Reorg
The instinct when creating a new function is to create a new team. For AI financial governance, this is usually the wrong starting point — there aren't enough organizations with mature AI programs to draw experienced talent from, and creating a new team signals a larger organizational commitment than most companies are ready to make in year one.
The more durable path is to build the function as a center of excellence or working group model first, with formal team structure following once the mandate is demonstrated:
- Name a lead. Someone needs to be accountable. This can be an existing engineering director, a technically-oriented finance manager, or a Chief of Staff with the right profile. The title matters less than the authority and the mandate. Without a named owner, the function doesn't exist, regardless of what's on the org chart.
- Define the first 90-day deliverables. The function earns credibility by producing tangible outputs, not by defining its scope. A useful 90-day set: a complete inventory of AI spend with attribution to teams and workflows; a draft spend policy that specifies approved models and cost thresholds; a monthly reporting cadence for executive visibility.
- Establish the tooling foundation. The function cannot operate without data. Instrument spend attribution, set up the reporting infrastructure, and establish the policy enforcement mechanism. This is where the technical investment is required — visibility and control infrastructure that makes the governance function operational rather than advisory.
- Run the first portfolio review. Within the first quarter, conduct a formal review of existing AI deployments against the cost and outcome data now available. This review will almost certainly surface deployments that should be discontinued, optimized, or expanded. Acting on those recommendations demonstrates that the function has teeth.
- Build the budget framework for the next cycle. The function's most important annual deliverable is an AI budget that has been structured, justified, and allocated in a way that finance and engineering both own. This replaces the ad-hoc, team-by-team budget requests that characterized the previous cycle.
The Politics of Creating This Function
Standing up any new governance function creates friction. Engineering teams often experience it as new overhead on decisions they previously made freely. Finance teams sometimes resist the encroachment on budget authority. Business unit leaders may worry about losing control over AI investments in their domain.
The framing that tends to work: this function exists to protect AI investment, not to restrict it. Engineering teams that demonstrate disciplined cost management and clear ROI get more budget, not less. Business units that track outcomes rigorously make a stronger case for expanded investment. Finance leaders who have a credible governance function to point to can justify larger AI budget allocations to boards and audit committees.
The alternative — continuing without governance — is increasingly untenable as AI spend scales. Organizations that are spending $500K per year on AI without governance can absorb the inefficiency. Organizations spending $5M cannot, and organizations heading toward $20M absolutely cannot. The question is not whether to build this function but when. The cost of building it early is organizational friction. The cost of building it late is years of preventable overspend and the credibility damage that comes from being unable to account for significant technology investment.
What the Mature State Looks Like
Two to three years into a well-functioning AI financial governance capability, the indicators of maturity include: AI spend that is allocated to business outcomes rather than cost centers, with clear visibility into cost per workflow across all major deployments. A vendor management process that benchmarks AI pricing and renegotiates contracts based on volume and alternatives. A quarterly portfolio review that retires underperforming AI investments and reallocates budget to high-value ones. A budget process that starts with outcome projections rather than cost projections — "we need $X in AI spend to deliver Y volume of workflow completions" rather than "we need $X because we spent $X-1 last year."
Reaching this state requires the tooling foundation — platforms that provide workflow-level cost attribution, policy enforcement, and management reporting, the kind of capability that platforms like Oberhahn are built to provide — and the organizational structure to act on what the data shows.
Neither the tooling nor the structure alone is sufficient. The tooling without organizational ownership produces a dashboard nobody acts on. The organizational structure without tooling produces a governance function that is making decisions based on incomplete information. The combination is what makes the function work — and it's what most enterprises have yet to build.
Cloud computing forced the FinOps function into existence. AI will do the same thing, and on a shorter timeline than most organizations expect. The leaders who build this capability proactively rather than reactively will have a meaningful structural advantage: the ability to scale AI investment confidently because they know what it's worth and what it costs to deliver.