Skip to main content

All Insights

FinOps in the AI Era: Why Your Cloud Cost Playbook Breaks on Consumption Pricing (And What Replaces It)

Rachel Ji, Director of Machine Learning, maps where a cloud-era FinOps playbook breaks on AI spend, the guardrails that replace it, and how to govern an Amazon Bedrock agent end to end.

Author

Rachel Ji

Director of Machine Learning at UTurn Data Solutions

Highlights

• Understand why the CIO and the CFO see two different problems in the same AI bill

• See which of the six cloud FinOps practices break on inference spend, and which only bend

• Learn the one rule to agree with your CFO before adoption makes the conversation harder

• Explore the new playbook: guardrails built into the platform instead of tickets and approvals

• Get a five-step pattern for governing an Amazon Bedrock agent, with a worked invoice-processing example

Share To

October 20, 2026

Uber spent its entire 2026 AI budget in four months, then capped AI coding tools at $1,500 per person per month. That is what happens when consumption pricing meets demand nobody can forecast, and it is coming for every company moving GenAI and agents into production. The FinOps playbook that got your cloud bill under control was built for capacity: tags, rightsizing, commitments sized from stable baselines. Four of its six practices break outright on AI spend, and the other two bend. In this post I walk through where each one fails, the target state to agree with your CFO (every AI dollar explainable to finance and controllable by engineering), and the exact pattern we use to govern an Amazon Bedrock agent end to end, down to the token budget and the fallback. If you own an AI budget or the platform it runs on, this is the conversation to have before month four.

Uber used up its entire 2026 AI budget in four months. The fix was a cap of $1,500 per person per month on AI coding tools, and the COO's explanation was the honest one: it is very hard to draw a line between usage and business outcomes.

That is not an Uber problem. It is what happens when consumption pricing collides with unpredictable demand, and every company putting GenAI and agents into production is about to meet it. I recently walked a room of CIOs and CISOs through this at the Quartz Network VISIONS CISO Leadership Summit in Atlanta. This is the version for everyone who was not in the room.

The short version: the FinOps playbook that got your cloud bill under control was built for capacity. AI spend needs one built for consumption and outcomes. Here is what breaks, what replaces it, and what it looks like wired into an Amazon Bedrock agent.

The CIO and the CFO Are Looking at the Same Bill and Seeing Different Problems

Ask a CIO about AI cost and you hear some version of "AI spend is growing faster than my ability to govern it." Gartner has warned that GenAI cost estimates can be off by 500 to 1,000 percent, and that at least half of GenAI projects will overrun their budgets by 2028. The reasons are structural:

  • Cost is decided at runtime. Inference is 70 percent or more of a model's lifetime cost, and one agent task can trigger many model calls.
  • The pilot-to-production shock. A pilot that works gets adopted, and adoption is what drives the bill.
  • Much of the spend is not visible. Only 31 percent of organizations have accurate visibility into AI software. A lot of it arrives as SaaS copilots and expensed tools.
  • Success becomes the cost problem. Token prices keep falling, but usage grows faster.

Ask the CFO and the complaint is different: "I can't trust the forecast, and I can't prove the return." In the Benchmarkit and Mavvrik survey reported by CIO.com, 85 percent of companies underestimated AI costs by more than 10 percent, and nearly one in four missed their forecast by 50 percent or more. More than 80 percent say AI costs have cut gross margin by more than six points. Only 51 percent can confidently evaluate AI ROI. And even quick-win use cases take nine to ten months to show value, which makes "where do we invest and when do we cut" a question nobody can answer with the data they have today.

Same money, two languages. Engineering counts instances, gigabytes, API calls, and tokens, organized by accounts, clusters, and tags, in real time. Finance counts dollars, GL accounts, and cost centers, organized by business units, products, and P&Ls, on a monthly close. "Good" means fast and efficient on one side, predictable and profitable on the other. FinOps exists to translate between them, and AI is where the translation currently fails.

Why Your Current FinOps Playbook Breaks

Most FinOps programs were built on six practices. Each one assumes something about cloud spend that stops being true once the spend is inference.

  • Visibility: breaks. Tags and accounts map every resource to an owner. AI spend pools in shared model endpoints used by many apps and agents, so the tag tells you which endpoint, not which product.
  • Accountability: breaks. Teams own budgets for what they provision. With AI, end users and autonomous agents drive the cost, not the team that built the app.
  • Optimization: strained. Rightsizing and shutting down idle resources assume something is idle. Nothing sits idle in an inference bill. Waste hides in prompts, retries, agent loops, and model choice.
  • Commitments: breaks. Commitments are sized from stable, predictable baselines. AI usage is volatile, and model prices and options change every few months.
  • Forecasting: breaks. Trend lines plus planned projects cannot see a pilot that takes off and multiplies spend in weeks. Demand follows behavior, not the roadmap.
  • Unit economics: strained. Cost per customer or per transaction worked because the unit was obvious. With AI, what is the unit: a token, a prompt, an agent task, or a business outcome?

