Uber burned through its entire 2026 AI budget in four months. Uber is a well established company, with thousands of senior engineers, a mature ML and AI  culture, and 95% of its workforce uses AI tools every month. When I hosted a leadership session at ALIGN AI Summit in Atlanta last week, I shared that real life example. The hands that went up when I asked who had received an unexpected AI bill in the last six months told me everything I needed to know: the entire room had all lived some version of it.

The Uber CTO's public response to the budget blowout stuck with me:

"We're back to the drawing board on AI budgeting."

I keep coming back to that line because of what it implies. Uber did not lack engineering talent, tooling, or institutional knowledge. What they lacked(or did not emphasize) was financial visibility at the layer where AI spend actually happens, not the invoice, but the individual query, model call, experiment, and pipeline that produced it.

That gap between where money is spent and where it can be seen is the central problem in data and AI infrastructure today. And it is, at its core, a governance problem (which is not a technology problem and not a spending problem). The organizations I see winning on AI and Data ROI are not the ones spending less. They are the ones who know what they are spending, who owns it, and whether it is working.

The numbers are harder to ignore than most leaders admit

Global cloud data platform spend has crossed $94 billion. Enterprise AI spend is forecast to hit $150 billion in 2026. Enterprise LLM adoption is growing 17x. Against all of that, the most important statistic is the one no one leads with: somewhere between 40% and 60 % of data and AI spend is either wasted or completely untracked.

Think about what that means operationally. When the CFO asks the CIO where the AI budget went, the CIO asks engineering. Engineering pulls up dashboards that were not built to answer that question. The loop continues until month-end, at which point everyone is surprised by the same invoice they will be surprised by again next month.

The problem compounds because data and AI costs do not grow the way traditional infrastructure costs do. Server procurement scales with approvals and procurement cycles. Snowflake warehouses, Databricks clusters, and LLM API calls do not. Giving every data scientist and engineer self-serve access to elastic compute is the right call for productivity but it is likely to create an environment where a forgotten experiment or a misconfigured pipeline can cost more in a week than a team's entire monthly budget. The hockey-stick curve people keep drawing on slides to describe AI adoption? That is exactly what the cost curves look like too.

The same five problems, over and over

At Revefi, we have spent the last few years working with Global 2000 companies on data and AI FinOps. The specific tools change; Snowflake here, Databricks there, a mix of Claude, GPT, and Gemini on the AI side but the underlying cost drivers are almost always the same five, in roughly the same proportions.

Idle and over-provisioned compute

This is where the largest share of waste lives, typically around 30 percent. Warehouses get spun up at X-Large "just to be safe" and are never right-sized after the initial project wraps. Auto-suspend policies are either not set or set too conservatively. On Databricks, clusters that should shut down after a job persist for hours because no one owns the cleanup. The fix is usually straightforward once you can see the utilization data; which, again, most teams cannot.

Inefficient queries, prompts, and pipelines

In most large Snowflake and BigQuery deployments, five percent of queries are responsible for eighty percent of compute spend. A single BI dashboard scanning a full unpartitioned table every fifteen minutes can quietly cost thousands of dollars a month. With LLMs, the dynamic is worse: prompt construction directly affects cost, and most teams write prompts the way they write code comments for correctness, not efficiency. A poorly structured prompt can cost ten times more than an optimized one achieving the same output.

Ungoverned AI model usage

Nobody knows which teams are calling which models, at what frequency, at what cost. Shadow AI projects get spun up, produce interesting results, and then sit idle while the API meter keeps running. Multiple teams run near-identical fine-tuning jobs because there is no model registry to check first. At $500 to $2,000 per engineer per month for coding assistants alone; a number Uber confirmed publicly this category of waste will only grow as adoption accelerates.

Data, AI sprawl and bloat

Eight versions of the same customer table across different schemas. Raw ingestion layers that were supposed to be temporary and are now two years old. Duplicate datasets created because the team did not know the data already existed in another project. Storage costs feel manageable at small scale, but the organizations we work with that have been running cloud data platforms for five or more years have often accumulated petabytes of data that nobody has looked at in years and nobody feels empowered to delete.

With the availability of many LLMs from frontier labs and data platform vendor specific LLMs the AI tool sprawl adds another twist to the FinOps challenge.

No attribution, no accountability

