What AI Can Do for FinOps, and the Work Teams Must Do First

FinOps teams are managing more spend than ever, often with the same headcount they had two years ago. According to the State of FinOps 2026, 98 percent of practices now manage AI spend, up from 63 percent the year before and just 31 percent the year before that. Most teams have also taken on SaaS, licensing, private cloud, and data center costs.

The pressure is about to intensify. IDC's FutureScape 2026 report predicts that the world's largest enterprises will underestimate their AI infrastructure costs by as much as 30 percent through 2027, not because they are careless, but because traditional methods of forecasting simply do not translate to AI. As IDC's Jevin Jensen puts it, "AI has moved technology spending from predictable consumption to probabilistic behavior." Translation: the bill is harder to see coming, and FinOps teams are the ones expected to catch it.

There are more expectations than ever for FinOps practitioners to mitigate waste and create new efficiencies. AI is starting to change how FinOps actually gets done by addressing the slow, repetitive work that sits between identifying a problem and acting on it. The opportunity for practitioners is huge, but so is the risk of getting it wrong. And the difference between the two comes down almost entirely to whether a team's data foundation is ready.

A quick distinction before going further: this piece examines AI for FinOps, meaning the use of AI to improve how FinOps operations run. That is separate from FinOps for AI, which is the practice of applying FinOps discipline to govern the cost of AI itself. The FinOps Foundation treats these as two sides of one coin; here, we explore how AI is reshaping the work of the FinOps practitioner.

The AI Maturity of Most FinOps Teams

The headlines suggest a world of autonomous agents hunting down waste and fixing it without human involvement, but the reality on the ground is more modest. The 2026 State of FinOps found that 49 percent rate using AI in their practice as highly important and another 32 percent as moderately important, but interest is not the same as deployment.

‍
Rajeev Laungani, Head of Product at Virtasant and a FinOps Foundation member, sees a clear gap between the leading edge and the average team. "The average enterprise is not yet running fully autonomous agentic workflows," he says. "Most are firmly rooted in the 'Inform and Explain' phase, using GenAI to write SQL queries against a data lakehouse, interpret complex enterprise bills, or act as an interactive FAQ for internal cloud policies."

For a team with a mature FinOps practice but no agentic experience, Laungani recommends a deliberate on-ramp rather than a leap. The first step is what he calls read-only context integration. The idea is to connect AI to your existing, well-organized cost data and let it study that data without giving it the ability to change anything. One useful starting point is billing data organized in a common, standardized format. A specification called FOCUS does exactly that, taking the differently labeled bills from each cloud provider and lining them up so they can be read the same way. It is catching on fast: among enterprises spending more than $100 million a year, roughly 68 percent already use or are testing FOCUS-formatted data.

"Teach the AI to understand your organizational topology before you ever give it a credential that lets software make a change."

—Rajeev Laungani, Head of Product, Virtasant

That sequence matters. The temptation is to start with a dramatic use case, the agent that finds and shuts down idle resources on its own. But the safer move is to let AI read and learn long before it acts.

An AI that understands your cost data is useful on day one and dangerous to no one. An AI with the power to change infrastructure it does not yet understand is a huge liability.

‍

What’s the Best Use Case for AI in FinOps?

"Novel discovery is still very much in progress across all AI use cases," Laungani says. But if he has to point to one approach that delivers clear value while respecting safe boundaries, it is this: policy checks through automated pull requests.

Here is how it works. Instead of giving an agent access to live cloud provider APIs to modify running infrastructure, you place the agent inside the developer workflow. Then, when an engineer proposes a change through a Terraform or CloudFormation pull request, the agent evaluates that proposed architecture against historical unit economics and organizational policy. It identifies inefficiencies, such as an oversized instance or a missing tag, and submits a companion pull request in tandem with the fix. A human still reviews and merges the inputs, so nothing happens to live infrastructure without a sign-off.

The reason this works so well, in Laungani's view, is that it meets engineers where they already are. "It delivers lightning-fast value because it operates inside the engineering team's native environment," he says. "It respects the human-in-the-loop boundary while eliminating the friction of manual code remediation."

The broader industry is moving in the same direction. Analyst group theCUBE Research reports growing demand for putting cost checks earlier in the process, before infrastructure is ever switched on, and notes that 84.5 percent of organizations already use AI for real-time issue detection in AppDev. IDC expects this to become standard practice for FinOps teams as well: by 2027, it predicts that 75 percent of organizations will combine GenAI with their FinOps processes to sharpen development pipelines and catch costs before workloads reach production. The rails for this kind of automation already exist in most companies. What is often missing is the cost information running through them. 