Four of the six break outright. The other two bend. That is not a tooling gap you patch with another dashboard. It is a different operating model.

What Good FinOps Looks Like in the AI Era

The target state fits in one sentence: every AI dollar is explainable to finance and controllable by engineering. In practice that means two flows running in opposite directions.

Engineering to finance, making spend understandable:

  • Attribute. Every request maps to a cost by product and business unit.
  • Forecast. Adoption signals turn into low, expected, and breakout scenarios instead of a single annual number.
  • Explain. Spend spikes come with a variance the CFO can explain, not a surprise at close.
  • Value. Tokens and compute roll up to a cost per outcome.

Finance to engineering, making targets actionable:

  • Guard. Budgets become quotas and alerts per team or per agent.
  • Target. Margin goals become cost-per-request targets engineers can design to.
  • Buy smart. Commitments become model and purchasing guidance.
  • Decide. Value checkpoints decide whether each pilot scales, gets fixed, or stops.

There is one rule worth agreeing with your CFO before any of this: if AI spend goes up but cost per outcome goes down, that is a win. Without that agreement, every successful adoption curve looks like a budget failure.

The New Playbook: Guardrails, Not Gates

Here is how each of the six practices changes. The theme across all of them is the same: controls built into the platform, not tickets and approvals. Gates slow teams down and get routed around. Guardrails let teams move and still keep the bill explainable.

  • Visibility: from tagging the resource to attributing every request. Route AI calls through a gateway or per-application inference profiles. Pull SaaS copilots and third-party APIs into the same view so the shadow spend stops being shadow.
  • Accountability: from team budgets to quotas by environment. Sandboxes get loose limits and alerts so teams can experiment. Production gets an alert at 80 percent of budget, a fallback to cheaper models, and an escalation path.
  • Optimization: from killing idle resources to the right model with the right context. Set a cost-per-request target and hit it with the smallest model that does the job. Cache, batch, trim context, and cap agent loops and retries.
  • Forecasting: from an annual budget to rolling scenarios. Plan for low, expected, and breakout adoption. Re-forecast and explain variance monthly, together with finance, not in separate meetings.
  • Unit economics: from cost per transaction to cost per outcome. Cost per resolved ticket. Cost per processed invoice. Then set a value checkpoint: pilots that cannot show one, stop.

Commitments get easier once the first five are in place, because you finally have a baseline that reflects behavior rather than a guess, and you can buy against the stable floor instead of the volatile peak.

Example In Practice: Governing an Amazon Bedrock Agent End to End

The playbook above is abstract until it is wired into a platform. Here is what it looks like for a single agent on Amazon Bedrock, using services most AWS customers already have. Think of it as two loops: a control loop (CloudWatch metrics, invocation logs, traces) that you use to steer and enforce, and a billing loop (Cost Explorer, Cost and Usage Report 2.0, AWS Budgets) that you use for chargeback and for the CFO.

  • Attribute: give every agent a cost identity. One application inference profile per agent, tagged by team and cost center. One IAM role per agent, because Bedrock cost is now allocated by IAM principal in CUR 2.0. Record per-request metadata (user, feature) in the invocation logs.
  • Observe: count tokens in near real time. CloudWatch token and invocation metrics per model and per agent alias. Invocation logs with tokens per request, queryable by user or feature. AgentCore Observability for traces per session and step, which is how you catch loops before they become a runaway bill.
  • Budget: set limits against those counts. A daily token budget per agent expressed as a CloudWatch alarm (tokens times price equals dollars). AWS Budgets and Cost Anomaly Detection by tag or IAM principal. Service quotas on tokens and requests per minute as the hard ceiling.
  • Enforce: act automatically. At 80 percent of budget, the alarm notifies the agent's owner. At 100 percent, a Lambda function switches the agent to a smaller model or the Flex tier. As a backstop, a Budgets action attaches a deny policy to the agent's role.
  • Optimize: lower the cost per outcome. Flex tier or batch inference for non-urgent work, Priority tier only where a customer is waiting. Prompt caching for repeated context and smaller models for simple steps. Then join the logs to business events so you can report cost per invoice or cost per ticket.

Here is an illustrative example to make this concrete. An invoice-processing agent gets its own IAM role tagged to the Finance business unit. Its budget is 40 million tokens per day with an alert at 80 percent. At 100 percent it routes to a smaller model on Flex. The backstop denies at 120 percent of the monthly budget. The KPI the CFO sees every week is not tokens anymore. Instead, it is cost per invoice processed.

Where to Start

If you are already running GenAI in production, start with attribution. Until every request has a cost identity, nothing downstream (budgets, forecasts, unit economics) has a reliable number to work with. If you are still in pilots, agree on the cost-per-outcome rule with your CFO now before adoption makes the conversation harder.

UTurn's Cost Optimization Audit was built for exactly this gap: it maps your current AI and cloud spend to owners and outcomes, identifies where the practices above are breaking, and leaves you with the guardrails designed for your platform rather than a slide about them. If your AI spend is growing faster than your ability to explain it, that is the place to begin.

References

Additional Insights