Around ten percent tends to be direct waste  but it is the root cause of the other four persisting. When a cloud data invoice arrives as a single line item with no team breakdown, no one changes behavior. Engineers do not know their pipelines cost $2,000 a day to run. Finance cannot connect spend to outcomes. And because nobody owns the number, nobody optimizes it. The absence of attribution is not just a reporting gap; it is a behavioral gap.

FinOps is about spending with intent

The FinOps Foundation defines the practice as bringing financial accountability to the variable, elastic costs of cloud data platforms and AI workloads, enabling teams to make spending decisions that align cost with business value. What I want to emphasize in that definition is the word "accountability"- it is not reduction, not restriction.

The instinct in most organizations, when costs spike, is to cut access. Lock down the warehouse. Require approval for GPU clusters. Rate-limit the API. Those interventions slow down the teams creating value, and they treat the symptom rather than the cause. The organizations that do this well give engineering teams full visibility into what they are spending and then hold them accountable for the efficiency of that spending, the same way they are held accountable for reliability and performance.
‍

The operating model is organized into three phases. Inform is the foundation: cost visibility by team and workload, real-time dashboards, anomaly alerts, and some form of showback so people can see the bill before Finance does. Optimize is where you act on what you can now see: idle resource identification, query and pipeline efficiency, right-sizing compute, and AI model usage governance. Operate is the cultural layer: budget forecasting, cross-team accountability, a FinOps review cadence that runs continuously rather than appearing once a year at planning time.

The critical thing about these three phases is that they are not sequential. You do not finish Inform before starting Optimize. They run in parallel, and they run permanently. FinOps is not a project with an end date. It is an operating model.

Where to start

The most common mistake I see organizations make is trying to optimize before they can attribute. They build a prototype tool or buy a handicapped cost monitoring tool, point it at their Snowflake environment, and get recommendations they cannot act on because they do not know which team owns the warehouse in question. Optimization without attribution is guesswork.

The right starting point is always a cost attribution sprint. Two engineers, two weeks, focused entirely on tagging your top twenty workloads by spend. That single exercise (knowing which team owns which dollar) unlocks every optimization that follows. You cannot govern what you cannot see, and you cannot see what you have not labeled.

From there, the path is fairly consistent. Build team-level cost dashboards and share them widely; start with showback before chargeback. Give teams a mirror before you hold them accountable. Trust built through transparency is what makes cost optimization sustainable; chargeback before showback creates resentment. Once you have baselines, set budgets with anomaly alerting so surprises get caught in days rather than at month-end. Then work through the optimization backlog in sprint-sized pieces: right-size the top five warehouses, fix the three most expensive queries, shut down the idle experiments.

At around the 90-day mark, the shift happens from reactive cleanup to proactive governance. Cost review becomes a standing agenda item in engineering sprints. FinOps reviews happen monthly with Finance. Engineers start thinking about cost efficiency the way they think about query latency as a property of the system they are responsible for.

Beyond that foundation, the frontier is AI and agentic workloads. Legacy FinOps tools were built for infrastructure such as compute, storage, and network. They were not built to answer questions like which of my agents is generating the most token spend, whether my prompts are priced efficiently for the task at hand, or what the cost-per-outcome looks like for a given AI use case. That observability layer is what most organizations are missing today, and it is where the next wave of cost surprises is coming from.

What we built at Revefi

Revefi exists because we kept seeing the same problem across every large data organization we talked to: the tooling for cloud infrastructure FinOps existed, but nothing was built specifically for the data and AI layer. Snowflake's native cost controls give you platform-level data. Databricks does the same. But when you have three data platforms, three LLM providers, a fleet of agents, and twenty one engineering teams, you need a unified layer that spans all of it  attribution, anomaly detection, optimization recommendations, and governance in one place.

The customers who get the most out of Revefi are the ones who treat it as the strategic layer for the FinOps operating model, not as a cost-cutting tool bolted on after the fact. They start with the attribution sprint, use Revefi to automate the visibility layer, and then work through optimization and governance from a position of actual data. Most see 30 to 40 percent reductions in data spend within 90 days, not because they cut anything blindly, but because visibility alone changes behavior.

The Uber story is not an edge case. It is a preview. As AI tooling becomes table stakes across engineering organizations, the cost curves are going to keep steepening and the organizations that have built financial accountability into how they operate will be the ones that can sustain the investment. The ones that have not will keep finding out at month-end.

If any of this resonates or if you want to compare notes on what you are seeing in your own environment reach out to Revefi or find me on LinkedIn.