This is a meaningful reframe. Workflow-embedded policy enforcement is often treated as an advanced move, something a team graduates to after mastering simpler automation. But because the pull request approach keeps a human in the loop and stays out of live systems, it is one of the safer places to start. It catches cost problems at the moment of decision, before spending occurs. Ultimately, this is far cheaper than chasing the same problem after the bill arrives.

The Data Foundation Decides Everything

The single biggest predictor of whether AI helps or hurts a FinOps practice is the quality of the data underneath it. Agents act on the foundation they’re given. Point one at a clean, well-structured environment, and it accelerates good work. Point one at a messy environment, and it accelerates the issues already present.

Laungani describes the pattern of missteps he sees most often as a cautionary tale. An agent evaluates raw utilization metrics without enough context. It produces a confident recommendation that happens to be wrong, flagging a cluster as idle when that cluster is actually a top-priority backup server. It then either floods engineers with false positives or, worse, executes a change that breaks the application on its own. The engineering team’s trust in the FinOps team evaporates, and the FinOps team loses the political capital it spent years building.

The root cause, he says, is almost always a missing context layer. "Traditional tagging strategies are built for human eyes and rigid BI dashboards [a visual report to track spending or usage]. Agents require semantic metadata." A human analyst can look at a resource and apply judgment about what it does, but an agent cannot, unless that judgment has been encoded into the data itself. An AI agent needs richer labels: ones that spell out what each resource does, what other systems depend on it, and how important it is to the business.

"If your infrastructure lacks programmatic indicators of dependency maps, SLA tiers, and business criticality, the AI cannot safely reason about optimization."

—Rajeev Laungani, Head of Product, Virtasant

When teams skip this step and deploy agents on an immature foundation, the problems move beyond awkwardness and become expensive. Laungani points to three failure points that he notices repeatedly:

1. Cost cascade. Non-deterministic agents turned loose on messy, unallocated billing data get caught in recursive reasoning loops. They burn through millions of tokens trying to make sense of anomalies that are really just bad data pipelines. The result is an AI bill that exceeds the cloud waste the agent was sent to find.
2. Attribution drift. When an agent relies on faulty tagging rules, it routes remediation tickets and cost penalties to the wrong teams. The accountability culture that FinOps depends on starts to break down, replaced by internal friction.
3. Runaway automation. Unstable data streams can cause an agent to toggle resources up and down repeatedly, triggering micro-spikes in API request fees and introducing instability into the very systems it was meant to optimize.

All three trace back to the same origin: the agent was given power before it was given context.

The Practitioner's Real Job Is Changing

The FinOps Foundation frames the practitioner's evolving role as a shift from investigator to guardrail-setter, someone who defines the boundaries within which agents operate rather than chasing anomalies one at a time. Laungani agrees, and he is specific about what that shift demands.

"Moving from an investigator, chasing anomalies post-facto, to a guardrail-setter requires the FinOps team to shift from an operational unit to a policy architecture unit," he says. Instead of hunting for a $2,000 leak, he says, the team spends its time defining the deterministic boundaries within which an agent is allowed to reason and act. The skill set moves from detective work to design work.

The hard part is rarely the technology and usually organizational. Getting agents to operate safely across a large enterprise depends on settling who owns which part of the AI lifecycle, from adoption and deployment through ongoing optimization. Laungani describes "an ownership see-saw" between teams over who truly owns what, and he ties the whole transition to one variable: how willing the broader technology organization is to centralize. Teams that have not will find that no amount of tooling substitutes for a missing agreement.

This is the part that the product demos leave out. The bottleneck on agentic FinOps is often whether finance, engineering, and product can agree on a shared taxonomy and a clear chain of ownership before the first agent is switched on.

It is also why so many teams still cannot answer the most foundational question about their AI spending. As one practitioner put it bluntly in the State of FinOps 2026 report, "Is your AI providing value? No one can answer that question yet." Strong data foundations and clear ownership are what finally make that question answerable.

What to Do Next

Return to the tripping hazard this article opened with: a team responsible for more spend each year, working through a long tail of small opportunities that each cost more effort than they save. AI offers a way out of that trap, but only for teams whose data is ready to support it.

The path Laungani lays out is sequential. Start with read-only context integration and let AI learn your environment. Add a context layer: the AI needs extra labels on each resource that explain what it actually does, what other systems depend on it, and how important it is to the business. Pick a safe, high-value entry point like pull request policy checks, where a human stays in the loop and live systems stay untouched. And settle the ownership question before, not after, you grant an agent the power to act.

The teams building this foundation now are setting the cost baselines and governance patterns that will define what a mature FinOps practice looks like for years to come.