Leadership wants to scale AI. Budgets are tripling. Adoption is up.

Then the CFO asks the question every board now asks: which of these initiatives is actually profitable?

Most organizations cannot answer that question, not because they lack visibility into cost, but because the cost data they have was never designed to produce that answer.

Applying lessons learned from managing cloud spend won’t be a fix for the AI and ROI quandary. True, cloud taught a generation of CFOs that billing without business context is noise. So to get cloud ROI, they stitched two data sources together: cost data plus business data. AWS reveals which account, which region, which tag, which resource. Merge in customer and product mappings on top and the ROI of the cloud spend comes into focus.

But AI is harder. It requires three data sources: cost, business, and telemetry—the automatic collection of data from disparate sources that helps to clarify the whole picture of what happened and why. An executive or engineering lead can have AI invoices and customer revenue. But they have no way to connect them to business value. The token count on the OpenAI invoice does not specify which customer triggered which call, which feature it served, or whether the prompt produced a business outcome. That data does not exist in the provider’s billing.

AI providers won’t fix this problem

The situation is not likely to change anytime soon because AI providers are not in the business of attributing an enterprise’s costs to that enterprise’s customers. Instead, AI providers are in the business of selling tokens. The granularity they expose is the granularity their billing systems require, not the granularity a CFO requires.

Not convinced? Compare what AWS gives you to what an AI provider gives you.

AWS billing exposes resource IDs, account hierarchies, region, SKU, tag metadata, usage by the minute. Every dollar can be attributed to a workload, a team, a customer segment if it was tagged correctly. The data is rich enough that mature FinOps teams built unit economics on top of it years ago.

An AI provider invoice gives you tokens consumed by model, with optional grouping by API key. That is the resolution. No request-level attribution. No customer ID. No feature mapping. No prompt outcome. No retry identification. Multi-step agent workflows collapse into a token count. Imagine a large bank receives a multi-million dollar AI invoice each month. But it has no visibility into what parts of the business were responsible for what parts of the cost so cannot allocate them.

If an enterprise wants to know what AI cost drove which customer or feature, it has to capture that data itself, inside an application, before the call leaves it. 

Three required sources

Building AI ROI measurement requires three data sources, stitched together in a single model.

1. Cost data, normalized across providers. Every AI provider delivers cost differently. OpenAI invoices in one taxonomy, Anthropic in another, fine-tuning vendors and inference platforms each in their own. Cloud GPU costs sit in AWS or Azure billing. Vector database costs land in Pinecone or Snowflake invoices. None interoperate by default. Normalization is necessary but not sufficient. It will put all your AI costs in one schema. It does not tell you what they produced.
2. Application-layer telemetry. This is the source most organizations are missing, and the one that makes AI ROI structurally different from cloud ROI. It requires instrumenting AI calls inside your application across six categories: request-level tracing tied to a customer or session ID; feature attribution tied to the product surface that triggered the call; agent-step capture for multi-step workflows; retry and fallback identification so recovery costs don’t get attributed to primary calls; model selection logging that records which model was chosen and why; and outcome capture that ties each call to whether it produced business value. None of this data exists in the provider’s billing. All of it has to be captured at the moment the call is made and stored in a system that can be stitched to the cost data.
3. Business data. Revenue, customer segments, product hierarchies, and feature usage. The same business data already feeding your CRM and analytics stack, mapped to the customers and features the telemetry layer attributes calls to.

Stitched together, the three sources produce the unit economics every AI investment decision now requires: cost per customer interaction, margin per feature, profitability per agent workflow, ROI per model choice. None of these can be calculated from billing data alone. None can be calculated from telemetry alone. They require all three sources, modeled together in a way that maps cost to outcome.

Why agentic AI makes this urgent

Single-call inference is the easy case. One request, one cost, one customer, one outcome.

Agentic workflows are different. An agent decomposes a task into multiple steps. Each step calls a model. Some steps fall back to a different model when the first fails. Some steps retry on a poor result. Some steps invoke external tools that themselves cost money. A single user request can produce dozens of inference calls across multiple providers, with the cost compounding in ways the provider invoice cannot disaggregate.

If telemetry does not capture agent-step granularity, no one will know which steps are profitable. Aggregate costs will show up three weeks later in the invoice. By then, the workflow has been running at scale, customers are onboarded, and unprofitable paths have been retried thousands of times.

When agents make the calls, the volume of cost-generating events without business context attached grows by an order of magnitude. The window for instrumenting this before it becomes unmanageable is closing.

What changes when the three sources come together

Once the three sources are stitched together, the AI investment conversation changes.

Five different ways to build the same AI capability stop looking equivalent. They converge on adoption metrics and diverge by 10x on cost. The team picks the approach that delivers a similar business outcome at one-fifth the cost, because the team can finally see the difference. Product teams design features with margin awareness from the architecture phase, not from the post-launch budget review. Engineering teams choose model architectures with cost-per-outcome data alongside latency and quality. Leadership evaluates AI initiatives the way they evaluate any other capital allocation: on unit economics, not on the engagement chart. Aggregated invoices track the cost per customer interaction. Engagement metrics reveal margin per feature. Gut-instinct model selection is checked against real cost-per-outcome model selection results. 

Within seconds, everyone can see which AI features are profitable, which should scale, and which should be killed. This is the insight everyone is looking for and companies that achieve it will optimize the benefits of AI.

The build trap

AI costs are compounding now. The board is not waiting 18 months for an internal project to reach production.

The temptation to build it anyway has never been sharper. AI coding tools have changed what a small engineering team can ship in a quarter. The instrumentation layer looks tractable. The cost normalization looks like a weekend project. The semantic model feels like something a senior engineer could draft over a sprint.

It is a trap. Three reasons.

Volume is the first. A production AI footprint generates millions of telemetry events per hour, and that volume scales with agentic adoption. Real-time ingestion, correlation, and attribution at that scale is not the same problem as vibe coding a prototype in an afternoon. It is a permanent operational system that has to be right every minute of every day.

The vendor landscape is the second. Cost data arrives in delayed billing windows from providers with non-interoperable schemas. Schemas change without notice. New AI providers enter the landscape monthly, each with its own taxonomy and metering. The system is not built once. It is maintained against a moving target that moves faster than most internal release cycles.

The third is what the first two add up to: this is business-critical infrastructure. The CFO and the board are going to make capital allocation decisions on the data this system produces. When schema drift goes unnoticed for two weeks, when an agent telemetry stream stops correlating to a vendor that quietly changed its billing API, the cost of being wrong is not a sprint of cleanup. It is a quarter of misallocated capital.

The build-vs.-buy question for engineering leaders has changed. It’s not “can we build this?” The honest answer is yes. The real question is whether the marginal hour of your strongest engineers is best spent stitching cost data to telemetry to business outcomes, or building the AI products that produce the revenue the cost data is measuring.

The capability is reproducible in weeks. The choice is whether to spend the next 18 months building it, or the next 18 months acting on it.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

In the client-server era, the penalty for inefficient programming, such as unoptimized database calls, was largely confined to application responsiveness. Today, in the AI era, code, architectural, and platform inefficiencies are no longer just a performance issue, they’re a financial and environmental liability. Left unchecked, poor code cascades into soaring token costs and spikes data center power consumption, directly undermining both cloud budgets and corporate sustainability goals.

AI’s impact on sustainability

By 2029, IDC projects that the number of actively deployed AI agents will exceed 1 billion worldwide, which is 40 times more than in 2025. And these agents will perform 217 billion actions per day.

To deliver on this demand, AI data centers are being built out at an unprecedented rate, with Gartner forecasting that global spending on data centers over the next three years will increase 31.7% to surpass $650 billion, driven primarily by hyperscaler cloud providers building out AI foundations, and optimizing servers for heavy AI workloads.

All this presents a significant strain on the energy grid as well as environmental sustainability, including:

• The power double-down: The International Energy Agency (IEA) projects that global data center electricity consumption will more than double from about 415 to 945 TWh by 2030, primarily fueled by energy-intensive accelerated computing for AI.
• The inference premium: AI workloads are vastly more demanding than standard web activities. A gen AI query consumes roughly 10 times the electricity of a conventional keyword search, or roughly 2.9 watt-hours as opposed to 0.3 watt-hours.
• Water consumption: Cooling these dense clusters is highly resource intensive. Global AI-related water demand is expected to reach 4.2 to 6.6 billion cubic meters by 2027.

The good news, however, is it’s not all out of the control of end user organizations and CIOs. Just as in the client-server era, through careful planning and execution, CIOs have the potential to significantly improve the performance, costs, and sustainability impacts of their AI application portfolio.

Here are four recommendations to maximize value as you look across your AI applications and infrastructure estate.

Revisit business objectives in light of AI

AI applications and platforms bring several new headaches for CIOs and CFOs in terms of FinOps. The variable nature of AI vendor billing due to variable monthly token costs is just one well-known example. To avoid unpleasant surprises, be sure to carefully review vendor contracts to decipher pricing models. Look for what’s included in seat-based license fees and what’s added as variable charges for agentic AI usage.

In addition, explore new metrics and KPIs such as intelligence per watt to help make sense of your return on AI. Just as miles per gallon helps us evaluate new car purchases, IPW can help to measure the computational efficiency of a system. It quantifies how much intelligence — typically measured in AI inferences, tokens processed, or model training iterations — a processor can deliver for every watt of electrical power it consumes.

According to Max Romanenko, chief engineering officer at relational database platform EDB, cost per query tells you almost nothing in an agentic world where autonomous systems are spinning up databases, pipelines, and queries around the clock. “The metric that matters is intelligence per watt, how much useful AI you get for every unit of energy you spend,” he says. “It isn’t just an environmental number, it’s also a performance indicator.”

With the measurements in place, you can then start to manage and optimize each layer in the AI stack from the infrastructure, or hyperscaler, layer to your own data and application layers.

It’s important to bear in mind that high token usage isn’t necessarily a bad thing. It depends on the net value delivered by each AI application and use case. Managing and optimizing the AI stack is important, but you’ll also want to measure the business value being delivered by each of these applications so you can measure your return.

Take a sovereign AI approach when evaluating hyperscalers

As you work with hyperscalers like Amazon, Google and Microsoft, it’s important to understand how they charge and how much, but also their environmental footprints. For example, by reading their sustainability reports, you can find out their annual water consumption across their global data centers and compare them with other providers.

In 2025, Amazon’s global data center operations used 0.12 liters of water per kilowatt-hour, which amounts to 2.5 billion gallons, or 5% of the annual water consumed by the metro Seattle area. The company has been able to operate more than seven times better than the industry average and have improved their water efficiency by 52% since 2021.

As demand for cloud computing and AI grows, water efficiency is another important metric for CIOs to monitor within hyperscaler ESG reports. While not at the same level of regulation as scope 2 and 3 greenhouse gas (GHG) emissions reporting, enterprises need to pay increasing attention to water use efficiency (WUE) with water scarcity becoming a growing risk for hyperscalers.

The key requisite at the infrastructure layer, though, is to ensure sovereign AI. This doesn’t mean you need to own everything, but you need control over your AI-driven operations when conditions change. With 71% of global executives stating that switching their primary AI vendor or model would be difficult if required today, it’s important to understand AI dependencies and be able to avoid vendor lock-in. 

Control efficiency at the data layer

The AI energy conversation has fixated on models and GPUs, but every agent, model, and inference call runs on the data layer beneath them, and that’s the one place a CIO can actually move the numbers.

“You can’t control consumption at the model layer,” says Romanenko. “Agents consume what they consume. But you can control efficiency at the data layer, and for most enterprises that’s the only real lever they have. Optimize search, retrieval, and vector indexing where the work actually happens and you cut compute, cost, and carbon at the same time. Ignore it, and it’s like running the heat with every window open.”

Ann Dunkin, distinguished professor of the practice at Georgia Tech, adds that CIOs who bring models in house and run them in their own infrastructure, or in the cloud infrastructure of their choosing, can have more control over the sustainability of inference, as well as of their costs and how their data is used.

Fine tune the application layer

When balancing a mix of commercial AI packages and custom-built code, costs can quickly spiral due to inefficient design and orchestration, redundant APIs, and unoptimized model routing.

With inference calls costing approximately 10 times that of conventional web queries, for custom AI applications, it’s important to design them to only use probabilistic code where necessary. Since many custom applications utilize a combination of both probabilistic and deterministic code, this is exactly where software developers need to make smart choices in their designs.

Other techniques to fine tune the application layer include semantic caching, intelligent model routing, and internal AI capability registries. “CIOs can implement intelligent routing solutions to select the most cost-efficient model for every prompt,” says Dunkin. “The most flexible routing solutions can drop into a user’s existing environment and orchestrate the actions of the company’s existing models.”

For CIOs looking to maximize the business value of every AI application in their portfolio, these new considerations, including new metrics, tools and approaches from the infrastructure layer all the way up to the application layer, should be an essential part of the equation.

A client called me last week with a problem I have been hearing about more often lately. They had made significant reserved instance commitments with a major cloud provider, overbuying for what they thought would be heavy AI training workloads. Now they were sitting on thousands of dollars in idle capacity every month. Their plan was simple: resell it to someone else. Except they couldn’t.

I have been doing cloud consulting for a long time, and this situation once had a straightforward solution. You went to the marketplace, listed your unused reservations, and found a buyer. The process was a bit clunky, but it worked. These days, the answer is far more complicated, and my client learned this the hard way.

AI has made this problem increasingly common. Companies initially committed to compute capacity based on ambitious training plans. Prototype projects were expected to scale, and inference workloads were projected to grow substantially. Then reality hit. Some projects did not materialize. Some models trained faster than expected. Some inference patterns were lighter than anticipated.

Many organizations now hold reserved capacity they can’t use, discard, or share without a complex, increasingly restricted process. This reality is something every company with significant cloud spend needs to clearly understand.

The history of cloud resale

There was once a functioning resale market for cloud reserved instances. AWS, for example, maintained a Reserved Instances Marketplace where companies that had purchased reserved capacity could sell those reservations to other AWS customers. This was a legitimate, AWS-sanctioned process. Companies would register as sellers, list their unused reservations with pricing and terms, and if a buyer appeared, the marketplace would facilitate the transaction.

The resale market was useful for companies that had overestimated their needs or whose business changes reduced their cloud consumption. Instead of simply absorbing the cost of unused commitments, they could recoup some of that investment by selling to other organizations with unmet demand. It created a secondary market that added liquidity to what was otherwise a rigid financial arrangement.

My client had some experience with this resale market a few years ago and assumed they could use it again. They were unpleasantly surprised to learn that the rules had changed.

AWS changes the rules

In January 2024, AWS implemented a significant policy change that effectively shut down the resale of EC2 Reserved Instances on its platform. AWS stopped allowing companies to resell their unused reserved capacity through the Reserved Instance Marketplace or any other official channel. If you have a reserved instance commitment with AWS, you are essentially stuck with it unless you can use it yourself or modify your reservation.

This change had a real impact on companies that had relied on resale as part of their cloud financial management strategy. It reduced flexibility and increased the risk of long-term reserved commitments. When I explained this AWS policy change to my client’s representatives, I could hear the frustration in their voices. They had made their commitment in good faith, carefully modeled their expected AI workloads, and now faced the reality that there was no easy exit.

The reasoning behind this change is not entirely clear, but AWS likely viewed capacity resales as something that complicated their billing and commitment models without providing enough benefit to the overall ecosystem. Regardless of the company’s reasons, the primary resale path for the largest cloud provider has been effectively closed.

What options still exist?

What can companies do now when they find themselves with reserved capacity they no longer need? The first possibility is to work directly with the cloud provider to modify or exchange the reservation if it is convertible. Some reservation types allow modifications, such as changing the instance type, region, or tenancy. This will not eliminate the commitment, but it may help companies better align their reservations with actual workload needs.

The second option is to use third-party brokers and marketplaces that operate independently of the cloud providers. Although AWS has shut down its official resale channel, brokers and marketplaces still facilitate resale arrangements for other cloud providers and for some AWS scenarios. These arrangements can be more complex and carry more risk, but they remain a possibility for companies determined to move unused capacity.

The third alternative is to optimize usage. Companies can invest in better utilization monitoring, workload placement, and automation to ensure that reserved capacity is used as efficiently as possible. This does not recover the money already spent, but it reduces future waste.

My client explored all three alternatives and found that each had significant limitations. Modifications were possible, but only within a narrow range. Third-party brokers were interested, but the process was opaque and uncertain. Optimization helped, but it could not eliminate the fundamental overcommitment they had already made.

The broader implications

Cloud commitments are more rigid than many enterprises initially realize because they lack a liquid market and because providers control modifications, transfers, or cancellations. Right now, I see this pattern most often in the AI space. Companies commit to massive amounts of compute for training and inference based on projections that rarely reflect the actual workloads. Then they are surprised to find themselves locked into payments. The AI boom has led to significant overcommitment because enterprises remain unaware that the resale mechanisms that once existed have been largely shut down.

This is why cloud financial management has become such an important discipline. Companies need to be far more thoughtful about how they commit to cloud resources, how they model their future consumption, and how they build flexibility into their cloud strategies. The days of assuming you can always resell your way out of an overcommitment are effectively over, at least with AWS.

For Azure and Google Cloud, the resale landscape is slightly different, but the same general principles apply. These providers have their own capacity transfer policies and, like AWS, those policies can change at any time. Companies should understand their options before making large, committed purchases and build contingency plans in case their actual usage diverges from their projections—or if resale policies change.

The bottom line is that reselling unused reserved cloud instances is far more complicated than it sounds. The market is not as open as it once was, the options are limited, and the providers themselves hold most of the cards. My client got burned, and I doubt they will be the only one. Companies that want to optimize their cloud spending should focus on accurate forecasting, thoughtful commitment sizing, and ongoing optimization rather than relying on resale as a safety valve. That approach worked at one point, but those days are largely gone.

AWS has updated AWS Data Exports, its service for generating and managing cost and usage Reports (CURs), to include standardized Amazon Bedrock product metadata, making it easier for enterprise engineering teams to analyze AI usage and spending as they scale AI deployments spanning multiple foundation models.

The update extends billing exports with normalized fields for model provider, model name, inference type, inference mode, billing unit and Bedrock product family, and will enable enterprises to identify which models generated costs and compare spending across providers without relying on custom parsing or normalization of billing records, AWS wrote in a blog post.

That reduced reliance on custom parsing will reduce the engineering effort required to analyze billing data, analysts said.

“Before the update, a data engineer would typically need to maintain a model ID registry, write regex against usage type strings, or join AWS CloudTrail with CUR to figure out which provider generated which cost,” said Bhupendra Chopra, chief revenue officer at IT consulting firm Kanerika.

The new standardized fields “can be the difference between a billing pipeline that needs constant babysitting and one that doesn’t,” Chopra added.

That’s because custom parsing logic is more prone to break down or require maintenance when AWS adds new models or updates pricing in Bedrock, said Pareekh Jain, principal analyst at Pareekh Consulting.

Richer billing data to boost enterprise AI cost governance

Beyond reducing engineering overhead, the update could also help enterprises improve AI cost governance.

Before this update FinOps teams struggled to identify which model Bedrock related to because usage type fields were inconsistent, and there was no unified product family name that captured all Bedrock costs in one place, Chopra said.

“Now those attributes — model provider, model name, inference type, inference mode, pricing unit — are standardized and available by default. That’s the plumbing work no one talks about, but it’s what makes downstream reporting actually reliable,” Chopra added.

This, said Jain, makes it easier to build dashboards showing cost by model, provider, token type or inference mode while also identifying expensive workloads, unusual token growth and opportunities to move to cheaper models or batch processing.

It’s a timely update, especially in light of last week’s AWS billing issue that caused some customers to see incorrect cost estimates of services consumed in the AWS Management Console, said Muskan Bandta, cloud associate at FinOps services providing firm ZopDev.

“Anything that gives customers clearer, more granular and more trustworthy billing data is welcome when confidence in the numbers has just been shaken. It does not fix what went wrong, but better visibility into where spend is going is exactly what teams want more of after an episode like that,” Bandta added.

This article first appeared on InfoWorld.

AWS has updated AWS Data Exports, its service for generating and managing cost and usage Reports (CURs), to include standardized Amazon Bedrock product metadata, making it easier for enterprise engineering teams to analyze AI usage and spending as they scale AI deployments spanning multiple foundation models.

The update extends billing exports with normalized fields for model provider, model name, inference type, inference mode, billing unit and Bedrock product family, and will enable enterprises to identify which models generated costs and compare spending across providers without relying on custom parsing or normalization of billing records, AWS wrote in a blog post.

That reduced reliance on custom parsing will reduce the engineering effort required to analyze billing data, analysts said.

“Before the update, a data engineer would typically need to maintain a model ID registry, write regex against usage type strings, or join AWS CloudTrail with CUR to figure out which provider generated which cost,” said Bhupendra Chopra, chief revenue officer at IT consulting firm Kanerika.

The new standardized fields “can be the difference between a billing pipeline that needs constant babysitting and one that doesn’t,” Chopra added.

That’s because custom parsing logic is more prone to break down or require maintenance when AWS adds new models or updates pricing in Bedrock, said Pareekh Jain, principal analyst at Pareekh Consulting.

Richer billing data to boost enterprise AI cost governance

Beyond reducing engineering overhead, the update could also help enterprises improve AI cost governance.

Before this update FinOps teams struggled to identify which model Bedrock related to because usage type fields were inconsistent, and there was no unified product family name that captured all Bedrock costs in one place, Chopra said.

“Now those attributes — model provider, model name, inference type, inference mode, pricing unit — are standardized and available by default. That’s the plumbing work no one talks about, but it’s what makes downstream reporting actually reliable,” Chopra added.

This, said Jain, makes it easier to build dashboards showing cost by model, provider, token type or inference mode while also identifying expensive workloads, unusual token growth and opportunities to move to cheaper models or batch processing.

It’s a timely update, especially in light of last week’s AWS billing issue that caused some customers to see incorrect cost estimates of services consumed in the AWS Management Console, said Muskan Bandta, cloud associate at FinOps services providing firm ZopDev.

“Anything that gives customers clearer, more granular and more trustworthy billing data is welcome when confidence in the numbers has just been shaken. It does not fix what went wrong, but better visibility into where spend is going is exactly what teams want more of after an episode like that,” Bandta added.

OpenAI’s recent update to its Codex coding agent has developers worrying over the impact of the change on large code repositories and long-running AI-assisted sessions.

The update to the Codex CLI reduces the default configured input context window for GPT-5.6 to 272,000 tokens from 372,000 tokens.

In practice, the update means the coding agent will retain a smaller amount of code, conversation history, and other session information before compacting older context to make room for new information, a change that has prompted criticism from some developers on Reddit and X over the reduced token window.

While OpenAI has not publicly explained the rationale behind the update, several developers took to social media to question why OpenAI reduced the default context configuration, with some arguing that the change could make Codex less effective on long-running coding sessions by triggering context compaction sooner.

Others expressed concern that the smaller window could require more frequent context management or session resets, although some noted that the practical impact would depend on project size and how developers structure their workflows.

Smaller context, bigger workflow implications

The context window reduction could affect developer productivity and the adoption of autonomous agents in enterprise workflows, analysts say.

“While the context reduction in Codex is unlikely to affect routine coding tasks such as bug fixes or changes involving a few files, it could impact large codebases, repository-wide refactoring, and long-running sessions,” said Pareekh Jain, principal analyst at Pareekh Consulting.

“Less memory per session means the AI agent forgets earlier parts of a long coding session sooner. The agent may need to summarize or reload context more often, increasing repeated searches, occasional loss of earlier decisions and the need for developers to re-establish context,” Jain added.

That need for manual context management, according to Muskan Bandta, cloud associate at FinOps services providing firm ZopDev, goes completely against the “whole appeal” of Codex-like tools that promised improved productivity out-of-the-box: “A lot of developers are saying their sessions now spend more time on compacting than actually working.”

“While context reduction may not further inflate bills, it shows up as more retries, more compaction, and your engineers spending more time babysitting the thing. The spend just moves from the invoice onto your team’s time.”

Amit Jena, AI development manager at IT consulting firm Kanerika, said that the context reduction will force development teams to choose between two options: either accept that the agent is reasoning with an incomplete picture of the required context or learn to manage a new design constraint around context compaction.

Development teams, Jena said, will need to design workflows that proactively manage context: by breaking work into smaller tasks, relying more on retrieval mechanisms, and monitoring context consumption.

That forced design constraint on engineering, echoed Bandta, will slow the enterprise adoption of agent-driven workflows: “Context is the agent’s working memory, so cutting it by a third changes what you can trust it to do at all.”

Build for changing AI platforms, not fixed limits?

More broadly, analysts pointed out that the episode is a reminder that enterprises should avoid tightly coupling software development workflows to the current operational characteristics of managed AI coding platforms, as context limits, pricing, runtime behavior, and model availability are all likely to evolve with little or no advance notice.

“Enterprises should avoid depending on any single context window, continuously benchmark AI coding tools on real workloads, and build workflows around retrieval, modular design, and agent orchestration so they remain resilient as models evolve,” Jain said.

Kanerika’s Jena echoed that view: “The right approach is to build AI-assisted development pipelines that degrade gracefully when operational parameters shift: instrument your context consumption, don’t hard-code context budgets, and treat the vendor’s current specifications as a starting point, not a contract.” Similarly, Bandta advised enterprises to treat managed AI coding platforms like any other critical software dependency: “Don’t build anything that only works right at the edge of a limit, and keep enough flexibility that you’re not stuck if one vendor changes the deal.”

CIOs remain at the forefront of setting the course for AI adoption in their organizations.

In fact, 82% of CIO respondents to CIO.com’s 2026 State of the CIO survey are responsible for researching and evaluating AI products, with 78% of IT leaders saying their IT departments are driving AI adoption efforts, with business units aligning their strategies accordingly.

As such, CIOs are leading or co-leading AI strategies at the majority of organizations, with many also playing a key role in tackling AI change management. They report encountering numerous factors — from heightened pressure to deliver ROI to challenges with trust in AI outputs — as they formulate and shape those AI strategies.

Here’s a look at seven notable issues impacting AI strategies in 2026.

1. Increasing pressure to show ROI for AI investments

The era of AI experimentation and pilots is over. Boards and CEOs are making it clear they want to see quantifiable returns from their AI investments. Kyndryl’s 2025 Readiness Report, for example, found that 61% of senior business leaders and decision-makers felt more pressure to prove ROI on their AI investments than they had the prior year.

“The era of funding AI is shifting from everything all-in to every project has to have line of sight to some financial value at the end of the day. It’s moving from the experimentation phase to expecting measurable outcomes,” says Jim Piazza, chief AI officer at IT services firm Ensono.

As a result, Piazza says companies, both his own as well as those he advises, are more diligent about building business cases that estimate implementation costs, AI run costs, and expected benefits so they’re primed to pursue AI initiatives that will deliver ROI.

That strategy seems to be paying off. According to the May 2026 AI Momentum Survey from Dun & Bradstreet, 67% of 10,000 businesses surveyed reported seeing early signs or pockets of ROI, 20% reported multiple projects delivering ROI, and 10% reported strong ROI.

That’s a big jump from earlier surveys that found few AI initiatives providing returns. For example, PwC’s 2026 Global CEO Survey, released in January, found that 56% of CEOs saw no significant financial benefit from AI to date, while The GenAI Divide: State of AI in Business 2025 from MIT found that 95% of enterprise generative AI projects failed to show measurable financial returns within six months.

2. The need to harness AI for transformation

The No. 1 concern for CEOs this year, according to PwC’s 2026 Global CEO Survey, is whether they’re transforming fast enough to keep pace with technological change, cited by 42% of respondents as their top concern. And 68% of the 1,120-plus C-suite executives surveyed by KPMG for its May 2026 Adaptability Pulse Survey said they feel pressure to accelerate innovation.

That in turn is influencing AI strategies.

Steve Santana, CIO and head of AI at ETS, the world’s largest private nonprofit educational testing and assessment organization, says his company is “pivoting from working on enterprise efficiencies using AI to figuring out how to deliver assessments,” adding that “AI will enable innovation we couldn’t get to before.”

For ETS, that means reimagining how the company delivers its core products, “finding areas to do something you couldn’t do before because it was too big or too daunting,” such as having more interactive tests and assessments at scale, Santana says.

And while Santana believes organizations can’t move too slowly, he predicts innovation will trump speed. “The winners and losers in the AI race aren’t always going to be the ones that got there the fastest,” he says, observing that those who move too fast “can drive behaviors that are very dangerous.”

He adds, “I’m not advocating for moving slow; I’m advocating moving at pace. It’s better to be measured in your approach.”

3. The black box of AI costs

CIOs are struggling to calculate the full cost to run AI for their use cases, with estimates coming in well under what their actual bills will be. Consider the figures from research firm IDC, which found that global 1,000 companies will underestimate their AI infrastructure costs by 30% through 2027.

That makes identifying which AI use cases will produce quantifiable value much more challenging, which in turn makes determining a winning AI strategy harder to do. CIOs, however, say they can’t let that stop them from advising their C-suite colleagues on which AI use cases are likely to be winners.

“You can’t sit on the sidelines and wait and watch. The general conclusion is you’re going to lose if you do that, so you have to play even though the cost dynamics are not really well understood,” says Mohan Sankararaman, executive vice president and CIO of First Horizon Bank.

Sankararaman says he’s devising his AI strategy with that uncertainty in mind.

“It’s up to me and my team to figure out how to optimize our use for costs, just like we did with cloud,” he says, noting that part of his strategy is to avoid infrastructure choices that could result in AI vendor lock-in and, thus, getting stuck with that vendor’s bills.

“IT has to get the engineering right and not overengineer solutions to make sure the AI strategy we pursue delivers returns,” he adds.

Researchers recommend such approaches. In a blog highlighting the IDC research, Jevin Jensen, research vice president for infrastructure and operations at IDC, wrote that “organizations successfully navigating this challenge are ones that effectively share a common trait: they’ve reimagined FinOps as a strategic team, not an after-the-fact accounting exercise. They treat AI economics as a living ecosystem — measurable, visible, and continuously optimized.”

4. Aligning use cases to business strategy

There are an overwhelming number of potential use cases, so execs must pick and prioritize those that will help them achieve their strategic goals.

That’s easier said than done.

Enterprise Strategy Group’s 2025 report on generative AI’s ROI surveyed 1,900 business and IT leaders across nine countries and found that 71% had more potential use cases that they want to pursue than they can possibly fund; 54% said selecting the right use cases based on objective measures like cost, business impact, and the organization’s ability to execute is hard; and 71% acknowledged that selecting the wrong use cases will hurt their company’s market position. Furthermore, 59% of respondents said advocating for the wrong use cases could cost them their job.

Longtime CIO adviser Larry Wolff says challenges picking and prioritizing use cases stems in part from boards and CEOs commanding their teams “to do AI.” Such directives, he explains, puts the technology first and business goals second — something CIOs have been trying to avoid for years.

“There should not be a technology strategy. There should be a business strategy with a technology component. The same applies to AI,” says Wolff, now CIO of Preferred Travel Group. “We need to talk about business challenges and opportunities first and then talk about how AI can solve for those.”

5. Human readiness to use AI

Even as Sankararaman and his executive colleagues build the bank’s AI strategy, he still sees the need to improve the organization’s understanding of the technology. “Everybody has a basic understanding, but AI fluency isn’t where it should be,” he says, noting that a subpar level of fluency “can hamper creativity.”

“If the strategy is to become top notch in, say, customer experience, we have to determine how to achieve that. And if you start building the road map but you don’t know what the technology can do, then the strategy will be limited,” he adds.

Sankararaman considers running AI boot camps for executives and their direct reports to improve their knowledge of AI and its transformative capabilities. “Not everyone needs to be an AI expert, but we still need to have a level of understanding of, say, what a large language model is and how to apply it and other elementary things like that. The hope is that when we do talk about strategy for business outcomes, everyone will know how to leverage AI,” he explains.

According to Jamaal Justice, principal for people consulting at EY, concern about AI fluency is widespread.

“One of the biggest challenges that impacts the success of an AI strategy is human readiness,” Justice says. He points to EY research showing “that while 88% of employees use AI at work, only 28% of organizations have positioned employees to achieve transformative business impact from AI. This underscores that the challenge is not access, but adoption and readiness.”

Like Sankararaman, Justice acknowledges that it’s OK to have a spectrum of knowledge and use among workers. But success with AI “depends on aligning mindsets, skillsets, and toolsets, by creating the right conditions for both workforce readiness and effective technology use,” he says.

“Organizations that integrate human capability with technology and fundamentally rearchitect work using a human-centered and value-oriented approach will unlock value at scale,” he adds. “Those that don’t risk fragmented adoption and limited returns.”

EY research confirms as much, finding that productivity gains can fall by more than 40% when AI is deployed on weak talent foundations, including poor learning, culture, and incentives.

6. Data readiness for AI use

Data readiness is also lagging at most organizations, further hindering AI ambitions.

According to a 2026 report from Cloudera and Harvard Business Review Analytic Services titled Taming the Complexity of AI Data Readiness, 73% of surveyed business leaders said their organization struggles with AI data preparation. The top obstacles are siloed data and difficulty integrating data sources (56%), lack of a clear data strategy (44%), data quality and bias issues (41%), and regulatory constraints on data use (34%).

To ensure AI success, “a radical reshaping of the data landscape is needed,” says Steve Prewitt, who as chief data and AI officer at IT services firm Genpact advises clients on AI deployments for their own organizations.

That reshaping is more critical today as agentic AI becomes more prevalent, Prewitt observes. Organizations need high-quality well-governed data to enable and trust AI agents to make real-time decisions autonomously. Otherwise, organizations either can’t move forward with deploying agents or, if they do, risk triggering cascading failures.

7. Engendering trust

ETS CIO Santana and his colleagues recognize AI’s potential to deliver faulty outputs, whether from problematic data, drift, or other problems. Everyday users recognize that potential, too.

That’s why the issue of trust has a significant impact on the nonprofit’s AI strategy. Companies such as ETS that provide critical, high-stakes services know they must earn trust by building AI use cases that can consistently and demonstratively deliver accurate outputs, Santana says.

ETS’s strategy is to highlight where AI is making high-stakes decisions and to detail what steps the company must take to ensure that it consistently delivers accurate, trustworthy outputs and that it conforms to established standards and requirements, he says.

“You don’t want someone to feel the results may be wrong if you’re using AI to assess a person and their future depends on it,” he notes. “You want to remove any doubts [in such AI use cases], and the strategy should ensure that. The strategy should include all the work needed to have that trust.”

For diversified enterprises, few operating model questions are as persistent or polarizing as centralization versus decentralization. Decentralization promises speed, ownership, and local responsiveness. Centralization promises efficiency, standardization, and leverage. Both can be right. Both can be wrong. The challenge is that many organizations end up with both models operating at once, without enough clarity about why.

The result of fragmented systems, duplicated capabilities, inconsistent data, rising IT spend, and a complexity tax that compounds over time is familiar to many CIOs. What starts as autonomy can become architectural sprawl. What starts as enterprise leverage can become bureaucracy. And as companies modernize core platforms, integrate data, and scale capabilities like AI, the tension becomes harder to ignore.

Paul Krebs has lived that tension from multiple vantage points. Most recently as CIO and chief transformation officer at Koch Industries, and previously a technology and transformation leader at The Coca-Cola Company, he’s worked in environments where business units value autonomy, enterprise scale matters, and the wrong operating model can slow progress just as easily as the wrong technology architecture.

His conclusion isn’t that CIOs should pick a side, but they need a more intentional form of centralization, one that starts with business architecture, clarifies decision rights, and continually revisits where capabilities should sit as the organization matures.

Centralization: a design choice, not a doctrine

In diversified organizations, decentralization often starts as the default because it aligns with how the business creates value. Local businesses understand their customers, markets, regulatory environments, and operating realities, and giving them decision rights can increase speed and accountability.

In Krebs’ experience, the default model often leaned toward decentralization, he says, with the belief that optimizing for customers and markets would allow different businesses to be as responsive as possible to the specific customers and markets they served. But that logic isn’t complete. Leaders also need to ask whether there’s a compelling case where a more centralized approach can generate additional value, accelerate progress, or optimize investments.

Digital transformation created one of those moments. Krebs recalls around 2016 when Koch challenged its businesses to build multi-year digital transformation roadmaps. The ambition was there, but the capabilities to execute at the necessary pace weren’t evenly distributed. In response, the organization invested more aggressively from the center, building shared services and centers of expertise in areas such as business transformation, enterprise applications, and data and analytics.

The purpose was acceleration, not control. Centralizing those capabilities helped accelerate learnings, capability building, and their ability to deploy new solutions at scale. But the move wasn’t treated as permanent. “There was always a belief that the centralization push should be re-looked at on a regular basis, not thought of as a forever decision,” he says.

Know what belongs at the center

Over time, Krebs learned that  the capabilities most likely to remain centralized were those where scale, consistency, and risk management mattered more than local differentiation. Infrastructure, collaboration platforms, cybersecurity, cloud management, FinOps, and the help desk were natural candidates to remain shared services.

Other areas were more nuanced. Some application capabilities moved back into the businesses as local maturity increased. Many data and insights capabilities also moved closer to the business once teams had built enough muscle to own them. Meanwhile, certain emerging capabilities such as spatial technologies like AR/VR remained centralized because it didn’t yet make sense for each business to build them independently. Many companies have lived this journey as well, for example, with gen AI, which often started with a center of excellence, and then evolved into a more decentralized approach, enabling teams across the business to innovate quickly.

That distinction avoids the trap of treating the enterprise as one uniform operating model. “Both models can be successful, and both have advantages,” he says. “That’s what makes the balance so difficult.”

Centralization provides a clearer path to execution at scale and cleaner decision rights, but it requires change management and careful attention to bureaucracy. Decentralization provides ownership and speed, but it can also over index toward preference versus real differentiation, he adds, while making architecture harder to scale later.

Don’t confuse standardization with centralization

One of the most important distinctions Krebs makes is between centralization and standardization. Many organizations treat them as interchangeable, but they’re not.

“You can have a centralized team that can manage the nuances of different requirements,” Krebs says. “You can also have a centralized standard platform that can be used in a decentralized manner.”

That distinction opens up more operating model choices. A company may centralize a platform but decentralize how business teams configure or use it. It may standardize process patterns while keeping execution close to the region or business unit. It may also centralize architectural governance while allowing local teams to move quickly within defined guardrails.

This is especially important in global organizations, where regional needs are real but not always unique. Krebs advises leaders to examine whether local requirements can be made more generic and reusable. The risk is solving each local requirement as a one-off, so the better path is to understand the underlying requirement, build it in a way that can scale, and still allow local teams to execute within the standard model.

Let business architecture lead technology architecture

Few topics expose the centralization tension more clearly than ERP consolidation. Many diversified companies, particularly those shaped by acquisition, end up with dozens or hundreds of ERP instances. Some leaders push for massive consolidation. Others prefer to build integration layers on top of the existing environment.

Krebs’s starting point is neither technology nor cost. It’s business architecture. “The easiest and most effective path is when the IT or systems architecture follows and aligns to the business architecture,” he says.

If the business is truly going to operate processes separately, separate systems may be appropriate. But if the organization has numerous teams, processes, and tools, leaders need to ask whether there’s enough differentiation and value to justify that complexity.

The same logic applies to M&A. Companies can get into trouble when integration synergies are held hostage by ERP migration timelines. Instead, Krebs advises starting with the business integration strategy. Understand where the synergies are, how the business architecture should come together, and then decide whether the IT architecture needs to be fully integrated, or whether a data layer, reporting platform, or other integration approach can deliver value faster.

Make the cost of complexity visible

CIOs in decentralized companies often face a frustrating dynamic. The business wants autonomy and speed, but the same leadership team still questions why IT spend is high relative to benchmarks. Krebs says the answer starts with cost alignment and visibility.

In environments with a mix of centralized and decentralized services, Krebs saw centralized capabilities like infrastructure, help desk, and security perform well on benchmarks. More decentralized areas, such as BI, reporting, and commercial applications, often had more redundancy and higher cost.

The point isn’t to blame the business but make the economics of complexity visible. CIOs need to show how flexibility in one area may require multiple systems, data stores, or teams elsewhere. “I understand we want flexibility here,” Krebs says. “But leaders must see when that flexibility may cost the company money, and be clear on whether the value justifies it.”

That shifts the conversation from IT cost to business service economics. A single aggregate IT spend number is rarely useful in a decentralized environment. More helpful is a capability-based view that shows which areas are scaled efficiently, which are fragmented, and where the business architecture is driving the technology cost structure.

Revisit the model as maturity changes

For a new CIO entering a decentralized environment, Krebs cautions against immediately declaring that too many things need to be centralized. The better starting point is curiosity. “I would begin with just trying to understand why they’ve made the decisions they have,” he says.

From there, CIOs can engage leaders in a conversation about the target operating model, connecting business architecture to technology, data, and organizational capabilities. Once the direction is clear, he advises CIOs to work with the willing. Find the parts of the organization that already see the need for change, prove the model there, and scale from demonstrated success.

Regardless of execution, though, the right model changes over time. A low-maturity capability may benefit from centralization because the organization needs to build talent, avoid reinventing the wheel, and accelerate learning. As maturity grows, decentralization may make more sense because business teams need flexibility to adapt quickly. Once maturity is high and patterns stabilize, the organization may be ready to centralize again to leverage scale.

“Once I’ve decided I’m going to start with centralized or decentralized, you don’t necessarily need to stay in that model,” Krebs says. “You need to be continually revisiting the operating model as your organization matures and evolves.”

That may be the heart of smart centralization. It rejects the false permanence of operating model decisions, and recognizes that autonomy and scale are both valuable, but in different places, at different times, for different reasons.

Gen AI spending is moving beyond the familiar software model of seats, licenses, and pilots. As AI shifts from copilots to embedded workflows and autonomous agents, one user request can trigger multiple model calls, retrieval steps, retries, orchestration layers, and infrastructure events. A tool that looks affordable in pilot may behave very differently once connected to production systems or allowed to act with less human supervision.

According to Michael Corrigan, CIO of World Insurance Associates, AI introduces a fundamentally different cost model — one that’s usage driven, non-linear, and tightly coupled to business activity. “Success requires shifting from traditional IT budgeting to FinOps-style discipline where consumption, value, and governance are actively managed in real time,” he says.

Here are five ways CIOs can build that discipline before AI costs spiral.

Forecast AI by workflow, not by user

At World, a top 25 insurance broker with about 3,000 employees across roughly 300 locations, AI use falls into three broad categories, Corrigan says. One is broad tools, such as copilots. Another is embedded AI inside SaaS platforms. And the third is bespoke AI built around specific workflows and manual processes.

“The bespoke is the area that’s growing the most right now,” he says. “And that’s where the model, from a cost perspective, has really been shifting from a license seat cost to a token consumption or token burn cost, or even a hybrid.”

Seat-based pricing is relatively easy to forecast whereas consumption-based AI isn’t. Costs may depend on prompt complexity, output length, model choice, workflow design, and whether the system calls a model once or many times in the background.

World tries to manage that uncertainty by defining the business problem, success criteria, and expected operational improvement upfront. Pilots help estimate consumption before scaling, but Corrigan says they don’t remove the ambiguity.

“We’ll try our best in the pilot to understand what the consumption rate is, what the token burn rate is,” he says. But once a consumption-based workflow goes into production, he adds, an estimate is put into place. That estimate is informed, but still rough.

Elmer Morales, founder and CEO of koder.com, an agentic AI coding startup, says CIOs should think less about headcount and more about workflow mechanics. Agentic AI costs are driven by the number of decisions an agent makes, how often it retrieves external data, how much context it carries, and how many systems it touches.

“CIOs should start by mapping workflows, not necessarily users,” he says. “The relevant variable isn’t going to be the headcount but how many decisions an agent makes per task.”

Model the failure path, not just the happy path

Pilots can mislead because they often test the cleanest version of an AI workflow. Morales says many enterprises model agentic AI costs around the happy path: the user gives a clear prompt, the system understands the request, the agent completes the task, and the process ends. Production is messier.

“They generally don’t model for situations where the agent is going to need to go back and check its work and redo things,” Morales says. “A lot of times, agents are wrong, either because they hallucinate or they understood the problem incorrectly.”

In an agentic workflow, the system may check its work, call another tool, retrieve more data, or redo a step. While that may improve quality, it also adds cost.

The difference between copilots and agents is central. A copilot interaction is often one prompt and one response. An agentic workflow may involve agents moving through a decision tree, executing tasks in sequence or in parallel, and calling sub-agents or external systems along the way. “By the time it’s achieved the original goal, the agent might have made 50 or 100 model calls, compared with a single call for a traditional copilot prompt,” Morales says.

That’s why CIOs should require teams to model the failure path before production, like how many retries are allowed, how much context is resent, which tools can be called, when a human should intervene, and what happens when the agent can’t complete the task.

Build cost controls into the architecture

Traditional FinOps practices still matter, but AI requires more than retrospective dashboards and chargebacks.

According to Pavan Madduri, senior cloud platform engineer at industrial supply company Graigner, looking backward at usage data, as traditional FinOps often does, can be too late. Costs are shaped by prompt design, model selection, agent behavior, orchestration choices, and runtime loops.

“Dashboards or chargebacks, those are historical accounting,” he says. “The money’s already gone.” For AI, he argues, cost controls need to be embedded into the architecture. That includes hard token caps, retry-depth limits, maximum runtime limits, workload prioritization, background-job throttling, and cluster-level controls that prevent runaway consumption.

“The real FinOps means you need to have the cost constraints embedded into your architecture framework,” Madduri says.

Those controls also extend to infrastructure. Expensive GPUs may sit warm between jobs because systems need capacity available when inference demand arrives. Teams may pass huge schemas, databases, or thousands of lines of code into frontier models when a smaller or more focused prompt would do.

Enterprises should also adopt event-driven autoscaling, Madduri says. “Use tools like KEDA to scale GPU nodes down to zero the moment inference demand drops, so teams only pay for the windows when the silicon is actively crunching tokens.”

Corrigan says World uses rate limits, spend limits, alerts, and approval gateways for consumption-based tools. When users approach token consumption limits, automated alerts allow IT and the business to review whether the continued spend is justified.

“If it’s not meeting the success criteria we expected, you have to have the control in place to say we’re going to move on or kill that process,” Corrigan says.

Route work to the right model

CIOs can also reduce AI bill shock by avoiding a default assumption that every task requires the most powerful model available. While some tasks need advanced reasoning, many others don’t. A simple support ticket, log-parsing task, or structured database transaction may be handled by a smaller or cheaper model. A complex architecture decision, legal analysis, or multi-step reasoning task may justify a more powerful one.

“Choosing the right model for the right prompt and right question — that’s where you leverage the maximum from that model, and you can decrease the costing,” Madduri says. “If you default every single call to a frontier model, that’s architectural laziness.”

Morales makes a similar point. Not every step in an agentic workflow requires a top-of-the-line model. Model routing, he says, is the discipline of determining the best model for the task, and providing the relevant context when the model needs it.

According to Jim Olsen, CTO of enterprise software company ModelOp, CIOs should use the least expensive model that can accomplish the business goal. Using the biggest model for everything is easier, but expensive. “It’s like hiring the most expensive engineer to change a few colors in a website’s CSS, or visual styling,” he says. “You wouldn’t do that. You use the appropriate tools for the task.”

Tie consumption to business value

For Olsen, the deeper enterprise problem is AI value shock, not just bill shock. Spending $200,000 in a quarter on AI is justified if it produces $2 million in business value. The problem is spending heavily on use cases that don’t generate a meaningful return.

“Are you actually getting that return on investment, or are you just blowing tokens for something that’s not delivering the value to your business?” Olsen asks. Tracking token usage by user or department may show who consumed AI, but not whether the consumption mattered.

For most enterprise AI systems, Olsen says costs should be tied back to business use cases. A model may be used for HR document search, customer support, code review, problem resolution, or other functions. Each use case may draw on the same underlying models or agents, but the business value can be very different.

That’s why he argues that companies need an AI inventory, a record of which business workflows use which models, agents, providers, workflows, and systems. Without that inventory, enterprises can’t connect consumption to value.

Corrigan takes a similar approach from a governance perspective. At World, new AI ideas go through an intake process. Business users propose improvements, and IT, finance, operations, sales, and business stakeholders evaluate, prioritize, and monitor them from pilot through production.

That may be where the next stage of AI FinOps is heading, toward a clearer understanding of which AI consumption deserves to scale, not just to lower bills. So the question, as Olsen puts it, isn’t whether someone used a million tokens. It’s what are they using them for.

A largely overlooked layer of the AI stack is emerging as a major driver of enterprise costs. New testing by AI consultancy Systima found that agent harnesses, the software that coordinates models, tools and workflows, can generate significant token overhead through their configuration alone, potentially inflating the cost of AI deployments as organizations scale agents from experimental pilots to production environments.

The firm, which ran a series of tests by juxtaposing two harnesses on the same tasks, namely Anthropic’s Claude Code and open-source OpenCode using the same Claude Sonnet 4.5 model underneath, found both exhibiting sharply different token overhead because of the differences in their configuration.

These differences included system prompts, tool definitions, agent coordination mechanisms and other orchestration components, resulting in markedly different baseline input token overhead before users even entered a prompt, the consultancy firm wrote in a blog post.

Separately, the firm also found that other configuration choices while setting up the harnesses such as repository instruction files, Model Context Protocol (MCP) servers, prompt framework templates and subagents can each add substantial token overhead.

The consultancy’s conclusions are also supported by emerging academic research examining how orchestration of the harnesses themselves, rather than optimizing models or changing them, can help enterprises reshape the economics around AI agents.

In a paper, titled The Harness Effect: How Orchestration Design Sets the Token Economics of Enterprise Agentic AI, researchers showed that changing the harness while keeping models and tasks the same can reduce token consumption by 38%, cost per task by 41%, and execution time by 44% while maintaining comparable quality.

Why enterprises overlook harness costs

Analysts say that enterprises can gain greater control over AI agent operating costs by paying closer attention to how their harnesses are configured and orchestrated, instead of just relying on model pricing as a yardstick.

“The evaluation shows that the model is only one part of agent economics. The harness, tool schemas, instructions, MCP connections, and subagents matter as well. Enterprises therefore need to measure the entire agent configuration, not assume model pricing tells them what an agent will cost,” said Stephanie Walter, practice lead of the AI stack at HyperFRAME Research.

Currently, most enterprises pick agent tooling based on model quality, benchmarks, developer experience, and headline pricing per seat or per million tokens, with almost no one measuring what the harness sends per request, how stable the cache prefix is, or what subagent fan out costs at scale, echoed Advait Patel, site reliability engineer at Broadcom.

“Ask the average CIO whether their coding agent rewrites its cache mid-session, and you will get a blank stare,” Patel added.

However, Ashish Chaturvedi, executive research leader at HFS Research, pointed out that lack of visibility is less a failure of enterprise leaders than a consequence of how AI agent ecosystem components are sold, stacked, and managed presently.

“Most organizations have no visibility, mainly due to the absence of any metric from the vendor’s end that lets CIOs measure the entire agent or at least the harness configuration. None of this shows up in the developer’s experience. The agent just works, and the tokens burn silently in the background,” Chaturvedi said.

The problem is further compounded, according to Chaturvedi, due to the manner in which AI agent configuration is distributed across enterprise teams.

“The harness is chosen by one team, the instruction file written by another, and the MCP servers attached by a third, so no single person sees the cumulative weight,” Chaturvedi noted.

Even when, in some cases, enterprises do have visibility and ownership, Patel argued, the industry, in general, still lack the operational maturity and discipline to systematically optimize AI agent costs.

“FinOps for agents is where cloud FinOps was in 2013. Nobody has hired the equivalent of a cost optimization team focused on prompt engineering, harness configuration, and cache stability,” Patel said.

Separately, Abhishek Satapathy, principal analyst at Avasant, pointed out that the invisibility issue stems from how enterprises evaluate AI agents before deploying them into production: “Most proof-of-concepts involve a limited number of users, relatively short-lived sessions, and controlled agentic interactions, where the accuracy of model output is the primary evaluation criterion.”

The analysts’ comments also echo the conclusions of another research paper, in which researchers argued that token consumption in agentic software engineering systems remains poorly understood because existing metrics provide limited visibility into where tokens are spent across orchestration components.

How CIOs can improve visibility into AI agent costs

Closing that visibility gap, though, according to Satapathy, is increasingly becoming a priority for enterprises, as AI agents move from pilots to production and operating costs become harder to predict.

“Across our advisory engagements, we are seeing growing demand for AI observability frameworks that combine runtime tracing, workload-level cost attribution, and execution analytics. This enables organizations to establish engineering baselines, benchmark workload efficiency, forecast AI operating costs, and continuously optimize agent performance as deployments mature,” Satapathy said.

However, until vendors provide more comprehensive visibility into harness-level token consumption, analysts said enterprises should begin treating harness configuration as an operational governance issue rather than merely a developer preference.

“The single most valuable move is to get visibility into what the harness actually sends. Enterprises should treat configuration as a governed cost decision, deliberately match harnesses to workloads, and closely monitor cache behavior and subagent fan-out, since those were among the biggest cost multipliers identified in the evaluation,” Chaturvedi said.

Walter echoed that recommendation, saying CIOs should require observability across the entire agent configuration: “Without that visibility, enterprises are effectively buying an agent platform without knowing how much of the bill comes from useful work versus orchestration overhead.”

A portmanteau of “development” and “operations,” devops emerged as a way of bringing together two previously separate groups responsible for the building and deploying of software.

In the old world, developers (devs) typically wrote code before throwing it over to the system administrators (operations, or ops) to deploy and integrate that code. But as the industry shifted towards agile development and cloud-native computing, many organizations reoriented around modern, cloud-native practices in the pursuit of faster, better releases.

This required a new way to perform these key functions in a more streamlined, efficient, and cohesive way, one where the old frustrations of disconnected dev and ops functions would be eliminated. With two groups working together, developers can rapidly roll out small code enhancements via continuous integration and delivery rather than spending years on “big bang” product releases.

Devops was born at cloud-native companies like Facebook, Netflix, Spotify, and Amazon; but it’s become one of the defining technology industry trends of the past decade, primarily because it bridges so many of the changes that have shaped modern software development.

As agile development and cloud-native computing have become ubiquitous, devops has enabled the entire industry to speed up its software development cycles. Thus, devops has now thoroughly infiltrated the enterprise, especially in organizations that rely on software to run their business, such as banks, airlines, and retailers. And it’s spawned a host of other “ops” practices, some of which we’ll touch on here.[JF1] 

Devops practices

Devops requires a shift in mindset from both sides of the dev and ops divide. Development teams should focus on learning and adopting agile processes, standardizing platforms, and helping drive operational efficiencies. Operations teams must now focus on improving stability and velocity, while also reducing costs by working hand in hand with the developer team.

Broadly speaking, these teams need to all speak a common language and there needs to be a shared goal and understanding of each other’s key skills for devops to thrive.

More specifically, engineers Damon Edwards and John Willis created the CALMS model to bring together what are commonly understood to be the key principles of devops:

• Culture: One that embraces agile methodologies and is open to change, constant improvement, and accountability for the end-to-end quality of software.
• Automation: Automating away toil is a key goal for any devops team.
• Lean: Ensuring the smooth flow of software through key steps as quickly as possible.
• Measurement: You can’t improve what you don’t measure. Devops pushes for a culture of constant measurement and feedback that can be used to improve and pivot as required, on the fly.
• Sharing: Knowledge sharing across an organization is a key tenet of devops.

“Who could go back to the old way of trying to figure out how to get your laptop environment looking the same as the production environment? All these things make it so clear that there’s a better way to work. I think it’s very tough to turn back once you’ve done things like continuous integration, like continuous delivery. Once you’ve experienced it, it’s really tough to go back to the old way of doing things,” Kim told InfoWorld.

What is a devops engineer?

Naturally, the emergence of devops has spawned a whole new set of job titles, most prominent of which is the catch-all devops engineer.

Generally speaking, this role is the natural evolution of the system administrator — but in a world where developers and ops work in close tandem to deliver better software. This person should have a blend of programming and system administrator skills so that he or she can effectively bridge those two sides of the team.

That bridging of the two sides requires strong social skills more than technical. As Kim put it, “one of the most important skills, abilities, traits needed in these pioneering rebellions — using devops to overthrow the ancient powerful order, who are very happy to do things the way they have for 30 to 40 years — are the cross-functional skills to be able to reach across the table to their business counterparts and help solve problems.”

This person, or team of people, will also have to be a born optimizer, tasked with continually improving the speed and quality of software delivery from the team, be that through better practices, removing bottlenecks, or applying automation to smooth out software delivery.

The good news is that these skills are valuable to the enterprise. Salaries for this set of job titles have risen steadily over the years, with 95% of devops practitioners making more than $75,000 a year in salary in 2020 in the United States. In Europe and the UK, where salaries are lower across the board, 71% made more than $50,000 a year in 2020, up from 67% in 2019.

Key devops tools

While devops is at its heart a cultural shift, a set of tools has emerged to help organizations adopt devops practices.

This stack typically includes infrastructure as code, configuration management, collaboration, version control, continuous integration and delivery (CI/CD), deployment automation, testing, and monitoring tools.

Here are some of the tools/categories that are increasingly relevant in 2025, and what is changing:

• CI/CD and delivery automation: Traditional tools like Jenkins remain in many stacks, but newer orchestration tools and CLI-driven or GitOps-centric platforms are growing in importance (e.g. ArgoCD, Flux, Tekton). Also, platforms that integrate more tightly with monitoring, secrets management, drift detection, and policy enforcement are gaining traction.
• Security, compliance, and devsecops tooling: Security tools are increasingly integrated into devops pipelines. Expect to see more use of static analysis (SAST), dynamic testing (DAST), dependency and supply chain scanning (SCA), secret management, and policy as code. The push is toward embedding security earlier and bridging gaps between dev, security, and machine learning teams. (InfoWorld:)
• AI  and automation augmentation: AI-assisted tools are increasingly part of tooling stacks: auto-suggestions in CI/CD, anomaly detection, predictive scaling, intelligent test suite selection, and more. The hope is that these tools will reduce manual interventions and improve reliability. Tools that are “AI ready”—that is, they integrate well with AI or have mature built-in automation or assistance—increasingly stand out from the pack.

Devops challenges

Even as devops becomes more widely adopted, there remain real obstacles that can slow progress or limit impact. One major challenge is the persistent skills gap. The modern devops engineer (or team) is expected to master not just source control, CI/CD, and scripting, but also cloud architecture, infrastructure as code, security best practices, observability, and strong cross-team communication. In many organizations these capabilities are uneven: some teams excel, others lag behind. A 2024 survey showed that while 83% of developers report participating in devops activities, using multiple CI/CD tools was correlated with worse performance — a sign that complexity without deep expertise can backfire.

Toolchain fragmentation and complexity is a related issue. Devops toolchains have sprouted into a sometimes bewildering array of packages and techniques to master: version control, CI build/test, security scanning, artifact management, monitoring, observability, deployment, secret management, and more.

The more tools you have, the more difficult it becomes to integrate them cleanly, manage their versions, ensure compatibility, and avoid duplicated effort. Organizations often get stuck with “tool sprawl” — tools chosen by different teams, legacy systems, or overlapping functionalities — which introduce friction, maintenance burden, and sometimes vulnerabilities.

Finally, although devops has spread far and wide, there is still cultural resistance and alignment. Devops isn’t just about tools and processes; it’s about collaboration, shared responsibility, and continuous feedback. Teams rooted in traditional silos (dev vs ops, or security separate) may resist changes to roles and workflows. Leadership support, communication of shared goals, trust, and allowance for continuous learning are all necessary.

Many CIOs focus too much on tools or implementation first, rather than organizational culture and behaviors; but without addressing culture, even the best tools or processes may not yield the hoped-for velocity, quality, or reliability. Organizations that succeed here tend to have proactive strategies: dedicated training programs, mentorship, internal “guilds,” pairing junior and senior engineers, and making sure leadership supports ongoing learning rather than one-off bootcamps.

Why do devops?

Whoever you ask will tell you that devops is a major culture shift for organizations, so why go through that pain at all?

Devops aims to combine the formerly conflicting aims of developers and system administrators. Under its principles, all software development aims to meet business demands, add functionality, and improve the usability of applications while also ensuring those applications are stable, secure, and reliable. Done right, this improves the velocity and quality of your output, while also improving the lives of those working on these outcomes.

Does devops save money — or add cost?

Devops teams are recognizing that speed and agility are only part of success — unchecked cloud bills and waste undermine long-term sustainability. Waste in devops often comes in the form of “devops debt”— idle cloud capacity, dead code, or false-positive security alerts—which was called a “hidden tax on innovation” in recent Java-environment studies.

 Embedding finops practices can help fight these costs. Teams should shift left on cost: estimating costs when spinning up new environments, resizing instances, and scaling down unused resources before they become runaway expenses.

How to start with devops

There are lots of resources for help getting started with devops, including Kim’s own Devops Handbook, or you can enlist the help of external consultants. But you have to be methodical and focus on your people more than on the tools and technology you will eventually use if you want to ensure lasting buy-in across the business.

A proven route to achieving this is a “land and expand” strategy, where a small group starts by mapping key value streams and identifying a single product team or workload for trialing devops practices. If this team is successful in proving the value of the shift, you will likely start to get interest from other teams and from senior leadership.

If you are at the start of your devops journey, however, make sure you are prepared for the disruption a change like this can have on your organization, and keep your eye on the prize of building better, faster, stronger software.

---

More on devops:

• Devops debt: The hidden tax on innovation
• 10 big devops mistakes and how to avoid them
• Smarter devops: How to avoid deployment horrors

What is cloud native? Cloud native defined

The term “cloud-native computing” encompasses the modern approach to building and running software applications that exploit the flexibility, scalability, and resilience of cloud computing. The phrase is a catch-all that encompasses not just the specific architecture choices and environments used to build applications for the public cloud, but also the software engineering techniques and philosophies used by cloud developers.

The Cloud Native Computing Foundation (CNCF) is an open source organization that hosts many important cloud-related projects and helps set the tone for the world of cloud development. The CNCF offers its own definition of cloud native:

Cloud native practices empower organizations to develop, build, and deploy workloads in computing environments (public, private, hybrid cloud) to meet their organizational needs at scale in a programmatic and repeatable manner. It is characterized by loosely coupled systems that interoperate in a manner that is secure, resilient, manageable, sustainable, and observable.

Cloud native technologies and architectures typically consist of some combination of containers, service meshes, multi-tenancy, microservices, immutable infrastructure, serverless, and declarative APIs — this list is not exhaustive.

This definition is a good start, but as cloud infrastructure becomes ubiquitous, the cloud native world is beginning to spread behind the core of this definition. We’ll explore that evolution as well, and look into the near future of cloud-native computing.

Cloud native architectural principles

Let’s start by exploring the pillars of cloud-native architecture. Many of these technologies and techniques were considered innovative and even revolutionary when they hit the market over the past few decades, but now have become widely accepted across the software development landscape.

Microservices. One of the huge cultural shifts that made cloud-native computing possible was the move from huge, monolithic applications to microservices: small, loosely coupled, and independently deployable components that work together to form a cloud-native application. These microservices can be scaled across cloud environments, though (as we’ll see in a moment) this makes systems more complex.

Containers and orchestration. In could-native architectures, individual microservices are executed inside containers — lightweight, portable virtual execution environments that can run on a variety of servers and cloud platforms. Containers insulate the developers from having to worry about the underlying machines on which their code will execute. That is, all they have to do is write to the container environment. 

Getting the containers to run properly and communicate with one another is where the complexity of cloud native computing starts to emerge. Initially, containers were created and managed by relatively simple platforms, the most common of which was Docker. But as cloud-native applications got more complex, container orchestration platforms that augmented Docker’s functionality emerged, such as Kubernetes, which allows you to deploy and manage multi-container applications at scale. Kubernetes is critical to cloud native computing as we know it — it’s worth noting that the CNCF was set up as a spinoff of the Linux Foundation on the same day that Kubernetes 1.0 was announced — and adhering to Kubernetes best practices is an important key to cloud native success. 

Open standards and APIs. The fact that containers and cloud platforms are largely defined by open standards and open source technologies is the secret sauce that makes all this modularity and orchestration possible, and standardized and documented APIs offer the means of communication between distributed components of a larger application. In theory, anyway, this standardization means that every component should be able to communicate with other components of an application without knowing about their inner workings, or about the inner workings of the various platform layers on which everything operates.

DevOps, agile methodologies, and infrastructure as code. Because cloud-native applications exist as a series of small, discrete units of functionality, cloud-native teams can build and update them using agile philosophies like DevOps, which promotes rapid, iterative CI/CD development. This enables teams to deliver business value more quickly and more reliably.

The virtualized nature of cloud environments also make them great candidates for infrastructure as code (IaC), a practice in which teams use tools like Terraform, Pulumi, and AWS CloudFormation, to manage infrastructure declaratively and version those declarations just like application code. IaC boosts automation, repeatability, and resilience across environments—all big advantages in the cloud world. IaC also goes hand-in-hand with the concept of immutable infrastructure—the idea that, once deployed, infastructure-level entities like virtual machines, containers, or network appliances don’t change, which makes them easier to manage and secure. IaC stores declarative configuration code in version control, which creates an audit log of any changes.

How the cloud-native stack is expanding

As cloud-native development becomes the norm, the cloud-native ecosystem is expanding; the CNCF maintains a graphical representation of what it calls the  cloud native landscape that hammers home to expansive and bewildering variety of products, services, and open source projects that contribute to (and seek to profit from) to cloud-native computing. And there are a number of areas where new and developing tools are complicating the picture sketched out by the pillars we discussed above.   

An expanding Kubernetes ecosystem. Kubernetes is complex, and teams now rely on an entire ecosystem of projects to get the most out of it: Helm for packaging, ArgoCD for GitOps-style deployments, and Kustomize for configuration management. And just as Kubernetes augmented Docker for enterprise-scale deployments. Kubernetes itself has been augmented and expanded by service mesh offerings like Istio and Linkerd, which offer fine-grained traffic control and improved security

Observability needs. The complex and distributed world of cloud-native computing requires in-depth observability to ensure that developers and admins have a handle on what’s happening with their applications. Cloud-native observability uses distributed tracing and aggregated logs to provide deep insight into performance and reliability. Tools like Prometheus, Grafana, Jaeger, and OpenTelemetry support comprehensive, real-time observability across the stack.

Serverless computing.  Serverless computing, particularly in its function-as-a-service guise, offers to strip needed compute resources down to their bare minimum, with functions running on service provider clouds using exactly as much as they need and no more. Because these services can be exposed as endpoints via APIs, they are increasingly integrated into distributed applications, operating side-by-side with functionality provided by containerized microservices. Watch out, though: the big FaaS providers (Amazon, Microsoft, and Google) would love to lock you in to their ecosystems.  

FinOps. Cloud computing was initially billed as a way to cut costs — no need to pay for an in-house data center that you barely use — but in practice it replaces capex with opex, and sometimes you can run up truly shocking cloud service bills if you aren’t careful. Serverless computing is one way to cut down on those costs, but financial operations, or FinOps, is a more systematic discipline that aims to aligns engineering, finance, and product to optimize cloud spending. FinOps best practices make use of those observability tools to best determine what departments and applications are eating up resources.

How cloud-native architecture is adapting to AI workloads

Enterprises deploy larger AI models and make use of more and more real-time inference services. That’s putting demands on cloud-native systems and forcing them to adapt to remain scalable and reliable.

For instance, organizations are re-engineering cloud environments around GPU-accelerated clusters, low-latency networking, and predictable orchestration. These needs align with established cloud-native patterns: containers package AI services consistently, while Kubernetes provides resilient scheduling and horizontal scale for inference workloads that can spike without warning.

Kubernetes itself is changing to better support AI inference, adding hardware-aware scheduling for GPUs, model-specific autoscaling behavior, and deeper observability into inference pipelines. These enhancements make Kubernetes a more natural platform for serving generative AI workloads.

AI’s resource demands are amplifying traditional cloud-native challenges. Observability becomes more complex as inference paths span GPUs, CPUs, vector databases, and distributed storage. FinOps teams contend with cost volatility from training and inference bursts. And security teams must track new risks around model provenance, data access, and supply-chain integrity.

Application frameworks for building distributed cloud-native apps

Microsoft’s Aspire is one of the most visible examples of a shift towards application frameworks to simplify how teams build distributed systems. Opinionated frameworks like Aspire provide structure, observability, and integration out of the box so developer don’t need to stitch together containers, microservices, and orchestration tooling by hand.

Aspire in particular is a prescriptive framework for cloud-native applications, bundling containerized services, environment configuration, health checks, and observability into a unified development model. Aspire provides defaults for service-to-service communication, configuration, and deployment, along with a built-in dashboard for visibility across distributed components.

While Aspire was originally aligned with Microsoft’s .NET platform,Redmond now sees it as having a  polyglot future. This positions Aspire as part of a broader trend: frameworks that help teams build cloud-native, service-oriented systems without being locked into a single language ecosystem. Several other frameworks are gaining traction: Dapr provides a portable runtime that abstracts many of the plumbing tasks in cloud-native distributed applications, and Orleans offers an actor-model-based framework for large-scale systems in the .NET world, and Akka gives JVM teams a mature, reactive toolkit for elastic, resilient services.

Frameworks and tools in the expanding cloud-native ecosystem

While frameworks like Aspire simplify how developers compose and structure distributed applications, most cloud-native systems still depend on a broader ecosystem of platforms and operational tooling. This deeper layer is where much of the complexity—and innovation—of cloud-native computing lives, particularly as Kubernetes continues to serve as the industry’s control plane for modern infrastructure.

Kubernetes provides the core abstractions for deploying and orchestrating containerized workloads at scale. Managed distributions such as Google Kubernetes Engine (GKE), Amazon EKS, Azure AKS, and Red Hat OpenShift build on these primitives with security, lifecycle automation, and enterprise support. Platform vendors are increasingly automating cluster operations—upgrades, scaling, remediation—to reduce the operational burden on engineering teams.

Surrounding Kubernetes is a rapidly expanding ecosystem of complementary frameworks and tools. Service meshes like Istio and Linkerd provide fine-grained traffic management, policy enforcement, and mTLS-based security across microservices. GitOps platforms such as Argo CD and Flux bring declarative, version-controlled deployments to cloud-native environments. Meanwhile, projects like Crossplane turn Kubernetes into a universal control plane for cloud infrastructure, letting teams provision databases, queues, and storage through familiar Kubernetes APIs. These tools illustrate how cloud-native development now spans multiple layers: developer-focused application frameworks like Aspire at the top, and a powerful, evolving Kubernetes ecosystem underneath that keeps modern distributed applications running.

Advantages and challenges for cloud-native development

Cloud native has become so ubiquitous that its advantages are almost taken for granted at this point, but it’s worth reflecting on the beneficial shift the cloud native paradigm represents. Huge, monolithic codebases that saw updates rolled out once every couple of years have been replaced by microservice-based applications that can be improved continuously. Cloud-based deployments, when managed correctly, make better use of compute resources and allow companies to offer their products as SaaS or PaaS services. 

But cloud-native deployments come with a number of challenges, too:

• Complexity and operational overhead: You’ll have noticed by now that many of the cloud-native tools we’ve discussed, like service meshes and observability tools, are needed to deal with the complexity of cloud-native applications and environments. Individual microservices are deceptively simple, but coordinating them all in a distributed environment is a big lift.
• Security: More services executing on more machines, communicating by open APIs, all adds up to a bigger attack surface for hackers. Containers and APIs each have their own special security needs, and a policy engine can be an important tool for imposing a security baseline on a sprawling cloud-native app. DevSecOps, which adds security to DevOps, has become an important cloud-native development practice to try to close these gaps.
• Vendor lock-in: This may come as a surprise, since cloud-native is based on open standards and open source. But there are differences in how the big cloud and serverless providers works, and once you’ve written code with one provider in mind, it can be hard to migrate elsewhere.
• A persistent skills gap: Cloud-native computing and development may have years under its belt at this point, but the number of developers who are truly skilled in this arena is a smaller portion of the workforce than you’d think. Companies face difficult choices in bridging this skills gap, whether that’s bidding up salaries, working to upskill current workers, or allowing remote work so they can cast a wide net. 

Cloud native in the real world

Cloud native computing is often associated with giants like Netflix, Spotify, Uber, and AirBNB, where many of its technologies were pioneered in the early ’10s. But the CNCF’s Case Studies page provides an in-depth look at how cloud native technologies are helping companies. Examples include the following:

• A UK-based payment technology company that can switch between data centers and clouds with zero downtime
• A software company whose product collects and analyzes data from IoT devices — and can scale up as the number of gadgets grows
• A Czech web service company that managed to improve performance while reducing costs by migrating to the cloud

Cloud-native infrastructure’s capability to quickly scale up to large workloads also make it an attractive platform for developing AI/ML applications: another one of those CNCF case studies looks at how IBM uses Kubernetes to train its Watsonx assistant. The big three providers are putting a lot of effort into pitching their platforms as the place for you to develop your own generative AI tools, with offerings like Azure AI Foundry,Google Firebase Studio, and Amazon Bedrock. It seems clear that cloud native technology is ready for what comes next.

Learn more about related cloud-native technologies:

• Platform-as-a-service (PaaS) explained
• What is cloud computing
• Multicloud explained
• Agile methodology explained
• Agile development best practices
• Devops explained
• Devops best practices
• Microservices explained
• Microservices tutorial
• Docker and Linux containers explained
• Kubernetes tutorial
• CI/CD (continuous integration and continuous delivery) explained
• CI/CD best practices

Meta has unveiled Muse Spark 1.1, saying the frontier AI model rivals leading LLMs on coding, computer use, and agentic AI benchmarks while undercutting OpenAI and Anthropic on API pricing, potentially lowering the cost of deploying AI agents in enterprises.

Meta unveiled Muse Spark 1.1 on Thursday, pairing frontier-model performance with aggressive pricing in a move that analysts say could pressure rivals such as OpenAI and Anthropic and reshape enterprise AI procurement decisions.

Meta is betting that lower inference costs can help it gain ground in the enterprise AI market with the launch of Muse Spark 1.1, a frontier model that rivals top competitors on key benchmarks while costing a fraction as much to deploy.

The latest model, which was teased last week, matched or was competitive with leading models, such as Claude Opus 4.8, Gemini 3.1 Pro, and GPT 5.5, across several agentic AI, coding, and computer-use benchmarks, including SWE-bench Verified, Terminal-bench, BrowseComp, SpreadsheetBench, and OSWorld, Meta wrote in a blog post.

Muse Spark 1.1, which is currently in public preview and available via the Meta Model API, will cost $1.25 per million input tokens and $4.25 per million output tokens, the company noted.

By comparison, OpenAI charges $5 per million input tokens and $30 per million output tokens for GPT-5.5, while Anthropic charges $5 and $25, respectively, for Claude Opus 4.8. Google’s Gemini 3.1 Pro, on the other hand, is priced at $2 per million input tokens and $12 per million output tokens.

Lower prices may open doors, not close deals

That sheer difference in API pricing, according to Pareekh Jain, principal analyst at Pareekh Consulting, is enough to attract CIOs’ attention, at least for pilots, at a time when enterprises are trying to scale agentic deployments: “Pricing matters because inference costs increase rapidly when thousands of agents are working continuously.”

“Output tokens are often the largest model expense in coding, customer service, and process automation agents. Muse Spark’s output price is about 86% below GPT-5.5 and more than 90% below Claude Opus 4.8,” Jain said.

However, Muskan Bandta, cloud associate at FinOps services providing firm ZopDev, pointed out that the price is not a guarantee of adoption, despite the fact that most enterprises are likely to deploy the Muse Spark 1.1 for new projects.

“Cost becomes the primary differentiator only once the model is judged good enough. Developers don’t pick the cheapest model; they pick the cheapest model that clears their quality bar. So, price is the reason people show up, capability is the reason they stay,” Bandta said.

Similarly, CIOs are also likely to put more emphasis on the model’s security, data protection, uptime, audit trails, regional availability, support, and predictable behavior, rather than just the price, Jain said.

That distinction, according to Bandta, reflects a familiar pattern in enterprise technology buying: “This is the same lesson we saw in the cloud, where the cheapest provider on paper rarely won the biggest enterprise share. Price is one input in the total cost of ownership that includes risk, control, and switching cost, not the whole decision.”

Even so, the lower pricing could still shift the balance of power in enterprise procurement, Jain said: “This could help CIOs negotiate larger volume discounts, committed-use agreements, and better pricing from OpenAI, Anthropic, and cloud providers. It also strengthens the case for multi-model procurement rather than depending on one vendor.”

“Companies that do not even adopt Muse Spark can also use its pricing as evidence that frontier-level inference is becoming cheaper,” Jain added.

Meta’s pricing could reshape competition between rivals

Analysts pointed out that Meta’s new model could intensify competition in the frontier model market by forcing rivals to compete on inference economics and model sizes.

“It’s a real shot across the bow, and I’d expect OpenAI and Anthropic to respond on two fronts. Some of it will be price, cheaper tiers, and better cached and batch rates, because Meta has just reset what the market thinks a frontier token should cost,” Bandta said.

“But the incumbents won’t win the race with lower-priced offerings and more flexible pricing models. I expect them to lean harder into the things price can’t buy, governance, security, reliability, and enterprise support, to justify premium pricing,” Bandta added, likening the shift to an “early innings” of a price war that the industry saw with the expansion of cloud.

“The cloud infrastructure price war showed that while prices fell over time, vendors ultimately differentiated themselves through platform capabilities rather than cost alone,” Bandta further added.

In contrast, Amit Jena, head of AI at IT consulting firm Kanerika, pointed out that a cloud-infrastructure-style pricing war was unlikely: “Frontier models are capital-intensive; margins are already thin. Vendors can’t sustain aggressive repricing without sacrificing quality.”

Rather, Jena sees Meta increasing prices soon after launch: “History suggests what happens next — aggressive entry pricing, then repricing once market share solidifies. See Meta’s advertising platform and cloud pricing evolution across the industry. If that pattern repeats, pricing could rise 30–50% in 18–24 months.”

For now, Meta is offering developers $20 in free API credits to experiment with Muse Spark 1.1.

The article originally appeared on InfoWorld.

Meta has unveiled Muse Spark 1.1, saying the frontier AI model rivals leading LLMs on coding, computer use, and agentic AI benchmarks while undercutting OpenAI and Anthropic on API pricing, potentially lowering the cost of deploying AI agents in enterprises.

Meta unveiled Muse Spark 1.1 on Thursday, pairing frontier-model performance with aggressive pricing in a move that analysts say could pressure rivals such as OpenAI and Anthropic and reshape enterprise AI procurement decisions.

Meta is betting that lower inference costs can help it gain ground in the enterprise AI market with the launch of Muse Spark 1.1, a frontier model that rivals top competitors on key benchmarks while costing a fraction as much to deploy.

The latest model, which was teased last week, matched or was competitive with leading models, such as Claude Opus 4.8, Gemini 3.1 Pro, and GPT 5.5, across several agentic AI, coding, and computer-use benchmarks, including SWE-bench Verified, Terminal-bench, BrowseComp, SpreadsheetBench, and OSWorld, Meta wrote in a blog post.

Muse Spark 1.1, which is currently in public preview and available via the Meta Model API, will cost $1.25 per million input tokens and $4.25 per million output tokens, the company noted.

By comparison, OpenAI charges $5 per million input tokens and $30 per million output tokens for GPT-5.5, while Anthropic charges $5 and $25, respectively, for Claude Opus 4.8. Google’s Gemini 3.1 Pro, on the other hand, is priced at $2 per million input tokens and $12 per million output tokens.

Lower prices may open doors, not close deals

That sheer difference in API pricing, according to Pareekh Jain, principal analyst at Pareekh Consulting, is enough to attract CIOs’ attention, at least for pilots, at a time when enterprises are trying to scale agentic deployments: “Pricing matters because inference costs increase rapidly when thousands of agents are working continuously.”

“Output tokens are often the largest model expense in coding, customer service, and process automation agents. Muse Spark’s output price is about 86% below GPT-5.5 and more than 90% below Claude Opus 4.8,” Jain said.

However, Muskan Bandta, cloud associate at FinOps services providing firm ZopDev, pointed out that the price is not a guarantee of adoption, despite the fact that most enterprises are likely to deploy the Muse Spark 1.1 for new projects.

“Cost becomes the primary differentiator only once the model is judged good enough. Developers don’t pick the cheapest model; they pick the cheapest model that clears their quality bar. So, price is the reason people show up, capability is the reason they stay,” Bandta said.

Similarly, CIOs are also likely to put more emphasis on the model’s security, data protection, uptime, audit trails, regional availability, support, and predictable behavior, rather than just the price, Jain said.

That distinction, according to Bandta, reflects a familiar pattern in enterprise technology buying: “This is the same lesson we saw in the cloud, where the cheapest provider on paper rarely won the biggest enterprise share. Price is one input in the total cost of ownership that includes risk, control, and switching cost, not the whole decision.”

Even so, the lower pricing could still shift the balance of power in enterprise procurement, Jain said: “This could help CIOs negotiate larger volume discounts, committed-use agreements, and better pricing from OpenAI, Anthropic, and cloud providers. It also strengthens the case for multi-model procurement rather than depending on one vendor.”

“Companies that do not even adopt Muse Spark can also use its pricing as evidence that frontier-level inference is becoming cheaper,” Jain added.

Meta’s pricing could reshape competition between rivals

Analysts pointed out that Meta’s new model could intensify competition in the frontier model market by forcing rivals to compete on inference economics and model sizes.

“It’s a real shot across the bow, and I’d expect OpenAI and Anthropic to respond on two fronts. Some of it will be price, cheaper tiers, and better cached and batch rates, because Meta has just reset what the market thinks a frontier token should cost,” Bandta said.

“But the incumbents won’t win the race with lower-priced offerings and more flexible pricing models. I expect them to lean harder into the things price can’t buy, governance, security, reliability, and enterprise support, to justify premium pricing,” Bandta added, likening the shift to an “early innings” of a price war that the industry saw with the expansion of cloud.

“The cloud infrastructure price war showed that while prices fell over time, vendors ultimately differentiated themselves through platform capabilities rather than cost alone,” Bandta further added.

In contrast, Amit Jena, head of AI at IT consulting firm Kanerika, pointed out that a cloud-infrastructure-style pricing war was unlikely: “Frontier models are capital-intensive; margins are already thin. Vendors can’t sustain aggressive repricing without sacrificing quality.”

Rather, Jena sees Meta increasing prices soon after launch: “History suggests what happens next — aggressive entry pricing, then repricing once market share solidifies. See Meta’s advertising platform and cloud pricing evolution across the industry. If that pattern repeats, pricing could rise 30–50% in 18–24 months.”

For now, Meta is offering developers $20 in free API credits to experiment with Muse Spark 1.1.

Every few years, some new technology comes along that promises to revolutionize how we do business, and enterprises pile in headfirst without asking how much it’s going to cost. I’ve been watching this movie for 30 years. Cloud computing was the first act. Now it’s generative AI, and the bill is arriving faster than anyone expected.

The latest data shows that many enterprises are seeing their AI token costs run 10 to 20 times higher than initial projections. That’s not a rounding error. That’s a strategic miscalculation that CFOs are starting to notice, and they’re not happy about it.

Here’s the thing: This crisis was entirely predictable. We’ve been through this before with cloud computing, and we learned some hard lessons about what happens when you deploy technology without rigorous cost management. The good news is that enterprises are finally applying those lessons, reaching back to their cloud finops playbooks to wrangle this new breed of spending.

The 50x problem

Let me explain the scale of what’s happening. Goldman Sachs has estimated that AI agents consume roughly 50 times more computing power per task than traditional prompt-based chatbots. That’s a fundamental shift in how resources get consumed. When you multiply that across an enterprise that’s deploying dozens or hundreds of AI agents, the math gets ugly fast.

The token problem compounds because AI costs are inherently variable. Unlike traditional software licensing or infrastructure contracts, you pay per token, and per-token usage can fluctuate wildly based on user behavior, query complexity, and the sheer volume of requests flowing through these systems. This is exactly the same problem we faced with cloud computing. Every time someone spins up a new instance or stores data in the wrong tier, the bill goes up.

Enterprises expected to deploy AI and see costs stabilize. Instead, costs are climbing month after month, often exceeding projections by an order of magnitude. The business case that looked compelling in the conference room is looking considerably less attractive in the finance committee.

Lessons from the cloud playbook

Here’s where it gets interesting. Cloud providers and the managed service providers who work with them have spent the better part of two decades building disciplines around financial operations—finops, if you want to use the buzzword. These are the practices, tools, and organizational structures that make cloud spending visible, controllable, and ultimately justifiable to the business.

Those same disciplines are now being applied to AI token costs, and enterprises with mature finops programs are faring better than those without. The playbook is essentially the same:

• Make spending visible.
• Attribute costs to the right teams.
• Set guardrails and alerts.
• Create feedback loops that encourage efficient behavior.

Companies like Priceline have deployed dashboards that provide executives with real-time visibility into token consumption, with monthly reports delivered directly to the CFO and CTO. Smartsheet has implemented similar approaches, providing department-level dashboards that let managers see exactly how their teams are consuming tokens, with automated alerts when consumption approaches predefined thresholds.

The accountability piece is critical. When developers and business users can see exactly how their AI usage translates to dollars, they tend to make better decisions about which models to use, how to structure prompts, and when to rely on human judgment instead of AI processing.

The show-back revolution

One of the most effective techniques emerging from this crisis is the “show back” approach to AI cost management. Rather than simply reporting costs to individual departments, companies are now attributing AI spending to the teams and individuals responsible for driving that consumption. This creates accountability without the organizational complexity of full chargeback models.

OpenText has reported that implementing show-back and chargeback approaches can reduce token costs by 20% to 30% within a few months. That’s not trivial. If you’re spending $5 million a month on AI tokens, that’s a $1.5 million savings just by making people aware of what they’re spending.

The mechanism is straightforward: When development leaders understand that their team has consumed $200,000 in tokens this month, they start asking questions. Why are we using the most expensive model for that task? What if a smaller model could handle 80% of these queries? Are prompts being repeated unnecessarily? These questions lead to optimization, and optimization leads to savings.

Model smarts

Another lesson from the cloud experience is that the most expensive option is rarely the best option. This sounds obvious, but organizations tend to default to the largest, most capable AI model for every task, regardless of whether that capability is actually required.

The emerging best practice is to match model capability to task requirements. A simple classification task doesn’t need a frontier model. A straightforward text-generation job might be handled perfectly by a smaller, cheaper model running locally or via a less expensive API tier. The efficiency gains from this approach can be substantial.

Some enterprises are going further, adopting older models or open source alternatives for appropriate use cases. Qualcomm, for instance, has invested in running models on its own hardware rather than relying exclusively on cloud-based model providers. This approach requires more technical sophistication but can dramatically reduce per-token costs for high-volume applications.

The real challenge

Here’s what concerns me most about the current situation. Many enterprises deployed AI without putting adequate cost management infrastructure in place up front. They got caught up in the excitement of the technology, the competitive pressure to move fast, and the belief that the benefits would justify whatever the costs turned out to be. That approach worked when AI projects were small-scale experiments. Now that AI is becoming core to business operations, the lack of financial controls is becoming a serious problem. We need to bring the same rigor to AI procurement and deployment that we’ve brought to every other significant technology investment.

The organizations that succeed will treat AI token costs as a managed operational expense rather than an unpredictable variable. That means deploying the same tools and disciplines that have worked for cloud cost management: visibility, accountability, optimization, and continuous improvement.

Cloud providers and the managed service partners who work with them have been doing this for years. They built the tools, developed the best practices, and trained the workforce that can now apply those skills to the AI cost challenge. If your organization is struggling with AI spending, finding partners with deep finops experience might be the fastest path to control.

The good news is that this crisis is solvable. But it requires acknowledging the problem, investing in the right capabilities, and accepting that technology deployment without financial discipline is a path to trouble.

Get smart about your AI spending. The CFO will thank you.

데이터독 코리아는 9일 서울에서 기자간담회를 열고 이 같은 사업 현황과 연례 컨퍼런스 ‘대시(Dash) 2026’에서 공개한 신제품 전략을 소개했다.

엄수창 데이터독 코리아 지사장은 이를 시장 변화의 신호로 해석했다.

엄 지사장은 “연초만 해도 ‘SaaS 아포칼립스’라는 말이 나올 정도로 SaaS 기업들의 미래를 부정적으로 보는 시각이 많았다”며 “하지만 데이터독은 AI와 함께 성장하면서 오히려 큰 미래 비전을 갖게 됐다”고 말했다. 이어 “글로벌 상위 AI 기업 10곳 모두 데이터독을 사용하고 있다는 사실 자체가 시장이 우리의 성장 가능성을 높게 평가하고 있다는 방증”이라고 강조했다.

이 같은 자신감의 배경에는 AI 시대 급증하는 운영 관리 수요가 있다. 과거에는 데브옵스(DevOps)와 SRE(Site Reliability Engineering) 조직이 장애 분석과 인프라 모니터링을 위해 주로 활용했다면, 이제는 AI를 활용해 운영을 자동화하는 기능과 AI 애플리케이션 자체를 관리하는 기능까지 제공하며 AI 시대에 맞춰 사업 영역을 확대하고 있다.

정영석 데이터독 기술총괄은 올해 대시에서 공개한 100여 개의 신기능을 ‘자율 IT 운영(Autonomous Operations)’과 ‘AI 거버넌스’라는 두 가지 축으로 설명했다.

자율 IT 운영 분야에서는 ‘비츠 AI(Bits AI)’가 장애 탐지부터 원인 분석, 해결까지 자동으로 수행한다. 정 총괄은 “장애가 발생하면 비츠 AI가 8가지 안팎의 가설을 세운 뒤 하나씩 검증해 근본 원인을 찾아내고, 코드 수정안까지 PR(Pull Request) 형태로 제안한다”며 “기존에는 엔지니어가 1~2시간 걸리던 분석 및 보고서 작성 작업을 빠르면 5분 이내로 단축할 수 있다”고 설명했다.

또 인프라 자원이 부족하면 슬랙 등을 통해 운영자 승인만 받아 메모리와 CPU를 자동으로 증설하고, 사전에 정의한 가드레일 안에서는 무인 복구도 수행한다. 코드 변경부터 스테이징 배포, 프로덕션 환경에 이르기까지 애플리케이션이 의도대로 동작하는지도 AI가 지속적으로 검증한다.

AI 거버넌스 분야에서는 ▲에이전트 옵저버빌리티(Agent Observability) ▲AI 게이트웨이(AI Gateway) ▲AI 가드(AI Guard) ▲LLM 비용 관리 콘솔 등의 기능 공개했다.

에이전트 옵저버빌리티는 AI 에이전트 내부에서 어떤 LLM과 도구를 사용했고, 토큰과 비용이 얼마나 발생했는지 시각화한다. AI 게이트웨이는 여러 LLM을 통합 관리하고 감사(Audit)를 수행하며, AI 가드는 프롬프트 인젝션과 민감정보 유출을 차단한다.

정 총괄은 “코파일럿, 커서(Cursor), 클로드 등 여러 AI 모델을 함께 사용하는 기업이 늘면서 비용과 보안, 신뢰성을 통제하는 것이 C레벨 경영진의 공통 과제가 됐다”며 “개발자별, 모델별 사용량과 비용을 세분화해 보여주기 때문에 임원들도 최적화 지점을 쉽게 찾을 수 있다”고 말했다.

최근 많은 기업이 멀티 LLM 전략을 채택하는 만큼 이러한 통합 관리 플랫폼의 필요성도 커질 것이라는 설명이다.

CIO 코리아가 AI 기능 추가로 관련 비용이 늘어나는 것 아니냐고 묻자 정 총괄 “데이터독이 제공하는 수백 개의 외부 서비스 연동 기능은 모두 기본 호스트 사용료에 포함돼 있어 AI 기능이 추가됐다고 모니터링 비용이 늘어나는 것은 아니다”며 “다만 로그는 저장량이 늘어나면 비용이 증가하는 구조인데 이는 어느 벤더나 비슷하다”고 답했다.

이어 “AI가 추가됐다고 인프라 모니터링 비용이 올라가는 것은 아니지만 AI SRE처럼 자동 분석 기능을 사용할 경우 토큰(크레딧)이 소모돼 비용이 추가될 수 있다”며 “반면 엔지니어의 업무 시간을 크게 줄일 수 있기 때문에 ROI 측면에서는 충분히 상쇄할 수 있고, UI 대신 MCP(Model Context Protocol)를 활용하면 비용을 낮출 수 있어 국내 여러 대형 고객도 MCP 기반 AI옵스를 구축하고 있다”고 덧붙였다.

AI가 문제 해결책까지 제시하는 것에 대한 고객사의 거부감은 없는지 묻는 질문에는 “잘못 분석할 가능성이 있는 것은 사실이지만 지금까지 고객 반응은 매우 긍정적”이라며 “AI가 잘못 탐지하더라도 사용자가 대화를 통해 추가 분석을 요청하면 계속 수정하면서 근본 원인에 더 가까운 결과를 제시한다”고 설명했다.

이어 “이 경험은 ‘비츠 메모리(Bits Memory)’ 기능에 축적돼 이후 유사한 장애가 발생하면 더욱 정확하게 분석하도록 학습된다”고 말했다.

내부 AI는 자체 모델과 업계 최신 모델을 함께 사용하는 하이브리드 구조다.

정 총괄은 “프론티어 모델과 자체 모델인 ‘토토(Toto)’를 함께 운영하고 있으며 작업 특성에 따라 가장 적합한 모델을 선택해 사용한다”고 밝혔다. 클로드, GPT, 제미나이 등 다양한 외부 최신 모델을 활용하며, AI SRE는 내부적으로 최적 모델이 자동 선택되지만 에이전트 빌더에서는 고객이 MCP와 사용할 모델을 직접 선택할 수 있다. 또한 LLM 옵저버빌리티에서는 환각을 탐지하기 위해 교차 검증용 모델을 별도로 지정하는 기능도 제공한다.

데이터독은 앞으로 옵저버빌리티(Observability), 보안, 핀옵스(FinOps), 비즈니스 인텔리전스(BI)를 하나의 플랫폼에서 통합 제공하는 차별성을 앞세워 국내 시장 공략을 확대하겠다고 밝혔다.
jihyun.lee@foundryco.com

KI-Pipelines zu optimieren, erfordert mehr als nur oberflächliche Hardwareanpassungen. Es gilt, die Art und Weise, wie Modelle Daten verarbeiten, grundlegend zu verändern. Zwar implementieren KI-Engineers oft einfache Effizienzmaßnahmen innerhalb des Training-Loops. Aber um die Trainingskosten permanent zu reduzieren, sind architektonische Änderungen nötig – direkt im neuronalen Netz.

Die folgenden zwölf Optimierungsmaßnahmen auf Modellebene verwandeln Ihre KI-Strategie von einem Brute-Force-Hardware-Ansatz in eine elegante, softwaredefinierte Disziplin – und senken die Stückkosten Ihrer KI-Pipeline drastisch.

1. Pretraining einsparen

Ein Foundation-Modell von Grund auf neu zu trainieren ist für Standard Enterprise-Applikationen selten nötig und verbietet sich mit Blick auf die dafür nötige Rechenleistung. Statt dafür Millionen zu verschwenden, sollten Engineering-Teams lieber öffentlich verfügbare Open-Weight-Modelle nutzen.

Dieser grundlegende Transfer-Learning-Ansatz ist der unverzichtbare erste Schritt, wenn es darum geht, interne Chatbots oder domänenspezifische Klassifikatoren zu entwickeln. Indem bestehende neuronale Architekturen zum Einsatz kommen, lassen sich die enormen Kosten (auch für Energie), die mit den initialen Pretraining-Phasen verbunden sind, umgehen.

2. Parametereffizient feinabstimmen

Selbst das standardmäßige Feintuning von umfassenden Sprachmodellen erforderte immense Mengen an VRAM, um die States von Optimizern und Gradienten zu speichern. Um dieses Hardware-Bottleneck aufzulösen, sollten Engineers PEFT-Techniken wie LoRA implementieren.

Die Technik reduziert den Memory Overhead drastisch, indem sie dafür sorgt, dass 99 Prozent der vortrainierten Weights „eingefroren“ und kleine, trainier- und adaptierbare Layer injiziert werden. Dieser mathematische Shortcut ist ideal geeignet, um hochgradig anpassbare GenAI-Funktionen umzusetzen – und erlaubt die Feinabstimmung von Milliarden von Parametern mit einer einzigen (Consumer-)GPU.

python
from peft import LoraConfig, get_peft_model

config = LoraConfig(r=8, lora_alpha=32, target_modules=["q_proj", "v_proj"])
efficient_model = get_peft_model(base_model, config)

3. Warmstart-Layer einziehen

Falls Sie spezifische Netzwerkkomponenten von Grund auf neu trainieren müssen, stellt der Import vortrainierter Embeddings sicher, dass nur die verbleibenden Layer erhöhten Rechenaufwand verursachen.

Dieser „Warmstart“-Ansatz reduziert den Rechenaufwand in Frühphasen der KI-Entwicklung erheblich, weil das Modell so grundlegende, universelle Datenrepräsentationen nicht erst neu erlernen muss. Besonders empfehlenswert ist dieser für Spezialdomänen.

python
# PyTorch warm-start example
model.embedding_layer.weight.data.copy_(pretrained_medical_embeddings)
model.embedding_layer.requires_grad = False

4. Gradient Checkpointing anwenden

Memory-Engpässe sind der wesentliche Grund dafür, dass Entwickler gezwungen sind, teure, VRAM-intensive Cloud-Instanzen zu mieten. Gradient Checkpointing (PDF) spart Speicherplatz ein, indem bestimmte Forward Activations während der Backpropagation neu berechnet werden – anstatt sie alle zu speichern.

Entwicklern ist zu empfehlen, diese Technik einzusetzen, wenn sie mit anhaltenden „Out of Memory“-Fehlern konfrontiert sind. Denn Gradient Checkpointing ermöglicht es, zehnmal größere Netzwerke auf derselben GPU unterzubringen – bei einem Mehr an Rechenaufwand von circa 20 Prozent.

python
# Enable in Hugging Face / PyTorch
model.gradient_checkpointing_enable()

5. Compiler-Fusion aktivieren

Moderne Deep-Learning-Frameworks leiden regelmäßig unter Engpässen mit Blick auf die Speicherbandbreite, da ständig Daten über die Hardware gelesen und geschrieben werden. Durch Compiler, die wie XLA oder PyTorch 2.0 auf Graph-Ebene operieren, lässt sich eine Vielzahl von Prozessen in einem einzelnen GPU-Kernel fusionieren.

Diese architektonische Optimierung führt dazu, dass Durchsatz und Ausführungsgeschwindigkeit massiv gesteigert werden. Parallel sind allerdings keine manuellen Änderungen am Code notwendig. Um die Hardwareauslastung zu maximieren, ist es Entwickler-Teams zu empfehlen, die Compiler-Fusion standardmäßig bei sämtlichen Trainings-Sessions in der Produktion zu aktivieren.

python
import torch

# PyTorch 2.0 compiler fusion
optimized_model = torch.compile(model)

6. Pruning und Quantisierung einsetzen

Ein umfangreiches, vollpräzises 16-Bit-Neural-Network in der Produktion bereitzustellen, erfordert ebenfalls oft teure Cloud-Instanzen, was die Gewinnmarge einer Applikation zunichtemachen kann. Durch algorithmisches Pruning werden mathematisch redundante Weights entfernt.

Eine Quantisierung des Modells sorgt hingegen dafür, dass die verbleibenden Parameter von 16-Bit-Gleitkommazahlen auf 8-Bit- oder 4-Bit-Ganzzahlen komprimiert werden. Das ermöglicht es, das KI-Modell auf deutlich kostengünstigeren GPUs mit geringerem Speicherbedarf auszuführen – ohne dass die Qualität der Konversationen darunter leidet. Diese physikalische Reduktion ist entscheidend dafür, Traffic-intensive Anwendungen kosteneffizient skalieren zu können. Davon abgesehen senkt es jedoch auch die CO²-Kosten, die ein API-Call verursacht, wenn Tausende von Usern parallel bedient werden.

python
import torch
import torch.nn.utils.prune as prune

# 1. Prune 20% of the lowest-magnitude weights in a layer
prune.l1_unstructured(model.fc, name="weight", amount=0.2)

# 2. Dynamic Quantization (Compress Float32 to Int8)
quantized_model = torch.ao.quantization.quantize_dynamic(
    model, {torch.nn.Linear}, dtype=torch.qint8
)

7. Curriculum Learning verwenden

Ein untrainiertes neuronales Netzwerk mit hochkomplexen und gleichzeitig verrauschten Datensätzen zu füttern, zwingt den Optimizer teure Extra-Rechenschleifen zu drehen, um chaotische Gradienten abzubilden. Dieses Problem lässt sich mit Curriculum Learning (auch Lehrplanlernen) lösen: Dabei wird die Daten-Pipeline so strukturiert, dass zunächst klare, leicht klassifizierbare Beispiele eingeführt werden – bevor der schrittweise Übergang auf hochpräzise Anomalien erfolgt.

Geht es etwa darum, ein Vision-Modell für autonomes Fahren zu trainieren, sollten die Entwickler diesem zunächst klare Tageslichtbilder von Autobahnen zuführen, bevor sie Rechenleistung für komplexe Nachtaufnahmen verschneiter Stadtkreuzungen in Städten aufwenden. Dieser schrittweise Ansatz ermöglicht dem Netzwerk, zentrale mathematische Merkmale ressourcenschonend abzubilden. Dadurch wird die Konvergenz deutlich schnell und mit geringerem Hardware-Aufwand erreicht.

8. Wissen destillieren

Ein massives KI-Modells mit 70 Milliarden Parametern für simple, repetitive Tasks zu nutzen, kommt einer gravierenden Fehlallokation von Rechenressourcen gleich. Dieses Problem lässt sich mithilfe von Wissensdestillation lösen: Dabei lernt ein hocheffizientes, schlankes „Student“-Modell, die Reasoning-Ketten eines großen „Teacher“-Modells exakt nachzuahmen.

Stellen Sie sich ein E-Commerce-Unternehmen vor, das Produktempfehlungen in Echtzeit direkt auf dem Smartphone eines Nutzers ausführen muss, wo Akku und Speicher streng limitiert sind. Dank Knowledge Distillation kann dieses winzige Mobile-Modell mit der Genauigkeit einer massiven, Cloud-basierten Architektur arbeiten. Das senkt die Inferenzkosten dauerhaft und kann Ihnen außerdem ersparen, in die „AI Accuracy Trap“ zu tappen.

9. Suchmethoden optimieren

Herkömmliche Grid-Search-Algorithmen fressen regelmäßig große Teil des Cloud-Budgets, weil sie blindlings Netzwerkkonfigurationen testen und ausführen, die von vornherein zum Scheitern verurteilt sind. Intelligentere Hyperparameter-Suchmethoden wie die Bayes’sche Optimierung und Hyperband können an dieser Stelle als finanzielle Wächter fungieren: Sie sagen unzureichende Versuche mathematisch vorher und sortieren diese direkt aus.

Optimiert eine Bank beispielsweise ein KI-Modell zur Betrugserkennung, kann Hyperband Konfigurationen aufspüren, die nicht akkurat sind – und lenkt die gesamte Rechenleistung ausschließlich auf die vielversprechendsten Setups um. Um die Kosten weiter zu reduzieren, lässt sich zudem auch das RES-Cost-Aware-Retraining-Framework integrieren.

10. Parallelstrategien fahren

Nicht sachgemäß konfigurierte Cluster führen ebenfalls zu massiven Netzwerk-Bottlenecks. Wenn Sie ein Modell mittlerer Größe auf zu viele GPUs aufteilen (Modellparallelität), verbringen die Prozessoren mehr Zeit damit, auf die Datenübertragung zu warten, als damit, tatsächlich Berechnungen durchzuführen.

Umgekehrt ist es bei der Verarbeitung großer Datensätze hocheffizient, das gesamte Modell über mehrere Knoten (Datenparallelität) zu replizieren – vorausgesetzt, die Batch-Größen sind korrekt abgestimmt. Ein FinOps-Team in der Praxis muss diese Parallelstrategien dynamisch an die jeweilige Architektur anpassen und dabei sicherstellen, dass die GPUs nicht in den Idle-Status verfallen, während das Netzwerk aufholt.

11. Asynchron evaluieren

Standardmäßige Trainings-Pipelines sorgen ständig dafür, dass das primäre (und teure) GPU-Cluster eine Pause einlegen muss. Einfach nur, um routinemäßige Validierungsprüfungen der Modellfortschritte durchzuführen. Anders ausgedrückt: Es ist eine katastrophale Geldverschwendung.

Indem Engineering-Teams asynchrone Evaluierung implementieren, lassen sich die Validierungsprüfungen auf eine separate, wesentlich kostengünstigere CPU- oder Low-Tier-GPU-Instanz auslagern. Die primären, kostenintensiven GPUs möglichst voll auszulasten, ist eine verpflichtende architektonische Trennung. Diese trägt dazu bei, die versteckten Betriebskosten abzumildern, die mit der KI-Governance einhergehen. 

12. Daten kuratieren

Riesige Datensätze blind zu verarbeiten, sorgt ebenfalls dafür, dass teure Compute-Zeit verschwendet wird – in diesem Fall für redundante Informationen von minderer Qualität.

Wenn ein visuelles KI-Modell bereits zehntausend identische Fotos eines Standard-Stoppschilds erfasst hat, liefert es keinerlei Mehrwert, noch einmal ein paar mehr nachzulegen. Algorithmisches Sampling zu nutzen, um informationsreiche Subsets zu kuratieren, resultiert in identischer Modell-Performance – zu einem Bruchteil der Hardwarekosten. (fm)

Dieser Beitrag wurde im Rahmen des englischsprachigen Expert Contributor Network von Foundry veröffentlicht. Alle Infos zum deutschsprachigen Experten-Netzwerk finden Sie hier.

AI promised to make software development faster, but for many enterprises, it has also created a new management challenge: developers increasingly rely on a mix of coding assistants, AI agents, and models that operate in isolation, making it harder for engineering leaders to govern usage, share knowledge, and control costs.

JetBrains has sought to address these challenges with a new suite of tools and capabilities named JetBrains AI for Teams and Organizations that supports nearly all coding tools, their respective CLIs, and most IDEs, such as Claude, Codex, Gemini, Junie, IntelliJ, Pycharm, and Rider, with support for VS Code to be added soon.

The suite, which consists of capabilities like team automations and cloud agents, JetBrains Context, JetBrains Central, and JetBrains Central CLI, will allow enterprises to manage AI-assisted software development from a single control layer while allowing developers to continue using their preferred coding assistants and IDEs, Oleg Koverznev, head of agent systems at JetBrains, wrote in a blog post.

While team automations and cloud agents are intended to let AI agents run long-running engineering tasks in managed cloud environments and trigger workflows based on repository events or schedules, JetBrains Context is designed to provide a shared understanding of project code, documentation, and development activity across tools, Koverznev added.

Complementing those collaboration capabilities, JetBrains Central serves as the administrative layer for governance, access control, and usage management, with the Central CLI extending those controls to the command-line and automation workflows, Kovernznev further added.

Tool sprawl to reduced operational friction

Fragmentation of AI-assisted coding tools and development environments adds complexity for enterprises and their leaders.

“Fragmentation of AI coding tools is an evolving problem for enterprises. A year ago, the conversation was whether to even allow an AI assistant. Now a single team is running Copilot, Claude Code, Cursor, and a few homegrown agents at once,” said Muskan Bandta, cloud associate at FinOps services providing firm ZopDev.

“The pain leaders raise with us isn’t the tools themselves. It’s that nobody can answer three questions: who is using what, what is it costing us, and is it actually safe? Fragmentation became a governance and cost problem the moment agents started touching real codebases and running up real bills,” Bandta added.

These governance and cost issues are increasing demand for suites, such as JetBrains AI for Teams and Organizations, that can coordinate AI-assisted software development across teams.

For development teams specifically, such suites with a centralized context layer can reduce operational friction, according to Nitish Tyagi, senior principal analyst at Gartner.

“Rather than teams manually configuring multiple AI coding tools, maintaining prompts, or repeatedly supplying context, a centralized context layer enables agents to work with a more consistent understanding of the organization’s codebase, standards, documentation, and workflows,” Tyagi said.

“Over time, this can help accelerate parts of the software development lifecycle by reducing time spent searching for information, understanding legacy code, onboarding developers, and reworking outputs that lack the necessary business context. The primary value is not necessarily that agents write more code, but that they produce more relevant and organization-aware outputs,” Tyagi added.

More so because, a shared context layer for AI agents primarily helps development teams by reducing knowledge silos, Tyagi further added.

Governance and cost management as benefits

The benefits of the suite, according to Bandta, transcend developer productivity and should help CIOs with governance and cost management.

“The suite will enable engineering leaders to gain greater control over what information can be accessed by different agents and teams, helping reduce security and compliance risks. For example, enterprises can prevent agents from directly accessing sensitive repositories or business-critical data,” echoed Tyagi.

 “Secondly, as the platform is continuously refining and managing context, agents get optimized and more relevant context to deliver higher quality output at lower cost,” Tyagi added.

The launch of JetBrains’ new suite, analysts pointed out, also reflects a broader shift in the software development tools market, where vendors are evolving from integrated development environments.

“This launch signals the evolution of the IDE into an ‘agentic development environment’. A platform where developers increasingly orchestrate fleets of AI agents instead of writing every line of code themselves,” Bandta said.

“The segment is splitting into agents that do the work and platforms that govern them, and the platform layer is where enterprise budgets will concentrate,” Bandta noted, adding that she expects rival vendors, including Microsoft, to pursue similar strategies.

The new capabilities, according to JetBrains, will be rolled out gradually to business customers throughout July and August.

Building an agent in an afternoon is now within reach of almost anyone in the enterprise with a credit card. The tools are accessible, the deployments are easy. The hard part is delivering the intended results.

Gartner predicts that more than 40% of agentic AI projects will be canceled by 2027, and the EU AI Act Article 14 requirements for human oversight for high-risk AI systems take effect on August 2, 2026. The deciding factor for whether agentic AI reaches production isn’t the model, the framework, or the use case. It’s the infrastructure beneath the agent: the part the people building agents have never had to think about.

Organizations are racing to deploy agentic AI to stay competitive, which means pressure-testing is often overlooked. Every agent project should be scrutinized by three executives asking three different sets of questions. The CISO asks whether we are exposed. The CFO asks whether we are overspending. The chief AI officer asks whether we are getting value.

As a product leader focused on AI governance, I see this pattern across customer environments. Three architecture layers answer those three questions: identity, observability, and cost optimization. I’ll walk through each of the layers and provide a four-question diagnostic for the next production push.

Why AI pilots stall

An agent is not a faster chatbot. It chains dozens of steps, calls external tools, retains state across sessions, and triggers real-world actions. Most inherit the credentials of whoever deployed them. They operate at machine speed without context for the consequences of each step.

The mismatch is not a competence gap on the human side. It is a time-horizon gap. An engineer reasons about a database change over hours. An agent triggers a hundred of them before anyone reviews the first. Traditional audit logging captures request and response. That does not catch this pattern.

When something breaks, the cost is rarely the incident. It is the months of stalled deployment that follow. The risk committee freezes pilots. The productivity gains the program was supposed to deliver never materialize. Finance still gets the API bill. Three architecture layers decide whether a deployment survives that pattern. Each one is the answer to a question the people building agents never had to ask.

Layer 1: Identity for non-human actors

Start with identity. The default failure looks routine: a product manager with broad API access spawns an agent that inherits the full scope of those credentials and runs at machine speed across systems no one inventoried.

The scale is bigger than most teams realize. Industry IAM research puts non-human identities at more than 100 to 1 versus human accounts, with some 2026 surveys putting the ratio as high as 144 to 1. A May 2026 Identity Gap Report found two-thirds are unseen and unmanaged.

Agents are moving from human identities with their “owners”’ permissions to first-class principals. They are purpose-bound, cryptographically attested, and scoped to one task at a time. Google’s Agent Identity, built on SPIFFE, is one early example. The production pattern has three properties. Credentials are issued per agent task. Token lifetime is measured in minutes to hours, not weeks. Scope is narrowed to the specific tools and data classes the task requires, and the credential revokes automatically on task completion.

If a single static credential is good for a week and 50 different tasks, you are not running agentic AI. You are running a service account with extra steps.

Layer 2: Observability that serves all three executives

Identity controls what an agent can do. Observability shows what it’s actually doing. One instrumentation layer, three views.

First, the security view. Traditional logging captures request and response, which assumes one human action per logged event. An agent’s unit of work is a chain. Pick a tool, call it, read the result, decide the next step. Twenty steps, some of them writing to production. Instrument every step as a durable audit object, independently queryable. Understand which tool was invoked, what data was accessed, what policy applied, and what the agent reasoned to justify the next step. That’s what Article 14 oversight requires for production.

Second, the business-outcomes view. Audit objects answer the CISO. The chief AI officer asks a different question. Is the agent accomplishing what we deployed it for, or burning compute on a tangent? An agent can run 200 tool calls, generate clean audit logs, and produce nothing. It might be looping on a sub-goal that drifted three steps back. Observe each step against the declared business purpose: on-task ratio, sub-goal coherence, progress markers. Project management telemetry for a non-human worker.

Third, the cost view. The same per-step instrumentation produces cost telemetry: token count per step, model per call, context size per turn, downstream tool-call costs. Without that attribution, the next section’s optimizations are blind.

A busy agent and a productive agent look identical in the security log. They look identical on the bill too. The difference shows up only when all three views run from the same instrumentation.

Layer 3: Cost optimization

Cost is where the architecture pays back. Gartner’s March 2026 analysis put agentic workloads at five to 30 times the token cost per task of a standard chatbot. The FinOps Foundation’s 2026 State of FinOps report found that 73% of organizations exceeded their original AI budget projections. Three failure modes drive that overrun.

First, using the wrong model. Agents default to the most capable one available. They call a frontier model for tasks a smaller one could handle with identical quality: summarizing a transcript, formatting JSON, classifying a ticket. The RouteLLM paper at ICLR 2025 demonstrated that intelligent routing cuts total LLM inference cost 40% to 80% with no measurable quality loss on routine work. Move model selection from a per-developer choice to a per-policy layer.

Second, running in loops. Agents can spend without limit if no one is watching. A widely-cited 2026 incident saw a LangChain multi-agent system run an infinite loop for 11 days and burn $47,000 in API charges. Per-session token ceilings, loop-detection circuit breakers that flag tool calls highly similar to prior calls, and hard daily caps stop this before it generates the bill. In our deployments, a three-tier cost structure catches the bulk of runaway patterns: a $50 daily soft alert, a $100 daily hard cutoff forcing routing to cheaper models, and a $1,000 monthly ceiling requiring manager approval.

Third, re-paying for the same context on every step. Every step re-sends the accumulated system prompt and conversation history. By step 20 the agent has paid for that context 20 times. Vantage’s 2026 analysis of agentic coding sessions found re-sent context accounts for roughly 62% of the average agent’s bill, the biggest single optimization target in agentic workloads. Three patterns help: anchored summarization at phase boundaries, sliding context windows, and provider-native prompt caching at the gateway. Most agents skip caching entirely, though Anthropic prices cached input at roughly 10% of base, Gemini at 10% to 25%, and OpenAI at 50%.

Governing agent cost means seeing every call, every model, every token attributed to the agent and the business purpose. Then act on it. Token counts without business attribution tell you how many gallons of gas you burned, not where you drove.

The deployment velocity payoff

The three layers serve the three executive questions. Identity gates what the agent can do. Observability shows what it is doing. Cost optimization controls what it spends.

The honest counterargument is that governance always slows deployment. That is true when governance is bolted on as approval gates layered over an agent that wasn’t built with observability or per-task identity. It is false when governance is built into the architecture from day one. Teams that experience governance as a brake installed the brake without the steering wheel.

Governance built right still costs something. Per-task credentials add work on every tool call. Observability infrastructure adds compute. The question is whether that cost beats the alternative.

The layers compound. Identity without observability is theoretical. Observability without cost control is descriptive. Without identity at the bottom, cost control becomes caps without context, forever reactive. All three together produce a governance review that runs in weeks, not quarters, because the data each executive needs already exists. In our experience, organizations with that infrastructure can deploy six workflows to production in the time competitors complete one governance review. The real ROI of agentic AI is not how much faster a single workflow runs. In practice, it’s how many workflows your team can defensibly put into production in a year.

Before the next pilot

Here are four questions to run against any agent your team is about to push to production:

1. Identity. For each agent in production, can you point to the per-task credentials it uses today, and the maximum scope of any single token?
2. Observability. For any agent session, can you produce three views from the same instrumentation: the audit object per step, the on-task ratio versus tangents, and the per-step cost broken down by model and context size?
3. Cost optimization. Does your platform automatically route by model, cap runaway loops, and avoid re-sending the same context every step?
4. Velocity. How long does it take a new agent workflow to move from approved pilot to production in your environment today?

If the answer is months, the architecture above is the gap. Gartner’s 40% stat is about your next pilot.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

The first time I used Kubernetes in an enterprise setting, I understood the hype. It gives every team the same way to package, deploy and run their apps. No more custom scripts or unique deployment hacks, just one control plane to rule them all. And really, that’s why it’s so popular with big companies: Kubernetes is an open-source system for automating deployment, scaling and management of containerized applications. It says so right on the box, and that’s what people want. But here’s the truth: Kubernetes doesn’t erase operational headaches. It just moves them around.

When your Kubernetes install is small, it feels like rocket fuel for engineers. At enterprise scale, though, suddenly it’s about governance, not just engineering. The game is no longer “Can we get this container running?” It’s “How do hundreds of engineers roll out their stuff safely, consistently, securely and without breaking the bank or burning out the platform team?”

This is where the fun really starts.

YAML isn’t the enemy

Folks new to Kubernetes obsesses over manifests, Helm charts, namespaces, ingress rules, deployments, all that stuff. But they’re not the hardest part once you start scaling. The real beast is standardization.

Every big company I’ve seen ends up with teams going their own way. One group writes beautiful deployment templates. Someone else copies and pastes from a two-year-old manifest. Some folks set resource requirements properly. Others skip them entirely. One team sticks to a strong naming convention, and someone else throws together random namespaces and service accounts that make sense only to them. Individually, this more or less works. At scale, when the whole platform has to operate like one system, it’s a mess.

That’s why I’ll say it: you don’t just need a Kubernetes cluster. You need a paved road. This would involve ensuring that there are approved templates, good deployment patterns, observability, security controls as defaults, good issue escalation processes and accountability.

There is no need for developers to be Kubernetes experts just to release their services. The best enterprise Kubernetes setups work like real products. They let application teams self-serve but never let anyone veer off road without good reason.

RBAC: necessary, but never enough

Security is paramount. Kubernetes supports role-based access control (RBAC), so on paper you can control who does what. In practice, in a big company, RBAC gets confusing fast.

The issue isn’t that engineers ignore security. It’s that permissions grow over time. You need a quick fix during an incident, so you give a service account more access. Maybe a team needs cluster-wide rights for a migration. That “just for now” permission sticks around because no one cleans it up. Month by month, the gap widens between what a workload should do and what it’s actually allowed to do. The only thing that works long-term: treat RBAC as a living thing, not a one-time checklist. Review it. Test it. Stick to least privilege. Service accounts get only what they need. Cluster-admin rights? Rare. Expiring exceptions. Set permissions as code so changes aren’t invisible.

Same story with workload security. Kubernetes brings you Pod Security Standards. There is baseline, restricted and privileged profiles, so everyone speaks the same language. But simply setting a standard isn’t enough. We’d also need things like admission controls, image scanning, runtime monitoring and audit trails.

Honestly, the NSA/CISA Kubernetes Hardening Guidance is still gold. Scan containers and pods. Run workloads as locked down as possible. Use strong authentication. Separate networks. Set up solid logging. These ideas sound obvious until you see what happens when your organization scales without good ops.

Network policies: where “it should work” meets reality

Kubernetes networking can trip up even the best teams. Engineers often think different namespaces mean automatic isolation between apps. Not true.

Kubernetes network policies decide which pods can talk to which, but the policies only matter if your networking plugin actually enforces them. I’ve seen a lot of teams write network controls that look great in YAML but don’t work, because the underlying network just ignores them. Security validation beats documentation every time. If two namespaces shouldn’t talk, test it. If a workload only needs access to a specific backend, check it. If only specific ingress is allowed, make sure nothing else gets through.

At scale, your Kubernetes security has to prove itself. “We have a policy” means nothing unless the platform can show the policy actually works.

Resource management becomes all about money

One of the biggest challenge is resource allocation. Kubernetes lets you set CPU and memory limits, and sure, there are official docs. But getting these numbers right is tough.

Set them too low, and your workload might get throttled or evicted under load. Set them too high, and you’re paying for unused infrastructure. That barely registers on a small cluster, but when you’re running thousands of pods? That’s cloud bills gone wild.

This is where Kubernetes ops and FinOps meet. Platform teams have to know who’s burning through which resources, what’s over-provisioned or flying blind, and where the real money goes. ResourceQuota helps keep things in check, but quotas alone don’t hold people accountable.

The culture shift is moving from “the cluster has spare capacity” to “every service has an owner, a cost profile and a plan for staying lean.” Teams should understand their infrastructure bill. Platform teams need dashboards that point out waste. Engineering leaders need to care about efficiency, not just hear from finance when things go off the rails.

Autoscaling isn’t a magic trick

The Horizontal Pod Autoscaler is handy. It adjusts your workloads automatically to match demand. But don’t overestimate it. Most real-world services don’t scale simply by CPU or memory. Sometimes a service hits latency limits before CPU usage spikes. Workers chewing through queues? You care more about backlog size. Machine learning? Maybe it’s all about GPU use or loading time. Customer-facing apps? You want to be scaled up before traffic hits, not scramble after users start complaining.

So autoscaling isn’t just a box you check. It’s a feedback loop, and it only works if you use the right signals. Sometimes CPU is enough. Sometimes you need to scale on queue length, request rate, latency or something totally custom.

Then there’s node autoscaling to provision infrastructure in response to demand. On paper, it just works. In real life, it runs into startup delays, availability zones, quotas, cloud provider quirks and pod disruption budgets. Scale pods faster than nodes? Users still see delays.

Test autoscaling like you test your app. Load-test it, break it, see what happens after an incident. Otherwise, you’ll find the limits when it hurts most.

Observability doesn’t matter unless it answers questions

Kubernetes has mountains of data. Things like  logs, metrics, traces, events, audits, deployment history, container restarts, control plane noise, you name it. The real challenge isn’t collecting info, but actually it’s making sense of it. The CNCF and others have best practices for logging and telemetry, like centralizing logs and not leaking secrets. Those matter, but at the end of the day, engineers need answers, not just data. When something breaks, no one’s asking, “Is Kubernetes alive?” They want to know what changed. Did something roll out? Did a pod crash? Did autoscaling fire too late? Was a node unhealthy, a secret rotated, a network policy too tight, a downstream DB choking?

Observability should line up with real operational questions and not just ticking boxes for logs, or metrics. Dashboards need to match service ownership. Alerts need to mean something to end users. Telemetry should connect to deployments and incidents. Measure how quickly engineers spot the root cause, not just that you have the data somewhere.

CNCF talks about newer models of unified telemetry and proactive troubleshooting for a reason. All the dashboards in the world don’t help when your team has to play detective during an outage.

Upgrades: Don’t wing it

Kubernetes upgrades catch people out. The CNCF Maturity Model says: Kubernetes drops three big releases a year, so maintenance is part of life—not a once-in-a-blue-moon project.

Upgrading at enterprise scale can involve everything: workloads, admission controllers, CI/CD, service mesh, ingress, storage drivers, monitoring, security, custom controllers. Version skew policies keep you between the lines, but that’s just the beginning. The real question is: can you test your whole stack?

Good upgrade programs need a repeatable process, staging environments that actually look like production, and clear communication so teams know what to expect. The worst upgrade process is the one that relies on heroes to pull it off at the last second. A strong platform turns upgrades into routine.

Reliability: Kubernetes helps, but it doesn’t guarantee it

Yes, Kubernetes restarts crashed containers, reschedules pods and does rolling deployments. But it doesn’t make a bad app reliable.

A poorly coded app will fail on Kubernetes just like anywhere else. Bad readiness or liveness probes? Your app gets traffic too soon. No graceful shutdown? Requests drop during deploy. Forgot pod disruption budgets? The app goes down during node maintenance. A flaky dependency? It will cascade through your services even if all your pods look healthy.

The mature approach is setting service-level objectives and making reliability a product of both platform and engineering. Cluster health isn’t user experience. That green status page can hide a lot of pain.

The platform team is a product team

Here’s the biggest lesson I’ve picked up is that running Kubernetes at enterprise scale isn’t really about the tech. One cluster? Maybe one expert can handle that. But for a full enterprise platform, you need a product mindset. The platform team serves customers such as engineers, security, compliance, finance and business. Everyone wants something a bit different.

Developers want speed and reliability. Security wants oversight. Finance wants transparency. Compliance wants proof. Ops wants predictability. The business wants all of those.

The platform team has to pull those threads together with APIs, docs, dashboards, paved roads, support and feedback. That also means saying “no” to the unique snowflake patterns that create chaos later. Kubernetes is powerful. But it doesn’t replace organizational discipline. That’s still on the shoulders of engineering leaders. The real challenge at enterprise scale isn’t memorizing every API object. It’s building a system where any team can ship safely without needing to be Kubernetes experts themselves.

When you reach that point, Kubernetes stops being just a cluster. It becomes your platform.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Conocido sobre todo por sus servicios como “boutique de inversión”, el banco Singular Bank, nacido en el año 2020 gracias al impulso del exconsejero delegado del Banco Santander Javier Marín Romano, después de adquirir y transformar la estructura del antiguo banco digital Self Bank, es en la actualidad una entidad con más de 400 profesionales, 17 oficinas en España y más de 180 banqueros y agentes financieros que gestionan casi 18.000 millones de euros de patrimonio de clientes.

La compañía financiera es noticia estos días por un sonado cambio de propietario: el grupo inversor estadounidense Warburg Pincus, que poseía más del 93% de las acciones, ha vendido su participación a un grupo de inversores nacionales e internacionales liderados por ING, que se convierte ahora en el principal dueño de la entidad, con 40%, mientras que el resto se diversifica entre ‘family offices’ españoles (21,5%), el propio equipo directivo y los empleados del banco (15,5%), la firma española de inversión ProA Capital (15%) y la financiera mexicana Actinver (8%). Un movimiento que, sin embargo, no afectará a la operativa de Singular Bank, que seguirá funcionando como una entidad independiente dentro del mercado español de banca privada y con una oferta de productos complementaria a la de su nuevo dueño mayoritario, ING, como confirma a CIO ESPAÑA Rubén Andrés Priego, director general de Tecnología y Operaciones de Singular Bank y miembro del equipo directivo, entrevistado por esta cabecera unos días antes de que se hiciera pública esta información. La charla gira, no obstante, en torno a otro asunto: el intenso viaje digital experimentado por el banco, y los retos y las oportunidades que se abren a la organización en un futuro próximo.

El directivo, un ejecutivo experimentado en el mundo de la banca minorista y privada y en consultoría financiera (desempeñó puestos de responsabilidad en Banco de España, Banco Popular, BBVA, Banca March y EVO Banco) aterrizó en Singular Bank en enero de 2025. En este periodo, explica, ha inyectado las últimas innovaciones de la inteligencia artificial al modelo “híbrido” con el que contaba la entidad, que combina “la excelencia digital y en automatización con una labor intrínsecamente humana”. Pero empecemos por el principio.

La IA da una vuelta de tuerca a la transformación de Singular Bank

“Singular Bank es un banco con una historia relativamente corta, de unos siete años”, rememora el CIO durante la entrevista, subrayando que, aunque la entidad nació como un banco orientado a la banca privada, a través de Self Bank dispone de una plataforma bancaria 100% digital que permite a los clientes gestionar sus inversiones y “tomar sus propias decisiones financieras”. Al aterrizar en la corporación, hace más de un año y medio, y después de mantener, dice, casi 70 reuniones con el consejo de administración, el comité de dirección y empleados de diferentes áreas del banco, el directivo vio la necesidad de “llevar a cabo un plan de transformación que no solo pasaba por modificar la plataforma tecnológica que había y que mantenía la cuenta de resultados, así como todos los canales, la plataforma de inversión, etc. sino afrontar una segunda gran ola: el uso de la inteligencia artificial en la compañía”.

La estrategia de Singular Bank en torno a la inteligencia artificial se articula en tres grandes líneas de actuación, como relata Rubén Andrés Priego. La primera consiste en impulsar el uso de la IA en el trabajo diario de los empleados. Para ello, la empresa selló un acuerdo con OpenAI, en marzo de 2025, con el fin de distribuir 50 licencias de ChatGPT entre los 400 profesionales de la entidad. La segunda línea se centra en la aplicación de la IA al ámbito de la ingeniería, bajo un enfoque de context engineering (ingeniería de contexto), con el que están transformando su modelo de desarrollo tecnológico. Y el tercer eje pasa por crear una arquitectura propia orientada a los agentes de inteligencia artificial. Sobre esta base, explica el CIO, la entidad ha lanzado Singularity, una plataforma que integra la IA de OpenAI, la visión del equipo de estrategia y el criterio del banquero para ofrecer un mejor asesoramiento al cliente, “uno de los proyectos estrella de este año”.

Esta apuesta por la IA y, en concreto, por la tecnología de OpenAI es de tal calado que la empresa creadora de ChatGPT ha seleccionado al de Singular como uno de los casos de éxito más destacados de Europa en la aplicación de IA dentro del sector financiero. “Lo que tiene Singularity de particular es que lo han creado los propios usuarios”, indica Andrés, que explica que el banco formó a los usuarios de ChatGPT para que fueran ellos los que identificaran oportunidades y propusieran nuevas aplicaciones. “Una de las grandes ventajas de la IA generativa es que ha reducido las barreras tecnológicas: hoy el valor diferencial está más en identificar el caso de uso adecuado que en la propia ejecución técnica”, añade Andrés Priego.

A partir de ahí, relata, los banqueros empezaron a detectar necesidades que requerían una infraestructura más sofisticada que una simple interfaz conversacional. “Fue entonces cuando decidimos crear un grupo de 20 banqueros que actuaron como embajadores de Singularity y participaron activamente en el diseño de la herramienta. Mantuvimos sesiones semanales para perfeccionarla y, hoy en día, los resultados son de éxito total”.

La plataforma Singularity está diseñada para facilitar el asesoramiento al cliente en las fases previas a cada reunión. La plataforma recopila información procedente de todos los sistemas del banco y se integra con Salesforce, gestores documentales, bases de conocimiento, datos de rentabilidad y catálogos de productos. Todo ese ecosistema está conectado a una red de 20 agentes de IA que analizan la información y generan recomendaciones y resultados útiles para el banquero. El objetivo, indica el CIO, es “liberar a los profesionales de tareas operativas y de bajo valor”, como la recopilación manual de información, para que puedan centrarse en lo realmente importante: “El asesoramiento personalizado al cliente”.

“Una de las grandes ventajas de la IA generativa es que ha reducido las barreras tecnológicas: hoy el valor diferencial está más en identificar el caso de uso adecuado que en la propia ejecución técnica”

La acogida de la plataforma, subraya Rubén Andrés, ha sido excelente. “Actualmente, 80 banqueros participan en el proyecto y el 90% utiliza la herramienta de forma habitual en su trabajo diario”. Este mes de julio, añade, Singularity se ampliará a los 200 banqueros que tiene la entidad. “La vamos a conectar con toda la inteligencia de inversiones y productos. Ya no va a ser solo una herramienta de recolección de información, sino que también utilizará la inteligencia del banco para perfilar el asesoramiento”.

El ROI (retorno de inversión) de este caso de uso es significativo: “Los banqueros se ahorran entre 60 y 90 minutos diarios en la preparación de reuniones”, afirma el CIO. Un ahorro que redunda en “más tiempo para pensar qué necesita el cliente y qué podemos aportarle como banco para mejorar su día a día, su vida y sus objetivos”. 

El banquero, no obstante, sigue siendo una pieza fundamental de la ecuación, según Rubén Andrés. “Es indispensable; por ejemplo, en momentos de incertidumbre, donde hay caídas de mercados y la situación se tensa, el banquero tiene la cabeza fría y pone raciocinio a las emociones del cliente, al que acompaña en las inversiones, pero siempre apoyado en unas capacidades avanzadas de análisis de datos e inteligencia”. Es más, según el CIO, “el humano es imprescindible en el mundo de la banca”, sea cual sea el modelo: “Banca masiva, mainstream digital, banca privada o un término intermedio que sería Self Bank, un banco 100% digital con capacidades avanzadas y con unos banqueros remotos que también pueden asesorar a los clientes”.

El ejecutivo cree que la banca del futuro será más humana porque es precisamente esto lo que va a diferenciar a los distintos actores entre sí. “El factor humano aumentará la calidad en el asesoramiento y en el trato al cliente. Por otro lado, también veremos redes de agentes en el entorno digital; me atrevería a decir que ya no competiremos por la experiencia de usuario (‘user experience’), sino por la del agente (‘agent experience’). Vamos a tener que generar capas de agentes que se comuniquen entre sí y generen una experiencia muy fluida para poder analizar los productos de los que disponemos, la oferta, y comparar unos con otros y saber qué encaja mejor con el cliente en función de su contexto y el del banco. Vamos a ver una revolución en banca en los próximos años de manera clara”, expone.

Gobierno, cultura y adopción, los desafíos de abrazar la inteligencia artificial

Aunque la IA trae consigo ingentes oportunidades, también abre retos de distinta índole. Preguntado por este asunto, el CIO contesta: “El mayor retorno que tiene la IA actualmente es tecnológico. Avanza cada vez más rápido y es más accesible, de hecho, cualquiera puede usar ChatGPT incluso para programar; pero el mayor reto lo hemos encontrado en materia de gobierno, cultura y adopción”.

Para subsanar el desafío del gobierno, en Singular Bank han creado un “comité de gobierno de la IA y una política que todos los empleados deben conocer y firmar antes de poder utilizar todas estas herramientas”, explica el CIO. En este comité, de carácter multidisciplinar —está formado por el equipo de Legal Compliance, el DPO (delegado de protección de datos), el equipo de seguridad y el de tecnología y operaciones— y alineado con la regulación vigente —como la IA Act (Reglamento europeo de IA) y el RGPD (Reglamento General de Protección de Datos), entre otros— se mide el riesgo que tiene cada una de las plataformas de IA antes de adoptarlas. Solo después se ponen a disposición de los empleados. Además, agrega, en los casos de uso que han desplegado, como Singularity, realizan un análisis continuo del rendimiento de los modelos para garantizar que éste se ajusta a lo buscado y, si no, se aplican ajustes a nivel tecnológico. 

Para superar el reto cultural y las barreras de adopción, pues “toda esta revolución de la IA ha generado muchos miedos a la pérdida de empleo y a ser sustituido”, el banco ha trabajado en ofrecer amplia formación sobre estas nuevas tecnologías “desde el punto de vista de hacia dónde va el mercado, pero también mirando al pasado, porque si nos hubiéramos negado a la imprenta, el ferrocarril y todas las revoluciones industriales, no estaríamos en el nivel de sofisticación actual; hemos trasladado a los empleados que esto es una revolución a la que hay que sumarse, pues gracias a ella vamos a tener mejores profesionales y un mejor servicio a nuestros clientes”. La clave, añade, ha sido hacer a los empleados “creyentes del cambio, darles formación y acompañarlos”.

El gran cambio de mentalidad con la IA, explica, es que los propios empleados pueden desarrollar sus propias soluciones tecnológicas, sin pedirlas al equipo de tecnología. “Esta es la gran revolución que estamos acometiendo”, sentencia.

El coste, en el punto de mira

Una de las grandes preocupaciones de los líderes de TI a la hora de abrazar la IA es que el coste se dispare y provoque situaciones similares a las vividas con la adopción de cloud en el pasado. “Cuando iniciamos el proyecto con OpenAI, en marzo de 2025, trabajábamos con un modelo de tarifa plana: pagábamos una licencia que cubría tanto el desarrollo de ingeniería con herramientas como Cursor como el uso de ChatGPT. Todo estaba incluido. Actualmente hemos pasado a un modelo de coste por consumo de tokens. Desde la perspectiva de negocio, no nos preocupa esta evolución, ya que la plataforma cubre con creces nuestras necesidades actuales. Además, hemos realizado proyecciones a futuro y no prevemos ningún problema significativo. Incluso en el caso de que se produjera un ligero sobrecoste, los beneficios obtenidos compensarían con creces ese incremento del gasto”, reflexiona Rubén Andrés.

Desde el punto de vista de ingeniería, añade, “el retorno también compensa el sobrecoste, ya que hemos multiplicado la productividad y las capacidades de nuestros desarrolladores”. Sí han observado, afirma el CIO, la necesidad de establecer cuotas y mecanismos de control del consumo, pues en algún caso han detectado que ciertos desarrolladores utilizaban modelos muy avanzados para tareas que no requerían ese nivel de capacidad, lo que generaba un consumo innecesario de tokens. Unas situaciones en las que modelos más sencillos habrían ofrecido el mismo resultado con un coste considerablemente menor.

El gran cambio de mentalidad con la IA, explica Rubén Andrés, es que los propios empleados pueden desarrollar sus propias soluciones tecnológicas, sin pedirlas al equipo de tecnología. “Esta es la gran revolución que estamos acometiendo”

Por todo ello, explica, el banco está aplicando los mismos principios de gestión financiera que ya utilizó con la nube: “Hemos trasladado el uso de FinOps al ámbito de la inteligencia artificial para optimizar el uso de los recursos, controlar los costes y garantizar que cada caso de uso emplee el modelo más adecuado, además de hacer un seguimiento mensual del consumo”.

Impacto en el desarrollo de software

Los desarrolladores de software son algunos de los perfiles profesionales más directamente impactados por el auge de la IA agentiva y generativa. “En el mercado en general muchos programadores ven la IA como una amenaza, pero, en realidad, esto va a hacer que se multiplique el software porque, de hecho, el mundo necesita más. Los bancos ya teníamos mucha más demanda de la que podíamos abordar. Por eso yo no veo que la IA sea un problema para los desarrolladores”.

Dicho esto, el CIO reconoce que el tipo de perfiles técnicos que busca la entidad en la actualidad ha cambiado: “Ahora buscamos perfiles técnicos senior, pues cuanta más experiencia tiene el profesional, mejor adopta la IA; también que tengan baja resistencia al cambio”. En este sentido, en el banco ya trabajan de forma que sus técnicos lideran equipos virtuales formados por los roles [agentes] de project manager, analista funcional, analista orgánico, etc. pero alimentados con el contexto y la arquitectura de la entidad. “Una iniciativa con la que te vuela la cabeza”, sentencia Rubén Andrés.

El ROI del uso de la IA asociado al área de desarrollo de ingeniería es también significativo, según el directivo. “Ahora un programador desarrolla software como si fuera un equipo de 15 desarrolladores, y lo hace a una velocidad nunca vista antes y con una calidad totalmente alineada con la requerida por el banco”.

El área de Tecnología de Singular Bank, cuyo equipo asciende a 41 personas, está abordando “una transformación completa de todos los sistemas legacy con toda esta tecnología”, recalca el CIO. “Es un catalizador del cambio”, añade.

Foco en la soberanía tecnológica

Preguntado por si le preocupa la soberanía tecnológica en el complejo contexto actual, marcado por un escenario geopolítico tensionado, Rubén Andrés es contundente: “Mucho”. Más aún, reconoce, después de ver cómo el Gobierno de Estados Unidos paralizaba recientemente el acceso a los modelos más avanzados de Anthropic (una decisión después revertida). Por ello, la filosofía del CIO es que “todo lo que construyamos permita la continuidad de negocio, es decir, el aumento de capacidades cognitivas es un ‘on top off’ de lo que son los básicos de poder llevar a cabo el asesoramiento y el resto de las tareas que hemos hecho antes de tener estos sistemas”. Además, reconoce, ya están trabajando en “desacoplar la capa agentiva. Esta pertenece a Singular Bank, es nuestra propia plataforma, a la que ponemos por encima una capa de experiencia. Ahora la capa de agentes la tenemos con tecnología de OpenAI (ChatGPT), pero se podría cambiar por cloud o una capa propia”.

Además, desvela a CIO ESPAÑA, Singular Bank está reforzando su estrategia de continuidad de negocio mediante una arquitectura multirregión en AWS que distribuye sus sistemas entre España (en Zaragoza) y el norte de Europa. El objetivo, asegura, es garantizar la resiliencia operativa y la recuperación rápida de los servicios ante incidencias graves, desde fallos técnicos hasta posibles ciberataques o eventos geopolíticos que afecten a una determinada ubicación.

Singular Bank está reforzando su estrategia de continuidad de negocio mediante una arquitectura multirregión en AWS que distribuye sus sistemas entre España (en Zaragoza) y el norte de Europa

Ya desde el punto de vista de la ciberseguridad, en la entidad están empleando la propia IA para crear ‘red teams’ virtuales que se encarguen de analizar continuamente la superficie de ataque y detectar posibles problemas y poder resolverlos antes de que los detecte un tercero. “La ciberseguridad nos preocupa mucho porque, al final, somos una infraestructura crítica y debemos ser responsables y tener control sobre lo que manejamos”.

La ventaja que aporta disponer de capacidades de análisis en ciberseguridad junto a las de un desarrollo vertiginoso facilita que “la defensa pueda abordarse de manera mucho más rápida”, reflexiona el portavoz.

Preguntado por cómo absorbe el banco toda la avalancha normativa que existe y si esta supone un freno a la innovación, el directivo también es claro: “Llevo trabajando en banca 20 años y nunca he visto la regulación como un freno para este sector. Honestamente, creo que este argumento se ha utilizado como excusa, pero la regulación es muy necesaria, garantiza que demos un servicio seguro y confiable”.

En Singular Bank, añade, “hay un equipo muy abierto a las nuevas tecnologías y a analizar la regulación desde un punto de vista más de facilitar el cambio que de bloquearlo”. “Si se adopta con sentido común y agilidad y todos los equipos del banco trabajan en pro del negocio y de la innovación esta no es un freno”.

Aumentar la escalabilidad del banco, el eje de futuro

En un futuro próximo, el equipo de Tecnología y Operaciones de Singular Bank, con Rubén Andrés al frente, proseguirá la transformación y modernización en la que está inmerso el banco. “Estamos renovando todos los sistemas legacy a través de tecnologías con IA y context engineering y, por otro lado, continuaremos trabajando la parte de agentes. Ya hemos desarrollado algunos que reemplazan o capacitan a las áreas de operaciones para poder hacer conciliaciones bancarias cada cinco minutos, mientras que antes las hacíamos cada día; esto nos permitirá aumentar la escalabilidad del banco, que es nuestro objetivo de cara a los próximos años. Y, finalmente, seguiremos apostando fuerte por las arquitecturas agentivas para poder generar experiencias de cliente mucho más naturales a través de conversaciones a través de los canales digitales”.

Respecto a la evolución futura del rol del CIO en general, el ejecutivo es plenamente consciente de la transformación que esta función ha tenido en los últimos años, ahora “más pegado al negocio”. “En la actualidad, se ha amplificado más el rol del CIO, que ya no está ligado a la continuidad, la resiliencia o la seguridad, sino es un rol de agente del cambio, impulsor de la adopción de nuevas tecnologías, formador, visionario de nuevos modelos de negocio… En definitiva, un rol, paradójicamente en esta era de la IA, cada vez más humano”.

Only 35% of CIOs have full visibility into their AI operating costs, according to a recent KPMG survey. That makes it difficult for them to control spend on software-as-a-service offerings from vendors who, like Workday, have incorporated pay-as-you-go agentic AI into their offerings. Workday is one of several vendors that have shifted to a hybrid subscription/consumption pricing model.

“Fundamentally, with AI we are shifting the value of what enterprise software as a service is delivering in the industry,” Workday CTO Gabe Monroy explained in a recent interview. “The key, though, is that the value is no longer derived by a fixed factor, like how many employees you have working for you. It’s now going to be derived by how much use are you getting out of the system, hence the consumption.”

However, “It’s going to be in some cases disruptive to our customers, and it’s incumbent on us to provide them with tools to forecast and navigate that transition effectively,” he said.

That will be welcome news for the 40% of organizations that KPMG found have usage or token budgets in place.

The changes Monroy described are part of an industry trend, according to Terra Higginson, principal research director at Info-Tech Research Group. “What we are seeing in the market is that basic seat pricing and seat counts are not going away. Customers are still paying for the core subscription footprint. AI is being layered on top as an incremental cost,” she said. “The practical message is simple: expect to pay more. The pricing model may shift from seats to credits or consumption, but the direction of spend is still up.”

And because each vendor’s program has its own twists and its own ways of measuring and charging for usage, every new model adds a layer of complexity to the budgeting headaches CIOs already face thanks to the ongoing move to consumption-based services, which began with the cloud.

Two parts to the model

Workday’s AI pricing model is in two parts. First, customers subscribe to the services they want, as they always have. With that subscription, they receive a pool of Flex Credits that can be used to enable AI agents and other “applicable platform capabilities” including Agent-Ready Tools, Workday Data Cloud, and high-volume use of Sana through its conversational AI interface. The number of credits included varies by company size. But on top of that, they also purchase a subscription for additional Flex Credits that can be applied to any product they subscribe to.

Flex Credit usage is monitored through the Platform Consumption Console, which generates alerts when consumption hits 80%, 90% and 100% of subscribed credits. Use is metered when a task is completed.

However, one Flex Credit doesn’t necessarily equal one action. Workday’s rate card lists the number of credits per activity; for example, as of May 21, in the Recruiting Agent, it currently costs six credits to screen and grade each candidate’s resumé against a job opening, and 750 credits per requisition to identify relevant leads in existing talent pools and rediscover candidates for recruiters, recommending jobs for those candidates to apply for. In the Contract Negotiation Agent, the review and redlining of a contract, based on a playbook, costs 500 credits.

The company also provides a reference guide listing the credits used by actions performed by the Sana platform and by self-service agents.

The good news is that, though Workday’s console counts credits used in both production and pre-production environments, only those used in production are charged for, offering an early budgeting reality check and a chance to tweak processes before they land in production. Pre-production usage count is only in aggregate, however, so if a customer wants to size a specific agent, the best approach is to run it in a defined window or dedicated test tenant and compare usage before and after the test.

Use them or lose them

The bad news is that Flex Credits expire after one year, and any left in a subscription do not roll over to the next; it’s a use them or lose them situation.

If, on the other hand, a customer exceeds their Flex Credit balance during the year, Workday said it does not just turn off their agents or other access to services. Instead, Workday’s account teams “partner with them to reconcile usage and help them purchase additional credits.”

Analysts agree that there are pros and cons to this new market reality.

“Workday’s Flex Credits are part of a broader shift we’re seeing across SaaS,” said Melody Brue, principal analyst at Moor Insights & Strategy. “Vendors are defining their own proprietary units for AI consumption so they can meter usage on top of existing subscriptions.”

Workday’s model, she said, is more flexible than a static AI add-on because customers can use Flex Credits for whichever agents drive the most value at a given time and get access to new AI capabilities as they launch.

The trade-off, however, is predictability. “Credit burn rates vary widely by task,” she said. A pilot can quietly consume a year’s worth of Flex Credits within weeks without strong telemetry and governance. And that, she said is what worries technology and finance leaders: apparently successful AI adoption that shows up as a budget surprise.

But, said Scott Bickley, advisory fellow at Info-Tech Research Group, “The Workday Flex Credits Rate Card seeks to quantify consumption of Flex Credits to specific value-added actions that are AI agent-driven. Many other vendors in the ERP space have created incredibly complex, multi-layered consumption models, leaving their customers’ heads spinning as they seek to decipher how capacity will be consumed, much less if it can add value.”

Brue, too, approved of Workday’s model, although she said that a core issue with AI pricing today is that vendors are each defining their own units, with no common measurement across platforms. This gives vendors pricing flexibility, but makes customers do extra work to create meaningful metrics like cost per resolution or cost per process run, just to keep budgets and ROI under control.

“Workday’s Flex Credits are a smart move for Workday because they align revenue with AI usage, but from the buyer’s side, they raise the bar on FinOps and governance,” she said. “You need clear dashboards, guardrails, and forecasting, or that flexibility can quickly turn into a budget black hole.”

Systems integrators (SIs) have been integral to IT projects for decades, providing consulting services and helping enterprises build and launch technology tools.

Now, as organizations move to deploy agentic AI, top large language model (LLM) providers are looking to get in on that action. A proliferation of Forward Deployed Engineer (FDE) services embeds AI experts directly into customer teams to help create, customize, and launch AI services.

For instance, this week, Microsoft launched a $2.5 billion venture, Microsoft Frontier Company, that the tech giant says “goes beyond” FDE, and Amazon Web Services (AWS) announced its own $1 billion investment into a new AWS FDE platform.

Both projects will integrate thousands of Microsoft and AWS engineers into customer environments to help them not only build AI tools, but learn essential skills to handle projects on their own going forward. Other big model players, including Anthropic, are also getting into the game with their own FDE services.

The gap between AI investment and ROI is growing, noted Thomas Randall, research director at Info-Tech Research Group, and organizations are under pressure to show production value from AI deployments.

This is the context in which vendor FDEs such as those from Microsoft and AWS will become relevant to “compress learning curves from their deep product knowledge, establish reusable processes, and build capabilities that can then be transferred,” he said.

Frontier transformation

Microsoft Frontier Company will place 6,000 experts with customers to “co-design, co-innovate, deploy and continuously improve” AI systems based on their specific business goals, Judson Althoff, CEO of Microsoft Commercial Business, wrote in a blog post.

The new offering focuses on what Microsoft calls “Frontier Transformation,” helping customers build an intelligence platform based on their proprietary data and internal expertise, workflows, and decision-making processes. Based on FinOps principles, the offering helps users “observe, govern, manage, and secure” AI tools across their stacks, and their intelligence compounds over time, Althoff said.

Microsoft Frontier Company is a “model-diverse, open, heterogeneous” platform, Althoff noted; customers can choose their own models: ChatGPT, Claude, Microsoft Copilot, or other open source or industry-specific models.

“Customers shouldn’t be locked into a single model any more than they should be locked into a single technology vendor,” Althoff noted. Further, he emphasized, customer data and IP are protected, and are not used to train Microsoft’s models.

The tech giant says it will leverage its SI and FDE partnerships with Accenture, Capgemini, EY, KPMG, PwC, and others to help scale the platform. Early users including London Stock Exchange Group (LSEG), Land O’Lakes, Unilever, and Novo Nordisk are already seeing “measurable outcomes,” Althoff said.

For instance, AI embedded into LSEG Workspace helps finance experts ask complex questions and get quick answers based on structured and unstructured financial data. The underlying foundation is “iteratively refined” through client feedback and real-time user testing, Althoff explained. This accelerates each cycle and improves model quality and scope.

This is the value of FDEs, he contended: “Enterprise AI engineering expertise with deep industry knowledge is required to build a system that acts as a continuous loop of improvement,”

Compressing timelines

Like Microsoft Frontier Company, AWS FDE embeds its experienced engineers into customers’ business, engineering, and security teams to help them build and launch agents purpose-built on their specific data, processes, and governance frameworks, AWS’ VP of frontier AI engineering and services Francessca Vasquez explained in a blog post.

“Unlike traditional consulting that assesses, recommends, and treats each deployment as a standalone project, AWS FDE builds for the long term,” she noted. Customers become “self-sufficient with AI,” moving from “observers to co-builders to autonomous operators” as they learn AI skills, workflows, and patterns that they can use to build AI going forward.

The platform is agentic-first and designed to compress timelines “from months to days,” and the derived business intelligence compounds to support future projects, Vasquez said.

Embedded engineers, many of whom build AWS AI services, verify and guide projects; AWS says it is also investing in training, tools, and resources for partners, to bolster the platform.

Customers gain access to runbooks, and architectural documentation, and a semantic layer connects to their data sources to create a knowledge graph that AI agents can reason over, Vasquez said.

She emphasized that domain expertise resides in the customer’s code, agents, and systems, so institutional knowledge does not get lost with employee turnover. Further, security tools provide hardware-based isolation and end-to-end encryption.

AWS FDE is not intended for those merely experimenting with AI, Vasquez noted, it is “built for organizations that have moved past experimentation and need production AI systems running real business processes.”

Still a market for SIs

SIs have enjoyed decades of high-margin relationships with their customers, so it makes “eminent sense” for hyperscalers to try to grab some of that business for themselves, noted technology analyst Carmi Levy.

“Both Microsoft and Amazon are aggressively looking for ways to tighten customer lock-in and open up more opportunities to get inside both their clients’ operations and decision making apparatus,” he pointed out.

In addition, Randall said, Info-Tech’s research reveals that 77% of organizations do not have a corporate-wide AI strategy. FDEs will address this by being narrow and specific to the customer’s working AI systems, reference architecture, runbooks, and other deliverables.

SIs, however, provide a different service, he said. Their relevance will be in broader integration knowledge across systems, managing change, and scaling programs. “Their deliverables will be more strategic and broader in scope.”

Of course, there is overlap, he said, and Microsoft will work closely with global SI partners. The investment gap and implementation complexity put hyperscalers under pressure to “provide more white-glove services to pull their customers along.”

Considerations for enterprises

Levy noted that, for customers who have already decided on a particular AI stack, these platforms may be worthwhile as long as they’re comfortable taking a single-vendor route.

“Assuming Microsoft and Amazon are price- and service-competitive with systems integrators, they may represent a compelling alternative,” he said. Still, using their services could come at a cost of potentially reduced choice, which could limit longer-term options.

It remains to be seen whether these types of platform are better for the customer or the vendor, and deliver more value than existing alternatives, he said, but the market will ultimately decide.

With that in mind, he advised IT decision makers to deep-dive not only into Microsoft’s and Amazon’s agentic delivery competencies compared to those of SIs, but into whether their underlying motivations are “truly in the customers’ best interests.”

Info-Tech’s Randall also advised enterprises to consider the output they’re looking for. FDEs will fast-track accurate builds on specific platforms they specialize in, while SIs will then help make the platform work across an enterprise context.

FDE options are best for organizations looking past AI pilots to quick, effective product buildouts, he said. SIs are needed when those organizations need to scale that pattern across messy enterprise processes.

Another factor to consider: “FDEs are not suitable for organizations still working on basic AI strategy questions or that want to remain cloud neutral,” said Randall.

This article originally appeared on CIO.com.

Systems integrators (SIs) have been integral to IT projects for decades, providing consulting services and helping enterprises build and launch technology tools.

Now, as organizations move to deploy agentic AI, top large language model (LLM) providers are looking to get in on that action. A proliferation of Forward Deployed Engineer (FDE) services embeds AI experts directly into customer teams to help create, customize, and launch AI services.

For instance, this week, Microsoft launched a $2.5 billion venture, Microsoft Frontier Company, that the tech giant says “goes beyond” FDE, and Amazon Web Services (AWS) announced its own $1 billion investment into a new AWS FDE platform.

Both projects will integrate thousands of Microsoft and AWS engineers into customer environments to help them not only build AI tools, but learn essential skills to handle projects on their own going forward. Other big model players, including Anthropic, are also getting into the game with their own FDE services.

The gap between AI investment and ROI is growing, noted Thomas Randall, research director at Info-Tech Research Group, and organizations are under pressure to show production value from AI deployments.

This is the context in which vendor FDEs such as those from Microsoft and AWS will become relevant to “compress learning curves from their deep product knowledge, establish reusable processes, and build capabilities that can then be transferred,” he said.

Frontier transformation

Microsoft Frontier Company will place 6,000 experts with customers to “co-design, co-innovate, deploy and continuously improve” AI systems based on their specific business goals, Judson Althoff, CEO of Microsoft Commercial Business, wrote in a blog post.

The new offering focuses on what Microsoft calls “Frontier Transformation,” helping customers build an intelligence platform based on their proprietary data and internal expertise, workflows, and decision-making processes. Based on FinOps principles, the offering helps users “observe, govern, manage, and secure” AI tools across their stacks, and their intelligence compounds over time, Althoff said.

Microsoft Frontier Company is a “model-diverse, open, heterogeneous” platform, Althoff noted; customers can choose their own models: ChatGPT, Claude, Microsoft Copilot, or other open source or industry-specific models.

“Customers shouldn’t be locked into a single model any more than they should be locked into a single technology vendor,” Althoff noted. Further, he emphasized, customer data and IP are protected, and are not used to train Microsoft’s models.

The tech giant says it will leverage its SI and FDE partnerships with Accenture, Capgemini, EY, KPMG, PwC, and others to help scale the platform. Early users including London Stock Exchange Group (LSEG), Land O’Lakes, Unilever, and Novo Nordisk are already seeing “measurable outcomes,” Althoff said.

For instance, AI embedded into LSEG Workspace helps finance experts ask complex questions and get quick answers based on structured and unstructured financial data. The underlying foundation is “iteratively refined” through client feedback and real-time user testing, Althoff explained. This accelerates each cycle and improves model quality and scope.

This is the value of FDEs, he contended: “Enterprise AI engineering expertise with deep industry knowledge is required to build a system that acts as a continuous loop of improvement,”

Compressing timelines

Like Microsoft Frontier Company, AWS FDE embeds its experienced engineers into customers’ business, engineering, and security teams to help them build and launch agents purpose-built on their specific data, processes, and governance frameworks, AWS’ VP of frontier AI engineering and services Francessca Vasquez explained in a blog post.

“Unlike traditional consulting that assesses, recommends, and treats each deployment as a standalone project, AWS FDE builds for the long term,” she noted. Customers become “self-sufficient with AI,” moving from “observers to co-builders to autonomous operators” as they learn AI skills, workflows, and patterns that they can use to build AI going forward.

The platform is agentic-first and designed to compress timelines “from months to days,” and the derived business intelligence compounds to support future projects, Vasquez said.

Embedded engineers, many of whom build AWS AI services, verify and guide projects; AWS says it is also investing in training, tools, and resources for partners, to bolster the platform.

Customers gain access to runbooks, and architectural documentation, and a semantic layer connects to their data sources to create a knowledge graph that AI agents can reason over, Vasquez said.

She emphasized that domain expertise resides in the customer’s code, agents, and systems, so institutional knowledge does not get lost with employee turnover. Further, security tools provide hardware-based isolation and end-to-end encryption.

AWS FDE is not intended for those merely experimenting with AI, Vasquez noted, it is “built for organizations that have moved past experimentation and need production AI systems running real business processes.”

Still a market for SIs

SIs have enjoyed decades of high-margin relationships with their customers, so it makes “eminent sense” for hyperscalers to try to grab some of that business for themselves, noted technology analyst Carmi Levy.

“Both Microsoft and Amazon are aggressively looking for ways to tighten customer lock-in and open up more opportunities to get inside both their clients’ operations and decision making apparatus,” he pointed out.

In addition, Randall said, Info-Tech’s research reveals that 77% of organizations do not have a corporate-wide AI strategy. FDEs will address this by being narrow and specific to the customer’s working AI systems, reference architecture, runbooks, and other deliverables.

SIs, however, provide a different service, he said. Their relevance will be in broader integration knowledge across systems, managing change, and scaling programs. “Their deliverables will be more strategic and broader in scope.”

Of course, there is overlap, he said, and Microsoft will work closely with global SI partners. The investment gap and implementation complexity put hyperscalers under pressure to “provide more white-glove services to pull their customers along.”

Considerations for enterprises

Levy noted that, for customers who have already decided on a particular AI stack, these platforms may be worthwhile as long as they’re comfortable taking a single-vendor route.

“Assuming Microsoft and Amazon are price- and service-competitive with systems integrators, they may represent a compelling alternative,” he said. Still, using their services could come at a cost of potentially reduced choice, which could limit longer-term options.

It remains to be seen whether these types of platform are better for the customer or the vendor, and deliver more value than existing alternatives, he said, but the market will ultimately decide.

With that in mind, he advised IT decision makers to deep-dive not only into Microsoft’s and Amazon’s agentic delivery competencies compared to those of SIs, but into whether their underlying motivations are “truly in the customers’ best interests.”

Info-Tech’s Randall also advised enterprises to consider the output they’re looking for. FDEs will fast-track accurate builds on specific platforms they specialize in, while SIs will then help make the platform work across an enterprise context.

FDE options are best for organizations looking past AI pilots to quick, effective product buildouts, he said. SIs are needed when those organizations need to scale that pattern across messy enterprise processes.

Another factor to consider: “FDEs are not suitable for organizations still working on basic AI strategy questions or that want to remain cloud neutral,” said Randall.

Data Lakehouses haben sich zum Goldstandard moderner Unternehmens-Datenplattformen entwickelt. Sie vereinen die Vorteile eines Data Lake – die kostengünstige Speicherung unterschiedlichster Datentypen – mit der Zuverlässigkeit, Struktur und Governance eines klassischen Data Warehouse.

Da sie Informationen aus verschiedenen Bereichen eines Unternehmens zentral zusammenführen und gleichzeitig Sicherheits- und Audit-Funktionen bereitstellen, eignen sie sich auch hervorragend als Basis für Enterprise-KI-Systeme. Tatsächlich sind sie inzwischen so weit verbreitet und leistungsfähig, dass sich nahezu alle großen Anbieter von Data Lakes und Data Warehouses zu Lakehouse-Anbietern entwickelt haben. Snowflake beispielsweise startete ursprünglich als Data-Warehouse-Anbieter und hat sich durch mehrere Jahre der Weiterentwicklung und zahlreiche Übernahmen zu einer vollständigen Data-Lakehouse-Plattform entwickelt.

Grundlage der zukünftigen KI-Landschaft

Auch Docusign nutzt diese Plattform nun, um seine Ambitionen im Bereich Agentic AI voranzutreiben. So werden beispielsweise Daten aus Salesforce übernommen und anschließend zum Training eines internen KI-Vertriebsagenten verwendet, erläutert Shivi Verma, Senior Manager of Engineering bei Docusign. Darüber hinaus trainiert das Unternehmen Machine-Learning-Modelle, um seinen Kunden präzisere Ergebnisse liefern zu können.

Die Informationen werden außerdem über RAG-Embedding-Pipelines an Large Language Models (LLMs) weitergegeben. Gleichzeitig untersucht Docusign den Einsatz des Model Context Protocol (MCP), sobald diese Technologie weiter ausgereift ist.

Ein zentrales Thema beim Bereitstellen der Lakehouse-Daten ist für Docusign jedoch die Sicherheit und Governance. „Wir gehen dabei äußerst vorsichtig vor“, sagt Verma. „Jeder Anwendungsfall durchläuft eine strenge Sicherheitsprüfung sowie Diskussionen mit technischen und fachlichen Stakeholdern, um sicherzustellen, dass wir weder gegen Sicherheitsvorgaben noch gegen Compliance-Anforderungen verstoßen.“

Diese Sicherheitskontrollen greifen sowohl beim Import der Daten in Snowflake als auch beim späteren Export. Besonders strenge Regeln gelten für den Zugriff auf sensible Informationen wie Kundendaten.

„Zunächst stellen wir nur Daten mit einem niedrigen Risikoprofil bereit“, erklärt Verma. Dazu gehören beispielsweise öffentlich verfügbare Informationen wie Inhalte der Unternehmens-Website oder Produktinformationen.

Docusign ist mit diesem Ansatz keineswegs allein. „Wir sehen inzwischen eine Lakehouse-Nutzung von 65 Prozent bei den Kunden von Gartner“, sagt Gartner-Analyst Prasad Pore. „Das ist innerhalb kurzer Zeit ein außergewöhnlich hoher Wert.“

Und die Zukunft der Lakehouses sieht seiner Einschätzung nach noch vielversprechender aus.

„Lakehouses entwickeln sich zur Grundlage der zukünftigen KI-Landschaft“, sagt Pore. Gleichzeitig erweitern die Anbieter ihre Plattformen gezielt um KI-Funktionen.

Ein klassisches Lakehouse-Konzept umfasst beispielsweise keine Vektordatenbanken, die für RAG-basierte KI-Systeme eine zentrale Rolle spielen.

„Viele Lakehouse-Anbieter haben inzwischen Funktionen zur Vektorindizierung integriert“, erklärt Pore. „Databricks und Microsoft Fabric verfügen bereits über eingebaute Vektor-Funktionalitäten.“ Kleinere Anbieter könnten diese Möglichkeiten allerdings noch nicht bieten.

Auch die Unterstützung für MCP, den Standard zur Verbindung von KI-Agenten mit Datenquellen und Systemen, unterscheidet sich je nach Anbieter und gehört bislang nicht zum traditionellen Funktionsumfang eines Lakehouses.

Eine Frage der Wahl

Ein Data Lakehouse ist nicht die einzige Möglichkeit für Unternehmen, ihren KI-Systemen den geschäftlichen Kontext bereitzustellen, den sie für einen sinnvollen Einsatz benötigen.

So können Unternehmen beispielsweise Vektordatenbanken oder entsprechende Datenpipelines manuell aus einzelnen Datenquellen aufbauen oder eine Data Fabric einsetzen, um die Verbindung zwischen den Systemen herzustellen.

„Eine Data Fabric kann sich direkt mit den ursprünglichen Datenquellen verbinden. Das eignet sich gut für schnelle Analysen“, erklärt Gartner-Analyst Pore. „Allerdings belastet man dadurch die Quellsysteme zusätzlich, was für diese Anwendungen und Maschinen nicht ideal ist.“

Wichtig dabei: Microsoft Fabric ist zwar eine Lakehouse-Plattform, jedoch keine Data-Fabric-Plattform im Sinne der Gartner-Definition.

Ein weiterer Nachteil direkter Verbindungen besteht darin, dass die Datenmodelle der operativen Systeme meist nicht für analytische Zwecke optimiert sind und ihre Nutzung häufig teuer ist. „Der direkte Zugriff auf Quellsysteme ist nicht effizient“, so Pore.

Hinzu kommt, dass für Data Lakehouses bereits etablierte Verfahren zur Verwaltung von Zugriffsrechten existieren.

„Ein Lakehouse vereinheitlicht Daten, Wartung, Sicherheit und Governance physisch an einem Ort“, erklärt Pore. „Gerade für die Einführung von KI ist das von entscheidender Bedeutung. Als unternehmensweite ‘Single Source of Truth’ ist ein Lakehouse der moderne Weg, ein zentrales Daten-Repository aufzubauen.“

Vom Data Lake zum Lakehouse

Das Beratungsunternehmen Lemongrass begann bereits vor rund zehn Jahren mit einem klassischen Data Lake und entwickelte es vor etwa vier Jahren schrittweise zu einem Lakehouse weiter.

„Damals war das Lakehouse-Konzept noch längst nicht so verbreitet“, erinnert sich Kausik Chaudhuri, Chief Innovation Officer bei Lemongrass.

Deshalb entwickelte das Unternehmen eigene Lakehouse-Funktionen auf Basis seines Amazon-S3-Data-Lakes. Nun, da das Lakehouse zunehmend KI-Anwendungen unterstützt, steht bereits die nächste Modernisierung an.

„Derzeit arbeiten wir an einer Lösung für Incident- und Change-Management“, erläutert Chaudhuri.

Die ursprünglichen Daten liegen in ServiceNow. Würde man sie direkt aus dem Lakehouse extrahieren, um sie in einem KI-System zu nutzen, wären die Kosten zu hoch. „Deshalb überlegen wir jetzt, einen MCP-Server aufzubauen, der diese Daten gezielt abfragt“, fügt er hinzu.

Gleichzeitig plant Lemongrass den Wechsel von den selbst entwickelten Lakehouse-Erweiterungen zu einer Standardlösung.

„Als wir begonnen haben, war Lemongrass vor allem ein Verfechter von AWS, weshalb viele unserer Werkzeuge auf AWS aufgebaut wurden“, erklärt Chaudhuri. „Jetzt denken wir darüber nach, diesen Ansatz zu ändern, weil KI deutlich mehr Möglichkeiten eröffnet.“

Allerdings bietet inzwischen auch AWS selbst umfassende Lakehouse-Funktionalitäten. „Die Daten liegen bereits dort. Wir müssen das Rad also nicht neu erfinden.“

Darüber hinaus stellt AWS direkte Anbindungen an Anthropic Claude und weitere KI-Modelle bereit. Da diese Modelle ebenfalls innerhalb der AWS-Infrastruktur betrieben werden, fallen keine Egress-Gebühren an.

Lemongrass plant, die Modernisierung im dritten Quartal dieses Jahres zunächst mit einem Proof of Concept (PoC) zu beginnen. Dabei müsse aber besonders sorgfältig müsse entschieden werden, welche Daten und in welchem Umfang sie aus dem Lakehouse an KI-Modelle übertragen werden.

„Wir schicken keine Kundendaten an ein LLM“, betont Chaudhuri. „Und ich lese auch nicht 10.000 Datensätze aus und sende sie an Claude – das würde den Token-Verbrauch explodieren lassen. Schon vor einigen Jahren haben wir erkannt, dass wir bankrottgehen könnten, wenn wir den Token-Verbrauch nicht sorgfältig kontrollieren.“

Für manche Anwendungsfälle muss das LLM nach der Implementierung der Lösung überhaupt keine Kundendaten mehr sehen. Beispielsweise erstellten Mitarbeiter früher manuell Statusberichte über Kunden für den eigenen Gebrauch – ein zeitaufwendiger Prozess. Ein LLM könnte diese Aufgabe zwar übernehmen, hätte dabei jedoch Zugriff auf sensible Kundendaten. Außerdem liefern generative KI-Modelle aufgrund ihrer nicht deterministischen Arbeitsweise jedes Mal leicht unterschiedliche Ergebnisse.

Ein weiteres Beispiel sind Formulare, die Kunden später unterschreiben sollen. Auch hier könnte ein LLM bei jeder Anfrage ein neues Formular generieren.

„Deshalb haben wir Claude stattdessen gebeten, ein Programm zu schreiben, das diese Eingaben verarbeitet und daraus den Bericht erzeugt“, erklärt Chaudhuri. Die eigentliche Berichts- oder Formularerstellung erfolgt anschließend durch klassische, deterministische Software. Dadurch bleiben Kundendaten geschützt, während Berichte schnell und kostengünstig erzeugt werden können.

Andere Unternehmen setzen KI dagegen bereits intensiv ein, um ihre Datenbestände besser auszuschöpfen.

Laut einem aktuellen Databricks-Bericht, der auf Daten von 20.000 Unternehmen basiert, stieg der Anteil der von KI-Agenten erzeugten Datenbanken innerhalb von zwei Jahren von 0,1 Prozent auf 80 Prozent. Heute erstellen KI-Agenten bereits 97 Prozent aller Datenbank-Branches.

Sicherheit und Governance

Eine der größten Herausforderungen für Unternehmen besteht darin, herauszufinden, wie sie mit Sicherheits- und anderen damit verbundenen Fragen umgehen sollen, wenn KI-Agenten auf Data Lakehouses zugreifen.

In der Vergangenheit wurden Daten hauptsächlich an Dashboards weitergeleitet, in denen die Sicherheits- und Zugriffskontrollen fest programmiert waren. Oder die Daten gingen an Datenanalysten, die im Rahmen ihrer eigenen Zugriffsrechte arbeiteten. Die ersten KI-Anwendungen basierten überwiegend auf Retrieval-Augmented Generation (RAG). Dabei extrahiert klassische, deterministische Software die benötigten Daten und fügt sie in den Prompt eines Large Language Models für einen konkreten Anwendungsfall ein. Die Entwickler konnten die Sicherheitsregeln dabei individuell für jeden Workflow festlegen.

Mit dem Aufkommen agentischer KI und MCP-Servern (Model Context Protocol) verändert sich dieses Modell grundlegend: KI-Agenten können nun selbstständig entscheiden, welche Daten sie benötigen, und diese eigenständig abrufen.

Nach Ansicht von Genpact-Manager Arellano müssen Unternehmen deshalb neue Konzepte entwickeln, um die Identitäten von KI-Agenten zu verwalten, den Zugriff auf Daten zu kontrollieren, Prüfpfade zu erstellen sowie Prompts und Inhalte zu filtern.

„Agenten benötigen ihre eigenen Zugangsdaten“, erklärt er. Beispielsweise dürfen KI-Agenten unter Umständen niemals Zugriff auf Patientenakten erhalten. „Ebenso wichtig sind Audit Trails, um lückenlos nachvollziehen zu können, was der Agent getan hat.“

Arellano zufolge bieten einige Lakehouse-Anbieter, darunter Databricks, diese Funktionalität an. Zusätzlich können Unternehmen Tools von Anbietern wie Okta, Palo Alto oder Zscaler integrieren.

Die neue semantische Grenze

Die nächste Entwicklungsstufe des Lakehouse ist der Semantic Layer. Gartner schätzt, dass universelle semantische Ebenen bis 2030 zur unverzichtbaren Infrastruktur gehören werden.

„Der Aufbau einer universellen semantischen Schicht ist heute eine Pflichtaufgabe für Verantwortliche im Bereich Daten und Analytics, die KI-Projekte leiten oder unterstützen“, erklärt Gartner. „Nur so lassen sich Genauigkeit verbessern, Kosten kontrollieren, technische KI-Schulden deutlich reduzieren, Multi-Agenten-Systeme aufeinander abstimmen und kostspielige Inkonsistenzen verhindern, bevor sie sich ausbreiten.“

Es reicht nämlich nicht aus, einer KI lediglich Zugriff auf Daten zu geben. Sie muss auch verstehen, was diese Daten für das Unternehmen tatsächlich bedeuten. Die semantische Ebene bildet genau dieses Geschäftswissen ab, das normalerweise nicht in einer strukturierten Datenbank formalisiert ist.  Beispielsweise kann der Begriff „Kunde“ oder „Bestellung“ in verschiedenen Unternehmenssystemen jeweils etwas anderes bedeuten.

„Früher war die semantische Ebene zwar wünschenswert, aber nicht unbedingt notwendig, da Datenwissenschaftler wussten, welche Datenquellen sie abfragen wollten“, erläutert Amit Kinha, Vorstandsmitglied der FinOps Foundation und Field-CTO bei DoiT International, einem Cloud-Beratungsunternehmen.

Für KI-Agenten gilt das jedoch nicht mehr. „Ohne eine semantische Schicht weiß ein Agent möglicherweise gar nicht, wo er nach den benötigten Daten suchen soll”, so Kinha. Oder noch schlimmer: „Er führt fehlerhafte Joins aus oder löst Prozesse aus, die die Kosten explodieren lassen.“

Deshalbwerde die semantische Schicht künftig entscheidend dafür sein, Data Lakehouses effektiv für KI einzusetzen.

Mitlernendes System

Die semantische Schicht kann darüber hinaus Teil eines Lern- und Feedbackprozesses werden. Kevin Martelli, Consulting AI Solution Development Leader bei EY Americas, beschreibt folgendes Beispiel: Angenommen, in einem Unternehmen müssen Zahlungen über 500.000 Dollar vom CFO genehmigt werden. Ein KI-Agent fordert die Genehmigung eines Mitarbeiters an.

Der Mitarbeiter erkennt jedoch: „Ich soll diese Rechnung freigeben, aber ich weiß, dass Beträge über 500.000 Dollar zusätzlich die Zustimmung des CFO benötigen.“

Diese Information kann anschließend dauerhaft gespeichert werden. „Sie kann innerhalb der Sitzung genutzt und anschließend als Prozessdokument oder Ereignisprotokoll wieder im Lakehouse abgelegt werden“, erklärt Martelli. Dadurch lernten agentische Systeme mit jeder Nutzung hinzu.

„Genau dadurch wird das System im Laufe der Zeit immer wertvoller – denn am ersten Tag wird man niemals alles perfekt modellieren können.“

Die semantische Schicht befindet sich allerdings noch in einer frühen Entwicklungsphase, wobei die verschiedenen Lakehouse-Anbieter unterschiedliche Ansätze verfolgen.

„In der Branche wird derzeit intensiv darüber diskutiert, wie Data Lakehouses und semantische Schichten zusammenwachsen und wo diese Schicht künftig eigentlich angesiedelt sein sollte“, erklärt Matt Arellano, SVP für Daten und KI bei der Digital-Transformation-Beratungsfirma Genpact. Einige Anbieter integrieren semantische Funktionen direkt in ihre Lakehouse-Plattformen oder kaufen entsprechende Spezialunternehmen hinzu. Andere Unternehmen setzen stattdessen auf spezialisierte Drittanbieter.

„Die Kunden tun sich damit schwer“, so Arellano. „Sie alle versuchen herauszufinden, welche Kombination aus Werkzeugen und Prozessen langfristig die richtige ist.“

Steven Karan, Vice President für KI-Transformation bei Capgemini Australien und Neuseeland, sieht im Lakehouse eine Entwicklung hin zu einer zentralen Orchestrierungsschicht.

„Unternehmen konzentrieren sich mittlerweile weniger auf klassische Analysen und Berichte, sondern vielmehr auf KI-gesteuerte Anwendungen und agentenbasierte Systeme“, erklärt er. „Die effektivsten Architekturen, die ich heute sehe, kombinieren einen Lakehouse-Kern mit spezialisierten Serverschichten.“

Dazu gehören Vektordatenbanken für KI, Streaming-Plattformen für Echtzeitdaten und operative Datenbanken für Anwendungen mit geringer Latenz.

Das Lakehouse diene nicht mehr nur der Analytik, fügt er hinzu. Es sei die Grundlage für Unternehmensdaten und KI. „Seine Aufgabe besteht heute weniger darin, alle anderen Systeme zu ersetzen, sondern vielmehr darin, sie miteinander zu verbinden, zentral zu steuern und zu überwachen. Damit soll sichergestellt werden, dass Unternehmen schneller innovieren können, ohne die Kontrolle über ihre Daten zu verlieren.“ (mb)

Dieser Artikel basiert auf einem Beitrag von CIO.com.

Operational autonomy is quickly becoming one of the defining capabilities of a modern enterprise. As digital estates become more distributed, cloud environments more dynamic and AI consumption more expensive and less predictable, traditional operating models begin to show their limits. Teams can no longer rely only on manual oversight, disconnected monitoring tools or periodic financial reviews to keep enterprise technology healthy and cost efficient. What is needed instead is a coordinated operating framework that brings together CloudOps, FinOps and AIOps, while also addressing the emerging discipline of AI token and model consumption governance. When these disciplines are designed as one connected system rather than as isolated workstreams, organizations move closer to operational excellence: faster decisions, better resilience, improved financial control, stronger compliance and a more measurable connection between technology investments and business outcomes.

What operational autonomy means in enterprise IT

Operational autonomy does not mean removing people from operations. In practice, it means designing enterprise IT so that routine sensing, decision support, remediation, optimization and policy enforcement happen with minimal friction and with the right human oversight at the right moments. A mature autonomous operating model continuously observes infrastructure, applications, data flows, AI services and financial consumption patterns; detects risk or inefficiency early; and triggers guided or automated action based on policy, confidence and business criticality. This approach depends on four connected pillars: CloudOps to maintain reliable and scalable digital infrastructure, FinOps to govern cost and value, AIOps to detect patterns and automate response, and AI consumption governance to manage token usage, model selection, inference workloads and unit economics.

Gartner’s 2024 research on FinOps for data and analytics emphasizes that cloud operations and financial governance are no longer separate concerns, especially as AI workloads reshape cost structures and accountability expectations. Forrester’s 2024 analysis of AIOps and observability similarly notes that modern enterprises need deeper operational visibility and broader insight-driven coordination to handle hybrid complexity. IDC’s 2024 perspective on future operations adds another useful lens by framing data-driven operations around agility, resilience and predictability. Taken together, these viewpoints reinforce the same idea: autonomy is not a tool purchase; it is a management framework.

Design principles for an enterprise operational autonomy framework

A practical framework begins with a few disciplined principles. First, the enterprise must build around a shared operational data layer. Telemetry from cloud infrastructure, applications, service management systems, security controls, business transactions and AI services should be normalized so that operations, finance and governance teams work from the same facts. Second, every automated action should be policy-aware. Cost optimization, scaling, failover, remediation, model routing, data retention and access control should all reflect business guardrails rather than isolated technical rules.

Third, the framework should be value-led rather than purely cost-led. FinOps has matured beyond simply lowering spend; the stronger objective is to align spend with business priorities, performance requirements and acceptable risk. Fourth, autonomy should progress in stages. Enterprises usually start with visibility, then introduce recommendations, then guided automation and finally closed-loop autonomy for low-risk scenarios. Fifth, executive accountability must be explicit. Operational autonomy touches architecture, finance, privacy, security, data stewardship and business strategy. Without a cross-functional ownership model, autonomy becomes fragmented and difficult to govern. Everest Group’s 2024 FinOps Cloud Cost Management assessment highlights the growing demand for role-based access, cost intelligence, governance and automation as core requirements for enterprise cloud cost management products. That is a useful signal that the framework must be built for collaboration, not just analytics.

Integrating CloudOps, FinOps and AIOps into one operating model

CloudOps, FinOps and AIOps are often discussed separately because each emerged from a different operational problem. CloudOps grew out of the need to run cloud estates reliably and at scale. FinOps developed in response to unpredictable consumption-based billing. AIOps emerged because traditional monitoring could not keep pace with the volume and complexity of telemetry generated across modern digital systems. Yet in a mature enterprise, these disciplines converge naturally.

A performance incident in a cloud platform is rarely only an availability problem; it may also drive higher infrastructure consumption, trigger excess logging charges, degrade customer experience or increase token usage in AI-enabled workflows. Similarly, a cost spike may not be a finance issue alone; it may reveal inefficient architecture, poor scheduling, unnecessary data movement or an AI agent behaving outside policy.

An integrated operating model therefore links observability signals, service context, business KPIs, financial metrics and automation rules into one decision fabric. CloudOps provides the runtime discipline, FinOps introduces value and accountability, and AIOps adds pattern recognition and intelligent response. When connected well, the enterprise can answer not only what is happening, but why it is happening, what it is costing, what risk it creates and what the best next action should be.

AI token optimization and AI cost spend governance

AI introduces a new cost curve into enterprise operations. Unlike traditional software costs, token spend can vary sharply based on prompt design, model choice, context length, retrieval patterns, orchestration logic, concurrency, caching strategy and user behavior. This makes AI cost governance an essential part of operational autonomy. A strong framework begins by defining the unit economics of AI consumption: cost per request, cost per conversation, cost per business workflow, cost per user segment and cost per outcome.

Once these baselines are visible, the enterprise can introduce optimization controls such as prompt compression, response-length policies, semantic caching, model tiering, workload routing to lower-cost models where quality tolerance allows, context-window discipline, batch processing for non-real-time use cases and approval thresholds for premium model usage. AI gateways and model brokers can enforce these policies consistently across teams.

Chargeback or showback mechanisms should also extend to AI services so that business units see both value and consumption behavior. Recent analysis in Forbes has drawn attention to the financial risks of unmanaged token growth and argues for governance layers that connect finance and engineering before AI expenditure becomes opaque. FinOps Foundation guidance on FinOps for AI reinforces the same message, noting that token-level metrics, quotas, tagging, GPU allocation practices and real-time monitoring are necessary to keep AI costs aligned to business value. In enterprise settings, the lesson is straightforward: if cloud cost needed FinOps, AI cost needs an even tighter form of FinOps because usage can scale much faster and become far less transparent as mentioned in IDC report.

FinOps for cloud infrastructure cost management

Cloud infrastructure cost management remains one of the foundational layers of operational autonomy because every autonomous workflow eventually rests on compute, storage, networking, platform services and data transfer. An effective FinOps capability does more than flag overspend after the month has ended. It creates near-real-time visibility into consumption, ownership, unit economics, forecast variance, commitments and waste patterns.

The enterprise should define standard practices for tagging, cost allocation, commitment management, rightsizing, idle resource detection, storage tiering, Kubernetes cost visibility, environment lifecycle controls and architecture reviews for high-cost services. More importantly, these practices should be tied to business context. For example, a workload serving a mission-critical customer channel may justify higher spend if it supports revenue protection, whereas a non-production environment should have stricter shutdown and spend caps.

Gartner’s 2024 research on FinOps for data and analytics underscores that AI and data workloads are changing the financial profile of cloud operations and increasing the need for more sophisticated tooling and governance. IDC’s market perspective on intelligent cloud and edge operations with FinOps software also points to the rapid growth of platforms that combine operations intelligence with financial control, suggesting that enterprises increasingly view operational management and cost management as linked disciplines rather than separate layers.

Autonomous operations through AIOps

AIOps gives the framework its intelligence and response speed. In most enterprises, operations data is noisy, fragmented and too voluminous for humans to interpret quickly during incidents or performance degradation. AIOps platforms reduce that burden by correlating events, identifying anomalies, clustering symptoms, surfacing probable root causes and recommending or initiating remediation actions. The best outcomes appear when AIOps is connected not only to infrastructure monitoring but also to service maps, change records, configuration data, incident workflows and business priorities.

That connection allows the enterprise to distinguish between a harmless signal fluctuation and an issue that threatens a critical business service. Forrester’s 2024 research on AIOps and observability explains this well by describing the complementary value of breadth and depth: observability provides richer technical insight, while AIOps helps transform those signals into operational action. In practice, autonomy grows when low-risk responses such as service restarts, resource adjustments, ticket enrichment, dependency checks or rollback decisions are automated under policy. High-risk actions should remain human-approved until confidence improves. Over time, the enterprise can move from reactive incident management to predictive operations, where emerging capacity risk, recurring error patterns or unusual AI workload behavior are addressed before service impact is visible to users.

How the framework leads to operational excellence

Operational excellence is the cumulative result of better decisions made earlier, faster and with clearer accountability. A well-designed autonomy framework improves service reliability because systems are observed continuously and remediation can be triggered before failures spread. It improves cost discipline because consumption anomalies are identified at the same time as performance or usage anomalies, not weeks later in a billing report.

It improves strategic focus because technology leaders can evaluate trade-offs in terms of business value rather than technical activity alone. It also improves employee productivity by removing repetitive operational effort and shifting skilled staff toward engineering improvements, policy tuning and service innovation. The most important outcome, however, is predictability. Enterprises become more confident in how they scale AI services, how they control cloud spend, how they handle operational events and how they meet compliance obligations. That confidence is what separates routine automation from genuine operational autonomy.

Security, governance, process implementation and people upskilling

No autonomy framework survives without strong security and governance. Automated operations amplify both efficiency and risk, which means identity controls, segmentation, least-privilege access, secrets management, encryption and auditability have to be embedded from the start. AI services add further concerns: prompt leakage, data residency, model misuse, training-data exposure, shadow AI adoption and uncontrolled access to external models.

Governance therefore needs to extend across cloud resources, operational workflows, AI services and data assets. Enterprises should establish clear policy domains covering infrastructure provisioning, AI model approval, token limits, vendor usage, observability data handling, retention rules, access reviews and exception management. Process implementation is equally important. The framework should define standard operating patterns for incident triage, automated remediation approval, cost anomaly review, model lifecycle management and post-incident learning. None of this works unless people are prepared for the shift.

Operations teams need skills in cloud economics, observability, automation engineering and policy-driven operations. Finance teams need to understand cloud and AI consumption models. Security and privacy teams need fluency in AI risk scenarios and control design. Business leaders need a clearer grasp of unit economics and value realization. IDC’s 2024 briefing on enterprise AI strategy highlights the tension between rapid AI investment, ROI pressure, staffing constraints, security and compliance. That is exactly why upskilling must be treated as part of the framework itself, not as an optional change-management activity as per FinOps Foundation documentation.

The role of regulatory compliance

Regulatory compliance is not a side topic in operational autonomy; it is one of the main reasons the framework must be formalized. Cloud environments frequently span jurisdictions, AI systems process sensitive information, observability platforms collect detailed operational data and automated decisions may influence customer experience or internal controls. Regulations such as GDPR, DPDP, sector-specific cybersecurity directives, financial reporting obligations, contractual data-handling requirements and internal audit standards all shape what autonomy can and cannot do.

Compliance requirements should therefore be translated into operational policy. Examples include residency-aware workload placement, data minimization in logs and prompts, access segregation for financial and regulated data, explainable automated actions, evidence retention, periodic control attestations and approval workflows for AI usage involving personal or confidential information. Chief privacy and data leaders play a central role here because the compliance question is no longer just where data is stored, but also how data is observed, transformed and consumed by AI-driven services. A mature framework reduces compliance risk by making control enforcement systematic rather than dependent on manual effort.

How to implement the framework in practice

Implementation is usually most successful when handled in phases. The first phase is baseline visibility: consolidate telemetry, cloud billing data, service inventory, AI usage data and business ownership into one operational picture. The second phase is governance design: define policies for tagging, spend thresholds, automation boundaries, access controls, model usage and compliance checkpoints.

The third phase is prioritization: choose a small number of use cases where autonomy can produce measurable value, such as cloud rightsizing, incident correlation, cost anomaly detection, AI token governance or automated remediation for recurring low-risk faults. The fourth phase is automation with guardrails: deploy workflows, approval rules and rollback paths. The fifth phase is optimization and learning: review outcomes, refine policies, update unit economics, expand autonomy coverage and measure business impact.

This staged approach matters because full autonomy is not achieved by switching on one platform. It is built progressively through trusted control, good data and disciplined execution.

Useful tools for building the framework

The tool landscape should be chosen based on architecture, governance maturity and operating model rather than vendor popularity alone. Cloud-native cost and operations tools from hyperscalers provide baseline visibility, but many enterprises supplement them with specialized FinOps platforms for allocation, forecasting, commitment analysis and chargeback. Observability platforms help unify metrics, logs, traces and service maps, while AIOps platforms add anomaly detection, event correlation and automation orchestration.

Service management platforms remain important for change control, incident workflows and audit evidence. AI gateways and model management layers are increasingly useful for token monitoring, policy enforcement, prompt controls, model routing and usage analytics. Security posture management, DSPM, identity governance and compliance automation tools also become part of the architecture because autonomy without trust quickly becomes fragile. The most effective toolchains are the ones that integrate technical telemetry, financial signals, governance policy and workflow automation into a coherent operating system for the enterprise.

Executive roles in developing and managing the framework

Here is a table that summarizes various Executive Roles and their responsibilities in Operational Autonomy governance.

Executive Role	Primary Responsibility in the Framework	Key Decisions and Governance Focus
CIO	Owns the enterprise operating model and ensures CloudOps, FinOps and AIOps are aligned to business service outcomes.	Sets operating priorities, funds enabling platforms, establishes accountability, sponsors service reliability and cost transparency programs, and chairs cross-functional governance.
CTO	Defines the target architecture for autonomy, including cloud platforms, observability, automation, AI services and integration patterns.	Approves technical standards, automation design principles, platform engineering choices, model architecture strategy and engineering guardrails for scale and resilience.
Chief Privacy Officer	Ensures that data use in observability, automation and AI operations complies with privacy law and internal policy.	Defines controls for personal data handling, retention, consent boundaries, cross-border transfer considerations, prompt and log privacy, and privacy impact assessments.
Chief Data Officer	Leads data governance, data quality, metadata management and trustworthy access to the shared operational data layer.	Defines data classification, stewardship, lineage expectations, AI data usage standards and interoperability rules required for accurate autonomous decision-making.
Chief Strategy Officer	Connects the autonomy framework to enterprise transformation goals, investment priorities and measurable business value.	Shapes business case design, prioritizes value pools, aligns the framework with growth and efficiency strategy, and ensures operating metrics support executive decision-making.

Conclusion

Developing operational autonomy for an enterprise is not about chasing a futuristic ideal. It is about building a disciplined and connected operating model that helps the organization run technology with greater confidence, speed and accountability. CloudOps keeps the estate reliable, FinOps ensures that spending reflects value, AIOps makes complexity manageable and AI cost governance brings much-needed control to token-driven consumption. Security, privacy, compliance, process rigor and people capability are what make the framework sustainable. When all of these parts work together, the enterprise does not just automate tasks; it strengthens resilience, improves financial stewardship and creates a more adaptive path to operational excellence.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Across the global corporations, I advise, in financial services, healthcare, retail and the public sector, the same crisis surfaces in leadership meetings. Executives approved a bold AI roadmap. Cloud spending climbed 40, 50, even 70 percent. And yet the AI workloads that made perfect sense in the boardroom presentation now stall, overshoot their budgets or collapse under production load before they reach real users.

I am writing this just after the spring 2026 conference season, and the signal from Google Cloud Next, Microsoft Build, and a run of AWS summits only sharpens the point. Over the past several weeks the industry shipped, in production form, the infrastructure to run and govern AI at scale. What most enterprises still lack is the operating model to decide how to use it.

The problem is not the AI models. The models work. The problem is that organizations built their AI ambitions on cloud strategies designed for a world that no longer exists: strategies built for SaaS applications, predictable traffic and linear cost curves. AI workloads break all three assumptions at once.

Why AI breaks traditional cloud assumptions

For a decade, cloud-first served enterprises well. It delivered elasticity, reduced capital expenditure and democratized access to compute, because enterprise workloads were predictable: web applications, ERP systems, databases and analytics pipelines that scaled smoothly and billed in ways finance could model on a spreadsheet. GenAI and agentic AI change every one of those assumptions at once.

When organizations move AI into production, real inference, retrieval pipelines, vector search and real-time decisioning, the cloud equation breaks in at least five ways:

1. Training clusters demand power densities far above standard compute.
2. Inference needs millisecond latency that network geography can defeat.
3. Vector databases generate cost spikes invisible in standard billing.
4. Agentic workloads chain hundreds of tool calls with cascading dependencies.
5. And data-sovereignty rules constrain where any of them can run.

In short, what works at the platform level fails at the workload level.

The costs are the first thing to surprise leaders, because they hide. CloudZero’s analysis and the FinOps teams I work with put it plainly: AI spend surfaces as generic compute, storage and instance line items, rarely labeled “AI.” Three layers drive most of the waste:

1. The most visible is LLM API cost, where stateless calls re-send the full conversation history on every request, so a deployment with a couple hundred users can burn many times the token budget in the business case.
2. The biggest is idle GPU: teams’ provision for peak and then run at 10 to 20 percent utilization, and most miss their AI cost forecasts by more than a quarter.
3. The most underestimated is the vector database and retrieval layer, where storage I/O, query volume and embedding refresh appear nowhere labeled AI until the bill arrives.

The dimensions leaders underweight resilience and control

Cost and latency dominate the conversation. Two dimensions rarely get the same rigor until something breaks:

1. Resilience, whether an AI-dependent system can survive failure, degrade gracefully and recover predictably.
2. Control, who can observe, halt and audit it.

AI introduces failure modes that traditional architecture never faced: GPU single points of failure under revenue-critical inference, agentic pipelines that fail mid-execution with no rollback, and models that degrade silently from drift or throttling.

I see the pattern repeated across industries. Organizations design resilience for their traditional applications, then deploy AI on top without asking whether the same guarantees hold. In one global financial services firm I advise, a real-time credit-decisioning model running on a single cloud region took a 47-minute outage during a regional availability event. The halted loan approvals cost more than the system’s entire annual infrastructure budget, and the resilience rework that followed cost several times what designing it in from the start would have. The leaders who avoid this should ask four questions before go-live:

1. What happens when the network fails?
2. What happens when the model degrades?
3. What happens when an agent executes only halfway?
4. Who holds the authority to halt and audit?

What the cloud providers signaled this spring

The major providers are on track to spend close to $700 billion on AI infrastructure in 2026, roughly three and a half times the 2024 level. Their announcements are strategic signals, not just features. Last year they converged on one message: enterprises cannot run everything in public cloud, so all three built ways to bring their infrastructure into your data center and your sovereign environment. This year the signal advanced a step. They stopped talking about where workloads run and started shipping the layer that governs what agents are allowed to do: identity, containment, auditability and rollback.

Microsoft introduced an “Agent Computer” model with execution containers and machine identity for agents. AWS built Amazon Bedrock AgentCore around runtime, memory, identity and auditability. Google shipped an agent gateway and sovereign controls for cross-cloud traffic. As Bain observed, agentic AI is now an economics and operations problem, not just a capability problem. The through-line, captured by Microsoft’s own framing, is that AI alone will not change your business; the system running it will. McKinsey’s read is consistent: workloads are becoming more distributed, specialized and operationally demanding, which forces more deliberate infrastructure decisions.

From platform choice to placement decision

The failure I document most often is not a technology failure; it is a governance failure. Most enterprises lack a clear, repeatable way to decide what runs where, under what conditions and with what tradeoffs. Platform teams make that call informally, under deadline pressure and repeat it hundreds of times as new use cases launch. Workloads then accumulate in public cloud by default, not by design and 30 to 50 percent cost overruns follow, not because public cloud was the wrong choice but because no deliberate choice was ever made.

In one global manufacturer I advise, a predictive-maintenance model went live on public cloud and performed exactly as validated in staging. But real-time inference on the factory floor ran at 80 to 120 milliseconds across the WAN, when the machine-control system needed under ten. Moving the model to edge nodes fixed the latency, but the company lost most of a quarter of the cost, rework and delayed benefits, and the line had run for weeks on stale recommendations: a control failure that could have caused a safety event. The fix was never more AI talent. It was a structured placement decision at the start, weighing six dimensions:

• Latency: real-time (under 10 ms, edge or on-prem), interactive (50 to 500 ms, cloud) or batch.
• Cost and TCO: token spend, GPU utilization, vector-database queries, egress and unit economics per workload.
• Resilience: failover architecture, degraded-mode behavior, recovery SLA and rollback policy.
• Control: observability, audit trails, governance authority and the ability to halt or reverse.
• Data sensitivity: sovereignty requirements, privacy and compliance rules, and IP protection.
• Integration: legacy system dependencies, pipeline complexity and data-residency constraints.

Run consistently, those dimensions produce a placement pattern like this:

Workload	Latency	Cost predictability	Data sovereignty	Recommended path
Customer-facing chatbot	200-500 ms	Medium	Low risk	Public cloud, reserved instances
Real-time fraud detection	Under 10 ms	Medium	High	On-prem or sovereign private cloud
Clinical decision support	100-300 ms	Predictable	Critical	Sovereign cloud or dedicated VPC
Demand forecasting (batch)	Hours	High	Low risk	Spot instances or scheduled cloud
Factory-floor vision AI	Under 5 ms	Predictable	Medium	Edge node (Azure Local, AWS on-prem)
Internal knowledge assistant	1-3 sec	Variable tokens	High (IP risk)	Private cloud with on-prem retrieval

This is no longer optional. Cloudian’s 2026 enterprise AI infrastructure survey found that 79 percent of enterprises have already moved AI workloads out of public cloud, and 93 percent are repatriating or actively evaluating it, driven by data sovereignty, cost overruns and real-time performance. Repatriation is now the norm, not the exception.

The agentic layer makes discipline urgent. An agent chains 20 to 100 tool calls, each with its own latency, cost and failure mode, so the governance model that works for a chatbot does not work for an autonomous agent approving procurement or onboarding a customer. This spring the providers shipped production infrastructure for exactly this, yet Deloitte’s 2026 survey of more than 3,000 leaders finds only about one in five companies has a mature governance model for autonomous agents. The platforms solved the mechanism. Most enterprises have not yet written the policy.

What the leaders do differently

The organizations extracting compounding value from AI, not just running experiments, share one discipline: they treat workload placement as a repeatable process, and they build resilience and control in from the start rather than after the first production incident. In practice, they do five things:

1. Classify every use case at intake across the six dimensions, before any infrastructure is provisioned.
2. Separate AI budget lines for experiments, production inference and training, so cost is governable.
3. Treat unit economics, cost per inference, per query and per agent run, as engineering KPIs, not month-end surprises.
4. Define repatriation triggers in advance, typically 12 to 18 months of stable volume.
5. Write an explicit resilience contract, and agentic observability and rollback rules, before scaling.

The gap between strategy-ready and infrastructure-ready is the remediation backlog, and most enterprises stall moving from proof of concept to production for exactly this reason. Deloitte’s tech-trends analysis frames the same shift as the move to inference economics: the bottleneck is infrastructure governance, not model capability.

For CIOs, a 90-day agenda. Five actions separate the leaders from those managing infrastructure crises:

1. Audit every AI workload in production across latency, cost, sovereignty, volume, resilience, control and integration.
2. Separate AI infrastructure budget lines so each workload type is attributable and governable.
3. Define unit economics by workload and review them as engineering KPIs.
4. Set a quantitative repatriation evaluation trigger.
5. Define observability, cost attribution and rollback policy before scaling agents.

The strategic reframe

The organizations making real progress on AI are not distinguished by the sophistication of their models or the size of their cloud contracts. One discipline sets them apart: a clear, repeatable way to decide what runs where, under what conditions, with what tradeoffs and what happens when something fails. That discipline is not an IT problem. It is a strategic capability that requires CIO ownership, CFO alignment and executive accountability.

This spring the cloud providers handed enterprises the infrastructure to run and govern AI, and agents, at every tier of the architecture. The gap is no longer supply. It is the operating model to use deliberately. The companies building that model now build the operating foundation for AI at scale. Everyone else builds a remediation backlog. The infrastructure decisions you make in the next 12 months will decide which of those two you become.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

For years, the enterprise narrative focused on moving to the public cloud for flexibility and leaving behind old infrastructure. While the public cloud remains a powerful platform for burst capacity, global reach, and modern application development, leaders now evaluate where each workload can achieve the best financial performance, operational efficiency, and risk. Cloud repatriation is back on the CIO’s agenda.

Cloud repatriation does not always mean dragging workloads back into a company-owned data center. In many cases, enterprises are moving applications and data from hyperscale public cloud platforms into colocation environments, hosted private clouds, or MSP-operated infrastructure. The common thread is not nostalgia for on-premises IT. It is the desire for a more suitable workload placement. Enterprises are deciding that some systems belong in public cloud while others are better served in environments with more predictable economics, tighter control, and fewer architectural compromises.

Cost is the loudest signal

The most common reason enterprises repatriate workloads is cost. Public cloud pricing works extremely well when demand is variable, when teams need rapid provisioning, or when a business wants to avoid upfront capital spending. But not every enterprise workload behaves that way. Many core systems are steady, always-on, data-intensive, and relatively predictable. For those workloads, usage-based pricing can become less attractive over time. Compute charges, storage growth, backup fees, inter-region traffic, and egress costs, especially, can add up in ways that were not obvious at the start of the migration.

This is often the point at which finance and infrastructure teams begin recalculating the total cost of ownership. A workload that seemed efficient during migration may look very different after two or three years of real-world use. Once a platform stabilizes, enterprises may conclude that dedicated hardware in a colo facility or an MSP-managed private environment delivers the same business outcome at a lower long-term cost. In that sense, repatriation is often less a retreat than a correction, a shift from paying for flexibility to paying for efficiency.

The issue is not simply that public clouds are expensive. Public clouds can be expensive in ways that are hard to forecast. Enterprise leaders increasingly want cost models that are easier to budget, easier to allocate, and less prone to surprises. Repatriated environments often offer that predictability. Even when they require more upfront planning, they can deliver cleaner unit economics for mature, high-utilization workloads.

Performance and data gravity

A second major driver is performance. Some applications benefit enormously from being physically closer to users, branch locations, industrial equipment, or large databases. Others depend on fast east-west traffic between tightly coupled systems or storage architectures that are difficult to optimize economically in the public cloud. When latency rises, throughput fluctuates, or data must constantly move across environments, the theoretical benefits of the cloud can be outweighed by practical performance limits.

In data-heavy environments, data gravity grows as data sets expand, creating a pull that favors moving compute closer to data instead of transferring data to compute locations. Examples include AI pipelines, media processing, industrial analytics, and large ERP ecosystems. Repatriation can enhance responsiveness and cut network costs.

Performance concerns also lead many enterprises to choose colocation or MSP-backed private platforms over fully self-managed on-premises infrastructure. They want local control and predictable performance without the operational burdens. This middle ground has become key to modern repatriation strategies.

Compliance, sovereignty, and security

Security and compliance are also central reasons enterprises repatriate workloads. Public cloud providers offer robust security capabilities, but the reality for enterprises is rarely about security features alone. They must consider governance, auditability, jurisdiction, segmentation, and accountability across a sprawling application landscape. For regulated industries, the burden of demonstrating compliance can grow significantly as cloud estates become more complex.

Data sovereignty has added another layer of pressure. Enterprises operating across borders increasingly need to know not only where data is stored but also which legal regime applies, who can administer the environment, and how cross-border movement is controlled. In that context, dedicated infrastructure in a known facility and under tightly defined operational terms can feel materially safer than a generalized hyperscale architecture spanning many services and regions.

This is why repatriation is more common among organizations with sensitive records, strict retention policies, or high audit overhead. Simpler controls and clearer infrastructure ownership improve risk posture. MSPs and private cloud providers benefit by offering better location control and managed operations.

Greater control and less lock-in

A fourth reason for repatriation is control. As platforms mature, leaders seek greater influence over architecture, upgrade cycles, network design, backup policies, and the selection of hardware and tools. Public clouds can do many things, but they also influence system design. Over time, some organizations want direct control, especially for critical systems affected by pricing, service limits, or provider strategy changes.

Control issues are tightly linked to vendor lock-in. Many public cloud migrations were sped up by using managed databases, analytics tools, messaging layers, and proprietary APIs. While these services boost speed, they also create dependency. Once integrated into a provider’s ecosystem, moving becomes costly and risky. Repatriation can restore portability, reduce dependence, and regain leverage in future negotiations.

For enterprises, this is not merely a technical preference; it is a governance issue. They want the freedom to place workloads where business conditions dictate, whether that means the public cloud, a private cloud, a colo cage, or an MSP-run platform. Repatriation helps restore their options.

Recalibration, not retreat

The most important point is that repatriation does not signal the failure of the public cloud. It signals the end of one-size-fits-all cloud thinking. Enterprises are becoming more disciplined about matching workload characteristics to the right operating model. In the past two decades, costs have become unpredictable, latency matters more, sovereignty rules are tightening, and governance has grown much more complex. Lock-in starts to limit options, and moving workloads out of the hyperscale cloud can become the rational choice.

In response to these developments, the decision-making process is growing correspondingly more sophisticated. Enterprises are no longer asking where the cloud fits into strategy. They are asking where each application and data set belongs. For a growing number of workloads, the answer is a more controlled environment closer to home.

For years, the enterprise narrative focused on moving to the public cloud for flexibility and leaving behind old infrastructure. While the public cloud remains a powerful platform for burst capacity, global reach, and modern application development, leaders now evaluate where each workload can achieve the best financial performance, operational efficiency, and risk. Cloud repatriation is back on the CIO’s agenda.

Cloud repatriation does not always mean dragging workloads back into a company-owned data center. In many cases, enterprises are moving applications and data from hyperscale public cloud platforms into colocation environments, hosted private clouds, or MSP-operated infrastructure. The common thread is not nostalgia for on-premises IT. It is the desire for a more suitable workload placement. Enterprises are deciding that some systems belong in public cloud while others are better served in environments with more predictable economics, tighter control, and fewer architectural compromises.

Cost is the loudest signal

The most common reason enterprises repatriate workloads is cost. Public cloud pricing works extremely well when demand is variable, when teams need rapid provisioning, or when a business wants to avoid upfront capital spending. But not every enterprise workload behaves that way. Many core systems are steady, always-on, data-intensive, and relatively predictable. For those workloads, usage-based pricing can become less attractive over time. Compute charges, storage growth, backup fees, inter-region traffic, and egress costs, especially, can add up in ways that were not obvious at the start of the migration.

This is often the point at which finance and infrastructure teams begin recalculating the total cost of ownership. A workload that seemed efficient during migration may look very different after two or three years of real-world use. Once a platform stabilizes, enterprises may conclude that dedicated hardware in a colo facility or an MSP-managed private environment delivers the same business outcome at a lower long-term cost. In that sense, repatriation is often less a retreat than a correction, a shift from paying for flexibility to paying for efficiency.

The issue is not simply that public clouds are expensive. Public clouds can be expensive in ways that are hard to forecast. Enterprise leaders increasingly want cost models that are easier to budget, easier to allocate, and less prone to surprises. Repatriated environments often offer that predictability. Even when they require more upfront planning, they can deliver cleaner unit economics for mature, high-utilization workloads.

Performance and data gravity

A second major driver is performance. Some applications benefit enormously from being physically closer to users, branch locations, industrial equipment, or large databases. Others depend on fast east-west traffic between tightly coupled systems or storage architectures that are difficult to optimize economically in the public cloud. When latency rises, throughput fluctuates, or data must constantly move across environments, the theoretical benefits of the cloud can be outweighed by practical performance limits.

In data-heavy environments, data gravity grows as data sets expand, creating a pull that favors moving compute closer to data instead of transferring data to compute locations. Examples include AI pipelines, media processing, industrial analytics, and large ERP ecosystems. Repatriation can enhance responsiveness and cut network costs.

Performance concerns also lead many enterprises to choose colocation or MSP-backed private platforms over fully self-managed on-premises infrastructure. They want local control and predictable performance without the operational burdens. This middle ground has become key to modern repatriation strategies.

Compliance, sovereignty, and security

Security and compliance are also central reasons enterprises repatriate workloads. Public cloud providers offer robust security capabilities, but the reality for enterprises is rarely about security features alone. They must consider governance, auditability, jurisdiction, segmentation, and accountability across a sprawling application landscape. For regulated industries, the burden of demonstrating compliance can grow significantly as cloud estates become more complex.

Data sovereignty has added another layer of pressure. Enterprises operating across borders increasingly need to know not only where data is stored but also which legal regime applies, who can administer the environment, and how cross-border movement is controlled. In that context, dedicated infrastructure in a known facility and under tightly defined operational terms can feel materially safer than a generalized hyperscale architecture spanning many services and regions.

This is why repatriation is more common among organizations with sensitive records, strict retention policies, or high audit overhead. Simpler controls and clearer infrastructure ownership improve risk posture. MSPs and private cloud providers benefit by offering better location control and managed operations.

Greater control and less lock-in

A fourth reason for repatriation is control. As platforms mature, leaders seek greater influence over architecture, upgrade cycles, network design, backup policies, and the selection of hardware and tools. Public clouds can do many things, but they also influence system design. Over time, some organizations want direct control, especially for critical systems affected by pricing, service limits, or provider strategy changes.

Control issues are tightly linked to vendor lock-in. Many public cloud migrations were sped up by using managed databases, analytics tools, messaging layers, and proprietary APIs. While these services boost speed, they also create dependency. Once integrated into a provider’s ecosystem, moving becomes costly and risky. Repatriation can restore portability, reduce dependence, and regain leverage in future negotiations.

For enterprises, this is not merely a technical preference; it is a governance issue. They want the freedom to place workloads where business conditions dictate, whether that means the public cloud, a private cloud, a colo cage, or an MSP-run platform. Repatriation helps restore their options.

Recalibration, not retreat

The most important point is that repatriation does not signal the failure of the public cloud. It signals the end of one-size-fits-all cloud thinking. Enterprises are becoming more disciplined about matching workload characteristics to the right operating model. In the past two decades, costs have become unpredictable, latency matters more, sovereignty rules are tightening, and governance has grown much more complex. Lock-in starts to limit options, and moving workloads out of the hyperscale cloud can become the rational choice.

In response to these developments, the decision-making process is growing correspondingly more sophisticated. Enterprises are no longer asking where the cloud fits into strategy. They are asking where each application and data set belongs. For a growing number of workloads, the answer is a more controlled environment closer to home.

Nach jahrelanger Erfahrung mit der Cloud glaubten IT-Führungskräfte, ihre Strategien diesbezüglich endlich fest im Griff zu haben. Dann kam die KI.

Die aktuellen Herausforderungen rund um die Cloud gehen jedoch weit über künstliche Intelligenz hinaus. Dazu zählen neben der Frage, wo Workloads für maximale Effizienz platziert werden sollten, auch Governance-Anforderungen, Datensouveränität, zunehmend ausgefeilte Cyberbedrohungen und steigender Kostendruck. All diese Faktoren machen die Cloud-Landschaft immer komplexer.

Mehr als ein Infrastrukturthema

„Das Ganze hat sich zu einem ziemlich komplexen Durcheinander entwickelt“, stellt der Cloud-Experte David Linthicum fest. Eine moderne Cloud-Strategie müsse heute Private Clouds, Multi-Cloud-Umgebungen, Hybrid-Cloud-Modelle und souveräne Clouds berücksichtigen – deutlich mehr, als die meisten CIOs bislang bewältigen mussten.

Anfangs drehten sich die Diskussionen rund um Cloud vor allem um Agilität, Skalierbarkeit und Kostenoptimierung, erklärt Joshua Bellendir, CIO des Einzelhändlers WHSmith North America. „Heute müssen wir eine wesentlich größere und komplexere Zahl von Faktoren berücksichtigen: KI-Bereitschaft, Cybersicherheit, Data Governance, Anforderungen an die Datensouveränität, Edge Computing, Integrationsarchitekturen und operative Resilienz.“

Eine der größten Veränderungen bestehe darin, dass die Cloud nicht mehr nur ein Infrastrukturthema sei, so Bellendir. „Sie ist inzwischen eng mit Unternehmensarchitektur, Business Transformation und Datenstrategien verknüpft.“

Auch Amit Basu, Vice President, CIO und CISO bei International Seaways, beobachtet zunehmende Komplexität. „Zwar gelten die Vorteile geringerer Investitionskosten und höherer Flexibilität in vielen Bereichen weiterhin, doch das Management der Cloud-Umgebung ist deutlich anspruchsvoller geworden.“, erklärt er.

Jason Johnson, CIO des Musikinstrumentenhändlers Sweetwater, beschreibt die aktuelle Situation als eine der komplexesten Phasen überhaupt für das Cloud-Management. Die Anbieter erweiterten ihre Portfolios kontinuierlich um neue Services, Produktvarianten und Optionen.

„Das schafft zwar zusätzliche Möglichkeiten, verursacht aber auch erheblichen Aufwand, um den Überblick zu behalten. Man braucht Fachkräfte, die nicht nur wissen, was verfügbar ist, sondern auch beurteilen können, welche Lösung für den jeweiligen Anwendungsfall die richtige ist“, meint der IT-Entscheider.

Viele Unternehmen würden inzwischen in eine zweite Phase ihrer Cloud-Reife eintreten, nachdem sie in der ersten Phase den Fokus auf Migration und Modernisierung gelegt hätten, erklärt Johnson. „Heute geht es stärker um Optimierung, Governance, KI-Unterstützung und nachhaltigen Betrieb. Dieser Wandel verändert die Diskussionen, die ich mit CIOs führe, grundlegend.“

Die wenigsten CIOs können es sich jedoch leisten, lange über ihre nächsten Schritte nachzudenken. Sie müssen den Herausforderungen zunehmend komplexer werdender Cloud-Strategien aktiv begegnen.

Wie KI die Cloud-Gleichung verändert

„Der Wunsch, KI möglichst schnell einzuführen, setzt IT-Verantwortliche erheblich unter Druck. Dabei spielt die Cloud eine zentrale Rolle“, führt Linthicum aus. „Die Aufsichtsräte treiben das Thema noch stärker voran als den Cloud-Boom vor 15 Jahren“, erklärt er. CIOs spüren diesen Druck und müssen so schnell wie möglich handeln, um zusätzliche Rechenkapazitäten für KI-Initiativen bereitzustellen – und das in einem ohnehin schon komplexen Umfeld.“

Gleichzeitig müssten CIOs das Problem der Datenkomplexität lösen, bevor KI-Systeme erfolgreich integriert werden können, betont der Cloud-Experte. „Derzeit drehen sich viele im Kreis und versuchen herauszufinden, welcher Ansatz dafür der Beste ist.“

Hyperscaler galten früher als der einfache Weg, so Linthicum, könnten aber drei- bis viermal so teuer werden. KI-Systeme kosten seiner Einschätzung nach etwa zehnmal so viel wie vergleichbare, traditionelle Anwendungen.

Basu von International Seaways erklärt, dass KI die Diskussion über die IT-Architektur grundlegend verändert habe. „Die Verfügbarkeit von GPUs, Vektordatenbanken, Inferenz mit geringer Latenz und groß angelegte Datenpipelines bringen Anforderungen mit sich, die sich nicht nahtlos in herkömmliche Cloud-Designmodelle einfügen“, merkt er an. Unternehmen verlagern Workloads nicht mehr einfach nur in die Cloud. Sie entwerfen Architekturen für völlig andere Rechen- und Datenanforderungen.“

Laut Zachary Lewis, CIO und CISO der University of Health Sciences and Pharmacy, verstärkten die Bedürfnisse interner Stakeholder diese Komplexität noch. „Geschäftsbereiche wünschen sich unterschiedliche KI-Fähigkeiten, Sicherheitsteams wollen Governance und eine gewisse Kontrolle über KI-Anwendungen, der Justiziar möchte wissen, welche Art von Daten in das KI-Modell eingespeist werden, und das Finanzteam erwartet Kostenvorhersehbarkeit. CIOs müssen all dies unter einen Hut bringen – und das erfolgreich versteht sich“, so Lewis.

Seit der Online-Händler für Musikinstrumente und professionelle Audiotechnik Sweetwater seine Cloud-Strategie um das Jahr 2016 formalisiert hat, versucht Johnson, Workloads dort zu platzieren, wo sie für externe und interne Kunden den größten Nutzen bringen.

„Alles mit Kundenkontakt muss so nah wie möglich am Endnutzer ablaufen“, erklärt er. Die gleiche Logik gilt auch für interne Workloads: Sie gehören in die Nähe derjenigen, die sie nutzen. KI wäre ohne die Cloud nicht möglich. Die für KI erforderliche Rechenkapazität war bereits vorhanden – die Cloud verfügte darüber und konnte sie bereitstellen. In vielerlei Hinsicht ist KI vielleicht das größte Geschenk der Cloud an die Branche. Beide haben sich gegenseitig ermöglicht“, fügt der Manager hinzu.

Cloud-Kostenmanagement wird immer komplexer

Johnsons größtes Problem ist die konsistente Steuerung der Kosten. „Früher war es relativ einfach: Rechenleistung, Speicher, Datenverkehr. Heute ist es ein Puzzle. Reservierte Instanzen, Sparpläne, Spot-Preise, Kosten pro Anfrage, Gebühren für Datenübertragungen zwischen Regionen – das summiert sich schnell. Und es ist wirklich schwer vorherzusagen, wie Ihre Rechnung aussehen wird, bis sie eintrifft.“

Deshalb sei FinOps inzwischen zu einer eigenen Disziplin geworden.

Auch Basu hält FinOps für unverzichtbar. „Kosten für KI-Inferenz, Datenübertragungen und wachsende Speichermengen können monatliche Kostenschwankungen verursachen, die selbst erfahrene Teams überraschen“, führt er aus. Kostenmanagement ist heute eine kontinuierliche operative Disziplin und nicht mehr nur eine gelegentliche Überprüfung.“

Auch die Gefahr des Vendor Lock-in beschäftigt Johnson ständig. „Je tiefer man die nativen Dienste eines Anbieters integriert, desto schwieriger wird ein Wechsel. Das ist nicht zwangsläufig schlecht, aber ein Kompromiss. Ich sehe das wie technische Schulden. Man gewinnt heute Geschwindigkeit und zahlt später Zinsen, wenn man die Richtung ändern möchte.“

Gleichzeitig erkennt Johnson an, dass Cloud-Anbieter Unternehmen sind, die auf Umsatz und Marge achten und regelmäßig die Regeln für Rabatte und Kostenmodelle ändern.

Finanzielle Effizienz entstehe nicht von selbst, betont er: „Das erfordert Teams, Prozesse und echte Investitionen in FinOps. Die Werkzeuge sind vorhanden. Die eigentliche Herausforderung besteht darin, sie richtig einzusetzen.“

In den meisten Unternehmen liege das Finanzwissen in der Buchhaltung und das technische Wissen in der IT, erklärt Johnson. Beide Gruppen beim Cloud-Kostenmanagement zusammenzubringen, sei eine vergleichsweise neue Herausforderung.

„Vor zehn Jahren war das Modell einfach: Man beantragte ein Investitionsbudget, die Buchhaltung genehmigte es, Hardware wurde bestellt und die IT installierte und optimierte alles. Fertig“, sagt Johnson. „Heute ist es eine tägliche Aufgabe. Neue Dienste werden aktiviert, Verträge ändern sich, Preisstrukturen werden angepasst. Die Finanzabteilung versteht die Geldströme, aber nicht die Technik. Die IT versteht die Technik, aber nicht die finanziellen Hebel.“

Jeder große Cloud-Anbieter verfügt über die entsprechenden Tools, erklärt Johnson. „AWS Cost Explorer, Azure Cost Management, die Abrechnungs-Dashboards von Google Cloud. Die Daten sind alle vorhanden. Doch viele Unternehmen nutzen diese Daten nicht. Dann kommt die Rechnung und alle sind überrascht. Die Werkzeuge haben die Entwicklung angekündigt. Man hat nur nicht hingehört.“

Datenregulierung bringt zusätzliche Herausforderungen

Die University of Health Sciences and Pharmacy hat Studierende aus der ganzen Welt. Laut Lewis ist Cloud-Management aufgrund der zunehmenden Datenschutz- und Regulierungsanforderungen weltweit deutlich schwieriger geworden.

„Wir müssen verstehen, in welcher Cloud-Region Metadaten gespeichert werden und wo sie dauerhaft liegen. Wenn diese Daten in ein intern trainiertes Modell einfließen, können wir garantieren, dass sie in der EU bleiben? Und wenn jemand die Löschung seiner Daten verlangt, können wir alle Speicherorte zuverlässig identifizieren?“

Basu ergänzt, dass Datensouveränität zu einer weiteren zentralen Architekturfrage geworden sei.

„Sie beeinflusst, wo Workloads ausgeführt werden dürfen, wie Daten zwischen Regionen bewegt werden und was mit bestimmten Datensätzen geschehen darf. Man kann nicht davon ausgehen, dass die Standardkonfiguration eines Hyperscalers automatisch alle regulatorischen Anforderungen erfüllt.“

Private Cloud, Public Cloud oder On-Premises?

KI hat eine Neubewertung der Platzierung von Workloads ausgelöst. Johnson glaubt jedoch, dass sich die Frage nach Private Cloud, Public Cloud oder On-Premises häufiger verändert, als viele denken.

„Ich denke, die meisten unserer Workloads befinden sich derzeit am richtigen Ort. Aber wir sind nur dorthin gelangt, weil wir bereit waren, Standardannahmen zu hinterfragen.“

Bei Sweetwater gebe es keine Regel, dass neue Workloads automatisch in die Cloud gehören. Ein Workload könne in der Cloud starten und später wieder ins eigene Rechenzentrum zurückkehren, wenn die Wirtschaftlichkeit dies erfordert.

„Die eigentliche Disziplin besteht darin, dies laufend zu überprüfen, Wendepunkte zu erkennen und die Größe der Umgebung kontinuierlich anzupassen. Das richtige Werkzeug zur richtigen Zeit – das ist das einzige Prinzip, das langfristig Bestand hat.“

Basu plant keinen Umstieg auf eine Private Cloud, da die Wirtschaftlichkeit und der betriebliche Aufwand dies für sein Unternehmen nicht rechtfertigen.

„Die richtige Frage lautet: Welches Modell für Datenresidenz, Latenz und Kontrolle ist für jeden Workload angemessen? Das ist eine Frage der Datenklassifizierung, nicht der Cloud-Bereitstellungsstrategie.“

Lewis, dessen Universität rund 95 Prozent ihrer Infrastruktur in der Cloud betreibt, sieht angesichts der Anforderungen von KI und moderner Hardware kaum praktikable Alternativen.

„Wenn man groß angelegte Data Lakes trainieren und fundierte Geschäftsentscheidungen mithilfe von maschinellem Lernen und der dahinterstehenden Intelligenz treffen möchte, ist es fast nicht mehr praktikabel, auf eigene Server zu setzen“, so Lewis.

CIOs müssten sich fragen, ob sie überhaupt über das notwendige Know-how verfügen, um eine solche Infrastruktur selbst zu betreiben. Letztlich müsse man das Beste aus den vorhandenen Möglichkeiten machen.

Fokus auf die Grundlagen

Unternehmen mögen vielleicht dem neuesten Trend hinterherjagen – derzeit ist das die agentische KI –, doch IT-Führungskräfte sollten sich auf ihre Infrastruktur, das Management und die Plattformplanung konzentrieren, betont Linthicum.

„Das ist vielleicht weniger spannend, aber wenn man KI im Unternehmen einsetzen will, muss man diese Probleme zuerst lösen.“

Johnson warnt, dass die Cloud eine Vielzahl architektonischer Muster ermöglicht – und diese Freiheit könne ohne Leitplanken zum Problem werden. „Erstellen Sie das Leitliniendokument, bevor Sie es brauchen – nicht erst, wenn bereits fünf Teams auf fünf verschiedene Arten vorgehen.“

IT-Verantwortliche sollten außerdem frühzeitig für ein sauberes Tagging und Transparenz bei den Kosten sorgen. Das müsse der erste Schritt sein und dürfe nicht erst als Aufräumprojekt betrachtet werden, warnt Johnson: „Wenn Sie Ihre Ausgaben nicht vom ersten Tag an klar nachvollziehen können, sind Sie bereits im Rückstand.“

Ein weiterer wichtiger Schritt sei der Aufbau eines Audit-Programms mit klaren Kontrollen darüber, wer Änderungen an Produktivsystemen vornehmen darf: „Die Auswirkungen einer fehlerhaften Änderung in der Cloud sind größer und treten schneller ein, als die meisten Menschen erwarten – bis sie es selbst erleben.“

Die Frage nach den Kompetenzen

Die Fähigkeiten, die für den Betrieb moderner Cloud-Umgebungen erforderlich sind, entwickeln sich laut Basu schneller weiter, als die meisten internen Teams realistischerweise mithalten können. Deshalb setzt International Seaways auf spezialisierte Managed Service Provider (MSPs), anstatt in jedem Bereich tiefgehendes internes Expertenwissen aufzubauen.

„Dadurch haben wir Zugang zu aktuellen Fähigkeiten, ohne Teams ständig umschulen oder neu aufbauen zu müssen, wenn sich die Technologie ändert. Die Entscheidungen, die uns 2020 geschützt haben, wurden Jahre zuvor getroffen – lange bevor jemand ihre Bedeutung erkannt hatte. Infrastrukturstrategie bedeutet immer, sich auf eine Zukunft vorzubereiten, die noch nicht vollständig sichtbar ist.“

Entscheidend sei, solche Entscheidungen bewusst und auf Basis klarer Überlegungen zu treffen, anstatt später unter Druck reagieren zu müssen.

Anpassungsfähige Organisationen aufbauen

Edge-Computing fügt laut Johnson eine weitere Ebene der Komplexität hinzu. Erfolgreich werden nicht diejenigen sein, die die perfekte Architektur finden. „Es sind diejenigen, die Organisationen aufbauen, die sich schnell anpassen können, wenn sich die richtige Antwort morgen ändert“, erklärt er.

Der eigentliche Wettbewerbsvorteil liege nicht in der gewählten Cloud-Plattform, sondern darin, wie schnell ein Team lernen und handeln kann, so Johnson.

Auf die Frage, wie sich Cloud-Umgebungen weniger kompliziert gestalten lassen, gaben die CIOs folgende Empfehlungen:

• Behandeln Sie Ihre Cloud-Architektur wie ein Produkt, nicht wie ein Projekt. Sie benötigt kontinuierliche Verantwortung und Weiterentwicklung, nicht nur eine einmalige Implementierung.
• Überprüfen Sie Ihre Entscheidungen regelmäßig. „Die richtige Entscheidung im ersten Jahr ist oft nicht mehr die richtige im dritten. Planen Sie feste Überprüfungspunkte ein“, erklärt Johnson.
• Ordnen Sie jeden Workload einer Kostenstelle zu. Basu hat dies umgesetzt; die IT überprüft kontinuierlich Auslastung und Größenanpassungen, anstatt auf periodische Audits zu warten.
• Die Datenklassifizierung bestimmt die regionale Platzierung. Bevor ein Workload in Produktion geht, sollten Rechts- und Compliance-Abteilungen von Anfang an eingebunden sein.
• Entwickeln Sie Cloud-fähige Lösungen. Das kann günstiger und risikoärmer sein als die unveränderte Migration stark angepasster Altsysteme.
• Konsolidierung ist eine strategische Entscheidung, kein Rückzug. Weniger Plattformen, die gut gesteuert werden, schneiden dauerhaft besser ab als eine zersplitterte Multi-Cloud-Landschaft.
• Unterschätzen Sie nicht die Governance-Lücke, die durch KI entsteht. Schaffen Sie jetzt eine KI-Governance-Struktur, bevor sich technische und organisatorische Schulden anhäufen.
• Cloud-Strategie ist keine reine IT-Architekturentscheidung. Die Pandemie habe gezeigt, dass sie vor allem eine Entscheidung zur Sicherung der Unternehmensresilienz sei. „Die Organisationen, die schwierige Entscheidungen vor einer Krise treffen, sind diejenigen, die unbeschadet daraus hervorgehen.“
• Verknüpfen Sie Cloud-Entscheidungen mit messbaren Geschäftsergebnissen. Bellendir von WHSmith berichtet, dass sein Unternehmen stark in Integrationsarchitekturen, Cybersicherheitskontrollen, Observability und Data Governance investiert, um hybride Umgebungen besser zu unterstützen.
• Legen Sie größeren Wert auf Cloud-Kostenkontrolle und operative Disziplin. Dadurch wird die Transparenz über die Cloud-Nutzung verbessert und sichergestellt, dass die Skalierung von KI-, Analyse- und Digitalisierungsinitiativen langfristig finanziell tragfähig bleibt.

Auch wenn niemand vorhersagen kann, ob Cloud-Umgebungen künftig weniger komplex werden, werden Unternehmen sie weiterhin nutzen.

„Die Cloud ist nicht mehr die Zukunft der IT – sie ist die Gegenwart. Die Diskussion hat sich von der Frage ‚Sollen wir das tun?‘ hin zu ‚Wie werden wir darin besser?‘ verschoben. Und genau damit verbringe ich heute den Großteil meiner Zeit“, konstatiert Johnson. (mb)

Dieser Artikel basiert auf einem Beitrag von CIO.com

---

SaaSおよびAIソフトウェア市場は価格の大転換期に入っている。従来型のSaaSと競合するAI製品の登場により、SaaSベンダーはシートベース（ユーザー数基準）の価格設定の見直しに迫られている。見直しの結果、従来型SaaSの価格はアウトカムベース（成果連動型）課金へと移行しつつある、これはCIOとCFOにとっては概ねプラスの動きだ。一方、一部のAIツールやSaaSパッケージは消費量ベースの課金へと向かっており、利用状況を注意深く管理しなければ、請求額が想定外に膨らむリスクがある。

CRMデータプラットフォームプロバイダーTwilioの戦略・オペレーション担当ディレクター、Sidharth Ramsinghaney氏は「最も差し迫った問題は、ほとんどの組織がこれまで経験したことのない予算の変動だ。この転換は、ベンダーから買い手に予測リスクを移転するものだ」と言う。Gartnerによれば、2030年までにエンタープライズSaaSの支出の少なくとも40%が利用量、エージェント、アウトカムベースの課金に移行し、シートベースのベンダー収益シェアは21%から15%に低下すると予測されている。

AIエージェントは価格モデルを揺るがす可能性を持っている。「AIエージェントが人間の業務を代替するようになれば、この予測は現実になる。以前は10人が必要だった仕事を1つのエージェントがこなせるなら、ユーザー数に基づくシートベースの課金は意味をなさなくなる」とRamsinghaney氏は言う。ただし、エージェントの導入が停滞すれば、シートベースの価格設定が長く続く可能性もある。不確実性が続けば、ハイブリッド型の価格設定がデフォルトになる可能性もある。

アウトカムベース課金の難しさ

一部の顧客がアウトカムベースの価格設定を求め、一部のベンダーが試験的に導入している。だが、実現は容易ではない。「アウトカムの帰属を明確に測定することが本質的に難しい」とRamsinghaney氏、「そのため、純粋なアウトカムベースの価格設定は多くのカテゴリーでまだ理想論にとどまる」と続ける。ソフトウェアコンサルティング会社Software Improvement GroupのCTO、Jasper Geurts氏も同意する。多くのAIベンダーはアウトカムではなく、シートベースと利用量の組み合わせに動いている。「エージェントはテストに合格しながら、誰も後から手を加えられない質の低いコードを生成することがある。機能すればいいという成果のみに課金するなら、将来の負債となるコードに対してお金を払っているのと同じだ」とGeurts氏は言う。

トークン経済の不透明さ

AIベンダーのコスト構造は従来型SaaSとは異なる。フロンティアAIモデルのコストは下がるどころか上がっており、AnthropicのFable 5モデルはOpus 4.8の2倍のトークン単価だとGeurts氏は指摘する。「CIOたちはトークン経済が不透明だと言う。エージェントがどれだけトークンを消費するか予測できなければ、請求額の見通しが立てられない。CIOはトークンを10年前のクラウド支出と同様に扱うべきだ——つまり計測し、管理し、成果と結びつける必要がある」。

「シートベースの価格設定はヘッドカウントで請求額を抑えられた。利用量ベースの価格設定は消費量に応じてスケールする。AIがアシスタントから自律的なコーディングに移行するにつれ、コードの量はレビューしきれないほど増える。誰もレビューしきれないコードが積み上がれば、それ自体が将来の負担になる」とGeurts氏は言う。

サブスクリプション価格も上昇している。Lorka AIの調査によれば、2023年に無料または低価格だったAIツールは今や社員1人あたり月額20〜30ドルが平均となり、プレミアムプランは月額200ドルに達するものもある。複数のAIツールを使う企業では、機能が重複する製品を含めて、1人あたり年間1200ドル以上を支出しているケースもある。

ITリーダーが今すぐ取るべき対策

ソフトウェア開発会社InnowiseのCIO、Maksim Hodar氏は「CIOはサービスの調達方法と利用量の両方に注意を払う必要がある」と助言する。そして、「利用状況の分析を通じてコスト管理策を特定し、どの価格モデルが自社のビジネスケースに最適かを判断すべきだ。また、新しい価格モデルを持つ新しいソフトウェアを本格導入する前にパイロットを実施することも勧める。「業界のトレンドに流され、単に皆がやっていることをやってしまいがちだ」とHodar氏は警告する。

Ramsinghaney氏は、FinOps（クラウドや技術コストの最適化の取り組み）をまだ取り入れていないITリーダーは今すぐ始めるべきだ、と言う。トークンやその他の利用状況を追跡し、機能がそのコスト以上の価値を提供しているか確認することが重要だ。アウトカムベースの価格設定に移行する場合は、ソフトウェアやプラットフォームプロバイダーと明示的なアウトカム測定の合意を結ぶべきだと言う。「帰属の争いがこうした契約を崩壊させる。アウトカムベースの価格設定は、双方が帰属について合意できる場合にのみスケールする」（Ramsinghaney氏）。

専門家たちの見解をまとめると、複数の価格モデルが共存する形が現実的、ということになる。利用量ベースはインフラとAPI主体の製品に、アウトカムベースは解決済みサポートチケットや完了したワークフローのように成果が明確に測定できる場合に適している。

このようなハイブリッドモデルがベンダーの収益予測と買い手のコスト整合のバランスを取る支配的なモデルになるとRamsinghaney氏は見る。ソフトウェアが人間の業務を代替するのではなく補強するコラボレーションツールや業務アプリケーションでは、引き続きシートベースが生き残る、との予想を示した。

専門家の採用はむしろ容易になった。SOCアナリスト、ML研究者、クラウドアーキテクト——こうした職種は数週間で採用が決まる。一方、採用に6〜9カ月かかるのはハイブリッドな職種だ。AIに精通しながらコードにも深く入り込め、ビジネスも理解できるエンジニア。「3つのスキル、1人の人物、少ない候補者プール」とBest BuyのCDTOであるNeal Sample氏は言う。「これらのハイブリッド人材がITの未来だ——現時点でこのようなハイブリッド人材は見つけるのがとても難しい」。

AIがサイバーセキュリティを抜いて採用最難関スキルになって2年が経過する。2026年のState of the CIO調査では、AI/機械学習とサイバーセキュリティが同率1位となり、データサイエンス・分析が僅差で続く、という結果になった。ランキングは似ているが、人材難の性質は変わった。LLMエンジニアやプロンプトスペシャリストへの需要は、AIをスケールで実用化し、リスクを管理し、盲目的に信頼せずに使いこなせる人材への需要に変わった。

リスク管理は初めてトップ5入りし、ビジネス・IT自動化は上位を維持している。一方で数年前まで注目されていた職種への需要は緩んでいる。その1つがクラウドアーキテクチャだが、今年は順位を落とし、アプリケーション開発もリストから外れた。「採用が最も難しいのは、AIとの組み合わせが求められる職種すべてだ」とValcom TechnologiesのITアドバイザー、Niel Nickolaisen氏は言う。

採用困難なIT職種：2026年 vs. 2024年

スキル	2026年	2024年	変化
AI/機械学習	1位（同率）	1位	横ばい
サイバーセキュリティ	1位（同率）	2位	上昇
データサイエンス・分析	3位	3位	横ばい
ビジネス・IT自動化	4位	4位（同率）	横ばい
リスク管理	5位	8位（同率）	上昇
ソフトウェアエンジニアリング	6位（同率）	6位（同率）	横ばい
DevOps/DevSecOps	6位（同率）	11位（同率）	上昇
エンタープライズアーキテクチャ	8位（同率）	10位（同率）	上昇
クラウドサービス・統合	8位（同率）	12位（同率）	上昇
クラウドアーキテクチャ	8位（同率）	6位（同率）	低下
デザイン思考・UX	8位（同率）	15位（同率）	上昇

出典：Foundry/CIO.com State of the CIO Survey、2024年および2026年

AI採用の成熟

「プロンプトエンジニアリングは単独の職種としては短命だった。現在はベースラインのスキルになっている」とSample氏は言う。多くの組織が求めるのは別のものだ——エージェントを立ち上げ、テストフレームワークを構築し、コスト・レイテンシ・品質のトレードオフを管理し、AIをスケールで展開できるAIプロダクトエンジニアだ。3年前は存在しなかったガバナンスやレッドチームの役割も生まれている。「モデルを作る人からモデルを使いこなす人へ、重力の中心が移った」とSample氏は言う。

このように、求められるスキルは、プロンプトエンジニアリングよりもエージェンティックAIの活用へとシフトしている。「ワークフロー、プロセスの簡略化を理解し、エージェントプラットフォームで業務を自動化できる人材が必要だ」とNickolaisen氏は言う。課題は、AIが急速に進化しているため、ある企業での経験が別の企業で通用しない可能性があること、また6カ月前に学んだことがすでに時代遅れになっている可能性があることだ。

サイバーセキュリティ——人数の問題ではなく、スキルの問題

サイバーセキュリティがAIと同率1位になったのは、単なる需要の増加だけでなく、課題の質的変化を反映している。SANS/GIACの2026年サイバーセキュリティ人材レポートによれば、6割の組織がスタッフ不足よりスキルギャップを主な課題として挙げており、1年前から20ポイント増加した。サイバーセキュリティリーダーの27%がスキルギャップと直接結びついた侵害を報告し、61%がチームのストレスが過去2年で増加したと言う。

スキル不足はエントリーレベルではなく、シニアアーキテクトの層にある。「本当に必要なのは、ダッシュボードを読むだけでなく、実際の制約の中でセキュリティの判断を下せる人だ。そういう人材は引く手あまたで、高い報酬を要求できる」とSample氏は言う。

SANSの調査では、74%の組織がAIがすでにサイバーセキュリティチームの規模と役割に影響を与えていると回答。SOCアナリストなどのエントリーレベルの職種が削減される一方、AI/MLセキュリティスペシャリストやAIガバナンスアナリストなど新しい役割が生まれている。

「二次的なAIスキル」の台頭

自動化とリスク管理スキルが両方ともトップ5入りを果たした。理由は同じだ。「AIがサーフェスエリアを拡大した。展開するエージェントはすべて新たな自動化であり新たなリスクだ。多くのGRC（ガバナンス・リスク・コンプライアンス）や業務部門はそのペースに対応できるよう設計されていない」とSample氏は言う。

自動化の需要はRPA開発者ではない——そこはコモディティ化した。必要なのはプロセスを見て何を自動化し、何を廃止し、何を再設計するかを判断できる人だ。「それは3つの仕事を一つにしたものだ。ビジネスアナリスト、プロセスエンジニア、テクノロジスト。3つすべてをうまくこなせる人は希少で、高額だ」とSample氏は言う。

リスク管理も同様だ。SOXやPCIコンプライアンスのために作られたGRC機能は、モデルリスク、プロンプトインジェクション、サードパーティのAIリスクに最適化されていない。「20年前の職務記述書に基づいて5年程度の新しい規律の採用をしている。そのギャップが問題だ」とSample氏は言う。

中堅層のジレンマ

AIコーディングツールはソフトウェアエンジニアへの需要を減らしてはいないが、その性質を変えた。優秀なエンジニアとAIツールの組み合わせで、数年前の3人分の成果が出る。「プレッシャーがかかっているのは中間層——APIをつなぎ合わせることが日常業務だった人たち」とSample氏は言う。

採用は二極化している。判断力とオーナーシップを持つ経験豊富なリーダーと、最初からAIネイティブなジュニア人材への需要は高い。「中堅で惰性的に仕事をしてきた人たちは、自分が採用市場で不利な立場にいることに気づき始めている」とLarridinのCTO、Ameya Kanitkar氏は言う。

クラウド職種の採用は安定

クラウド職種の採用は容易になった。多くの組織はクラウドの安定期に達し、パブリック、プライベート、オンプレのワークロードが確立している。ただし一部の専門領域——FinOps、規制業界の移行、逆移行（クラウドからオンプレへ）——は依然として人材が少ない。「特にAI推論は、クラウドのユニットエコノミクスがスケールで厳しくなる。それがスキルの組み合わせを再び変えている」とSample氏は言う。

ギャップを埋めるために有効な手段

ITリーダーの間で一致しているのは、社内でのスキルアップと異動が外部採用よりスピード、コスト、定着率の面で効果的だということだ。「2025年に最も生産性が高かったAIエンジニアは、AIエンジニアとして採用された人ではない。優秀なソフトウェアエンジニアを社内トレーニングと実際のプロジェクトを通じてAIに対応させた人たちだ」とSample氏は言う。

Best BuyのSample氏は、AIの採用を別のパイプラインとして扱うのをやめたことで、才能のプールが10倍以上広がったと言う。「まずエンジニアとして採用し、AIの使い方は後から教える。この考え方に変えるだけで、候補者のプールが10倍以上広がり、成果も上がった」。

CompTIAのJames Stanger氏は「最も進んでいる組織は、『どの大学を出たか』ではなく、『どんなスキルを持っていて、それで何を実現してくれるか』を問うようになっている」と言う。

「「2023年のプロンプトエンジニア採用ブームは18カ月で終わり、その役割に就いた人たちは今スキルを磨き直している。同じ過ちを、今度はエージェンティックAIで繰り返している組織がある。職種名ではなく、ケイパビリティで採用しなければ、同じ結果になる」とSample氏は言う。

Key takeaways

• Backstage solved the portal problem, not the platform problem. A portal organizes catalogs, documentation, and templates. A platform owns deployments, environments, policies, and runtime operations. Backstage assumes that the execution layer exists beneath it.
• Point-to-point integrations become a maintenance burden. Many organizations end up with a “messy middle” where Backstage is connected directly to CI/CD, GitOps, Kubernetes, and observability tools through custom wiring that’s fragile and hard to evolve.
• Abstractions are the interface between developers and infrastructure. Developers work with components, endpoints, and dependencies. Platform engineers work with environments, pipelines, and component types. The platform compiles both into Kubernetes resources.
• A control plane bridges the gap. It sits between the portal and runtime, compiling abstractions into infrastructure, enforcing policies consistently, reconciling drift, and aggregating runtime state back to the portal.
• Good abstractions enable advanced capabilities. Unified observability, automated guardrails, and AI agents that can reason about and act on your platform. All becomes possible when you have well-defined concepts and a control plane that understands both sides.

…

Start with Backstage

If you’re building an internal developer platform, Backstage is certainly part of your architecture. It solved the discovery problem and became the default choice for developer portals.

Before Backstage, developers navigated wikis, spreadsheets, and tribal knowledge just to find who owned a service or how to spin up a new one. Backstage brought structure: a unified catalog, a plugin ecosystem, and golden-path templates that actually got adopted.

Backstage is a Cloud Native Computing Foundation (CNCF) project with one of the most active contributor communities in the ecosystem. When organizations evaluate developer portals, Backstage is the starting point.

However, many teams discover something after deployment: Backstage provides a portal, not a platform. A portal organizes information. A platform owns execution: deployments, environments, policies, observability, and runtime operations.

Backstage assumes that the execution layer exists beneath it. That layer is where most of the complexity lives, and it’s what this article is about.

What a developer platform actually is

A developer platform or an internal developer platform is a self-service framework you build to help developers build, deploy, and manage applications independently.

Most organizations already have an organically grown version of this:

• Developer commits code
• CI pipeline builds and pushes images to a registry
• Pipeline updates a GitOps repo containing Helm charts or Kubernetes manifests
• Argo CD or Flux syncs those manifests to clusters

You may have this workflow running today. The question is whether it’s a pipeline stitched together with scripts and tribal knowledge, or a platform with consistent abstractions and self-service capabilities.

What usually happens after adopting Backstage

How do you add Backstage to this setup? The common approach is for developers to maintain Backstage entity files (primarily component and API entities) alongside the source code. Then you configure the built-in entity provider in Backstage to scan source code repositories to populate the catalog. Eventually, you’ll end up with a portal with all your systems, components, APIs, and other resources. So far, so good.

Once developers start using the portal, you’ll be hit with a consistent flow of feature requests:

• “I see my component in the catalog, but is it actually running?” You configure the Kubernetes plugin and link components to their corresponding manifests. Now developers can see pod status, deployment state, and replica counts.
• “I need logs, metrics, and traces related to my component.” You integrate your observability stack or developers context-switch to Grafana, Datadog, or whatever you’re running. Either way, more wiring.
• “Can I create new components from here?” You build Backstage templates that scaffold repos with the right structure, Backstage entities, Helm charts, and CI pipelines, all of which encode your organization’s best practices. Now you’re maintaining golden paths in templates, separately from the runtime configuration that actually enforces them.

Each request is reasonable and achievable, but they add up.

The messy middle

Eventually, you end up with a platform held together by point-to-point connections. Every new capability requires new wiring. Every upgrade risks breaking something. You spend more time maintaining integrations than building features.

You would never design a production system with this many point-to-point dependencies. Why accept it for your platform?

Treat the platform as a product, but also as a system

Organically grown systems get you started, but once you commit to Backstage as your portal, you need a product mindset. Start from developer experience, understand their pain points, then design a system that addresses them coherently.

A platform is also a system. Approach it the way you would approach any production system you’re building. You wouldn’t design a back-end service without thinking about separation of concerns, clear interfaces, and extensibility.

The same principles apply here:

• Separation of concerns: Don’t mix developer-facing abstractions with infrastructure implementation. Keep them separate so you can evolve each independently.
• Clear interfaces: Define explicit abstractions. Developers and platform engineers should interact with well-defined concepts rather than implementation details scattered across Helm charts and CI scripts.
• Extensibility: Requirements keep changing. If every new capability requires custom wiring, you’ll spend more time maintaining than improving. Design for extension from the start.

The difference between a pile of integrations and a platform is architecture. Get the system design right, and new capabilities slot in cleanly. Get it wrong, and every feature request becomes a maintenance burden.

The missing layer beneath Backstage

Moving from an organically grown pipeline to an actionable developer platform is a big leap. You probably have CI/CD pipelines that work, a Kubernetes cluster running workloads, and a Backstage catalog describing what exists.

The questions are:

• How do you transform an informational portal into one with a platform under the hood?
• How do you bridge the gap between what the catalog describes and what’s actually running?
• How do you enforce golden paths beyond initial scaffolding?
• How do you design a platform that evolves with your organization’s needs?

What’s missing is a connective layer between Backstage and your runtime, something that makes the portal operational rather than just informational. Let’s look at the key architectural elements to consider when designing that layer and the whole platform.

Start with abstractions

One of the main goals of a developer platform is to reduce cognitive load. The platform should meet developers where they are and speak their language, not Kubernetes’.

Every organization has its own vocabulary, but the Backstage system model is a good starting point. It may not cover everything, but you can extend it with custom entities. The key is that developers work with high-level concepts while the platform compiles them into Kubernetes resources. Developers are abstracted away from the underlying details, but they can still see what’s happening underneath.

Concept	Description	Backstage mapping
Project	A cloud-native application composed of multiple components. It is also a unit of isolation.	System
Component	A deployable unit, such as web services, APIs, workers, or scheduled tasks.	Component
Endpoint	A network-accessible interface exposed by a component.	API
Resource	External infrastructure such as databases, queues, and caches.	Resource
Dependency	A component’s reliance on endpoints or resources.	consumesAPI, dependsOn

These are not just static abstractions; they also have associated runtime semantics. The following diagram illustrates runtime representations of these concepts.

In the workload cluster, a project becomes an isolation boundary for all of its components. The platform translates this into Kubernetes namespaces and network policies that enforce the boundary, not just document it.

Endpoint visibility determines which endpoints can talk to which. A project-scoped endpoint gets network policies that block traffic from outside the project. An organization-scoped endpoint is exposed to internal traffic but remains behind the internal gateway. An external endpoint gets routed through the public gateway with appropriate authentication. Developers declare visibility; the platform generates the policies.

Dependencies work the same way. When a component declares a dependency on an endpoint, the platform injects the URL and other environment variables required to connect to the dependency. It configures the network policies for both directions, egress from the calling endpoint and ingress to the target endpoint. Without the declared dependency, egress is blocked by default. The dependency graph you see above reflects actual permitted traffic flow, not just intended relationships.

You need platform abstractions, too

Developer abstractions help your developers. Platform abstractions help you.

While developers work with components, endpoints, and dependencies, you need a different vocabulary to design and operate the platform itself. These abstractions let you and your team define standards, enforce policies, and create structure without writing low-level configurations for every scenario.

Concept	Description
Namespace	A logical grouping of users and resources, typically aligned to a company, business unit, or team. Defines ownership and access boundaries.
Data plane	A Kubernetes cluster that hosts one or more deployment environments. You can have multiple data planes for isolation, regional distribution, or scaling.
Environment	A runtime context, such as dev, test, staging, or prod, where workloads are deployed and executed. Environments carry their own policies and resource configurations.
Pipeline	A defined process that governs how work, such as builds, deployments, promotions, or any automated workflows, flows through the platform. Encodes your operational processes as a platform primitive.
Component type	Defines a category of workload—Service, Worker, Cron, Job.
Trait	A reusable capability that attaches to any component, such as autoscaling, resilience, observability, and security policies. Compose behaviors without duplicating configuration.

These abstractions separate platform concerns from application concerns. Developers don’t need to know which cluster their code runs on or how environments are wired together. They deploy to “staging” or “prod,” and you define what those terms mean.

The missing layer is a control plane

The control plane is where abstractions become real. It sits between the portal and your workload clusters, translating developer intent into infrastructure configuration.

You can think of it as a compiler that targets Kubernetes clusters, converting higher-level abstractions into what Kubernetes and its underlying frameworks understand. It can also apply platform-wide rules during this compilation. Resource limits, security requirements, etc., can be enforced consistently, not merely documented and hoped for.

But compilation is only half the job. The control plane also reconciles continuously. It monitors drift between the declared and actual states. When they diverge, it corrects. Your abstractions remain the source of truth; the control plane enforces them over time.

Programmability is not optional

One of the key aspects of this control plane is programmability. If you want your platform to evolve, the control plane needs to be extensible. Different teams have different requirements. New capabilities emerge. You can’t anticipate everything up front.

This means allowing customization of how abstractions compile to Kubernetes manifests. But extensibility without guardrails is dangerous. You need programmability that preserves your invariants. The goal is constrained flexibility, open enough to evolve, structured enough to stay coherent.

Observable abstractions make the portal useful

The control plane also aggregates runtime state and associates it with your abstractions. This is what makes the portal useful. Without this, developers piece together information from different tools: Kubernetes dashboard for pod status, Argo CD for the deployment state, Grafana for metrics, Jaeger for traces. Each tool knows part of the story; none shows the full picture.

With the control plane aggregating state, the portal tells a connected story. When a developer opens a component page in Backstage, they see:

• Deployed environments and their status
• Current replicas and resource usage
• Recent deployments and who triggered them
• Logs, metrics, and traces that are scoped to that component, in each environment
• Dependencies and their health

No context-switching. No reconstructing which pod belongs to which service in which cluster. The abstraction is the anchor; everything else attaches to it.

This only works because the control plane understands both sides. It compiled the abstractions to Kubernetes, so it knows how to map runtime data back. Information flows in both directions. Downward: developer intent flows through the control plane and becomes running workloads. Upward: runtime state flows back through the control plane and appears in the portal.

This is what makes the portal actionable. It’s not just displaying information; it’s connected to a system that can act.

Data plane: keep it simple

The data plane is where your workloads actually run. In most cases, this means one or more Kubernetes clusters. The data plane doesn’t know about your abstractions. It understands Kubernetes primitives such as pods, deployments, services, and ingresses. The control plane’s job is to compile your higher-level concepts into these primitives and apply them.

The data plane does one thing: it runs what the control plane tells it to run. The intelligence lives in the control plane; the execution happens in the data plane.

Where AI fits into the platform

AI is now part of every platform conversation, but the architectural question is where it actually belongs.

The abstractions and control plane you’ve built create the foundation. You have well-defined concepts such as components, endpoints, and dependencies. You have a runtime state aggregated and tied to those concepts. You have a connected view of your system. AI agents can definitely leverage this.

Agents as platform users

AI agents should be able to interact with your platform as first-class participants. This requires exposing platform capabilities through interfaces that agents can use, such as Model Context Protocol (MCP) servers, APIs with clear semantics, user-friendly CLIs, and skills that map to platform operations.

These capabilities of the platform enable agents to create components, trigger builds and deployments, query environment status, and reason about dependencies. They help you and your developers become more productive.

Agents as platform capabilities

You can also embed agents inside your platform to help your teams’ day-to-day operations. Here are some examples of agents you can develop:

• SRE agents: Analyze logs, metrics, and traces to surface likely root causes. Instead of developers digging through dashboards, the agent correlates signals and suggests where to look.
• FinOps agents: Help teams understand and optimize resource costs across environments and components.
• Architect agents: Assist with system design decisions, such as dependency analysis, capacity planning, and migration impact assessment.

These agents work because they have access to the control plane’s unified view. They see abstractions, runtime state, and observability data in one place, the same connected story developers see in the portal.

The pattern holds. Good abstractions make everything easier, including AI.

OpenChoreo as a reference implementation

OpenChoreo is an open-source developer platform for Kubernetes. It was recently accepted into the CNCF as a sandbox project. OpenChoreo implements the architecture described in this article: developer abstractions backed by a control plane, a Backstage-powered portal, integrated CI/CD and GitOps, and observability wired to your abstractions.

If you’re building this architecture yourself, OpenChoreo is worth studying as a reference, even if you don’t adopt it directly. The project demonstrates how these pieces fit together: how abstractions compile into Kubernetes resources, how runtime state flows back to the portal, and how guardrails are enforced during compilation.

You can use OpenChoreo as a complete platform, or install its Backstage plugins into your existing portal and use just the control plane layer. Either way, the underlying patterns are what matter. The architecture is the idea. OpenChoreo is one way to implement it.

A useful mental model: multi-plane architecture

OpenChoreo separates concerns across five planes:

1. Experience plane: Where developers, platform engineers, and SREs interact with the platform via the Backstage-powered portal, CLI, GitOps, or AI agents.
2. Control plane: The brain that translates high-level abstractions (components, APIs, environments, pipelines) into Kubernetes manifests. Programmable through component types and traits, so you can extend it without forking or writing low-level controllers. Continuously reconciles the runtime state back into those abstractions.
3. Data plane: Where workloads run. Enforces the semantics of your abstractions, such as project isolation, traffic policies, and security boundaries. These aren’t just configurations; the platform guarantees them.
4. Observability plane: Feeds metrics, logs, and traces back through the same abstractions developers already understand, requiring no translation.
5. Workflow plane (optional): Handles builds using Cloud Native Buildpacks and Argo Workflows by default.

These planes work together but remain separate concerns. You can reason about each independently, evolve them at different rates, and deploy them flexibly: a single cluster with namespace isolation for dev/test, fully separated multi-cluster setups for production, or hybrid topologies that colocate planes like Control and CI for cost efficiency.

AI and OpenChoreo

OpenChoreo is being built to treat AI agents as first-class participants. In OpenChoreo 1.0, external agents can interact with the platform via MCP servers, agent skills, or the CLI to generate and edit component configurations, reason about releases and environments, and more. The built-in SRE Agent is a first example of this. It analyzes logs, metrics, and traces from your deployments and uses LLMs to surface likely root causes and actionable insights.

From portal to platform

Backstage solved the portal problem. It gave you a unified interface for catalogs, documentation, and golden paths. But a portal isn’t a platform. There’s a gap between what developers see and what’s actually running, and that’s where you get stuck. You fill it with point-to-point integrations, custom plugins, and scripts that become their own maintenance burden.

The pattern that works is portal, control plane, data plane:

• A portal that gives developers ready access to catalogs, documentation, and templates.
• A control plane that compiles platform abstractions, reconciles drift, and aggregates runtime state.
• A data plane that runs workloads and enforces guarantees.

Whether you build this yourself or you adopt something like OpenChoreo, the architecture matters more than the tools. Get the layers right, and new capabilities slot in cleanly. Get them wrong, and every feature request becomes a project.

Backstage gives you the front door. The real platform begins behind it.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

Data lakehouses have become the gold standard for enterprise data platforms since they combine a data lake’s ability to support a variety of different types of data at low cost, and the reliability, structure and governance of a traditional data warehouse.

The fact they offer a central repository of information that might come from different places at a company, together with security and auditing tools, make them a perfect fit for enterprise AI systems, too. In fact, they’ve become so popular and useful that all the major data lake and data warehouse vendors have all but converged into data lakehouse vendors. Snowflake, for example, started out as a data warehouse and over the course of several years and acquisitions, has transformed into a full data lakehouse platform.

Docusign is now using it to support its agentic AI ambitions, too. For example, data is pulled in from Salesforce and then used to train an internal AI agent for sales, says Shivi Verma, Docusign’s senior manager of engineering. The company is also training ML models in order to serve customers more accurately.

The information also goes out to LLMs using RAG embedding pipelines, and MCP connectivity is being explored as the technology matures.

One issue Docusign keeps top of mind when exposing the data in its lakehouse is security and governance.

“We’re proceeding very cautiously,” Verma says. “It goes through a stringent security review and discussion with both technical and business stakeholders to make sure we’re not doing anything that isn’t allowed from the security lens and compliance lens.”

The security checks are in place both when the data first goes into Snowflake, he says, and when it goes out again. The restrictions are particularly tight when it comes to access to anything sensitive, such as customer data.

“We’re first exposing those with a low risk profile,” he says. That can include publicly-facing information like website content or product details.

Docusign isn’t alone. “We see 65% adoption of lakehouses among Gartner’s client base,” says Gartner analyst Prasad Pore. “It’s a very strong number in a short time.”

And the future of lakehouses looks even brighter.

“Lakehouse is becoming the foundation for the future of AI,” Pore says, adding that vendors are evolving to support this use case. For example, lakehouse as a concept doesn’t support vector databases, which are a key type of data structure for AI systems that use RAG to feed data into LLMs.

“But many lakehouse vendors have added capabilities for vector indexing,” he says. “Databricks and Microsoft Fabric both have a vector capability built into their platform.” Yet smaller players might not provide the functionality, he adds.

Similarly, support for MCP, a standard that allows AI agents to connect to data and systems, varies by vendor, and isn’t traditionally a core lakehouse functionality.

A matter of choice

A data lakehouse isn’t the only option for companies looking to provide their AI system with the critical business context they need to be useful to the enterprise.

For example, companies can build vector databases or vector database pipelines manually from individual sources, or use a data fabric to make the connection.

“Fabric can directly connect to original sources, which is a good use case for quick analytics,” Pore says. “But then you’re overloading your source systems, which isn’t a good thing for those products and machines.”

Microsoft Fabric is a lakehouse platform, though, and not a data fabric platform in the way Gartner defines the term.

Another downside is that the data models used in original systems aren’t usually optimal for analytics, and can be expensive. “Connecting to direct sources isn’t efficient,” Pore says.

Finally, there are well-established processes for managing data permissions in a lakehouse.

“A lakehouse physically unifies your data, maintenance, security, and governance,” he says. “This is very critical for AI implementation. As an organizational single source of truth, a lakehouse is the modern way to create a central repository.”

Consulting firm Lemongrass originally started out with a data lake about a decade ago, and then began upgrading it to a lakehouse four years ago.

“Back then, the concept of a lakehouse wasn’t that popular,” says Kausik Chaudhuri, chief innovation officer at Lemongrass. So the firm built custom lakehouse functionality on top of its Amazon S3 data lake. Now that it’s using the data lakehouse to support AI, it’s time for another upgrade.

“Right now, we’re working on something for our incident and change management,” he says. The original data is in ServiceNow, and it’d be too expensive to pull it out directly from the lakehouse to use in an AI system. “So now we’re thinking of building an MCP server to query that data,” he adds.

And they also plan to upgrade from its own custom lakehouse add-ons to a standard solution. “Lemongrass was primarily an AWS evangelist when we started, and a lot of our tooling was on top of AWS,” Chaudhuri says. “Now we’re thinking of changing this because with AI, there’s a lot more opportunity.” Then again, AWS now offers lakehouse functionality. “The data’s already there,” he adds. “We don’t have to reinvent it.”

Plus, AWS has connectivity to Anthropic’s Claude AI and other AI models. And since the models are also running on AWS, there are no data egress fees. Lemongrass plans to start the upgrade with a POC in Q3 this year. “Everybody’s busy, so we need to pull in people and figure out when and how we implement that,” he says. For example, the company has to be careful about what data and how much is pulled in from the lakehouse and sent to the AI.

“We don’t send out customer data to an LLM,” he says. “And I’m not reading 10,000 rows and sending it to Claude, which would blow up to token usage. We figured out a couple of years ago we can go bankrupt if we’re not careful about the amount of tokens we use.”

And for some use cases, the LLM doesn’t need to see anything at all after the solution is deployed. For example, firm employees used to manually generate status reports about its customers for internal use, which was a time-consuming process. An AI model could, in theory, take over that job, but then it’d see the customer data. And since AIs aren’t deterministic, each report would look different.

Or, say, the firm needs to generate forms to fill out and then the customer would sign. Again, an LLM could create a custom form each time. “So then we asked Claude to write a program that takes this input and writes this report,” says Chaudhuri. The process of generating reports or the forms is traditional, deterministic software. The customer data is never exposed, and the reports are cheap and fast to produce.

But other companies are use AI to make better use of its data. In a recent report by Databricks based on data from 20,000 organizations, the percentage of databases created by AI agents rose from 0.1% to 80% over the past two years, and agents now create 97% of database branches.

Security and governance

One major area of struggle for enterprises is to figure out how to handle security and other related issues for when AI agents access data lakehouses.

In the past, data went out to dashboards, in which the security and access controls were programmed. Or the data went to data analysts, who worked within their own access privileges. The first use cases for AI involved RAG embeddings, which were easier to manage.

In a RAG embedding, traditional, deterministic software is used to pull in data and embed it into an LLM prompt for a particular workflow. The developers setting it up would handle the security aspects for each particular use case. With agentic AI and MCP servers, however, the AI can go and grab data autonomously, as needed.

According to Genpact’s Arellano, enterprises need to figure out how to manage the identities of AI agents, control access to data, create audit trails, and filter prompts and content.

“Agents need their own credentials,” he says. For example, AI agents might not have permissions to ever touch patient records. “And audit trails are important, with full observability of what the agent did.”

Some lakehouse vendors, including Databricks, offer this functionality, he says, and there are other tools that can be brought in like Okta, Palo Alto, or Zscaler.

The new semantic frontier

The next evolution of the lakehouse is the semantic layer, and Gartner estimates that universal semantic layers will be critical infrastructure by 2030.

“Developing a universal semantic layer is now a must‑do for data and analytics leaders either leading or supporting AI,” Gartner says. “It’s the only way to improve accuracy, manage costs, substantially cut AI debt, align multiagent systems, and stop costly inconsistencies before they spread.”

It’s one thing for an AI to have access to data, but entirely something else to understand what that data actually means to the business. The semantic layer is the business knowledge that’s not normally formalized in a structured database, such as, say, the knowledge that an order or a customer means different things in different systems.

“Before, the semantic layer was nice to have but not as necessary because data scientists know what data sources they want to query,” says Amit Kinha, board member of the FinOps Foundation and field CTO at DoiT International, a cloud consultancy.

But now, without it, an AI agent won’t know where to look for the data it needs, he says. “Or it’ll do a bad join, or do something that creates a cost explosion,” he adds. “The semantic layer is going to be critical for leveraging lakehouses effectively.”

This semantic layer can also become part of a feedback loop, where the agentic systems learn from experience, says Kevin Martelli, consulting AI solution development leader at EY Americas.

Say for example a company has a process where approvals are required for certain payments, and a CFO is required to sign off for payments over half a million. If the AI agent goes to a human for approval, he says, the human might say this is telling me to approve this invoice, but I know it’s over $500,000 and I need to get CFO approval on this. “Then it can be stored in the session and persisted back in the lakehouse as a procedural document or as a record of something that occurred,” says Martelli. “This is where it becomes more beneficial and aggregates over time with usage because you’re never going to get it perfect on day one.”

The semantic layer is still very much an evolving area, and different data lakehouse vendors handle it differently.

“There’s this great debate going on in the industry of how lakehouses converge with semantic layers and where they actually live,” says Matt Arellano, SVP of data and AI at digital transformation consultancy Genpact.

Some vendors are building semantic tools into their data lakehouse platforms, or acquiring additional firms to get the technology. In other cases, customers are using third-party tools instead.

“Clients are struggling with that,” Arellano says. “They’re all trying to figure out the different combinations and permutations of tools and processes.”

Steven Karan, VP of AI transformation for Capgemini Australia and New Zealand, says he sees the lakehouse as evolving into a central orchestration layer.

“Organizations are now less focused on analytics and reporting, and more on building AI-driven applications and agentic systems,” he says. “The most effective architectures I see today combine a lakehouse core with specialized serving layers.”

That includes vector databases for AI, streaming platforms for real-time data, and operational databases for low-latency applications. The lakehouse isn’t just for analytics anymore, he adds. It’s the foundation for enterprise data and AI. “Its role is now less about replacing all other systems, and more about unifying and governing them to accelerate innovation while maintaining control,” he says.

It is tempting to date cloud computing from the launch of Amazon S3 in 2006 and the rise of infrastructure as a service (IaaS) that followed. That was certainly the moment the market changed in a visible, irreversible way. But the truth is that cloud began earlier, in the 1990s, when software as a service (SaaS), application hosting, managed services providers, and various forms of remote subscription computing started to reshape how enterprises thought about owning and operating technology. Even then, the core value proposition was familiar: Let someone else run the infrastructure, abstract the complexity, deliver capability as a service, and allow the business to consume only what it needs.

What AWS changed was the scale, accessibility, and precision of the execution. Amazon turned infrastructure into a programmable utility. It made compute and storage available in ways that were elastic, self-service, API-driven, and globally reachable. That was the breakthrough. Enterprises had outsourced pieces of technology before, but now they could rent raw infrastructure with unprecedented speed and flexibility. The launch of Amazon S3 was especially important because it provided a durable, scalable storage foundation that became one of the building blocks for modern digital business.

AWS changed everything

Technology markets are rarely transformed by the first company to think of an idea. They are transformed by the first company to make that idea operationally real, economically viable, and broadly consumable. AWS did exactly that. It built a model for infrastructure as a service that allowed enterprises, startups, and eventually governments to rethink the entire life cycle of IT delivery.

Looking back from 2026, it is difficult to remember how radical this concept once seemed. At the time, many enterprise leaders considered public cloud too risky, too immature, too uncontrolled, or simply too foreign for conventional IT governance. There were concerns about security, compliance, vendor dependency, performance, data residency, and reliability. Many of those concerns were valid. Early cloud adoption often ran ahead of cloud maturity, and many organizations discovered that moving quickly did not always mean moving wisely.

Still, the economics of agility overwhelmed the inertia of the old model. Provisioning that once took months could be done in minutes. Capital expenditure gave way, at least in part, to operating expenditure. Experimental workloads became easier to justify. Digital businesses could scale without building data centers first. AWS led that transition, and the rest of the industry followed, including competitors that helped mature the market.

Cloud’s strengths and liabilities

If the first decade of cloud was about acceleration, the second decade was about correction. Enterprises learned that cloud was not automatically cheaper, not automatically simpler, and not automatically better. It was better when used with discipline. It was more cost-effective when architected intelligently. It was more resilient when governance, operations, and security were designed into the system rather than added later.

This is when the industry grew up. We learned about cloud financial management because too many organizations assumed elasticity would control cost, only to discover that unused resources, poor workload placement, and fragmented accountability could drive spending far beyond expectations. We learned that public cloud could provide extraordinary innovation and reach, but also that not every workload belongs there. Latency, sovereignty, compliance constraints, legacy integration challenges, and predictable high-volume workloads all forced a more nuanced view.

We also learned about concentration risk. As enterprises standardized on a small number of hyperscalers, questions emerged around resilience, lock-in, and strategic dependency. The answer was never simplistic multicloud posturing for its own sake. It was architectural realism. Use the public cloud where it creates a clear advantage. Keep options open where business risk requires it. Understand portability, but do not romanticize it. In other words, cloud became less ideological and more practical.

Cloud is now an assumption

Perhaps the most important shift of all is that we no longer debate whether cloud is real or whether enterprises should use it. That argument is over. Cloud is baked into the cake. It is part of enterprise operating reality. The modern enterprise assumes on-demand infrastructure, platform services, automation pipelines, managed databases, identity fabrics, observability stacks, and globally distributed application delivery. Even when workloads remain on-premises or at the edge, they are often built, governed, or operated with cloud-native thinking.

This is maturity. Cloud is not a project or a trend. It is not even a strategy by itself. It is an enabling model that now underpins enterprise strategy. Businesses no longer ask whether to adopt cloud in the abstract. They ask how much cloud, which cloud services, under what governance model, at what cost profile, and in support of which business outcomes.

That may sound less exciting than the early days of disruption, but it is actually the mark of success. The most powerful technologies eventually disappear into standard practice. Electricity, networking, virtualization, and mobile platforms all went through this process. Cloud has done the same.

How cloud supports the AI race

As enterprises move aggressively into AI, cloud has entered another pivotal phase. AI is not replacing cloud. It is intensifying the importance of cloud while also changing how value is measured. Training, tuning, deploying, and governing AI systems require immense computational scale, specialized infrastructure, distributed data access, and operational consistency. Public cloud providers are well positioned to offer those capabilities, particularly with GPUs, AI platforms, managed model services, and data integration tools.

But this is not a repeat of the early cloud era. Enterprises are more sober now. They know the importance of cost, latency, and data gravity. They know that governance and accountability matter more in AI than perhaps anywhere else in modern IT. The role of cloud in the AI race is therefore foundational, but not absolute. Some AI workloads will run in public cloud. Some will be distributed across edge computing environments. Some will remain in private environments for reasons of sovereignty, economics, or control. The key is not to force a universal answer. The key is to create an architecture that aligns AI ambitions with operational reality.

Cloud should play the role it has gradually earned: not as a religion, but as a strategic utility. For AI, the cloud is where many enterprises will source scale, experimentation speed, global reach, and managed innovation. The winning organizations understand where cloud creates leverage and where other operating models make more sense.

Changing how enterprises think

The real story of the past 20 years is not just that AWS launched S3 and helped popularize infrastructure as a service. It is that cloud changed enterprise behavior. It normalized service consumption over asset ownership. It moved architecture toward abstraction, automation, and modularity. It forced IT organizations to broker capability rather than build everything from scratch. It redefined speed as a core competitive requirement.

And now, as AI becomes the next forcing function, cloud stands less as a novelty and more as the platform on which the next era will be built. That is a remarkable outcome for something that, in many ways, started with the old idea that computing could be delivered remotely on a subscription basis. We have been heading here for longer than many people realize. In the past two decades, led in large measure by AWS and the broader hyperscale movement it accelerated, cloud has evolved from a gamble to an indispensable foundation.

Hard to believe? Yes. But also inevitable in retrospect.

OpenAI has introduced spend controls and enhanced usage analytics for ChatGPT Enterprise to enable organizations to monitor AI adoption, track consumption across teams, and set budgets for AI usage. But, analysts cautioned, it still can’t show how those costs lead to business benefits.

The new features provide administrators with centralized dashboards showing how ChatGPT is being used across an organization, enabling them to understand adoption patterns, and manage AI costs by setting budgets and tracking spending.

“The Global Admin Console brings ChatGPT and Codex credit usage into one view, so admins can see a more granular breakdown of credit consumption across users, products, and models — helping them understand where spend is coming from and how it maps to actual credit usage,” OpenAI said.

A shift toward AI cost governance

The introduction of budgeting and usage analytics reflects a broader change in enterprise priorities, according to Biswajeet Mahapatra, principal analyst at Forrester.

“Enterprises are clearly shifting from adoption-led enthusiasm to cost and value governance, but this is a natural maturity transition rather than a pullback,” Mahapatra said. “AI is no longer an adoption problem but a measurement and credibility problem, with productivity gains present but fragmented and hard to tie to financial outcomes.”

As AI expands across business units, spending becomes distributed across teams, tools and experiments, making visibility and governance increasingly important, he said.

“Budgeting, usage visibility and spend controls are therefore becoming foundational, not just operational concerns, as they enable alignment between technology usage and business outcomes,” Mahapatra added.

OpenAI is addressing those needs with its new dashboards and spending controls address, he said.

Agent sprawl will add to cost control challenges

Anushree Verma, senior director analyst at Gartner, said AI cost governance is becoming a focus for enterprises, as fragmented pricing models, vendor-defined consumption units and inconsistent pricing structures make it difficult for organizations to predict AI costs.

She expects the challenge to intensify over the next few years as enterprises scale up their use of AI.

“By 2028, an average global Fortune 500 enterprise will have over 150,000 agents in use, up from less than 15 in 2025, generating significant agent sprawl, IT complexity and management challenges,” she said.

Against that backdrop, OpenAI’s new administrative capabilities provide organizations with tools to monitor organizational usage and spending as AI deployments become larger and more distributed.

Measuring AI value beyond consumption

While OpenAI’s analytics emphasize adoption patterns and usage visibility, analysts say enterprises will ultimately need to connect AI consumption with business outcomes.

“Token consumption alone is insufficient because it measures activity rather than impact,” Mahapatra said.

Instead, organizations should evaluate AI initiatives using business metrics such as revenue growth, cost reduction and risk mitigation alongside operational indicators including productivity improvements and quality gains.

Verma said traditional cloud FinOps practices are also evolving to accommodate AI’s usage-based economics.

“Traditional FinOps practices were built around predictable, centralized cloud environments and are insufficient for handling unpredictable AI consumption metrics, such as token usage, LLM requests and GPU hours,” she said.

She added that real-time tracking is becoming increasingly important as multiagent systems scale, because misconfigurations can cause AI costs to rise rapidly across interconnected environments.

OpenAI has introduced spend controls and enhanced usage analytics for ChatGPT Enterprise to enable organizations to monitor AI adoption, track consumption across teams, and set budgets for AI usage. But, analysts cautioned, it still can’t show how those costs lead to business benefits.

The new features provide administrators with centralized dashboards showing how ChatGPT is being used across an organization, enabling them to understand adoption patterns, and manage AI costs by setting budgets and tracking spending.

“The Global Admin Console brings ChatGPT and Codex credit usage into one view, so admins can see a more granular breakdown of credit consumption across users, products, and models — helping them understand where spend is coming from and how it maps to actual credit usage,” OpenAI said.

A shift toward AI cost governance

The introduction of budgeting and usage analytics reflects a broader change in enterprise priorities, according to Biswajeet Mahapatra, principal analyst at Forrester.

“Enterprises are clearly shifting from adoption-led enthusiasm to cost and value governance, but this is a natural maturity transition rather than a pullback,” Mahapatra said. “AI is no longer an adoption problem but a measurement and credibility problem, with productivity gains present but fragmented and hard to tie to financial outcomes.”

As AI expands across business units, spending becomes distributed across teams, tools and experiments, making visibility and governance increasingly important, he said.

“Budgeting, usage visibility and spend controls are therefore becoming foundational, not just operational concerns, as they enable alignment between technology usage and business outcomes,” Mahapatra added.

OpenAI is addressing those needs with its new dashboards and spending controls address, he said.

Agent sprawl will add to cost control challenges

Anushree Verma, senior director analyst at Gartner, said AI cost governance is becoming a focus for enterprises, as fragmented pricing models, vendor-defined consumption units and inconsistent pricing structures make it difficult for organizations to predict AI costs.

She expects the challenge to intensify over the next few years as enterprises scale up their use of AI.

“By 2028, an average global Fortune 500 enterprise will have over 150,000 agents in use, up from less than 15 in 2025, generating significant agent sprawl, IT complexity and management challenges,” she said.

Against that backdrop, OpenAI’s new administrative capabilities provide organizations with tools to monitor organizational usage and spending as AI deployments become larger and more distributed.

Measuring AI value beyond consumption

While OpenAI’s analytics emphasize adoption patterns and usage visibility, analysts say enterprises will ultimately need to connect AI consumption with business outcomes.

“Token consumption alone is insufficient because it measures activity rather than impact,” Mahapatra said.

Instead, organizations should evaluate AI initiatives using business metrics such as revenue growth, cost reduction and risk mitigation alongside operational indicators including productivity improvements and quality gains.

Verma said traditional cloud FinOps practices are also evolving to accommodate AI’s usage-based economics.

“Traditional FinOps practices were built around predictable, centralized cloud environments and are insufficient for handling unpredictable AI consumption metrics, such as token usage, LLM requests and GPU hours,” she said.

She added that real-time tracking is becoming increasingly important as multiagent systems scale, because misconfigurations can cause AI costs to rise rapidly across interconnected environments.

This article first appeared on CIO.

I recently spent some time reflecting on the announcements from Google Cloud Next 2026, as well as a series of vendor briefings and a handful of enterprise architecture engagements, where the same question kept coming up across different venues: once an organization has agents, who governs them? For two years, the enterprise AI conversation has been a conversation about models — whose is largest, whose is cheapest, whose context window stretches furthest.  Virtually no one was talking about data and semantic context.

After getting some perspective, I was forced to consider that model obsession might have finally fizzled out under the grim reality of non-existent ontologies and limited to no semantic context for enterprise data. The interesting question is no longer which model an enterprise runs. It is who controls the connective context layer — the agentic control plane — that decides what those agents know, what they are allowed to do and who is accountable when a thousand of them are running at once. Whoever owns that layer owns the next decade of enterprise AI and judging by the “marketecture” of every major vendor at Next 2026, the industry has reached the same conclusion.

The urgency here is clearly not a slide-ware exercise. Gartner has reported an exponential surge in enterprise inquiries about multi-agent systems and predicts that 40% of enterprise applications will embed task-specific agents by the end of 2026, up from less than 5% a year earlier. Yet the same analysts deliver an equally important counterweight: Gartner also expects more than 40% of agentic AI projects to be canceled by the end of 2027, citing escalating cost, an expanded risk surface and governance that no one built in advance. The 2026 Gartner Hype Cycle for Agentic AI makes the diagnosis plain — governance, security and FinOps capabilities are proliferating precisely because enterprises are alarmed about accountability and control as agents grow more autonomous and interconnected. Exponential demand colliding with non-existent guardrails is the environment Google walked into. So, what is the path forward to a control plane an enterprise can actually trust?

What Google actually brought to Next 2026

I’m not ardent supporter of single-ecosystem architectures.  That’s not the world we live in and interoperability has always prevailed as the final arbiter of truth.  Beneath all the agent drama, however, Google’s message was fundamentally architectural. The company repositioned Gemini less as a standalone model and more as the connective and contextual tissue binding data systems, applications and agent runtimes, and assembled Big Query, Alloy DB, Spanner and its managed Spark service into a new category it calls the Agentic Data Cloud. As Constellation Research observed, the standardization of data on Apache Iceberg has put the data layer itself in play, and Google responded by stacking its assets into a cross-cloud lakehouse and a knowledge catalog, complete with migration tooling pointed squarely at Snowflake and Databricks.

Three pillars define the offering. The first is a federated data layer built on the principle of reach, not relocation. By integrating Cross-Cloud Interconnect directly into the data plane and pairing it with the Apache Iceberg REST Catalog, Google lets agents query data residing on AWS or Azure as though it were local, with no egress fees and extends bi-directional federation in preview to Databricks’ Unity Catalog, Snowflake’s Polaris and the AWS Glue Data Catalog, according to Google’s own technical briefings and independent analysis. Google data cloud managing director Yasmeen Ahmad summarized in Google’s Next ’26 announcement with characteristic economy: you don’t move the data, you connect it.

The second pillar is a semantic layer — the Knowledge Catalog, an evolution of Dataplex — which uses Gemini to tag assets, infer relationships and map business meaning so that agents are grounded rather than, as one analysis put it, fast but blind. Critically, its retrieval is permission-aware, meaning agents can only retrieve and act on assets they are explicitly authorized to see — a design choice that fuses context delivery and access control into a single operation. The third pillar is a build layer, the Data Agent Kit, which ships as portable skills, MCP tools and IDE extensions that drop into VS Code, Claude Code, Gemini CLI and Codex, deliberately declining to impose a new proprietary interface.

This is a credible and, to Google’s credit, a mostly real offering.  A control plane, however, is a claim, not a feature, and the term deserves more focus and detail than vendors typically provide.   An agentic control plane is not a product it is a semantically governed set of domain services and underlying structured and unstructured data.   How we federate agentic access and data with intention and governance means everything.

What an interoperable control plane requires

A control plane governs how a system behaves rather than performing the work itself. For agents, a genuine control plane must deliver at least five functions, and an interoperable one must deliver them across vendor, model and cloud boundaries rather than only within a single domain or scope.

The first is identity. Agents are a new class of non-human actors, and an enterprise must be able to authenticate them and manage their actions. Microsoft’s competing Agent 365, unveiled at Ignite 2025, is built explicitly around a registry of which agents exist, plus access control and security — as an Ignite 2025 industry analysis noted, that identity is foundational. The second is context and semantics, the half of the problem the data clouds have collectively rushed toward. The third, and the most consistently underplayed, is action governance — control not merely over what an agent can read, but over what it can do: the writes, the state changes, the transactional operations. The fourth is observability and lifecycle management, the simulate-evaluate-monitor-optimize loop across an agent fleet, where Google’s integrated offering is, by most accounts, the most complete a hyperscaler has yet shipped. The fifth is economics; the reason so many projects are forecast to fail is partly cost, and FinOps for agentic AI is now an expressly named discipline on Gartner’s Hype Cycle.

Interoperability cuts across all five, and here the industry has done something genuinely impactful and useful: it has agreed on protocols. The Model Context Protocol, originated by Anthropic and since donated to the Linux Foundation under multi-vendor governance, standardizes how an agent connects to tools and data. The Agent2Agent protocol, originated by Google and likewise moved to the Linux Foundation, governs how agents discover and delegate to one another across organizational boundaries. Forrester predicts that 30% of enterprise app vendors will launch their own MCP servers in 2026, and Gartner’s Anushree Verma positions standardized protocols as the enabler of the seamless interoperability that, by 2028, will let networks of specialized agents collaborate dynamically across applications.

What is key here — and what enterprise leaders miss — is that open protocols deliver portable messages, not a portable control plane. Two agents can exchange tasks across clouds in A2A all day long, but identity, semantics, action governance, observability and cost remain platform functions.  A2A and MCP have ensured that the communication protocol has been commoditized.  The final frontier and the competitive moat is not the communication and access protocol, it is the semantic context and the business ontology

Where Google is strong, and where leaders should look twice

Google deserves real credit for embracing open standards where it counts. It adopted MCP across its own services, repositioned Apigee as an MCP bridge that turns any standard API into a governed agent tool and built its federation story on the open Iceberg REST Catalog rather than a proprietary format. Technology Business Research (TBR) characterized this as a meaningful strategic shift: a company historically defensive about keeping data inside BigQuery now signals that it cares less about where data physically resides than about ensuring Gemini is the semantic context layer generating value on top of it.

That repositioning is exactly the lock-in risk an enterprise must carefully consider, and two limitations matter significantly and deserve an architect’s attention. The first is that federation is not the same as unified control. In my view, TBR’s analysis is totally on point: The Knowledge Catalog addresses upper-stack governance but is not an operational catalog in the way that Databricks’ Unity Catalog, Snowflake’s Polaris and AWS Glue are — those systems govern the underlying Iceberg tables. Google reads into them; it does not replace them. The second is that the focus of lock-in has simply moved up the stack to the semantic context and ontology layers.  Moor Insights & Strategy and others all have cautionary tales that exiting Google-managed semantics, Gemini agents or BigQuery abstractions may prove harder than migrating the data itself. The semantics and the orchestration are now the sticky layer. I think this is a logically coherent and impressive strategy, but for every gain, something is lost.  That loss is exactly the moment where an enterprise either preserves its independence or succumbs to lock-in for convenience and expedience.

There is a maturity gap also worth mentioning here as well. One widely-circulated analysis of Next 2026 carried its verdict in the title — the agent stack is ready, the semantic engine isn’t — arguing that the Knowledge Catalog, however promising, is not yet the governed business-context layer a true enterprise operating system demands and remains more aspirational than operational. With much of the federation and catalog functionality still in preview, optimism is the right approach from my perspective, not “all-in” commitment.

Meanwhile, the competition is playing a different game

The competitors are not building the same artifact, and the differences are instructive. The data-cloud catalogs — Databricks Unity Catalog, Snowflake Polaris and Cortex, AWS Glue, Microsoft Fabric — govern data and, increasingly, semantics; the entire field now accepts that agents need context, not merely access, as industry analysis of the field documents. Their structural limit is that catalog constraints are frequently informational rather than strictly enforced, and metric-oriented semantic layers model measures rather than actions or state changes. They excel at conversing with data and remain weaker at agents that act. The agent-management planes, exemplified by Microsoft’s Agent 365, approach the problem from fleet control — registry, identity, observability — and are excellent for organizations living inside Microsoft 365, bounded by that same dependence.

Palantir Foundry represents a genuinely different category. Where catalogs register tables and semantic layers define metrics, Foundry is built around an ontology that models entities, their typed relationships and the actions that can be taken against them — semantics in service of operational execution, not merely analytics.  That distinction is the single most important idea for anyone designing an agentic control plane today. As Atlan frames it, a semantic layer hands agents governed metrics, which solves half the problem; agents that reason across domains and act need a knowledge-representation layer underneath — what things are, how they relate and what operations are possible. A control plane that governs reads but not writes, metrics but not actions, is fundamentally limiting for agents, and semi-autonomous action is the entire point.    It is also worth noting, the semantic layer itself is now standardizing: the Open Semantic Interchange initiative, launched in late 2025 by Snowflake, dbt Labs, Salesforce and a coalition of partners under an Apache 2.0 license, finalized its v1.0 specification in early 2026. Just as MCP and A2A commoditized the agent communication protocols, OSI aims to commoditize semantic portability.

A blueprint for enterprise leaders

As always, the path forward is clear enough to state but extremely demanding to execute. An interoperable agentic control plane is not a product an enterprise purchases from a single vendor; it is an architecture it composes — open standards at the commoditized layers, owned assets at the differentiating one. Drawing on both the Next 2026 announcements and recent architectural engagements, I would urge leaders to prioritize four design commitments.

First, standardize on open formats at the storage layer. Apache Iceberg and its REST Catalog deliver genuine data portability, and this is the one element of Google’s model worth adopting wholesale, precisely because the broader industry already has. Second, standardize on open protocols at the agent layer— A2A between agents and MCP to tools and systems — so that a Gemini agent, a Claude agent and a partner’s agent can interoperate without any one of them owning the others. Third, own the semantic and ontology layer in the middle. Don’t just model metrics but entities, relationships and the typed actions agents may perform; this is what delivers semantic portability and keeps the vendor lock-in at bay and in the enterprise’s own hands rather than a vendor.   Fourth, own the control-plane core components — identity, registry, observability and policy — so that governance remains independent of any single platform.

Any vendor relationship that requires managed semantics will make it intentionally harder to migrate data.   The architectural response should never be to place those semantics in any single vendor’s control in the first place. Federation buys data portability; an owned ontology buys semantic portability; open protocols buy agent portability. Composed together, they close the gap that the analysts identified.

The vendors will continue to make the case that the control plane is a product. The analysts — Gartner on governance and failure rates, Forrester on protocol proliferation, TBR and Moor on the limits of federation — are collectively telling enterprise leaders something more useful: it is an architectural decision, and the organizations that treat it as one, that build adaptive governance before their agentic minions outpace them and that preserve the option to change their minds, will be the ones still in command of their AI a decade from now.

Google Cloud Next 2026 is a genuinely strong architecture, and there is no doubt that it is the most complete agentic control-plane offering any hyperscaler has yet shipped. It is also the clearest illustration to date of why no enterprise should outsource its control plane to anyone. The shift from owning models to owning the control plane is not just underway; for organizations serious about operating at the speed of an agent-driven business, it is inevitable. The winning move at this point is to show up with an architecture, not a purchase order.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time, as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects. 

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

With years of cloud experience, IT leaders thought they finally had firm control of their cloud strategies. And then came AI.

Of course, cloud issues today extend beyond artificial intelligence. Where to place cloud workloads for maximum efficiency is one. Questions about governance, sovereignty, the growing sophistication of cyberthreats, and escalating cost concerns are also conspiring to make the cloud ever more complicated.

“It’s just grown into a complex mess,” observes cloud expert David Linthicum, emphasizing that cloud strategy today needs to address private cloud, multicloud, hybrid cloud, and sovereign clouds — much more than most CIOs have dealt with to date.

Initially, cloud discussions centered around agility, scalability, and cost optimization, says Joshua Bellendir, CIO of retailer WHSmith North America. “Today, we are balancing a much broader and more complicated set of considerations, including AI readiness, cybersecurity, data governance, sovereign data requirements, edge computing, integration architecture, and operational resilience.”

One of the biggest shifts is that “cloud is no longer simply an infrastructure conversation,” Bellendir says. “It has become deeply tied to enterprise architecture, business transformation strategy, and data strategy.”

Amit Basu, vice president, CIO, and CISO of International Seaways, also notes cloud’s growing complexity. While reduced capital expenditure and greater flexibility still apply in some areas, dealing with the environment has become significantly more challenging, he says.

Sweetwater CIO Jason Johnson describes the current state as “genuinely one of the more complex times to be managing cloud.” Providers keep expanding their catalogs with more SKUs, more services, and more options, he says. “While that’s great for capability, it creates real overhead in just keeping up. You need people who understand not just what’s available, but what’s actually the right fit for your use case.”

Many organizations are now entering a second phase of cloud maturity. “The earlier phase was focused heavily on migration and modernization,” Johnson says. “The current phase is more focused on optimization, governance, AI enablement, and operational sustainability. That shift is changing the conversation significantly for the CIOs I’m speaking with.”

But few CIOs have the luxury of simply pondering what to do. All must meet the challenges of complexifying cloud strategies head on.

How AI changes the cloud calculus

The desire to deploy AI quickly is creating tremendous pressure on IT leaders, with cloud a central concern, Linthicum says.

“The board of directors are screaming for it worse than the cloud push 15 years ago,” he says. “CIOs are feeling the pinch and having to make that move as quickly as they can” to gain more compute for AI initiatives in an already tricky environment, he adds.

At the same time, CIOs must solve the data complexity problem before integrating AI systems, Linthicum notes. “They’re running around in circles right now trying to figure out the best way to do that.”

Hyperscalers used to be “the easy button,” Linthicum says, “but they’ll be three, four times the cost.”

AI systems cost 10 times as much as traditional equivalent applications, he estimates. “So [CIOs are] putting a lot of money on the line.”

International Seaways’ Basu says AI has changed the architecture conversation. “GPU availability, vector databases, low-latency inference, and large-scale data pipelines introduce requirements that do not fit neatly into traditional cloud design models,” he notes. “Organizations are no longer simply lifting and shifting workloads. They are designing for very different compute and data requirements.”

Zachary Lewis, CIO and CISO of University of Health Sciences and Pharmacy, says the needs of internal stakeholders only compound that complexity. Business units want disparate AI capabilities, security teams want governance and some control over AI apps, the general counsel wants to know what kind of data is being put in the AI model, and the finance team wants cost predictability.

“CIOs have to reconcile all of this and try to deliver on everyone’s needs, and you have to do that successfully,” Lewis says. “Everyone has a different end goal and demand and we’re trying to square all of that for them.”

Ever since the online retailer of musical instruments and pro audio equipment formalized its cloud strategy around 2016, Sweetwater’s Johnson has sought to place workloads wherever it made the most sense for external and internal customers.

“Anything customer-facing needs to be geo-specific; as close to the end user as possible,” he says. “Same logic applies — internal workloads belong close to whoever is using them.”

The cloud offers infinite opportunities, and with that comes infinite levels of complexity, he says. “It’s just the reality of the model.”

“AI wouldn’t be possible without the cloud. The compute scale AI needed had already been built — the cloud had it and could deliver it,” he adds. “In a lot of ways, AI might be the cloud’s greatest gift to the industry. They enabled each other.”

Cloud cost control complexifies

Johnson’s biggest headache is managing costs consistently. “It used to be relatively straightforward: compute, storage, egress. Now it’s a puzzle,” he says. “Reserved instances, savings plans, spot pricing, per-request costs, data transfer fees between regions — it stacks up fast — and it’s genuinely hard to predict what your bill is going to look like until it arrives.”

Consequently, FinOps has become a discipline in its own right, he says.

Basu also believes FinOps has become essential. “AI inference costs, egress charges, and storage growth can create month-over-month cost swings that surprise even experienced teams,” he says. “Cost management is now a continuous operational discipline rather than an occasional review exercise.”

Vendor lock-in is also always in the back of Johnson’s mind. “The more deeply you integrate with a provider’s native services, the harder it is to move.” While that’s not always bad, he adds, it’s a tradeoff. “I think about it like technical debt. You’re borrowing speed now and paying interest later if you ever want to change direction.”

But Johnson recognizes that cloud providers are businesses that “squeeze for revenue and margin, and they change the rules on how you buy committed discounts and manage spend.”

Financial efficiency doesn’t happen by accident, he points out. It requires teams, processes, and real investment in FinOps. “The tools exist. Using them well is the harder part,” he says.

Most organizations have their financial expertise sitting in accounting and their technical expertise sitting in IT, Johnson explains. Getting those two to work together on cloud cost is a relatively new challenge.

“Ten years ago, the model was simple: You asked for a CapEx budget, accounting approved it, you placed hardware orders, and IT installed and optimized. Done. Now it’s a daily exercise,” Johnson says. “New services get turned on, contracts change, pricing structures shift. Finance understands the cash but not the tech. IT understands the tech but not the financial levers.”

Every major cloud provider has the tools, Johnson explains. “AWS Cost Explorer, Azure Cost Management, GCP’s billing dashboards. The data is all there.” But most organizations aren’t acting on that data, he says, “and then the bill shows up and people are surprised. The tools told you it was coming. You just weren’t listening.”

Data regulations add sovereign subtleties

The University of Health Sciences and Pharmacy has students from all over the world. Cloud has become significantly more difficult to manage due to the rise in regulatory laws around the globe surrounding data, Lewis says.

“We have to understand if the metadata is in a specific cloud region, where it is stored, and kept,” he says. “If that data ends up in a model we trained internally, can we guarantee it stays in the EU? Then, if someone wants their data purged, can we find all those locations with some level of competence?”

Basu says data sovereignty has become another major architectural consideration. “It affects where workloads can run, how data moves between regions, and what can be done with certain datasets,” he says. “You cannot assume a hyperscaler’s default configuration satisfies your regulatory obligations.”

Private vs. public vs. on-prem

AI has sparked a rethink on where to place cloud workloads, but Sweetwater’s Johnson believes the question of whether to pull more workloads into private clouds versus public clouds shifts more often than people expect. “I think the vast majority of our workloads are in the right place right now, but we got there by being willing to question the default,” he says.

Sweetwater does not operate under a rule that says new workloads always go to the cloud, he notes. A workload might start in the cloud and end up on-prem if the math changes. “The discipline is in reviewing that in real-time, finding the inflection points, and right-sizing as you go. Right tool, right time. That’s the only principle that holds up over time.”

International Seaways’ Basu is not planning a move toward private cloud, as the economics and operational overhead do not justify it for his organization.

“The right question is what is the correct data residency, latency, and control model for each workload,” he says. “That is a data classification discipline, not a cloud deployment strategy.”

Lewis, who has about 95% of the University of Health Sciences and Pharmacy’s infrastructure running in the cloud, doesn’t see a good alternative given how the stakes have changed for AI and hardware.

“If you want to train large scale data lakes and make informed business decisions with machine learning and the intelligence behind it, it’s almost not practical anymore” to be on-prem, Lewis says.

CIOs need to ask themselves whether they have the expertise to handle that infrastructure, he adds. Ultimately, “you have to make the best of what you’ve got,” he says.

Stay focused on fundamentals

Organizations may want to chase the shiny object, which is agentic AI right now, but IT leaders should focus on their infrastructure, management, and platform planning, Linthicum stresses.

“It’s not as fun,” he says, “but to do any AI within your environment, you have to solve those issues.”

The cloud enables a lot of architectural patterns, and that freedom will work against you if you don’t have guardrails, cautions Sweetwater’s Johnson. “Write the guidance document before you need it — not after you’ve already got five teams doing things five different ways.”

IT leaders also need to get ahead of tagging and cost visibility early, saying that it needs to be a first step, not a cleanup project. “If you can’t see your spend clearly from day one, you’re already behind,” he says.

A key step is to build an auditing program with solid controls around who can create production changes, Johnson says. “The blast radius of a bad change in the cloud is bigger and faster than most people expect, until they experience it.”

The skills question

The skills needed to operate a modern cloud environment are evolving faster than most internal teams can realistically keep up with, Basu says. As a result, International Seaways relies on specialized MSPs rather than trying to maintain deep in-house expertise across every domain.

“That gives us access to current capabilities without constantly retraining or rebuilding teams as the technology changes,” he explains. “The decisions that protected us in 2020 were made years before anyone realized how important they would become. Infrastructure strategy is always about preparing for a future that is not yet fully visible.”

The key is to make those decisions deliberately, with clear reasoning, rather than reacting under pressure later, he adds.

Build adaptable organizations

Edge computing is adding another layer of complexity, Johnson says. Leaders who navigate this effectively won’t be the ones who find the perfect architecture, he notes. “They’re the ones building organizations that can adapt quickly when the right answer changes tomorrow,” he says.

The real competitive advantage is not the cloud you picked, but how fast your team can learn and move, Johnson says.

Asked about other advice to make cloud less complicated, the CIOs offered the following:

• Treat your cloud architecture like a product, not a project. It needs ongoing ownership, not just implementation, Johnson stresses.
• Make sure you’re reviewing your decisions regularly. “The right call at year one often isn’t the right call at year three. Build in the checkpoints to revisit,” Johnson says.
• Tie every workload to a cost center. Basu has done this, and IT continuously reviews utilization and rightsizing rather than waiting for periodic audits.
• Data classification determines regional placement. Before any workload reaches production, ensure “Legal and Compliance are in that conversation from the start, not at the end,” Basu says.
• Create a cloud-ready solution. This can sometimes be less expensive and lower risk than lifting and shifting a heavily customized legacy environment, Basu says.
• Consolidation is a strategic choice, not a retreat. Fewer platforms, governed well, consistently outperform a fragmented multicloud estate, he says.
• Don’t underestimate the governance gap AI is opening. Build your AI governance layer now, before the debt accumulates, Basu says.
• Cloud strategy is not an IT architecture decision. The pandemic proved that it is a business resilience decision, Basu says. “The organizations that make the hard calls before the crisis arrives are the ones that come out intact.”
• Ensure cloud decisions are tied to measurable business outcomes. WHSmith’s Bellendir says IT is also investing heavily in integration architecture, cybersecurity controls, observability, and data governance to better support a hybrid ecosystem.
• Place greater emphasis on cloud cost governance and operational discipline. This will improve visibility into cloud usage and ensure that scaling AI, analytics, and digital initiatives remains financially sustainable over time, Bellendir says.

While no one can foresee whether cloud will grow less complicated down the road, organizations will continue to use it. “Cloud is no longer the future of IT — it’s the present,” says Sweetwater’s Johnson. “The conversation has shifted from ‘should we?’ to ‘how do we get better at it?’ That’s where I spend most of my time.”

This story originally appeared on CIO.

The SaaS and AI software markets have entered an era of pricing upheaval, with some new pricing models that can benefit IT leaders and some that may burn through their budgets.

The global software marketplace may be headed toward a widespread pricing reset, as AI products that compete with traditional SaaS offerings force vendors to rethink per-seat pricing, many observers say.

Pricing for traditional SaaS products is trending toward outcome-based billing, which is generally good news for CIOs and CFOs. At the same time, however, pricing for some AI tools, and some SaaS packages, is moving toward consumption-based billing, which can lead to huge invoice surprises if IT leaders don’t keep a close eye on employee usage.

CIOs should expect major pricing changes — and the need to deal with pricing uncertainty — as software vendors respond to competition and market demand, says Sidharth Ramsinghaney, director of strategy and operations at CRM data platform provider Twilio.

“The most immediate problem is budget volatility that most organizations have never had to manage before,” he says. “The shift transfers forecasting risk from vendor to buyer.”

At least 40% of enterprise SaaS spending will shift toward usage-, agent-, or outcome-based pricing by 2030, Gartner has predicted, with seat-based vendor revenue share declining from 21% to 15%. As recently as late 2025, however, some SaaS vendors were hiking prices.

AI agents, in particular, have the potential to disrupt pricing models, Ramsinghaney says. “That projection holds if AI agents continue replacing human task execution,” he adds. “AI agents have decoupled labor from value, making per-seat pricing obsolete when one agent does work that previously required 10 employees.”

However, if agent adoption stalls, per-seat pricing may have more longevity than current predictions suggest, he says, and with uncertainty about the most profitable pricing model, hybrid pricing may become the default.

Questions about outcomes

Meanwhile, even though some customers have pushed for, and some vendors have experimented with, outcome-based pricing, it’s not an easy model to figure out, Ramsinghaney says.

“Pure outcome-based pricing stays aspirational for most categories because outcome attribution is genuinely hard to measure cleanly,” he adds.

Jasper Geurts, CTO at software consulting firm Software Improvement Group, agrees that outcome-based pricing is difficult to implement. Many AI vendors, for example, are combining seat-based pricing with usage, instead of focusing on outcomes, he says.

Vendors will continue to experiment with outcome- and usage-based models, but there’s an ongoing debate over what counts as an outcome, he notes.

 “An agent can pass every acceptance test and still produce code nobody can safely evolve,” he explains. “If you pay only for functional outcomes, you are paying vendors to create technical debt.”

While some SaaS vendors look at outcome-based or hybrid pricing models, it’s a different story with AI vendors, Geurts says. The cost for frontier AI models is going up, not down, with Anthropic’s new Fable 5 model costing double the per-token price of Opus 4.8, he notes.

“CIOs tell me the token economy is opaque,” he says. “You cannot forecast a bill when agents decide how many tokens to burn. CIOs should treat tokens like cloud spend a decade ago: Meter it, govern it, tie it to outcomes.”

Still, token pricing isn’t fixed, with both OpenAI and Anthropic considering price cuts to better compete against each other as both move toward IPOs.

This pricing upheaval creates new headaches for IT leaders, Geurts says. Spending becomes harder to predict, and the outputs harder to control.

“Per-seat pricing capped the bill at headcount,” he adds. “Usage pricing scales with consumption, and as AI moves from assistants to autonomous coding, code volume outgrows what any architecture team can review. The code itself is a liability you keep paying for.”

At the same time that token usage pricing has increased, subscription pricing for AI tools has risen as well, according to a study from Lorka AI, provider of an AI-based writing and research tool.

AI tools that were free or low cost in 2023 now average between $20 and $30 per employee per month, with some premium AI tiers now reaching $200 per month, Lorka AI says. Some enterprises using several AI tools are now spending more than $1,200 per year per employee, often with overlapping functionality between products, according to the company.

Vigilance needed

All of this pricing uncertainty means that IT leaders need to be extra vigilant about software costs, experts say.

CIOs will need to pay close attention to both how services are procured and how much they are used, says Maksim Hodar, CIO at software development firm Innowise. CIOs should pay attention to usage analytics so that they can identify cost control measures and determine which pricing model best suits their business cases, he recommends.

CIOs should also conduct pilot programs before scaling the use of new software with new pricing models, he suggests.

“CIO success depends upon your ability to choose a service’s pricing model based on your business process, risk profile, and expected value associated with the service,” he says. “It’s easy to become overwhelmed by trends in the industry and simply go with what everybody else is doing.”

Hodar expects several different pricing models to hang on, with the predictability of per-seat pricing and the flexibility and scalability of usage-based pricing keeping both models around. Outcome-based pricing will also emerge as an alternative as long as vendors and customers can measure the outputs, he predicts.

IT leaders who haven’t yet embraced FinOps practices should now do so, adds Twilio’s Ramsinghaney. CIOs should track token and other usage to verify that features deliver more value than they cost, he recommends.

Those enterprises moving to outcome-based pricing models should enter explicit outcome measurement agreements with software and platform providers, he adds. “Attribution disputes are where these contracts fall apart,” he says. “Outcome-based pricing only scales where both parties can agree on attribution, and in complex enterprise environments where multiple factors drive results, that clean attribution often doesn’t exist.”

Like others, Ramsinghaney sees room for multiple pricing models going forward. Usage-based pricing works for infrastructure and API-first products where buyers build their own applications, while outcome-based pricing wins where results are cleanly measurable, such as resolved support tickets or completed workflows.

“Hybrid wins as the dominant model rather than either pure form, because it balances vendor revenue predictability with buyer cost alignment,” he adds.

Some per-seat pricing will survive as well, he says, but its use will shrink to situations where humans remain the primary users and value is closely tied to headcount.

“Per-seat persists for collaboration tools and applications where software augments human work, rather than replacing it,” Ramsinghaney says. “The misalignment only becomes acute when AI agents start acting as users that don’t occupy seats.”

Every organization has data scattered across data warehouses, data lakes, SaaS platforms, cloud drives, and data centers. Data fabrics enable organizations to centralize and control data access, making it easier for users, such as data scientists and citizen data analysts, to find and use trusted and governed data sources. 

Data fabrics, data meshes, and distributed data clouds are all platforms to help IT and data teams put some order to the chaos around the myriad of data sources they support. Large companies need data fabrics due to the volume and variety of their data sources.

“A data fabric can be thought of as the connective tissue that ensures consistent accessibility, availability, and understanding of data across an organization,” says Dominic Wellington, data and AI expert at SnapLogic. “Individual siloed platforms may have their own internal data transfer systems, and particular teams or departments may adopt interchanges that work for that domain, but a data fabric operates at a higher level, ensuring that unified data policies are applied end-to-end across the entire enterprise.”

Types of data fabrics

When reviewing data fabrics, it’s important to consider their primary use cases, supported data types, data processing capabilities, data management structures, and governance functions. Below are some considerations when reviewing data fabrics as features, platforms, and stand-alone products.

• Some data fabrics are optimized for analytics and machine learning use cases and may have limited support for unstructured data.
• Other data fabrics extend the functionality of data governance platforms beyond data cataloging and metadata management and now include persistent data management, data quality, and dataops capabilities.
• Many data integration and API connectivity platforms go beyond proxying, pipelining, and transforming data to include search, governance, and other capabilities from data centralization.
• Some SaaS platforms are extending their connectivity and data integration capabilities, enabling multicloud portability and persistent data.
• The more advanced data fabrics support features needed for AI agents and AI model training. These platforms create a semantic context layer for structured and unstructured data sources, support Model Context Protocol (MCP) integrations, have real-time query capabilities, centralize policy-driven governance, and track data lineage.    

Why data fabrics are needed for AI

Data fabrics are not just for enterprises, and today, even smaller companies need them as part of their AI democratization programs. Here are a few reasons why:

• AI agents in enterprise SaaS solutions need access to broader data sets than those core to their workflows. Platforms such as Adobe, Appian, Oracle, Salesforce, ServiceNow, SAP, and Workday offer data fabric capabilities to bring data outside of the business processes they manage into scope for their AI agents.
• Unstructured data is important for setting the context for AI agents, and data fabrics are now used to provide access to documents, emails, transcripts, and other media formats.
• Data fabrics provide data access standards for the devops teams experimenting with AI code generators, vibe coding tools, and spec-driven development approaches to develop applications and AI agents. 
• As companies use MCP servers to connect AI agents, data fabrics provide a standardized way for the agents to access governed, trusted data sources.

“As AI agents move from generating insights to taking action, the data fabric becomes foundational in the agentic era,” says Irfan Kahn, president and chief product officer of SAP Data & Analytics. “Most enterprises operate across scattered data sources and diverse data landscapes, and what’s needed is shared business context, governed access, and clear accountability for how data is used in decision-making. Without that context, agents can’t fully understand or coordinate across the enterprise to deliver meaningful value.”

Sanjay Koppikar, chief product officer and cofounder of EvoluteIQ, adds, “Multi-agent architectures become untrustworthy when a unifying data fabric architecture is missing, since agents will often work against each other in the service of their own objectives.”

Delivering context to AI agents

AI agents need a combination of real-time data, user information, problem details, and historical context to guide their decision-making. Vishal Sood, president of research and development at Typeface, says, “MCP and data fabrics give agents access, but the harder problem is contextualizing data across multiple sources and ensuring the underlying content, media, and unstructured data are trustworthy.”

Data fabrics are the foundational elements for providing current information and long-term memory to AI agents. They simplify the many-to-many problem of connecting multiple AI models, AI agents, and MCP server integrations to multiple structured and unstructured data sources.

“The data fabric does a beautiful job of encompassing three concepts needed to create applications and processes: the data catalog, the data model, and data access,” says Sanat Joshi, executive vice president of product and innovations at Appian. “But now add business rules, process models, APIs, security groups, the organizational model, and their interrelationships into one unified view of the enterprise, and that becomes your context layer.” 

Integrations with data fabrics

Devops teams just getting started on an AI agent proof of concept may want to connect directly to the optimal data sources and APIs. Michel Tricot, CEO and cofounder at Airbyte, says connecting agents to live APIs is a great start, but it creates two big problems: APIs only return data that an agent already knows to ask for, and every query is an expensive API call chain that, with overhead, can overwhelm infrastructure in production volumes.

Tricot says the data fabric for AI use cases must be dynamic, leveraging discovery of available information from replicated data, fetching live contextual information, and writing the data back to business applications to update records.

Moving data in and out of the data fabric requires an integration strategy. Zero-ETL (extract, transform, load) is one low-cost, efficient approach for connecting to structured data sourced without replicating information. Once information is accessed centrally, it also enables streamlined security and governance.

“The promise of AI agents breaks down when they’re stuck waiting on brittle ETL, dealing with poor data quality, and lacking the right context to perform analysis,” says Preston Wood, chief security and strategy officer at Databahn. “Generating AI-ready data within a data fabric gives agents real-time access to operational data without the latency and drift that undermine decision quality. A well-architected data fabric provides the governance and lineage controls that let you deploy agents confidently, knowing exactly what data they’re touching and why.”

Centralizing AI-ready data

Data fabrics centralize AI-ready data and help data governance teams address data quality issues, biased data concerns, privacy compliance, and other data governance non-negotiables. Data fabrics also help address integration issues, monitor for data pipeline errors, and report on performance latencies. The result is that AI agents, models, and other analytics capabilities can then connect to trusted data sources with consistency.

“As AI agents and MCP architectures increasingly rely on data fabrics as their golden source of truth, data quality stops being a hygiene problem and becomes a trust problem, as we all know that trust is foundational to autonomous decision-making,” says Kellyn Gorman, database and AI advocate and engineer at Redgate Software. “Organizations that invest now in semantic consistency, lineage tracking, and observable data contracts across data fabrics will be the ones whose AI agents can be trusted to act without constant human correction.”

Data fabrics that support zero-ETL and other bidirectional integrations with sources thus become an organizational knowledge base, the data source for training AI models, and a foundation for producing data metrics.

“AI agents are only as reliable as the data they’re built on, and most organizations underestimate how much implicit tribal knowledge lives in their transformation logic rather than their source systems,” says Tobias Ostwald, director of analytics at NMI. “If you’re exposing a data fabric to agents or MCP integrations, you need lineage, testing, and metric definitions baked into the layer itself, not just documented somewhere, because the agent can’t call a colleague to gut-check a number.”

Streamlining security and governance

With a data fabric in place, governance, security, and other risk management leaders have a central location to manage data security, centralize access controls, and fulfill other governance responsibilities. Miles Ward, CTO of AI in Solution Lines at Insight, says, “We have to move past security by isolation to a governance model where the fabric itself enforces the pavement and walls of compliance.”

The data fabric also governs entitlements for AI agents and their users. Centralizing these business rules can help organizations avoid creating AI debt, a risk if controls are implemented directly in data sources or consumers.

“The convergence of AI-generated code sprawl and autonomous MCP connectivity creates a ‘perfect storm’ of architectural drift and toxic permission combinations,” says Karen Cohen, vice president of product at Apiiro. “Effective governance requires a security data fabric that monitors these autonomous connections in real time to enforce intent-based policies and strictly limit agent scope to its specific purpose. By integrating guardrails that align AI-assisted development with secure architecture principles, enterprises can proactively secure their expanding attack surface without sacrificing developer velocity.”

Future considerations for data fabrics

Expect vendors to expand the scope of their data fabrics beyond text and documents. Some will include specialized document processing for common formats such as invoices, contracts, and product documentation. There will be skills and tools to support industry-specific documents such as health records and construction documents. Others will support multimedia file types and provide metadata extraction and search capabilities. 

“Enterprises are asking agents to reason across contracts, images, PDFs, and video, and this is where most data fabrics break,” says Dave Shuman, chief data officer at Precisely. “Multimodal data must be chunked, embedded, and governed with the same rigor as structured data, including lineage and access controls.”

Several other emerging capabilities include:

• Extended support for AI agent interfaces to aid in data discovery, and with greater contextual controls on where and when AI agents can access sensitive data
• Business ontologies, semantic layers, and knowledge graph capabilities, with management tools or integrations with third-party platforms
• Support for data contracts, service-level agreements, centralized data observability, auditing, and other functions that will enhance explainable AI capabilities
• Finops functions to track costs for data owners and consumers

As more companies depend on AI agents in their operations, expect top data fabric platforms to release capabilities to expand scope, scale, use cases, and governance.  

These days, hiring a specialist is relatively easy — a SOC analyst, an ML researcher, a cloud architect. Those requisitions close in weeks. What stays open for six to nine months are hybrid roles: engineers fluent in AI who can go deep in code and also understand the business. “Three skills, one person, small pool,” says Neal Sample, chief digital and technology officer at Best Buy. “These hybrids are the future of IT — and are hard to find right now.”

Two years after AI leapfrogged cybersecurity as the most difficult IT skill to hire for in CIO.com’s State of the CIO survey, the top of the list hasn’t budged. AI/machine learning and cybersecurity are now tied as the hardest roles to fill, according to the 2026 State of the CIO survey, with data science and analytics close behind. But while the rankings look familiar, the nature of the talent crunch has shifted. The hunt for LLM engineers and prompt specialists has given way to demand for people who can operationalize AI at scale, govern its risks, and wield it effectively without blindly trusting it.

Meanwhile, risk management has climbed into the top five for the first time, while business/IT automation is holding steady near the top. And pressure has eased on roles that dominated just a few years ago: cloud architecture has dropped, and application development has fallen off the list entirely as AI tools reshape what developers actually do.

“The most challenging roles are anything that needs to be bundled with AI,” says Niel Nickolaisen, IT advisor and field CTO at Valcom Technologies. Security analysts who can use AI to improve cyber posture while bad actors sharpen their attacks. Software engineers skilled at using AI platforms to design, build, and deploy. “There are simply not yet enough of these people available,” Nickolaisen says.

Hardest-to-fill IT roles: 2026 vs. 2024

Skill	2026 rank	2024 rank	Change
AI/machine learning	#1 (tie)	#1	Steady
Cybersecurity	#1 (tie)	#2	Rising
Data science/analytics	#3	#3	Steady
Business/IT automation	#4	#4 (tie)	Steady
Risk management	#5	#8 (tie)	Rising
Software engineering	#6 (tie)	#6 (tie)	Steady
DevOps/DevSecOps	#6 (tie)	#11 (tie)	Rising
Enterprise architecture	#8 (tie)	#10 (tie)	Rising
Cloud services/integration	#8 (tie)	#12 (tie)	Rising
Cloud architecture	#8 (tie)	#6 (tie)	Falling
Design thinking/UX	#8 (tie)	#15 (tie)	Rising

 Source: Foundry/CIO.com State of the CIO Survey, 2024 and 2026

AI hiring grows up

IT leaders seeking LLM expertise can take heart in the fact that the frenzy around LLM engineers has eased. “Prompt engineering as a standalone job title was a short-lived fad,” Best Buy’s Sample says. “Today, it’s a baseline skill.”

But what most organizations are looking for now is different: AI product engineers who can stand up agents, build testing frameworks, manage the cost-latency-quality triangle, and deploy AI at scale. They’re also trying to fill governance and red-team roles that didn’t exist on anyone’s org chart three years ago.

“The center of gravity moved from people who build models to people who wield them,” Sample says. “That’s a very different resume.”

Gen AI and LLM tools have become intuitive enough that the skills organizations need have evolved toward more agentic AI and less prompt engineering. “We need people who understand workflows, process simplification, and can work with an agent platform to automate work and tasks,” says Nickolaisen of Valcom Technologies. “I expect this will change over the next year or two as the agent platforms get more intuitive. We can then focus our reskilling on how to make agents more autonomous.”

The challenge is that AI is evolving so rapidly — and being invested in by everyone from cloud providers to the startup ecosystem — that experience at one company may not translate to another, and what someone learned six months ago may already be outdated.

“Best to look for people with a broad understanding and ability to consume market shifts constantly happening,” says Scott Hicar, a fractional technology leader focused on the private equity market.

Cybersecurity: A skills crisis, not a headcount crisis

Cybersecurity’s rise to share the top spot with AI reflects more than just demand. It also signals a fundamental shift in the challenges organizations face.

Six in 10 organizations now say skills gaps outweigh staffing shortages as their primary workforce challenge, according to the 2026 SANS/GIAC Cybersecurity Workforce Report, a 20-point shift from just a year ago. And the consequences are measurable: 27% of cybersecurity leaders surveyed report breaches directly tied to capability gaps, while 61% say that team stress has increased over the past two years.

The skills scarcity isn’t at the entry level; it’s at the senior architect tier. “People who can make a good security trade-off under real constraints, rather than read a dashboard, are hard to find,” Best Buy’s Sample says. “Those people are naming their price.”

The strain on security teams is compounding. Attack surfaces have expanded with every SaaS addition, API, and agent deployed. Cyber adversaries are using the same AI tools as defenders. Security teams are burning out.

Nickolaisen frames it in operational terms: “Cyber with AI is the biggest need because it’s the most near-term threat. If the bad guys can use vibe programming to build an attack in less than an hour and revise it in minutes, I need to be able to respond and modify my response in near real-time.”

The SANS research found that 74% of organizations say AI is already impacting the size of their cybersecurity teams and the roles within them. SOC and security analysts are the roles most likely to be cut as AI reshapes security teams, and these are precisely the entry-level positions where the next generation of cybersecurity leaders traditionally learned their craft. At the same time, new roles are emerging, including AI/ML security specialists, AI security engineers, and AI governance analysts.

The rise of ‘second-order’ AI skills

Automation and risk management skills have both climbed into the State of the CIO’s top five hardest-to-fill roles for the first time — and they’re rising for the same reason.

“AI blew out the surface area,” says Sample of Best Buy. “Every agent you deploy is a new automation and a new risk, and most governance, risk, and compliance (GRC) and ops functions weren’t designed for that pace.”

With automation, the need isn’t for more RPA developers; that work has become a commodity. Organizations need people who can look at a process and decide what to automate, what to retire, and what to redesign. “That’s three jobs welded together,” Sample says. “Business analyst, process engineer, and technologist. Anyone who does all three well is rare — and expensive.”

The shift from chatbots to agents is driving much of this demand for automation talent. “The first wave of agents won’t invent new tasks; they’ll replace how existing work gets done,” says Ameya Kanitkar, co-founder and CTO at AI measurement platform Larridin. “Enterprises are rearchitecting critical business workflows around fully or semi-autonomous agentic flows, and the demand for people who can build and operate these is massive.” The catch, he says, is that it requires an uncommon combination: understanding how systems work and how the business runs.

Risk management presents a similar challenge. GRC functions built for SOX and PCI compliance aren’t necessarily optimized for model risk, prompt injection, or third-party AI exposure. “We’re hiring for a discipline that’s maybe five years old, against a job description that’s twenty years old,” Sample says. “That gap is the problem.”

One capability that’s grown more critical is third-party risk management. “With AI being embedded in most of what we purchase and use, [the question becomes] do I need both more people and a better-governed process to assess the AI that comes from third parties?” says Nickolaisen of Valcom Technologies.

Dr. James Stanger, chief technology evangelist at CompTIA, notes that risk management requires a different mindset than many technical workers bring to the table. “You’ve got to know your technical stuff, but you have to understand the business use of the technical stuff — otherwise you’re addressing technology, not risk,” he says.

The midlevel squeeze

AI coding tools and low-code platforms haven’t reduced the demand for software engineers, but they’ve changed its shape. A strong engineer with good AI tooling now produces roughly what three engineers did just a few years ago. “The squeeze is on the middle tier: the people whose day job was wiring APIs together,” Sample says.

Engineering hiring is bifurcating, says Larridin’s Kanitkar: strong demand for experienced leaders who bring judgment and ownership, and for junior talent that’s AI-native from day one. “The squeeze is in the middle,” he says. “People coasting on midlevel execution are finding themselves on the wrong side of the job market.”

AI tools are pushing engineers to think more like architects. “At one time, the industry was looking for IT ‘plumbers’ who could code,” CompTIA’s Stanger says. “Now the industry is demanding people who can think architecturally and in terms of risk and privacy. We don’t need keyboard code punchers; we need proactive designers who use AI to model potential performance issues.”

For DevOps specifically, a consolidation is under way. “Platform engineering is the growth role,” Sample says. “The generic DevOps engineer title is being absorbed into platform or site reliability engineering (SRE), and I don’t think it survives the next few years as a distinct function.”

Cloud has stabilized

Cloud roles have become easier to fill. Already visible in 2024, the trend has only continued.

Most organizations have reached a cloud steady-state, says Valcom Technologies’ Nickolaisen. “Unless something big changes, we have our public, private, and on-prem workloads,” he says. “The skills of my system administration teams are adequate to support that.”

Training programs have caught up with cloud, Stanger notes — though he adds it’s hard to say exactly why the pressure has eased.

“Cloud has matured into a real profession,” Sample adds, “and more people have done it at scale for many years now.”

Some cloud specialties remain hard to fill: FinOps, regulated-industry migrations, and reverse migrations. And certain workloads are coming back on-prem. “Especially AI inference, where the unit economics in cloud can be brutal at scale,” Sample says. “That’s shifting the skill mix again, and nobody’s resume says, ‘I can move workloads off the cloud intelligently.’”

What’s working to close the gap

If there’s one point of agreement among IT leaders, it’s this: Upskilling and internal mobility are more effective than external hiring in terms of speed, cost, and retention.

“Our most productive AI engineers in 2025 were not hired as AI engineers,” says Best Buy’s Sample. “They were strong software engineers, upskilled with good internal training and real projects.”

Outside expertise offers less advantage than it used to. AI has moved so fast that contractors aren’t necessarily ahead of internal teams, according to Nickolaisen. “Once my teams are over the initial hump and embrace AI, their skills develop quickly,” he says.

The key is trust. “Assure the teams that we will not use the resulting productivity to get rid of people, and it’s amazing what can be done to accelerate the delivery of value,” says Nickolaisen.

One change that dramatically expanded Best Buy’s talent pool was to stop treating AI hiring as a separate pipeline. “We hire engineers, then we introduce them to our take on AI,” Sample says. “That one reframe opened a pool at least 10 times larger and gave us better output.”

Stanger advocates cross-skilling, apprenticeship-based mentoring, and pathway-based learning — tactics that focus on building capabilities rather than checking off credential boxes.

“Instead of the tired, old, pedigree-based lens that asks, ‘Where is your four-year degree from,’ the most progressive hiring institutions are now asking, ‘What are your skillsets, and where can you take us with them?’” says Stanger.

Chasing the latest job titles carries risk. “The prompt engineer hiring wave of 2023 — those roles aged out in eighteen months, and the people who took them are reskilling now,” Sample says. “Hiring a job title rather than a capability has a short shelf life. That lesson is already repeating with agentic AI in some places. It won’t age better the second time.”

Soft market, hard problem

The tech hiring market is sluggish, driven by uncertainty about AI-driven job displacement, economic conditions, and what Nickolaisen characterizes as “pretty much everything in our lives.” But for the skills that matter most, the competition remains fierce.

“The next couple of years are critical,” Kanitkar says. “This is when the separation happens.” The frontier moves every day, which means the gap between IT organizations that master the shift and those that resist it will only widen.

Tokenomics has quickly become one of the most practical subjects in enterprise AI. In simple terms, it is the discipline of understanding how tokens are consumed, how that consumption turns into cost and how an organization can shape usage patterns so that AI remains valuable without becoming financially unpredictable. In most large language model services, every prompt, every retrieved context block, every tool description, every system instruction and every generated response contributes to the token bill. That means the economics of AI are no longer driven only by licenses or infrastructure. They are increasingly driven by usage behavior, prompt design, model choice and governance decisions. For technology leaders, this creates a new operating responsibility: they must treat tokens the way they already treat compute, storage and network consumption. Token usage needs to be measured, planned, optimized and governed with the same discipline as any other cloud resource.

Understanding tokenomics in AI services

A token is the smallest billing unit used by many AI services to represent pieces of text, code, symbols or structured content processed by the model. A single user request usually consumes input tokens and output tokens. Input tokens come from the instructions sent to the model, including the system prompt, user prompt, conversation history, retrieved documents, tool schemas and metadata. Output tokens are the tokens generated in the response. In most commercial AI services, output tokens are priced higher than input tokens, which means long and unconstrained responses can silently become one of the largest sources of waste. This matters even more in enterprise settings where thousands of requests are executed every day across assistants, search copilots, engineering agents, document summarizers, support bots and automated workflows.

In practice, token costs are shaped by a handful of recurring patterns as per the Gartner report. The first is context inflation, where applications keep sending large prompt prefixes, verbose policy instructions, long chat history and oversized retrieval payloads on every call. The second is poor model matching, where high-end models are used for routine tasks such as classification, extraction, formatting or test data generation, even though smaller and cheaper models would do the job well. The third is response sprawl, where no output length controls are enforced and the model returns far more text than the user or process actually needs. The fourth is retry amplification, where agentic or automated workflows invoke the model repeatedly because the surrounding application lacks validation, caching or routing logic. Once AI usage expands across departments, these issues accumulate rapidly and can distort the economics of a program even when the underlying models are technically sound.

How an organization should plan token optimization

Organizations that manage AI well do not begin with model selection alone. They begin with operating intent. That means clearly identifying which use cases need premium reasoning, which use cases can tolerate lower latency or asynchronous processing, which ones need strict output controls and which ones are suitable for summarization or retrieval before generation. You can refer to Gartner’s “Tokenomics will become a new discipline” for guidelines.

A sensible token optimization plan usually starts with workload segmentation. Interactive experiences such as executive copilots, complex engineering assistance or contract analysis may justify higher-quality models. Routine workloads such as log classification, regression test explanation, boilerplate documentation, FAQ answering and metadata tagging often do not. Segmenting workloads this way allows the enterprise to create a service catalog for AI usage rather than exposing every consumer to the most expensive model by default.

The next step is governance. Every enterprise AI platform should collect token telemetry at the request level and aggregate it by application, environment, team, model and use case. Without that visibility, optimization becomes guesswork. Leaders should define token budgets, monthly thresholds, rate limits and environment-specific quotas. It is also wise to introduce approval paths for long-context models, tool-heavy agents and experimental multi-step reasoning workflows because these patterns can multiply token consumption very quickly.

A mature operating model also includes prompt standards, retrieval size limits, output token caps, response templates and model routing policies. This turns token optimization into an engineering discipline rather than a one-time cost exercise. When done well, the organization creates a feedback loop where usage data improves architecture decisions and architecture decisions reduce unnecessary consumption over time.

Core token optimization techniques across cloud AI platforms

Some optimization practices are effective regardless of whether the organization is using AWS, Azure or Google Cloud. The first is prompt minimization with purpose. This does not mean making prompts unnaturally short. It means sending only the instructions and context required for the current task. Static instructions should be kept stable and separated from dynamic content. Retrieved documents should be ranked and trimmed instead of being attached in full. Tool definitions should be exposed only when needed. Few-shot examples should be used selectively and removed when they no longer improve quality. In many enterprise systems, the easiest savings come not from changing the model, but from removing repetitive and low-value prompt baggage. You can refer to Deloitte’s report “The pivot to tokenomics” for more details on this scenario.

The second technique is model routing. Not every prompt deserves the largest model. A classifier, router or policy layer can evaluate the request and direct simple tasks to lighter models while reserving premium models for complex reasoning, domain-sensitive analysis or code-heavy interactions. The third technique is response shaping. If the application needs three bullet points, a JSON object, a summary or a fixed-length explanation, that expectation should be explicit. Output token controls, concise formatting instructions and schema-bound responses help contain cost while also improving consistency. The fourth technique is caching. Repeated prompt prefixes, repeated documents, repeated tool descriptions and repeated intermediate outputs should be cached wherever the platform allows it. Prompt caching can reduce the need to recompute long shared prefixes, while response caching prevents duplicate model calls for frequently repeated requests. These approaches are especially valuable in internal copilots, support bots and engineering assistants where repetitive interactions are common. AWS, Azure and Google Cloud all support variations of context or prompt caching for repeated content, which can significantly reduce repeated input-token processing when prompts share the same stable prefix.

The fifth technique is asynchronous and batch execution for non-urgent work. Many AI jobs inside enterprises do not need interactive response times. Offline summarization, document enrichment, code review snapshots, test case explanation, defect clustering and log interpretation can often be queued and processed later at lower cost. The sixth technique is context lifecycle management. Long conversations and agent sessions must be pruned, summarized or checkpointed instead of carrying the full history forever. If a session needs memory, a summarized state is usually cheaper than replaying every turn. In retrieval-augmented systems, only the top-ranked passages should be injected into the prompt and documents should be chunked intelligently so that the model receives the smallest high-value context possible. These changes reduce cost, improve latency and often improve answer quality because the model is forced to focus on more relevant inputs.

Token optimization on AWS

On AWS, token optimization typically centers on Amazon Bedrock and the architecture built around it. A strong starting point is model selection by task type. Bedrock gives organizations access to multiple foundation models and that creates an opportunity to route simple workloads to smaller models and reserve more capable models for difficult reasoning or coding tasks. This is often the single biggest cost lever. Another major lever is prompt caching. Amazon Bedrock supports prompt caching for supported models, allowing repeated prompt prefixes to be reused instead of being recomputed on every request. This is particularly useful when the application repeatedly sends large system instructions, policy context, product manuals or codebase guidance. Bedrock documentation explains that cached prefixes can reduce latency and lower input-token cost for repeated context, with model-specific checkpoint thresholds and time-to-live behavior. [Amazon Bedrock]() prompt caching can reduce repeated input processing when stable prompt prefixes are reused across calls.

AWS environments also benefit from separating real-time and non-real-time inference paths. Bedrock batch-style or queued processing patterns are far more economical for workloads such as nightly test artifact analysis, bulk document summarization, defect triage and generated knowledge extraction. Engineering teams should also place a policy layer in front of Bedrock to cap output size, restrict unsupported long-context prompts and enforce retrieval limits. If the application uses agentic orchestration, every tool call and every retry should be monitored because agents can consume tokens far faster than interactive human users. A practical AWS pattern is to combine Bedrock with a lightweight gateway that logs tokens per request, tags usage by environment and application and routes requests to the least expensive model that still meets quality objectives. This gives CIO and CTO teams better visibility into where token spending is justified and where it is simply accidental.

Token optimization on Azure

On Azure, token optimization is often discussed in the context of Azure OpenAI and Microsoft Foundry model services. Azure provides one of the clearest examples of prompt caching as a cost and latency lever. Microsoft documentation explains that prompt caching can reduce repeated processing of identical prompt prefixes and supported models can keep cached prefixes available for short in-memory periods or extended retention windows, depending on the model and configuration. To benefit from this, organizations must structure prompts carefully. Stable content, such as system instructions, compliance rules, coding standards or tool schemas, should appear at the beginning of the request, while variable user content should appear later. [Microsoft Foundry]() documents that prompt caching applies to supported Azure OpenAI models when prompts meet minimum length and prefix-match requirements, helping reduce latency and input-token cost.

Azure environments are also well-suited for strong observability. Organizations can capture request telemetry, prompt tokens and completion tokens through platform diagnostics and application-level logging, then correlate that usage with deployment names, environments and business applications. This makes it easier to spot noisy prompts, excessive completions or teams that are using premium models for low-value work. In mature Azure estates, leaders often separate pay-as-you-go experimentation from predictable, high-volume workloads. Stable workloads may justify reserved or provisioned capacity, while spiky or uncertain workloads can remain on variable pricing. For DevTest, Azure teams should use model allow-lists, token ceilings and shorter retention periods for conversation history. Developers should never have unrestricted access to large-context and premium reasoning deployments unless the workload genuinely requires it. Governance is most effective when prompt templates, response formats, budget thresholds and environment-level quotas are built into the platform rather than enforced only by policy documents.

Token optimization on Google Cloud

On Google Cloud, token optimization is commonly associated with Vertex AI and Gemini-based workloads. Google Cloud has emphasized context caching as a way to reduce the cost of repeatedly sending large prompt content such as detailed instructions, codebases, multimodal assets or long documents. Vertex AI supports both implicit and explicit caching patterns, which allow organizations to either benefit from automatic reuse or deliberately persist reusable context for predictable savings. Google notes that Vertex AI context caching reduces repeated token processing and can lower the cost of cached tokens for supported Gemini models, while also improving latency.

Google Cloud also offers a practical ecosystem for prompt improvement and token discipline. Vertex AI prompt optimization capabilities help teams refine prompts so that they are clearer, more compact and more effective without depending on excessive examples or unnecessary instruction text. That matters because poor prompts often lead to repeated retries, broader context injection and inflated output lengths. Another valuable pattern on GCP is workload routing through Model Garden or application logic so that lower-cost models handle straightforward summarization, extraction and routing tasks while premium models are reserved for high-value reasoning. In large enterprise deployments, teams should also use token-count estimation before execution for expensive workflows, especially when long documents, code repositories or multimodal content are involved. This creates a preflight check that can stop oversized requests before they reach production inference paths.

Real-time example: AI-powered test failure analysis in a DevTest program

Consider a large engineering organization that uses AI to analyze failed test cases during continuous integration. Every failed build triggers an AI workflow that reads stack traces, selected log fragments, recent code changes, known defect patterns and testing guidelines, then generates a root-cause summary and recommended next steps for developers. At first, the team builds the solution straightforwardly. It sends the entire recent build log, the full testing policy, the complete conversation history from the issue thread and a long instruction template to a premium model for every failure. The results are useful, but the token bill rises sharply. The reason is obvious in hindsight: the same policy content is sent repeatedly, the logs are far longer than necessary and many failures are routine enough that they do not require the most capable model.

Now, imagine the same workflow after token optimization. The platform first classifies the failure type. If it is a known regression signature, a smaller model handles the explanation. Only ambiguous failures go to the premium model. The testing policy and coding standards are moved into a reusable cached prefix. The log stream is preprocessed so that only the most relevant error windows and surrounding events are included. Older conversation turns are summarized into a short state object instead of being replayed in full. The response is constrained to a fixed template: probable cause, impacted component, confidence level and recommended action. If the same failure signature appears again, the prior explanation is served from the response cache unless recent code changes suggest a new interpretation. This redesigned flow typically reduces unnecessary input tokens, lowers output verbosity and improves turnaround time. More importantly, it turns AI usage into a disciplined engineering service rather than a loosely controlled experimental feature.

How CIOs and CTOs can optimize AI usage in DevTest

DevTest environments are where token waste often hides in plain sight. Teams experiment freely, prompts change often, logs are verbose and developers naturally gravitate toward the best available model because they are trying to move quickly. That is exactly why CIO and CTO leaders need a distinct DevTest token strategy rather than simply copying production policies. The goal in DevTest is not to eliminate experimentation. The goal is to make experimentation cost-aware. A sensible starting point is environment segmentation. Sandbox, development, testing, performance validation and pre-production should each have their own token budgets, model permissions and rate limits. Premium reasoning models should be limited to approved scenarios, while most routine experimentation should default to cheaper models with smaller context windows.

Leadership teams should also insist on a small set of operating controls. First, every DevTest AI request should be tagged with application, team, engineer, environment, model and use case so that usage can be traced accurately. Second, token ceilings should exist at both user and application level, with alerts when thresholds are crossed. Third, platform teams should provide reusable prompt templates that are already optimized for brevity, schema-based output and caching compatibility. Fourth, batch windows should be used for heavy non-interactive workloads such as codebase summarization, test artifact enrichment and bulk defect clustering. Fifth, long-running agent workflows should be monitored for retry loops and context growth, because these are common sources of runaway consumption. When these controls are present, DevTest remains innovative without turning into an uncontrolled cost sink.

From an executive planning perspective, CIOs and CTOs should treat AI token usage as part of both cloud FinOps and engineering governance as you can read from this forbes report on “Best practices for designing effective Tokenomics”. Monthly reviews should not focus only on total spend. They should examine token consumption per workflow, cost per successful outcome, model utilization by task category, cache hit rates and the percentage of requests routed to lower-cost models. Teams that repeatedly exceed expected token usage should not simply be blocked; they should be helped to redesign prompts, reduce retrieval payloads, improve orchestration logic and replace verbose responses with structured outputs. This creates a healthier operating culture. The conversation moves away from restricting AI and toward making AI economically sustainable at scale. That shift is important because enterprise AI programs succeed not when usage is unlimited, but when value and consumption stay in balance.

Conclusion

Tokenomics is now a foundational part of enterprise AI architecture. As organizations scale AI across engineering, operations, support and knowledge work, token usage becomes a direct determinant of cost, responsiveness and sustainability. The most effective organizations plan for this early. They segment workloads, match models to task complexity, constrain outputs, trim context, use caching intelligently, batch non-urgent work and govern DevTest with the same seriousness they apply to production infrastructure. AWS, Azure and GCP each provide useful mechanisms to support this approach, but the bigger advantage comes from disciplined design. When token optimization is treated as a core architectural practice, AI programs become easier to scale, easier to govern and far more likely to deliver measurable business value without waste.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

IT leaders and CFOs are starting to push back on unrestrained AI spending within their organizations, with many enterprises now looking for ways to get better value out of their automation tools, observers say.

In recent months, several companies have blown through AI token budgets while encouraging employees to experiment with the technology. Several companies have deployed AI token usage leaderboards to advance adoption, but the practice has led to employee tokenmaxxing, with one Disney employee interacting with the Claude AI 460,000 times in a nine-day period.

Over at Uber, employees burned through the company’s entire 2026 AI budget in four months, prompting executives to cap AI coding assistant use.

At the same time, Anthropic and other major AI vendors are rolling out new metered pricing models.

Now, to counter runaway token use, some companies have begun to focus on “valuemaxxing,” by combining visibility, governance, and financial accountability to create better returns on their AI spending.

Value as a new metric

The focus at many enterprises in past years has been using AI to increase productivity, but value is increasingly becoming an important metric, says Becky Trevino, chief product officer at FinOps vendor Flexera.

“Before, the value was, ‘Let’s just deploy it to as many people as possible,’” she says. “It’s now quickly becoming, ‘Let’s be smart about this because we have a set amount of tokens.’”

AI budget surprises have become a serious talking point among customers of the technology, she adds.

“The metric for success is not if I have 99% of my organization using Microsoft Copilot,” Trevino says. “It’s now, show me the money. Show me what’s changing in your organization.”

FinOps companies such as Flexera aren’t the only organizations pushing AI customers to focus on value. In early June, the Linux Foundation announced the new Tokenomics Foundation to establish open industry standards, benchmarks, and best practices for the economics of AI infrastructure. 

The bill comes due

A reckoning about AI value and cost is overdue, some experts say. IT leaders who aren’t worried about the price of AI services are underestimating the coming problems, says Cliff Jurkiewicz, vice president of global strategy at HR-focused AI vendor Phenom

“AI is underpriced right now, and that’s masking the real cost,” he adds. “Behind every prompt is expensive infrastructure — data centers and energy — and providers aren’t absorbing that forever.”

There seems to be a casual approach to AI token use at many organizations, he says, with the current cheap access phase encouraging overconsumption.

“There’s very little discipline around what actually drives business value versus what’s just convenience,” Jurkiewicz says. “Every interaction has a cost, input and output, and these systems tend to overdeliver, which means you’re paying for more than you need. Multiply that across an entire workforce, and costs scale fast.”

As Anthropic and OpenAI both appear to be headed toward IPOs, pricing models will change, he predicts. Smart AI users will respond by limiting use, he adds.

“As pricing shifts to metered models, companies are going to get a wake-up call,” Jurkiewicz says. “The winners will be the ones that put guardrails in place early by prioritizing high-impact use cases and treating AI like a finite, strategic resource, not an unlimited utility.”

IT leaders need to recognize that costs can vary widely between AI models, adds Andy Sen, CTO of IT services marketplace AppDirect. Many companies are allowing employees to use models without considering the cost, he says.

“A lot of companies are turning on AI features everywhere, riding the productivity wave until they are blindsided by a huge bill,” he adds.

Encourage savings

Sen encourages IT leaders to research the costs of individual models and to encourage employees to use the most economic choice available. IT leaders should consider turning off premium features for small tasks, such as writing emails.

“The key is understanding the difference in cost between some of these models, because there are some that can be one hundred times more expensive than others,” he says. “Instead of getting an answer in fifteen seconds, you’re getting it in five seconds, and for most work, that’s not really worth it.”

CIOs can also help employees use AI more economically by pointing out the workers who are using it well, Sen says.

“If you want to see more people leveraging AI across the board, point to the people who are already using it successfully,” he says. “Role models can be a great way to show people how they can be more effective at their job and encourage AI use.”

Flexera’s Trevino recommends that organizations consider FinOps services and prioritize which departments have more access to AI tools.

“If you have a limited amount of budget and you have 20 departments, which of those departments matter the most?” she says. “Allocate most of your AI budget there. If you know three of those 20 are the ones that are you need to drive growth or competitiveness for your business, then you should really ensure that those three business units have the access they need.”

Modern AI systems have evolved beyond the simple chatbots that quickly became popular. Now they use semantic tools to manage workflows and link machines to machines, providing a flexible and effective framework for the next generation of business automation. What you used to build in Microsoft’s Power Platform or construct inside Biztalk is now an agent, built around large language models (LLMs) that can parse both your data and the APIs that you want to use your data with, orchestrating workflows with a level of autonomy that traditional tooling can’t match.

That shift has offered new opportunities, much like those that came with business platforms like Microsoft Dynamics and Salesforce. Here, tools built to solve one set of business problems could be turned into applications that could be sold to other companies. What worked for you to solve one of your problems could now be an added revenue stream, sold through platform marketplaces that helped customers manage installations and customizations.

Agents are business applications now

Modern agents are much like those business applications. Often developed to solve a specific need, but quicky adopted by organizations and refactored to apply enterprise standards (using tools like the Agent Governance Toolkit and frameworks like Microsoft’s Agent Framework), they’re rapidly maturing and are ready to be shared more widely. The process of sharing needs to be curated and controlled, and, if possible, tied to a revenue stream.

There’s certainly some urgency here. Until recently, subsidized tokens have kept costs artificially low. Now companies like GitHub and Anthropic are moving to a more sustainable (for them) pricing model, increasing the cost of inferencing and squeezing companies’ AI budgets. As a result, switching AI projects away from a cost to a revenue source is high on CIOs’ agendas. If those tuned and trained agents can be sold on a marketplace, then that token budget can be justified.

Microsoft has always been a company built on partner relationships, starting with individual developers and working all the way up to the largest software companies and consultancies. That reach is key to helping partners extract as much value as possible from their agents, as it allows Microsoft to integrate its partner sales tools into its own products and services, as well as into other platforms.

Extending the Microsoft Marketplace for AI developers

We’re already familiar with many of Microsoft’s marketplaces, built into individual tools like Teams, into platforms like Microsoft 365 or Visual Studio, or into the Windows Store. Now the company is doing the same for AI developers, extending Microsoft Marketplace to software agents. Announced at Build 2026, the updated Microsoft Marketplace provides ways to publish code—apps and agents—developed across all of Microsoft’s development platforms, including Copilot Studio, opening the marketplace up to traditional and non-traditional developers alike.

Perhaps the most important aspect of this new Marketplace is its own intelligence, using context to expose your code to the right audience. If you’ve developed an agent for use with Microsoft 365, it will be exposed inside the Microsoft 365 Copilot Agent Store; for Visual Studio, in the Visual Studio Marketplace; or for Teams, in the Microsoft Marketplace. All of these are different views on the same back end, using AI to ensure that the relevant agents are displayed.

Replacing search with Intelligent Discovery

This is extended by another new service, Intelligent Discovery, which adds natural language support to search, using AI to infer user intent and highlight the most relevant tools. Building on the familiar metaphor of the search bar, the initial smart search model offers a freeform way to explore the Marketplace. While there are suggested prompts, they’re not necessary. The search tooling allows you to generate comparisons between tools using your own criteria, with the Marketplace AI generating views based on your requirements.

Microsoft’s aim here is to shift discovery from keywords to use cases, so that buyers can quickly get the tools they need without having to evaluate different solutions, before completing a purchase. By handing that aspect of the buying process over to Marketplace’s AIs, customers can go straight to trials or even to buying agents and applications.

For a tool like this to be successful it needs to be trustworthy. By building it on top of the same development frameworks as your agents, Microsoft can take advantage of the AI guardrails built into Microsoft Foundry as well as low-level tooling like the Agent Governance Framework. Restricting the intelligent search to the Marketplace catalogue reduces the risk of hallucination, as output is grounded in Marketplace data and metadata.

A developer-friendly marketplace

Microsoft is providing tooling to help developers get their listings right. According to Cyril Belikoff, Microsoft’s vice president of Commercial Cloud and AI, “We actually have a separate AI tool that we give to software companies to optimize their listings, called a listing optimizer, funny enough, and that listing optimizer reviews their listing and then provides them with particular guidance on how to best improve it, so that it can be best discoverable in today’s search world.”

You can expect the listing optimizer to be tuned to work with the new Marketplace tooling, but for now it still focuses on traditional search. As Marketplace is a B2B platform, there’s a lower risk of spam applications, but even so, Microsoft remains aware of the possibility of a new system being gamed, and will be rolling out Intelligent Discovery carefully, monitoring its performance as more customers get access over time.

Having a new discovery method is one thing; getting quality AI applications in the Marketplace is another. Microsoft is validating all code submitted, though the criteria will differ between target platforms. An agent built for Teams will be treated differently than one built on Microsoft 365’s WorkIQ. It’s an approach that allows Microsoft to support new standards as they become available.

Alongside its agent development tooling, Microsoft is rolling out a new set of guidelines and processes to help developers get ready to sell their agents. Hosted on GitHub, these offer code templates as well as a link to the App Advisor guidance tools.

Still gaps to fill

This first release of Intelligent Discovery is promising, but some key features are missing. With agent token costs an increasing problem for businesses, it would be nice to see tools that help predict costs, integrating with finops tooling. We’re living in an age of shadow AI, and putting the AI we used to buy with credit cards in Microsoft Marketplace is one way to shine a light on those shadows — bringing the necessary control and governance to AI purchases, and maybe even providing support for site licensing.

Microsoft Marketplace is becoming a useful resource for AI application developers. It encompasses the entire development life cycle: offering tools that can help you build agents, the models that you need to power your agents, and finally a way to monetize your work. There’s a longer-term opportunity here, for both the Marketplace and Intelligent Discovery to offer Model Context Protocol (MCP) interfaces, ensuring that tooling and tool discovery become part of the developer workflow, and making developers aware of new tools that might help solve a problem or simplify a task.

Salesforce is planning to acquire m3ter, a provider of usage-based billing, to expand the capabilities of Revenue Cloud, now known as Agentforce Revenue Management.

“The acquisition will bring high-volume mediation, metering and rating capabilities natively to Agentforce Revenue Management, enabling enterprises to launch, track, scale, and bill with the flexible usage and outcome-based pricing models needed for the AI era,” the company said in a statement.

“Most enterprises selling software or services are still on legacy CPQ and billing systems built for seat-based pricing. Their own products are increasingly AI-driven and usage-heavy, and their billing infrastructure simply hasn’t kept up. They’re either building custom metering layers, stitching together Stripe with homegrown tools, or leaving money on the table because they can’t accurately track consumption,” said Bhupendra Chopra, chief revenue officer at IT consulting firm Kanerika.

“m3ter inside Agentforce Revenue Management means those companies can run usage-based and outcome-based billing natively inside Salesforce, without cobbling together external systems. Faster billing cycles, fewer reconciliation errors, and the ability to launch new pricing models without rebuilding their monetization stack from scratch. That’s a real operational win for a CIO,” Chopra added.

Aiding the monetization layer for Headless 360

While Salesforce talks up how the acquisition will enable it to better serve its customers, it could also enable it to better bill them, as it attempts to grow its own revenue by monetizing interactions with its AI services.

Pareekh Jain, principal analyst at Pareekh Consulting, said, “m3ter’s metering and rating capabilities are likely to become a core component of Salesforce’s broader Headless 360 and agentic CRM strategy, enabling monetization of APIs, AI agents, workflows, and machine-to-machine interactions.” Jain said.

“Salesforce’s Headless 360 enables AI agents, applications, and APIs to consume CRM capabilities directly, making traditional per-seat licensing less relevant. By adding m3ter’s metering and rating capabilities, Salesforce gains the ability to measure, price, and bill for that consumption, making the acquisition key to generating revenue from the new offering,” he added.

He sees m3ter’s capabilities helping Salesforce address some of the more critical concerns that CIOs have around implementing agentic systems at scale: what constitutes a billable event, how AI agent interactions will be charged, what usage visibility tools are available, whether spending caps and anomaly detection exist, and how future costs can be forecast.

“The acquisition creates the foundation for CRM FinOps capabilities such as consumption dashboards, quotas, spending alerts, chargeback mechanisms, cost forecasting, and agent ROI tracking,” Jain said.

Salesforce expects to close the deal by the end of July.

For many CIOs, the challenge of cloud cost management is no longer identifying spending problems but determining what caused them, why they happened, and how quickly they can be fixed. As cloud environments expand and AI workloads add new layers of complexity, cost governance is increasingly becoming an operational challenge that stretches beyond centralized FinOps teams.

AWS is betting that its new FinOps Agent, currently in public preview, can help solve that problem by automatically investigating anomalies, answering cost questions, and routing findings directly to engineers and finance team members after drawing data and findings from existing services, such as AWS Cost Explorer, Cost Anomaly Detection, Cost Optimization Hub, and Compute Optimizer.

That routing, according to AWS, is made possible due to the agent’s integration with Jira and Slack, enabling alerts and optimization recommendations to be surfaced directly within the collaboration and ticketing tools that most engineering teams use.

Faster remediation and improved accountability

FinOps Agent’s value lies in stronger accountability and faster remediation that could result in improved cloud financial governance maturity.

“Most enterprises can already identify cost anomalies. What they struggle with is latency: Determining ownership, tracing the operational cause, and getting the issue in front of the correct engineering team quickly enough to matter,” said Dion Hinchcliffe, lead of the CIO practice at The Futurum Group. “FinOps Agent seeks to close the loop between detection, investigation, attribution, and operational response. That is strategically important because cloud inefficiency is often cumulative and highly distributed. Small misconfigurations repeated across thousands of workloads create enormous aggregate waste over time.”

In fact, the new agent’s automated root-cause analysis and routing, according to Ashish Chaturvedi, leader of executive research at HFS Research, is precisely what most enterprises currently lack.

“The gap in enterprise FinOps has never been data availability. The gap is what happens after the data surfaces. A cost anomaly detection alert fires, and then what? That workflow used to take hours and depended on a human remembering to do it. FinOps Agent collapses that entire chain into an automated loop,” Chaturvedi said.

The agent’s automated workflow could act as a way to embed accountability directly into cloud cost management processes, Chaturvedi noted.

“The agent traces the anomaly to a root cause, identifies the responsible owner (using your account-to-team mappings), and opens a Jira ticket in that engineer’s queue. When the person who caused the cost change gets the investigation summary in their own ticketing system, the accountability loop closes itself,” Chaturvedi said.

“That’s the real unlock: not better data, but data that arrives at the right desk at the right time with enough context to act on,” Chaturvedi added.

That automated workflow, according to Hinchcliffe, should also help reduce one of the biggest hidden costs in FinOps today: “The manual coordination overhead between finance, platform engineering, operations, and application teams.”

Bringing cost intelligence closer to developers

While the governance benefits may resonate most with CIOs and FinOps leaders, analysts say the new agent could also help reduce the burden on developer and engineering teams by making cost information more accessible and actionable without disrupting workflows.

“Traditionally, devs have had really poor visibility into the downstream financial impact of infrastructure decisions. Cost data often arrives too late, in the wrong format, or through centralized governance channels disconnected from day-to-day engineering work,” Hinchcliffe said.

“FinOps Agent brings cost reasoning directly into developer tooling and collaboration environments. The result is that developers can increasingly treat cost efficiency as a real-time engineering signal alongside performance, reliability, and security, which is exactly where mature cloud enterprises want it to be,” Hinchcliffe added.

New operating model for FinOps?

Beyond accountability and faster remediation, analysts also see the new agent as capable of driving  “meaningful evolution” in the FinOps operating model for CIOs.

“FinOps teams move away from being the people who manually chase anomalies and toward being the designers of guardrails, policies, and operating models. Engineers take on more day-to-day ownership because the feedback loop becomes immediate and embedded. For CIOs, the implication is significant: governance becomes more distributed, which can improve speed and accountability,” said David Linthicum, an independent consultant.

However, Linthicum warned that CIOs shouldn’t take the FinOps Agent at face value: “Enterprises should watch for three things — whether recommendations are trusted, whether ownership routing is accurate, and whether actions actually get completed.”

“If AWS can make FinOps more embedded, contextual, and automated, this could be meaningful. If it becomes just another interface over existing data, the impact will be more incremental than transformational,” Linthicum pointed out.

Why AI may accelerate the shift to agentic FinOps

FinOps Agent could become more common and replace traditional FinOps due to the growing complexity and cost of AI deployments, analysts say.

“Traditional FinOps was built for infrastructure that scales predictably. Existing practices will buckle under AI workloads, and that will challenge this core underpinning principle. First, cost attribution is harder. Second, consumption is less predictable. Third, the ROI measurement is fundamentally different,” Chaturvedi said.

In fact, Hinchcliffe sees the new agent as part of a much larger industry transition from passive observability systems toward autonomous operational agents.

“FinOps is simply one of the first major operational domains where this transition is becoming commercially visible. The big implication is that CloudOps, SecOps, infrastructure management, governance, and even IT financial management are all likely to become increasingly agentic over the next several years,” Hinchcliffe added.

Enterprises and developers willing to try out the new FinOps Agent can do so from the AWS Management Console, the hyperscaler said.

The agent, which is available only in the US East region, currently comes at no charge, with a monthly usage limit, although standard charges apply for other AWS Services used in connection with the agent, it added. “It (FinOps Agent) can manage costs across other AWS Regions and accounts when set up in the management account,” the hyperscaler further said.

For many CIOs, the challenge of scaling AI is no longer about building applications but about understanding what they cost. With AI models priced through complex token-based structures, enterprises deploying multi-agentic AI are facing a fast-growing and often opaque expense, making it harder to benchmark providers, measure efficiency, and prove returns on AI investments.

Seeking to address that problem, the Linux Foundation has announced its intent to launch the Tokenomics Foundation, a vendor-neutral organization that will develop open standards, benchmarks, and best practices for AI cost management.

The foundation, instead of working alone, will collaborate with the FinOps Foundation, another Linux Foundation initiative focused on advancing the discipline of cloud financial management and technology value management.

A key part of that collaboration will be the expansion of FinOps Open Cost and Usage Specification (FOCUS), an open standard originally developed to normalize cloud spending and usage data across providers.

The two foundations plan to adapt the specification to account for token-based AI consumption, creating a common framework for measuring, comparing, and governing AI costs across models and platforms, the Linux Foundation said in a statement.

While the Tokenomics Foundation’s Governing Board will help set strategic priorities and allocate funding for the initiative, its Technical Committee will work with FinOps Foundation contributors to develop the specifications, benchmarks, and reference frameworks needed to incorporate AI token usage into FOCUS, it added.

The new foundation, the Linux Foundation further said, has already attracted support from a broad group of enterprise technology vendors, cloud providers, and end-user organizations, including Accenture, Booking.com, Flexera, Google Cloud, IBM, JPMorganChase, KPMG, Microsoft, Oracle, Salesforce, SAP, and ServiceNow.

Why will the new foundation matter for CIOs?

The move to launch a new foundation to standardize metrics around token usage addresses a growing gap in enterprise AI rollouts in production use cases.

“The industry lacks common standards for measuring AI costs and efficiency. That makes it difficult for CIOs to compare models and vendors, in turn making it difficult to track ROI, optimize spending, or decide which models deliver the best value,” said Pareekh Jain, principal analyst at Pareekh Consulting.

“A neutral body, in contrast, can help define shared terminology, benchmarks, and accounting frameworks, similar to how FinOps brought discipline to cloud spending. Standardization can make AI costs more transparent and comparable across vendors for CIOs,” Jain added.

The challenge is not just about managing AI costs but also about how enterprises architect, deploy, and govern AI applications at scale, even as per-token pricing continues to decline, pointed out Yugal Joshi, partner at Everest Group.

“The gross AI bill for enterprises continues to rise due to poor design practices such as throwing unwanted models at specific problems. In addition, the same workflow ends up costing differently based on input queries and user prompts,” Joshi said. “No CIO can make meaningful budgeting decisions or calculate RoI of such workflows. This creates complexity around selecting workloads that can derive the best outcome with the least investment.”

The Tokenomics Foundation’s emphasis on standards and best practices could help CIOs make more informed decisions about workload design, Joshi noted.

Another area of focus?

Cost governance and design best practice, however, are only one part of the equation.

Another challenge facing CIOs is determining when open-source models make more economic sense than proprietary alternatives, Jain said.

“When enterprises use models such as Llama or Mistral on their own infrastructure, costs shift from paying per token to paying for GPUs, electricity, and infrastructure utilization,” Jain pointed out.

“The long-term challenge for the Tokenomics Foundation will be creating a common framework that lets CIOs compare the true cost of self-hosted models with commercial AI APIs. Determining the point at which it becomes cheaper to run a private AI platform rather than consume AI as a service could become one of the most important financial decisions in enterprise AI,” Jain added.

While the initiative has been announced, the Linux Foundation has not provided a target date for the Tokenomics Foundation’s formal launch or operational rollout.

Multi-cloud is now the operating reality of every serious enterprise. Governing it requires four disciplines – not another tool. A field-tested framework for the CIOs running it.

Walk into almost any large enterprise today and ask the CIO how their multi-cloud is going. The answer is rarely a single sentence. It’s a list of qualifications: two strategic hyperscalers, a third for a regulated workload, a sovereign cloud for one geography, a colocation footprint for latency-sensitive systems, an on-premises estate that hasn’t gone anywhere, and a long tail of SaaS that quietly behaves like infrastructure when it fails.

This is not a failure of strategy. It is the strategy. Multi-cloud is the operating reality of every serious enterprise, driven by acquisition history, regulatory geography, AI workload economics, and the simple fact that no single provider is best at everything. The question has shifted from whether to run multi-cloud to how to govern what we already have.

And on that question, most enterprises are still trying to buy their way out. Another observability tool. Another policy engine. Another connectivity overlay. The result, predictably, is a stack with more dashboards than the people watching them have hours in the day, and a complexity tax that compounds in the seams between every tool the procurement team has signed off on.

The CIOs I work with – increasingly – have stopped asking what to buy next. They’ve started asking a different question: what would it take to run multi-cloud the way we already run finance, or security, or supply chain? As an operating discipline. Not a project. Not a stack. A continuous loop, with clear ownership and a clear cycle.

That is the case I want to make. Multi-cloud has matured past the point where it can be governed by tools alone. It needs an operating model with four disciplines, each of which the next three years will judge every CIO on: Measure, Route, Comply, Recover (Figure 1).

These aren’t sequential phases. They’re a closed loop. And the platforms that close it – disclosure: my team at Tata Communications is building one called IZO+ Multi Cloud Network (MCN) – are about to redefine what good multi-cloud looks like. The platforms that don’t will, eventually, be remembered as dashboards bolted onto point tools.

Figure 1. The four disciplines of a multi-cloud operating model, arranged as a closed cycle.

PILLAR 1

Measure: Quantify what your bill never will

Of all the line items on the enterprise technology balance sheet, the largest one is the one no system reports: the cost of complexity itself. CFOs receive a cloud bill every month. CIOs receive an uptime dashboard every morning. Neither captures the cost of the routine policy change that needs three tickets across two teams, or the configuration drift in one region that surfaces as a customer outage in another, or the senior-engineer time spent reconciling things that should never have diverged.

The first discipline of a multi-cloud operating model is to make this cost legible. That means a complexity index – a quantified score, not a qualitative survey – that decomposes into the dimensions actually driving it: base connectivity, cross-domain coupling, governance gap, toolchain fragmentation, and geographic dispersion. (My team has built and patented one called the Enterprise Multi-Cloud Complexity Index. The framework matters more than the brand.)

A good index does three things a one-off assessment cannot: it is continuous (the score moves with reality, not with the audit cycle), decomposable (it tells you which dimension is driving the number, so remediation can be prioritised), and peer-benchmarked (it tells you whether your number is normal for your industry and your scale).

The CIO insight is simple: a one-off complexity score is a slide. A live one is an operating signal. And once you have an operating signal, you can do something with it. That something is the next three disciplines.

PILLAR 2

Route: Make applications self-networking

Once you can see complexity, the next discipline is to stop accumulating more of it. That is what routing – done right – does.

The traditional multi-cloud network is defined by infrastructure topology: VPCs, VLANs, transit gateways, peering connections, the long tail of NATs and firewalls in between. Every new application inherits that topology. Every new region multiplies it. Every team learns it differently. The result is what most enterprises now have: a network that can technically reach everywhere but can’t be reasoned about anywhere.

The shift that matters is from infrastructure-defined to intent-defined routing. The right unit of design is no longer the VPC; it is the application – or, more precisely, an Application Connectivity Domain (ACD): a logical boundary that spans clouds, regions, and on-premises footprints, and within which an application’s reachability, identity, and policy travel together. The infrastructure underneath becomes a substrate to be orchestrated, not a topology to be hand-stitched.

For AI workloads in particular, this matters more than most CIOs realise. All-reduce performance, inference latency, and data-gravity economics are all functions of physical fabric layout – GPU placement, interconnect topology, regional data residency. A network that doesn’t know where the GPUs are will route AI traffic the way it routes everything else, and the training run will pay for it.

The CIO question to ask: can my network be defined by what my applications need, or only by where my infrastructure happens to sit?

PILLAR 3

Comply: Move sovereignty into the data plane

For most enterprises, compliance is still something that happens after a routing decision is made. A packet flows; an audit later confirms whether it should have done so. A workload runs in a region; a quarterly review checks whether the data residency clause was honoured.

That model has expired. Between GDPR Article 44, India’s DPDP Act, the EU AI Act, the patchwork of GCC sovereignty mandates, and a growing list of sectoral regulations, jurisdictional rules now change faster than annual audits can catch up with them. Treating sovereignty as an after-the-fact check guarantees one of two outcomes: a compliance violation, or a chilling effect that slows every cloud decision into paralysis.

The discipline I’d urge every CIO to adopt is pre-flight compliance: jurisdictional assurance built into the routing decision itself, not bolted on afterwards. Before a workload is placed, before a packet leaves a region, before a failover target is chosen, the platform should already know which jurisdictions are eligible – and silently exclude the ones that aren’t. Compliance becomes a property of the data plane, not a clause in a policy deck.

The shift in CIO conversation is unmistakable when this works. The board no longer asks “Are we compliant?” They ask “What would it cost to add another jurisdiction?” – and the answer is a configuration change, not a programme.

PILLAR 4

Recover: Score yourself against your weakest layer

The February 2026 AWS UAE infrastructure incident was, for many of the CIOs I work with, the moment the recover discipline stopped being theoretical. Enterprises that had spent years building “multi-region” architectures discovered that being multi-region and being recoverable are not the same thing. Their compute had a backup region. Their data didn’t. Or their data did, but their identity layer was tied to the failed region’s IAM. Or every layer was technically replicated, but no one had ever tested the failover end-to-end under load.

The most useful framing I’ve seen is the Failover Readiness Score (FRS): a single number scored as the weakest of five layers – Infrastructure-as-Code, Network, Data, Workload, and Sovereignty. The weakest-link formulation is the entire point. Your real recovery time objective is governed by your worst-prepared layer, not your average. An IaC pipeline that can spin up a region in ninety seconds means nothing if the database promotion takes four hours, or if the failover target turns out to be sovereignty-ineligible for the data you’re moving to it.

Pre-flight failover simulation – running the failover continuously in shadow mode against multiple targets and reporting which are viable – is the discipline that separates resilience theatre from actual recoverability. The CIO question: if I had to fail over right now, against my second-best target, would my weakest layer let me?

THE SYNTHESIS

The loop

The four disciplines look like a stack. They are actually a feedback cycle.

Measure identifies the highest-complexity surfaces in your estate. Route lets you bypass or absorb them without rebuilding applications. Comply ensures every routing and failover decision is jurisdictionally clean by construction. Recover validates, continuously, that your weakest layer can carry the load when something goes down – and feeds the result back to Measure, which updates the complexity score and the cycle starts again.

The reason the loop matters more than any single pillar is that it eliminates the place where complexity wins today: the seam between teams. Today, measurement lives with the FinOps and architecture teams; routing lives with networking; compliance lives with risk; recovery lives with SRE. Each owns its piece. Nobody owns the seam. The complexity tax compounds in the seam.

A platform that closes the loop collapses the seams. That is the structural change underway in our category, and it is the change CIOs should be evaluating vendors against.

A four-question test for your next vendor conversation

Before the next multi-cloud purchase, ask:

1. Can I measure complexity continuously, not just survey it? A score that doesn’t move with reality is a slide, not a signal.
2. Can I route around complexity without rebuilding applications? If every new connectivity decision means new infrastructure, you’ve bought a tool, not a fabric.
3. Is compliance enforced in the data plane, or only in policy decks? If the answer involves a quarterly review, your sovereignty posture is a hope, not a guarantee.
4. Is my failover readiness scored against my weakest layer? Average preparedness is the wrong number. The weakest-link score is the only honest one.

If your current stack can’t answer all four with a straight yes, the right next move isn’t another point tool. It’s the loop. That, more than any individual product capability, is what separates the CIOs who will spend the next three years firefighting multi-cloud from the ones who will spend it compounding it.

To learn more, visit us here.

————————————————————

>About the author. The author leads product and strategy for IZO+ MCN, a multi-cloud overlay networking platform developed by Tata Communications. The Enterprise Multi-Cloud Complexity Index (EMCI) referenced in this article is a patent-pending framework. Views are the author’s own.

AI 업계 선두 주자인 앤트로픽(Anthropic)과 오픈AI(OpenAI)가 모두 IPO를 추진하는 것으로 알려지면서, 이들 AI 모델에 의존하는 기업의 IT 리더들은 앞으로 어떤 변화가 닥칠지 주목하고 있다.

가장 큰 관심사는 기업용 AI 서비스 비용 상승 가능성이다. 특히 최첨단 AI 모델을 사용하는 기업 고객의 부담이 커질 수 있다는 우려가 나온다.

두 기업은 상장을 통해 주식을 공개 매각함으로써 수억 달러 규모의 자금을 조달해 제품 개발과 운영 비용에 투자할 것으로 예상된다. 그러나 일각에서는 연구 중심의 비상장 기업에서 상장사로 전환되면서 앤트로픽과 오픈AI 모두 수익 창출에 대한 새로운 압박에 직면할 것이라고 우려한다.

IT 시장조사업체 스마트테크 리서치(SmartTech Research)의 CEO 겸 수석 애널리스트 마크 베나는 “오픈AI가 상장할 경우 기업 고객은 상당한 수준의 가격 인상을 예상해야 한다”라며 “특히 API 사용량이 많거나 코파일럿, AI 에이전트, 맞춤형 구축 환경에 크게 의존하는 기업일수록 그 영향이 클 것”이라고 분석했다.

반면 베나는 앤트로픽의 IPO는 다른 양상으로 전개될 것으로 내다봤다. 앤트로픽이 AI 안전성에 폭넓게 집중해 온 점이 차별화 요소라는 설명이다.

베나는 “앤트로픽은 기업 신뢰와 안전성, 개발자 생산성, 그리고 CFO와 CIO가 이사회에 설명할 수 있는 보다 안정적이고 체계적인 AI 브랜드를 제공하고 있다”라며 “솔직히 오픈AI가 문화적 영향력을 이끄는 로켓이라면, 앤트로픽은 기관과 기업이 선택할 AI 투자처로 자리매김하고 있다”고 평가했다.

다만 앤트로픽의 수익성에 대한 우려는 여전히 존재한다고 덧붙였다.

베나는 “결국 핵심 질문은 공개 시장 투자자들이 앤트로픽의 재무적 절제를 높게 평가할 것인지, 아니면 최첨단 AI 개발이 가진 냉혹한 경제성을 문제 삼을 것인지에 달려 있다”라며 “모델 학습과 컴퓨팅 자원 확보, 그리고 오픈AI·구글(Google)·메타(Meta)·xAI와 경쟁하기 위해서는 막대한 비용이 필요하다. 앤트로픽은 단순히 우아하게 자금을 소진하는 기업이 아니라는 점을 입증해야 한다”고 말했다.

앤트로픽은 오픈AI 역시 상장을 추진하고 있다는 보도가 나온 직후인 6월 1일 IPO 신청 사실을 발표했다. 오픈AI는 상장 가능성에 대해 공식 입장을 내놓지 않았지만, 업계에서는 수주 내 상장 계획이 발표되고 이르면 오는 9월 공모가 진행될 것으로 전망하고 있다.

베나는 IPO가 가격 정책 외에도 다양한 변화를 가져올 것이라고 분석했다. 경영 투명성과 외부 감시가 강화되고, 거버넌스와 서비스 가동 시간, 보안, 제품 로드맵 이행에 대한 기업 차원의 규율도 한층 엄격해질 것이라는 설명이다. 동시에 새로운 과금 체계 도입 가능성도 높다고 내다봤다.

베나는 “오픈AI가 상장하면 빠르게 움직이는 AI 연구소에서 월가의 감시를 받는 플랫폼 기업으로 변모하게 될 것”이라며 “이용자는 더 이상 ‘빠르게 움직이며 모두를 놀라게 하는’ 방식보다는 모든 서비스를 상품화하고 계량화하며 수익화하려는 압박이 커지는 모습을 보게 될 것”이라고 전망했다.

연구소 모델의 종말

오픈AI가 상장한 이후 가격 정책이 변화할 것이라는 우려는 다른 전문가들 사이에서도 제기되고 있다.

AI 연구기업 마인드 시뮬레이션 랩(Mind Simulation Lab)의 CEO 겸 공동 설립자 레오 데리키언츠는 IT 리더들이 API 요금의 대폭 인상과 기본적인 데이터 프라이버시 기능조차 고가의 프리미엄 엔터프라이즈 요금제로 제공되는 상황, 그리고 점점 더 불투명해지는 과금 체계에 대비해야 한다고 경고했다.

데리키언츠는 “오픈AI의 IPO는 ‘연구소’라는 환상의 종말이자 전통적인 기술 독점 기업의 탄생을 의미한다”라며 “공개 시장은 예측 가능하고 지속적으로 증가하는 매출을 요구하지만, 오픈AI의 핵심 기술인 자기회귀 기반 대규모언어모델(LLM)은 본질적으로 예측 불가능한 확률적 시스템”이라고 말했다.

반면 앤트로픽은 오픈AI보다 더 강력하고 방어 가능한 위치에서 상장을 추진하는 것으로 보인다고 평가했다. 두 회사 모두 유사한 확률 기반 자기회귀 아키텍처를 사용하고 있지만, 앤트로픽은 영상 생성과 같은 소비자 대상 기능보다 기업 시장에 집중해 왔으며, 이를 통해 보다 안정적인 수익 기반을 구축했다는 설명이다.

하지만 데리키언츠는 앤트로픽의 IPO 발표가 AI 산업의 실망스러운 현실도 보여준다고 지적했다.

그는 “주요 AI 연구소들은 아키텍처의 한계나 장기적인 가치에 대한 근본적인 질문 없이, 사실상 동일한 확률 기반 제품을 서로 다른 브랜드로 포장해 반복적으로 내놓고 있다”라며 “업계는 본래의 목표를 완전히 잃어버렸다. 원래의 목표는 진정한 범용인공지능(AGI)을 구현하는 것이었지만, 지금의 목표는 월간 구독 매출을 극대화하는 데 있다”고 비판했다.

또한 CIO들은 앞으로 더욱 공격적인 벤더 종속 전략과 강제적인 생태계 통합, 그리고 유연하고 오픈소스 친화적인 정책의 축소에 대비해야 한다고 전망했다.

데리키언츠는 “기업들은 안전한 AI를 만드는 것보다 주주 가치를 극대화하기 위해 고객 데이터를 자사 독점 API 생태계 안에 묶어두는 데 집중하게 될 것”이라고 주장했다.

아울러 AI 벤더들이 이른바 ‘AI 스케일링 함정(scaling trap)’에 빠져 있다고 진단했다. 현재 AI 아키텍처는 추론 성능을 소폭 향상시키기 위해서도 기하급수적으로 더 많은 컴퓨팅 자원과 에너지를 요구한다는 것이다.

데리키언츠는 “이들 모델의 운영은 본질적으로 비효율적이며 상당 부분 벤처캐피털 자금에 의존해 유지되고 있다”라며 “상장 이후에는 월가가 이런 막대한 인프라 손실을 무기한 용인하지 않을 것”이라고 말했다.

시스템 통합 및 클라우드 서비스 기업 블루 맨티스(Blue Mantis)의 CIO 리처드 에이모스 역시 IPO 이후 두 기업 모두 새로운 가격 정책을 도입할 것으로 예상했다. 스타트업에서 상장사로 전환되면 기업의 우선순위 자체가 달라지기 때문이라는 설명이다.

에이모스는 “상장 전에는 혁신과 성장, 미래 가능성에 초점이 맞춰져 있다”라며 “하지만 상장 후에는 상황이 달라진다. 주주들은 안정적인 분기 실적과 규제 준수, 엔터프라이즈급 신뢰성을 요구하게 된다”고 설명했다.

다만 그는 오픈AI 상장 이후 긍정적인 변화도 기대했다. 플랫폼 안정성과 보안, 규제 준수 역량이 강화되고 산업별 특화 기능 개발에도 더 많은 투자가 이뤄질 것으로 전망했다.

동시에 AI 벤더들은 기업 전체 라이선스 방식에서 벗어나 퍼블릭 클라우드 시장과 유사한 사용량 기반 과금 모델로 이동할 것으로 내다봤다.

에이모스는 현재 오픈AI가 적자를 기록하고 있다는 관측이 많은 만큼, 상장 이후 가격 체계를 전면 개편할 가능성이 높다고 분석했다. 예를 들어 고성능 모델이나 에이전트 기반 워크플로우, 고급 오케스트레이션 기능 등에 프리미엄 가격 정책이 적용될 수 있다는 것이다.

이에 대응해 일부 기업은 사용량과 비즈니스 가치를 균형 있게 관리하기 위해 AI 핀옵스(FinOps) 솔루션을 도입할 것으로 예상했다.

에이모스는 “일정 수준의 가격 인상은 불가피할 것”이라며 “AI 생태계 비용을 관리하기 위한 새로운 도구와 라이선스 체계도 등장할 것으로 본다”고 말했다.

새로운 가격 정책

앤트로픽은 IPO 발표를 앞둔 며칠 전 일부 제품에 대해 새로운 사용량 기반 계량 과금(metered pricing) 모델을 공개했다.

한편 통합 인텔리전스 기업 YOUnifiedAI의 CEO 겸 공동 설립자 유지나 조던은 오픈AI가 최근 선보인 ‘보장 용량(Guaranteed Capacity)’ 구독 모델이 새로운 가격 정책 방향을 보여준다고 분석했다.

조던은 “이 모델은 유연한 API 토큰 판매 중심에서 벗어나, 기업이 수년 단위의 지출을 사전에 약정해야 하는 계약 기반의 예측 가능한 엔터프라이즈 서비스 모델로 전환하려는 의도를 보여준다”고 설명했다.

오픈AI는 지난 5월 신규 컨설팅 사업 출범도 발표했다.

조던은 상장 기업이 되면 가격 정책 개편에 대한 압박이 더욱 커질 것으로 전망했다.

조던은 “오픈AI의 IPO는 IT 리더들에게 상당한 변화를 가져올 것”이라며 “회사는 민첩한 기술 혁신 기업에서 월가의 분기 실적 요구에 묶인 상장사로 전환하게 된다”고 말했다.

이어 “대규모 공모 자금 유입은 엔터프라이즈 제품의 안정성을 높이는 데 필요한 강력한 인프라 구축을 지원할 수 있다”라면서도 “사용자들이 당장 체감하게 될 현실은 보다 공격적인 수익화 전략으로의 급격한 전환일 가능성이 높다”고 덧붙였다.

다만 기업용 AI 사용자들에게 긍정적인 요소도 있다. 조던은 2022년 말 첫 번째 챗GPT가 출시된 이후 AI 시장에 여러 강력한 경쟁자가 등장했다고 평가했다.

조던은 “앤트로픽은 기업 개발자와 고급 코딩 분야에서 빠르게 기본 선택지로 자리 잡았고, 구글의 제미나이는 강력한 업무용 소프트웨어 생태계를 기반으로 영향력을 확대하고 있다”라며 “미스트랄(Mistral)은 유럽 오픈소스 시장에서 입지를 강화하고 있다”고 설명했다.

또한 “오픈AI가 예측 가능한 기업 매출 확보에 집중하는 시점에 시장은 이미 분산되고 경쟁이 매우 치열해졌다”라며 “이제 선점 효과만으로 승리를 보장받을 수 없는 환경이 됐다”고 분석했다.

이어 “과거 야후(Yahoo)가 구글에 밀리고 마이스페이스(MySpace)가 페이스북(Facebook)에 자리를 내준 것처럼, 기술을 처음 선보이는 것과 이를 대규모 사업으로 성장시키는 것은 전혀 다른 문제”라며 “IPO는 오픈AI가 빠르게 성숙한 기업으로 변화하도록 압박하는 계기가 될 것이며, 그 사이 경쟁사들은 오픈AI의 기업 시장 지배력을 조금씩 잠식하고 있다”고 말했다.

스마트테크 리서치의 마크 베나 역시 구글, xAI, 메타(Meta)를 주요 경쟁자로 꼽았다.

베나는 “내 관점에서 오픈AI는 여전히 시장 선도 기업이지만 더 이상 AI 시장의 주도권을 독점하고 있지는 않다”라며 “오픈AI는 여전히 강력한 브랜드 영향력과 제품 추진력을 보유하고 있지만, 앞으로의 경쟁은 누가 더 화려한 데모를 보여주느냐가 아니라 누가 안정적이고 안전하며 비용 효율적인 AI를 대규모로 제공할 수 있느냐에 달려 있다”고 말했다.
dl-ciokorea@foundryco.com

• 관련 기사 : 오픈AI, 한국에 ‘데이브레이크’ 도입…정부·공공기관 AI 보안 지원 본격화

Los pioneros de la IA Anthropic y OpenAI parecen dirigirse hacia sus respectivas salidas a bolsa, lo que deja a los directivos de TI cuyas organizaciones dependen de sus modelos de IA preguntándose qué les deparará el futuro. Una de las principales preocupaciones es la posibilidad de un aumento de costes para el uso empresarial, especialmente en los modelos más avanzados. Al ofrecer acciones al público, es probable que ambas compañías recauden cientos de millones de dólares para invertir en sus productos y cubrir sus gastos. Sin embargo, muchos analistas temen que, al pasar de ser organizaciones privadas centradas en la investigación a empresas cotizadas, tanto Anthropic como OpenAI se enfrenten a nuevas presiones para generar beneficios.

Los clientes empresariales de OpenAI deberían esperar aumentos sustanciales de precios tras su salida a bolsa, especialmente aquellos que dependen intensamente del uso de API, copilotos, agentes y despliegues personalizados, según Mark Vena, CEO y analista principal de la firma de investigación IT SmartTech Research.

Vena considera que una salida a bolsa de Anthropic se desarrollará de forma distinta, dado el amplio enfoque de la compañía en la seguridad de la IA. “Lo que vende es confianza empresarial, seguridad, productividad para desarrolladores y una versión más controlada de la IA que los CFO y CIO pueden explicar a sus consejos de administración”, afirma. “Sinceramente, creo que OpenAI es el cohete cultural, pero Anthropic se perfila como la apuesta institucional en IA”.

Aun así, añade, existen dudas sobre la capacidad de Anthropic para generar beneficios. “Seamos claros: la gran cuestión para Anthropic es si los inversores públicos premiarán la disciplina o castigarán la dura economía de la IA de frontera”, señala. “Entrenar modelos, alquilar capacidad de cómputo y competir con OpenAI, Google, Meta y xAI es extremadamente caro, por lo que Anthropic tendrá que demostrar que es algo más que una sofisticada máquina de consumir efectivo”.

Anthropic anunció el 1 de junio que había iniciado los trámites para su salida a bolsa, después de informaciones que apuntaban a que OpenAI también avanzaba en esa dirección. Aunque OpenAI declinó hacer comentarios sobre una posible salida a bolsa, diversas informaciones sugieren que la compañía podría anunciarla en las próximas semanas, con una posible oferta inicial en septiembre.

Las salidas a bolsa traerían otros cambios, señala Vena, como mayor transparencia, más escrutinio y una mayor disciplina empresarial en gobernanza, disponibilidad del servicio, seguridad y cumplimiento de hoja de ruta. Pero también es probable que surjan nuevos modelos de precios. “Una salida a bolsa de OpenAI convertiría a la empresa de un laboratorio de IA ágil en un proveedor de plataforma supervisado por Wall Street”, afirma Vena. “Los usuarios deberían esperar menos de la actitud de ‘movernos rápido y sorprender a todos’ y más presión para empaquetar, medir y monetizar absolutamente todo”.

Hacia el fin del modelo de laboratorio de investigación

Otros observadores expresan preocupaciones similares sobre los modelos de precios de OpenAI tras una salida a bolsa. Leo Derikiants, CEO y cofundador de la firma de investigación en IA Mind Simulation Lab, afirma que los responsables de TI deberían esperar fuertes subidas en los precios de API, la introducción de niveles premium empresariales caros para cuestiones básicas como la privacidad de datos, y modelos de facturación cada vez más opacos.

“Una salida a bolsa de OpenAI señala el fin de la ilusión del ‘laboratorio de investigación’ y el nacimiento de un monopolio tecnológico tradicional”, añade. “Los mercados públicos exigen ingresos predecibles y crecientes, pero la tecnología central de OpenAI —los LLM autoregresivos— es fundamentalmente impredecible y probabilística”.

Por su parte, Anthropic parece dirigirse hacia una salida a bolsa en una posición más sólida y defendible que OpenAI, según explica. Aunque ambas empresas se basan en arquitecturas probabilísticas similares, Anthropic se ha centrado menos en productos de consumo como la generación de vídeo y más en el mercado corporativo, lo que le proporciona una base de ingresos más estable.

No obstante, el anuncio de la salida a bolsa de Anthropic también confirma una realidad decepcionante: que el mercado de la IA está impulsado por una mentalidad de rebaño, afirma Derikiants.“Los grandes laboratorios están dando vueltas en círculo, construyendo exactamente los mismos productos probabilísticos con diferentes marcas, sin cuestionar los límites de la arquitectura ni el valor real a largo plazo”, señala. “La industria ha perdido completamente su rumbo original. El objetivo fundacional era alcanzar la verdadera inteligencia artificial general (AGI). Hoy, el único objetivo es maximizar los ingresos mensuales por suscripción”.

Los CIO deberían prepararse para tácticas agresivas de bloqueo por proveedor, paquetes cerrados de ecosistema y un alejamiento de las iniciativas flexibles y favorables al código abierto, predice. El foco corporativo pasará de crear una IA segura a retener los datos empresariales dentro de APIs propietarias para maximizar el valor para el accionista.

Añade que los proveedores de IA están atrapados en un modelo de escalado que requiere cantidades exponencialmente mayores de computación y energía para lograr mejoras marginales en razonamiento. “Operar estos modelos es fundamentalmente ineficiente y está fuertemente subvencionado por capital riesgo”, explica. “Una vez que coticen en bolsa, Wall Street no tolerará indefinidamente esas enormes pérdidas de infraestructura”.

Tras una salida a bolsa, los clientes de ambas compañías deberían esperar la aparición de nuevos modelos de precios, según Richard Amos, CIO del integrador de sistemas y proveedor de servicios cloud Blue Mantis. Las prioridades de una organización cambian cuando pasa de startup a empresa cotizada, añade. “Antes de salir a bolsa, el foco está en la innovación, el crecimiento y el potencial”, afirma. “Una vez en bolsa, cambian las expectativas y los accionistas exigen resultados trimestrales consistentes, cumplimiento normativo y fiabilidad a nivel empresarial”.

Amos prevé varios desarrollos positivos, como un mayor énfasis en la estabilidad de plataformas, seguridad, cumplimiento y desarrollo de capacidades específicas por industria tras una salida a bolsa de OpenAI. Al mismo tiempo, espera que los proveedores de IA se alejen de las licencias globales empresariales hacia modelos de precio basados en consumo, en línea con las tendencias del cloud público.

Dado que muchas informaciones apuntan a que OpenAI opera actualmente con pérdidas, Amos cree que la empresa reformulará sus modelos de precios tras su salida a bolsa, probablemente introduciendo tarifas premium para capacidades avanzadas como modelos de gama alta, flujos de trabajo con agentes y orquestación avanzada.

Como respuesta, algunos usuarios adoptarán soluciones de FinOps para la IA con el objetivo de equilibrar consumo y valor de negocio. “Veremos algunos aumentos de precios y creo que surgirán nuevas herramientas o esquemas de licencia para gestionar el coste del ecosistema”, añade.

Nuevo modelo de precios

Días antes de anunciar su salida a bolsa, Anthropic presentó un nuevo modelo de precios medidos para algunos de sus productos. Por su parte, el nuevo modelo de suscripción de capacidad garantizada de OpenAI apunta a una nueva filosofía de precios que desplaza el foco desde la venta de tokens de API flexibles hacia un servicio empresarial predecible, ligado a contratos, que requiere compromisos de gasto multianuales por adelantado, según Eugina Jordan, CEO y cofundadora de YOUnifiedAI. OpenAI también anunció en mayo una nueva empresa de consultoría.

Convertirse en empresa cotizada probablemente incrementará la presión para revisar los precios, señala Jordan. “Una salida a bolsa de OpenAI transformaría radicalmente el panorama para los líderes de TI, pasando de ser un pionero ágil a una entidad pública sujeta a las exigencias de resultados trimestrales de Wall Street”, afirma. “Aunque la entrada masiva de capital podría financiar la infraestructura necesaria para estabilizar los productos empresariales, la realidad inmediata para los usuarios será un giro brusco hacia una monetización agresiva”.

Sin embargo, hay algunas buenas noticias para los usuarios empresariales de IA, ya que han surgido varios competidores relevantes desde que OpenAI abrió el mercado con ChatGPT a finales de 2022, añade Jordan. Anthropic se ha convertido rápidamente en la opción por defecto para desarrolladores empresariales y programación avanzada, Gemini de Google ha aprovechado su amplia distribución en entornos de trabajo y Mistral está consolidando el espacio europeo de código abierto.

“Este impulso hacia ingresos empresariales predecibles llega en un momento en que OpenAI se enfrenta a un paisaje competitivo fragmentado y muy agresivo donde ser el primero ya no garantiza ganar”, añade. “Al igual que Yahoo perdió frente a Google o MySpace frente a Facebook, OpenAI está comprobando que innovar no es lo mismo que escalar, y una salida a bolsa les obligará a madurar rápidamente, justo cuando sus competidores están erosionando su posición en el mercado empresarial”.

Vena también apunta a competidores importantes como Google, xAI y Meta. “Desde mi punto de vista, OpenAI sigue siendo líder, pero ya no controla el relato de la IA sin oposición”, concluye. “Aunque mantiene una fuerte marca y dinamismo de producto, la siguiente fase dependerá menos de quién tenga la demo más espectacular y más de quién pueda ofrecer una IA duradera, segura y rentable a escala”.

AI pioneers Anthropic and OpenAI both appear to be headed toward IPOs, leaving IT leaders whose organizations rely on their AI models wondering what might be in store for them.

Top of mind is the possibility of higher costs for enterprise use, especially for frontier models.

By offering stock for sale, the two AI innovators will likely raise hundreds of millions of dollars to invest in their products and pay their bills. But many observers worry that by shifting their focus from private, research-focused organizations to publicly traded companies, both Anthropic and OpenAI will be under new pressure to turn a profit.

OpenAI’s enterprise customers should expect substantial price increases after an IPO, especially those who are leaning hard on API usage, copilots, agents, and custom deployments, says Mark Vena, CEO and principal analyst at IT research firm SmartTech Research.

Vena sees an Anthropic IPO landing differently, with the company’s broad focus on AI safety. “It is selling enterprise trust, safety, developer productivity, and a more buttoned-up brand of AI that CFOs and CIOs can actually explain to their boards,” he says. “Frankly, I think OpenAI is the cultural rocket ship, but Anthropic is shaping up as the institutional AI bet.”

Still, there are concerns about Anthropic’s ability to generate profits, he adds.

“Let’s face it: The big question for Anthropic is whether public investors will reward discipline or punish the brutal economics of frontier AI,” he adds. “Training models, renting compute, and keeping pace with OpenAI, Google, Meta, and xAI is insanely expensive, so Anthropic will have to prove it is more than a very elegant cash-burning machine.”

Anthropic announced that it had filed for an IPO on June 1 after news reports that OpenAI was also headed in that direction. Though OpenAI declined to comment on a potential IPO, news reports suggest that the company will announce one within the next few weeks, with the initial stock sale potentially happening in September.

IPOs would bring several other changes, Vena notes, including more transparency, more scrutiny, and more enterprise discipline around governance, uptime, security, and roadmap commitments. But new pricing models are likely as well.

“An OpenAI IPO would turn the company from a fast-moving AI lab into a Wall Street–monitored platform vendor,” Vena says. “Users should expect less ‘move fast and surprise everybody’ energy and more pressure to package, meter, and monetize everything.”

End of the research lab model

Other observers express similar fears about OpenAI’s pricing models after an IPO.

Leo Derikiants, CEO and cofounder at AI research firm Mind Simulation Lab, says IT leaders should expect steep API price hikes, the introduction of expensive premium enterprise tiers for basic data privacy, and increasingly opaque billing models.

“An OpenAI IPO signals the end of the ‘research lab’ illusion and the birth of a traditional tech monopoly,” he adds. “Public markets demand predictable, escalating revenue, but OpenAI’s core technology — autoregressive LLMs — is fundamentally unpredictable and probabilistic.”

Anthropic, meanwhile, seems to be headed toward an IPO in a stronger, more defensible position than OpenAI, he says. While both companies rely on similar probabilistic and autoregressive architectures, Anthropic has focused less on consumer-facing toys such as video generation and more on the corporate enterprise market, giving the company a stable revenue foundation, he notes.

The Anthropic IPO announcement, however, also confirms a disappointing truth — that the AI market is driven by herd mentality, Derikiants says.

“The major labs are running in circles, building the exact same probabilistic products with different branding, without questioning the architectural limits or the actual long-term value,” he says. “The industry has completely lost the original plot. The foundational goal used to be achieving true artificial general intelligence (AGI). Today, the only goal is maximizing monthly subscription revenue.”

CIOs should prepare for aggressive vendor lock-in tactics, forced ecosystem bundling, and a shift away from flexible, open-source-friendly initiatives, he predicts. The corporate focus will pivot from creating safe AI to trapping enterprise data within the company’s proprietary API walls to maximize shareholder value, he says.

AI vendors caught in an AI scaling trap, with its architecture requiring exponentially more computing power and energy to yield marginal improvements in reasoning, he adds.

“Operating these models is fundamentally inefficient and heavily subsidized by venture capital,” he notes. “Once public, Wall Street will not tolerate those massive infrastructure losses indefinitely.”

After an IPO, customers of both companies should expect new pricing models to emerge, says Richard Amos, CIO at systems integrator and cloud services provider Blue Mantis. An organization’s priorities change when it transitions from a startup to a publicly traded company, he adds.

“Before an IPO, the focus is largely on innovation, growth, and potential,” he says. “Once public, the expectations change and shareholders demand consistent quarterly performance, regulatory compliance, and enterprise-grade reliability.”

Amos expects several positive developments, with a greater emphasis on platform stability, security, compliance, and the development of more industry-specific capabilities after an OpenAI IPO.

At the same time, he expects AI vendors will move away from enterprise-wide licensing toward consumption-based pricing, mirroring trends in the public cloud market.

With many reports suggesting OpenAI is currently operating at a loss, Amos sees the company revamping its pricing models after an IPO. The company could, for example, move to premium pricing for advanced capabilities such as higher-end models, agentic workflows, and advanced orchestration.

In response, some users will adopt AI FinOps solutions to balance consumption and business value, Amos predicts. “We will see some price increases, and I believe that we will have new tools or licensing constructs to manage the cost of the ecosystem,” he adds.

New pricing model

Days before announcing its IPO, Anthropic unveiled a new metered pricing model for some of its products.

Meanwhile, OpenAI’s new Guaranteed Capacity subscription model points to a new pricing philosophy that moves the focus away from selling flexible API tokens and toward a predictable, contractually locked enterprise utility requiring companies to make upfront multi-year spending commitments, notes Eugina Jordan, CEO and cofounder at unified intelligence provider YOUnifiedAI.

OpenAI also announced a new consulting company in May.

Becoming a publicly traded company will likely increase pressure to revamp pricing, Jordan says.

“An OpenAI IPO would drastically reshape the landscape for IT leaders, shifting the company from an agile tech pioneer to a public entity tethered to Wall Street’s quarterly earnings demands,” she adds. “While a massive influx of public capital could fund the robust infrastructure needed to stabilize enterprise products, the immediate reality for users is a sharp pivot toward aggressive monetization.”

However, there’s some good news for enterprise AI users as several major competitors have emerged since OpenAI opened the AI floodgates with its release of the first version of ChatGPT in late 2022, Jordan says. Anthropic has rapidly become the default choice for enterprise developers and deep coding, Google’s Gemini has leveraged its unmatched workspace distribution, and Mistral is securing the European open-source stronghold, she notes.

“This push for predictable enterprise revenue comes at a time when OpenAI is facing a fragmented, highly aggressive competitive landscape where being the first mover is no longer a guarantee of winning,” she adds. “Much like the historic shifts where Yahoo lost to Google or MySpace fell to Facebook, OpenAI is finding that pioneering a technology is very different from scaling it, and an IPO will force them to mature rapidly, just as their competitors are successfully chipping away at their enterprise armor.”

SmartTech Research’s Vena also sees several major competitors, including Google, xAl, and Meta.

“From my perspective, OpenAI is still a leader, but it no longer owns the AI narrative uncontested,” he says. “OpenAI still has brand gravity and product momentum, but the next phase will be less about who has the flashiest demo and more about who can deliver durable, secure, cost-effective AI at scale.”

With years of cloud experience, IT leaders thought they finally had firm control of their cloud strategies. And then came AI.

Of course, cloud issues today extend beyond artificial intelligence. Where to place cloud workloads for maximum efficiency is one. Questions about governance, sovereignty, the growing sophistication of cyberthreats, and escalating cost concerns are also conspiring to make the cloud ever more complicated.

“It’s just grown into a complex mess,” observes cloud expert David Linthicum, emphasizing that cloud strategy today needs to address private cloud, multicloud, hybrid cloud, and sovereign clouds — much more than most CIOs have dealt with to date.

Initially, cloud discussions centered around agility, scalability, and cost optimization, says Joshua Bellendir, CIO of retailer WHSmith North America. “Today, we are balancing a much broader and more complicated set of considerations, including AI readiness, cybersecurity, data governance, sovereign data requirements, edge computing, integration architecture, and operational resilience.”

One of the biggest shifts is that “cloud is no longer simply an infrastructure conversation,” Bellendir says. “It has become deeply tied to enterprise architecture, business transformation strategy, and data strategy.”

Amit Basu, vice president, CIO, and CISO of International Seaways, also notes cloud’s growing complexity. While reduced capital expenditure and greater flexibility still apply in some areas, dealing with the environment has become significantly more challenging, he says.

Sweetwater CIO Jason Johnson describes the current state as “genuinely one of the more complex times to be managing cloud.” Providers keep expanding their catalogs with more SKUs, more services, and more options, he says. “While that’s great for capability, it creates real overhead in just keeping up. You need people who understand not just what’s available, but what’s actually the right fit for your use case.”

Many organizations are now entering a second phase of cloud maturity. “The earlier phase was focused heavily on migration and modernization,” Johnson says. “The current phase is more focused on optimization, governance, AI enablement, and operational sustainability. That shift is changing the conversation significantly for the CIOs I’m speaking with.”

But few CIOs have the luxury of simply pondering what to do. All must meet the challenges of complexifying cloud strategies head on.

How AI changes the cloud calculus

The desire to deploy AI quickly is creating tremendous pressure on IT leaders, with cloud a central concern, Linthicum says.

“The board of directors are screaming for it worse than the cloud push 15 years ago,” he says. “CIOs are feeling the pinch and having to make that move as quickly as they can” to gain more compute for AI initiatives in an already tricky environment, he adds.

At the same time, CIOs must solve the data complexity problem before integrating AI systems, Linthicum notes. “They’re running around in circles right now trying to figure out the best way to do that.”

Hyperscalers used to be “the easy button,” Linthicum says, “but they’ll be three, four times the cost.”

AI systems cost 10 times as much as traditional equivalent applications, he estimates. “So [CIOs are] putting a lot of money on the line.”

International Seaways’ Basu says AI has changed the architecture conversation. “GPU availability, vector databases, low-latency inference, and large-scale data pipelines introduce requirements that do not fit neatly into traditional cloud design models,” he notes. “Organizations are no longer simply lifting and shifting workloads. They are designing for very different compute and data requirements.”

Zachary Lewis, CIO and CISO of University of Health Sciences and Pharmacy, says the needs of internal stakeholders only compound that complexity. Business units want disparate AI capabilities, security teams want governance and some control over AI apps, the general counsel wants to know what kind of data is being put in the AI model, and the finance team wants cost predictability.

“CIOs have to reconcile all of this and try to deliver on everyone’s needs, and you have to do that successfully,” Lewis says. “Everyone has a different end goal and demand and we’re trying to square all of that for them.”

Ever since the online retailer of musical instruments and pro audio equipment formalized its cloud strategy around 2016, Sweetwater’s Johnson has sought to place workloads wherever it made the most sense for external and internal customers.

“Anything customer-facing needs to be geo-specific; as close to the end user as possible,” he says. “Same logic applies — internal workloads belong close to whoever is using them.”

The cloud offers infinite opportunities, and with that comes infinite levels of complexity, he says. “It’s just the reality of the model.”

“AI wouldn’t be possible without the cloud. The compute scale AI needed had already been built — the cloud had it and could deliver it,” he adds. “In a lot of ways, AI might be the cloud’s greatest gift to the industry. They enabled each other.”

Cloud cost control complexifies

Johnson’s biggest headache is managing costs consistently. “It used to be relatively straightforward: compute, storage, egress. Now it’s a puzzle,” he says. “Reserved instances, savings plans, spot pricing, per-request costs, data transfer fees between regions — it stacks up fast — and it’s genuinely hard to predict what your bill is going to look like until it arrives.”

Consequently, FinOps has become a discipline in its own right, he says.

Basu also believes FinOps has become essential. “AI inference costs, egress charges, and storage growth can create month-over-month cost swings that surprise even experienced teams,” he says. “Cost management is now a continuous operational discipline rather than an occasional review exercise.”

Vendor lock-in is also always in the back of Johnson’s mind. “The more deeply you integrate with a provider’s native services, the harder it is to move.” While that’s not always bad, he adds, it’s a tradeoff. “I think about it like technical debt. You’re borrowing speed now and paying interest later if you ever want to change direction.”

But Johnson recognizes that cloud providers are businesses that “squeeze for revenue and margin, and they change the rules on how you buy committed discounts and manage spend.”

Financial efficiency doesn’t happen by accident, he points out. It requires teams, processes, and real investment in FinOps. “The tools exist. Using them well is the harder part,” he says.

Most organizations have their financial expertise sitting in accounting and their technical expertise sitting in IT, Johnson explains. Getting those two to work together on cloud cost is a relatively new challenge.

“Ten years ago, the model was simple: You asked for a CapEx budget, accounting approved it, you placed hardware orders, and IT installed and optimized. Done. Now it’s a daily exercise,” Johnson says. “New services get turned on, contracts change, pricing structures shift. Finance understands the cash but not the tech. IT understands the tech but not the financial levers.”

Every major cloud provider has the tools, Johnson explains. “AWS Cost Explorer, Azure Cost Management, GCP’s billing dashboards. The data is all there.” But most organizations aren’t acting on that data, he says, “and then the bill shows up and people are surprised. The tools told you it was coming. You just weren’t listening.”

Data regulations add sovereign subtleties

The University of Health Sciences and Pharmacy has students from all over the world. Cloud has become significantly more difficult to manage due to the rise in regulatory laws around the globe surrounding data, Lewis says.

“We have to understand if the metadata is in a specific cloud region, where it is stored, and kept,” he says. “If that data ends up in a model we trained internally, can we guarantee it stays in the EU? Then, if someone wants their data purged, can we find all those locations with some level of competence?”

Basu says data sovereignty has become another major architectural consideration. “It affects where workloads can run, how data moves between regions, and what can be done with certain datasets,” he says. “You cannot assume a hyperscaler’s default configuration satisfies your regulatory obligations.”

Private vs. public vs. on-prem

AI has sparked a rethink on where to place cloud workloads, but Sweetwater’s Johnson believes the question of whether to pull more workloads into private clouds versus public clouds shifts more often than people expect. “I think the vast majority of our workloads are in the right place right now, but we got there by being willing to question the default,” he says.

Sweetwater does not operate under a rule that says new workloads always go to the cloud, he notes. A workload might start in the cloud and end up on-prem if the math changes. “The discipline is in reviewing that in real-time, finding the inflection points, and right-sizing as you go. Right tool, right time. That’s the only principle that holds up over time.”

International Seaways’ Basu is not planning a move toward private cloud, as the economics and operational overhead do not justify it for his organization.

“The right question is what is the correct data residency, latency, and control model for each workload,” he says. “That is a data classification discipline, not a cloud deployment strategy.”

Lewis, who has about 95% of the University of Health Sciences and Pharmacy’s infrastructure running in the cloud, doesn’t see a good alternative given how the stakes have changed for AI and hardware.

“If you want to train large scale data lakes and make informed business decisions with machine learning and the intelligence behind it, it’s almost not practical anymore” to be on-prem, Lewis says.

CIOs need to ask themselves whether they have the expertise to handle that infrastructure, he adds. Ultimately, “you have to make the best of what you’ve got,” he says.

Stay focused on fundamentals

Organizations may want to chase the shiny object, which is agentic AI right now, but IT leaders should focus on their infrastructure, management, and platform planning, Linthicum stresses.

“It’s not as fun,” he says, “but to do any AI within your environment, you have to solve those issues.”

The cloud enables a lot of architectural patterns, and that freedom will work against you if you don’t have guardrails, cautions Sweetwater’s Johnson. “Write the guidance document before you need it — not after you’ve already got five teams doing things five different ways.”

IT leaders also need to get ahead of tagging and cost visibility early, saying that it needs to be a first step, not a cleanup project. “If you can’t see your spend clearly from day one, you’re already behind,” he says.

A key step is to build an auditing program with solid controls around who can create production changes, Johnson says. “The blast radius of a bad change in the cloud is bigger and faster than most people expect, until they experience it.”

The skills question

The skills needed to operate a modern cloud environment are evolving faster than most internal teams can realistically keep up with, Basu says. As a result, International Seaways relies on specialized MSPs rather than trying to maintain deep in-house expertise across every domain.

“That gives us access to current capabilities without constantly retraining or rebuilding teams as the technology changes,” he explains. “The decisions that protected us in 2020 were made years before anyone realized how important they would become. Infrastructure strategy is always about preparing for a future that is not yet fully visible.”

The key is to make those decisions deliberately, with clear reasoning, rather than reacting under pressure later, he adds.

Build adaptable organizations

Edge computing is adding another layer of complexity, Johnson says. Leaders who navigate this effectively won’t be the ones who find the perfect architecture, he notes. “They’re the ones building organizations that can adapt quickly when the right answer changes tomorrow,” he says.

The real competitive advantage is not the cloud you picked, but how fast your team can learn and move, Johnson says.

Asked about other advice to make cloud less complicated, the CIOs offered the following:

Treat your cloud architecture like a product, not a project. It needs ongoing ownership, not just implementation, Johnson stresses.

Make sure you’re reviewing your decisions regularly. “The right call at year one often isn’t the right call at year three. Build in the checkpoints to revisit,” Johnson says.

Tie every workload to a cost center. Basu has done this, and IT continuously reviews utilization and rightsizing rather than waiting for periodic audits.

Data classification determines regional placement. Before any workload reaches production, ensure “Legal and Compliance are in that conversation from the start, not at the end,” Basu says.

Create a cloud-ready solution. This can sometimes be less expensive and lower risk than lifting and shifting a heavily customized legacy environment, Basu says.

Consolidation is a strategic choice, not a retreat. Fewer platforms, governed well, consistently outperform a fragmented multicloud estate, he says.

Don’t underestimate the governance gap AI is opening. Build your AI governance layer now, before the debt accumulates, Basu says.

Cloud strategy is not an IT architecture decision. The pandemic proved that it is a business resilience decision, Basu says. “The organizations that make the hard calls before the crisis arrives are the ones that come out intact.”

Ensure cloud decisions are tied to measurable business outcomes. WHSmith’s Bellendir says IT is also investing heavily in integration architecture, cybersecurity controls, observability, and data governance to better support a hybrid ecosystem.

Place greater emphasis on cloud cost governance and operational discipline. This will improve visibility into cloud usage and ensure that scaling AI, analytics, and digital initiatives remains financially sustainable over time, Bellendir says.

While no one can foresee whether cloud will grow less complicated down the road, organizations will continue to use it. “Cloud is no longer the future of IT — it’s the present,” says Sweetwater’s Johnson. “The conversation has shifted from ‘should we?’ to ‘how do we get better at it?’ That’s where I spend most of my time.”

기업의 클라우드 운영팀은 일반적으로 사용률 데이터를 기반으로 의사결정을 내리도록 훈련받아 왔다.

가상머신(VM)이 유휴 상태라면 더 작은 규모로 조정한다. 스토리지가 과도하게 할당돼 있다면 회수한다. GPU 사용률이 낮게 나타난다면 작업을 더 작은 인스턴스로 옮긴다.

이러한 접근 방식은 현대 핀옵스(FinOps)의 핵심 원칙이다. 조직이 낭비를 줄이고 예측 정확도를 높이며 클라우드 비용을 통제하는 데 도움을 준다.

하지만 보안 AI 학습은 또 다른 문제를 만들어낸다. 사용률 지표는 기술적으로는 정확할 수 있지만, 운영 관점에서는 잘못된 판단을 유도할 수 있기 때문이다.

실제로 워크로드가 과도하게 프로비저닝되지 않았더라도 GPU는 충분히 활용되지 않는 것처럼 보일 수 있다. 프라이버시 보호 머신러닝 환경에서 낮은 가속기 활용도는 여유 용량이 아니라 메모리 병목(memory-bound) 현상을 의미할 수 있다. 만약 클라우드 최적화 시스템이 이러한 신호를 단순한 자원 낭비로 해석한다면, 권장된 조치가 오히려 작업 속도를 늦추고 비용을 증가시킬 수 있다.

CIO에게 이는 단순한 GPU 튜닝 문제가 아니다. 클라우드 거버넌스의 문제다. 필자가 이전에도 강조했듯이, IT 리더는 AI 거버넌스에 수반되는 숨겨진 운영 비용을 이해하기 위해 단순한 클라우드 청구 금액을 넘어 전체 운영 구조를 살펴봐야 한다.

사용률 수치만으로는 병목 현상을 설명할 수 없다

기존의 클라우드 자원 최적화는 사용률이 낮으면 여유 자원이 존재한다고 보는 단순한 전제 위에서 작동한다. 사용률이 낮으면 일반적으로 사용되지 않는 용량이 존재한다는 것이다.

이 같은 가정은 많은 기업용 워크로드에서 유효하다. 웹 서비스, 배치 작업, 데이터베이스, 일반적인 컴퓨팅 작업에는 잘 적용된다. 하지만 보안 AI 학습은 워크로드의 특성이 달라지기 때문에 이러한 전제를 무너뜨릴 수 있다.

필자는 머신러닝의 프라이버시와 강건성(robustness)을 연구한 IEEE 시스템 연구를 통해 모델 학습 과정에 신뢰성 제어 기능이 추가될 때 어떤 변화가 발생하는지 분석했다. CIO가 얻어야 할 중요한 교훈은 단순히 보안 학습의 비용이 더 높다는 점이 아니다. 보안 학습은 인프라 지표가 의미하는 바 자체를 바꿀 수 있다는 점이다.

통제된 엔비디아(NVIDIA) V100 GPU 환경에서 프라이버시 보호 학습은 비전 워크로드 비용을 3.55배, 테이블형 데이터 워크로드 비용을 2.96배 증가시켰다. 또한 강건성 학습은 비전 워크로드 비용을 4.07배 높였다.

이러한 비용 증가 수치는 분명 중요하다. 하지만 핀옵스 팀이 주목해야 할 더 근본적인 발견은 따로 있다.

보안 AI 워크로드에서는 클라우드 운영팀이 자원 규모를 조정할 때 활용하는 기존 하드웨어 지표만으로는 실제 자원 활용 상태를 정확히 파악하기 어려워진다. 다시 말해, 워크로드 특성이 변화하면서 기존 인프라 지표만으로는 실제 자원 활용 상태를 정확하게 해석하기 어려워졌다는 의미다.

프라이버시 보호 학습이 비효율적으로 보이는 이유

현대 AI 가속기는 대규모의 고밀도 수학 연산을 처리하는 데 매우 뛰어나다. 일반적인 모델 학습은 작업을 큰 연산 블록 단위로 구성할 수 있기 때문에 GPU 가속 유닛을 지속적으로 바쁘게 유지한다.

하지만 차등 프라이버시(Differential Privacy) 학습은 개별 샘플 단위의 그래디언트 계산과 클리핑(clipping)을 요구하는 경우가 많다. 대부분의 연산을 대규모·고효율 작업으로 처리하는 대신, 개별 학습 샘플마다 더 세분화된 연산 단계를 수행해야 한다.

이로 인해 성능 특성이 달라진다. 필자의 연구에서는 이러한 패턴이 메모리 병목(memory-bound) 현상을 유발하고 텐서 코어(Tensor Core)와 같은 GPU 전용 연산 유닛의 실질적인 활용도를 떨어뜨리는 것으로 나타났다. 대시보드에서는 이를 단순히 GPU 활용도가 낮은 상태로 해석할 수 있다.

하지만 시스템 엔지니어의 관점에서 이는 훨씬 구체적인 의미를 갖는다. 작업이 지연되는 이유는 GPU 성능이 과도해서가 아니다. 메모리 이동과 개별 샘플 단위 연산이 병목을 일으키고 있기 때문이다. 두 문제는 전혀 다른 성격의 이슈다.

핀옵스의 위험 요소: 정답 같은 권고, 잘못된 맥락

자동화된 클라우드 추천 시스템은 과도하게 할당되었거나 유휴 상태로 보이는 리소스를 찾아내는 데 유용하다. 문제는 이런 도구의 존재가 아니다. 일반적인 자원 최적화 기준을 특수한 AI 워크로드에 동일하게 적용하는 데 있다.

일반적인 권고 프로세스는 “가속기가 충분히 활용되고 있는가?”라는 질문을 던진다.

그러나 보안 AI 학습 환경에서는 CIO가 팀에 “왜 가속기가 충분히 활용되지 않고 있는가?”라는 질문을 하도록 해야 한다.

답이 실제 유휴 용량 때문이라면 인스턴스 규모를 줄여 비용을 절감할 수 있다.

반면 원인이 메모리 병목 기반의 프라이버시 연산이라면 인스턴스 축소가 오히려 총비용 증가로 이어질 수 있다.

더 작은 인스턴스는 시간당 요금이 저렴할 수 있다. 하지만 클라우드 비용은 시간당 요금만으로 결정되지 않는다. 시간당 요금에 전체 실행 시간을 곱한 값으로 산정된다.

만약 더 작은 인스턴스로 인해 학습 시간이 크게 늘어난다면 총비용은 오히려 증가할 수 있다.

바로 이것이 핀옵스의 사각지대다. 사용률 대시보드만 보면 해당 권고가 올바른 것처럼 보일 수 있지만, 전체 학습 작업의 경제성 관점에서 평가하면 잘못된 결정이 될 수 있다.

보안 AI에는 별도의 예외 정책이 필요하다

기업 IT 조직은 이미 일부 워크로드에 대해 별도의 관리 정책을 적용하고 있다. 규제 대상 데이터베이스, 보안에 민감한 시스템, 초저지연이 요구되는 애플리케이션에는 특별한 인프라 정책이 마련돼 있다.

보안 AI 학습에도 이와 유사한 예외 처리 정책이 필요하다. 차등 프라이버시(Differential Privacy)나 적대적 학습(Adversarial Training)을 사용하는 모델 학습 작업을 단순한 유휴 개발 서버와 같은 기준으로 평가해서는 안 된다. 이러한 워크로드는 알고리즘 자체가 하드웨어 사용 방식을 바꾸기 때문에 일반적이지 않은 사용률 패턴을 만들어낼 수 있다.

1. 보안 AI 학습 작업에 태그를 부여하라

핀옵스 팀은 학습 작업이 프라이버시 보호 기법이나 강건성 향상 기법을 사용하는지 파악할 수 있어야 한다.

간단한 워크로드 태그만으로도 해당 작업이 일반적인 컴퓨팅 워크로드로 분류되는 것을 막을 수 있다. 이 태그는 클라우드 운영팀에 다음과 같은 정보를 전달해야 한다.

“낮은 사용률은 자원 낭비가 아니라 알고리즘 특성 때문에 발생할 수 있다.”

이렇게 하면 핀옵스, ML옵스, 인프라 운영팀은 자원 규모 조정 여부를 검토하기 전에 해당 워크로드의 특성을 공통된 기준으로 이해할 수 있다.

2. 인프라 축소보다 병목 원인 파악이 우선이다

보안 AI 작업의 경우 자동화된 최적화 권고는 조사의 출발점이 되어야 한다. 자동으로 변경 요청으로 이어져서는 안 된다.

워크로드를 더 작은 인스턴스로 옮기기 전에 팀은 다음 네 가지 질문에 답해야 한다.

• 워크로드는 연산 중심(compute-bound)인가, 메모리 중심(memory-bound)인가?
• 병목 현상의 원인은 데이터 로딩, 메모리 대역폭, 개별 샘플 기반 프라이버시 연산 중 무엇인가?
• 더 작은 인스턴스가 전체 작업 비용을 줄이는가, 아니면 시간당 요금만 낮추는가?
• 변경 승인 전에 실행 시간에 미치는 영향을 측정했는가?

이는 핀옵스를 단순한 사용률 관리에서 워크로드를 이해하는 비용 거버넌스 체계로 발전시키는 접근법이다.

3. 핀옵스 의사결정에 ML옵스를 참여시켜라

핀옵스 팀은 비용 구조, 예약 구매 계획, 비용 배분(chargeback), 사용률 분석에 대한 전문성을 갖고 있다.

하지만 보안 AI 워크로드는 한 단계 더 깊은 해석을 필요로 한다.

누군가는 학습 알고리즘이 실제로 무엇을 수행하고 있는지 이해해야 한다.

DP-SGD와 PGD는 단순히 GPU 사용 시간을 늘리는 것이 아니다. 연산 패턴 자체를 바꾼다. 따라서 GPU 사용률 수치만으로는 적절한 인프라 의사결정을 내릴 수 없다.

CIO는 보안 AI 학습 워크로드에 비용 최적화 권고를 적용하기 전에 핀옵스, ML옵스, AI 거버넌스, 인프라 엔지니어링 조직을 긴밀하게 연결해야 한다.

4. 인스턴스 사용률이 아닌 전체 작업의 경제성을 측정하라

가장 저렴한 인스턴스가 반드시 가장 비용 효율적인 선택은 아니다.

보안 AI 학습 환경에서 CIO는 다음 요소를 종합적으로 비교하도록 요구해야 한다.

• 시간당 비용
• 전체 실행 시간
• 에너지 사용량
• 작업 완료 시간
• 모델 성능 및 활용도에 미치는 영향
• 인프라 병목 구조

진정한 비용 최적화를 위해서는 하드웨어 지표만 바라봐서는 안 된다. 모델 수준의 최적화까지 함께 검토해 AI 학습 비용을 줄여야 한다.

결국 사용률이 낮아 보이는 GPU라도 작업을 더 빠르게 완료하고 장시간의 메모리 병목 구간을 피할 수 있다면 더 경제적인 선택일 수 있다. 반대로 인프라 변경 과정에서 모델 성능에 미치는 영향을 고려하지 않으면 비용 절감이 실제 서비스 성능 저하로 이어지는 ‘AI 정확도 함정(AI Accuracy Trap)’에 빠질 위험이 있다.

CIO를 위한 핵심 메시지

기업 AI의 다음 단계는 단순히 모델 정확도를 높이고 빠르게 실험하는 것을 넘어선다.

조직은 프라이버시를 보호하고, 강건성을 확보하며, 거버넌스를 지원하고, 경제적으로도 지속 가능한 AI 시스템을 구축해야 한다.

일반적인 클라우드 운영 환경에서는 낮은 사용률이 곧 자원 낭비를 의미하는 경우가 많다.

하지만 보안 AI 학습에서는 낮은 사용률이 워크로드를 통해 하드웨어와 소프트웨어 간의 구조적 불일치가 드러났음을 의미할 수 있다.

CIO가 기억해야 할 원칙은 간단하다.

가속기가 충분히 활용되지 않는 이유를 파악하기 전에는 보안 AI 학습 작업을 리사이징해서는 안 된다.

신뢰할 수 있는 AI 환경에서는 사용률 수치가 항상 진실을 말해주는 것은 아니다.
dl-ciokorea@foundryco.com

수년 동안 기업용 소프트웨어 벤더들은 사용자를 자사 애플리케이션 안에 머물게 하기 위해 경쟁해 왔다. 그러나 AI 에이전트와 자동화 워크플로우의 확산으로 이러한 공식이 바뀌고 있다. 세일즈포스는 이에 발맞춰 지난달 새로운 헤드리스 360(Headless 360)을 출시하며 빠르게 대응에 나섰다.

세일즈포스 경영진은 수요일 진행된 실적 발표에서 헤드리스 360을 AI 시대를 위한 중요한 아키텍처 전환이자 새로운 수익 창출 기회로 규정했다. 기업들이 자동화 워크플로우를 구축하는 과정에서 기존 애플리케이션 인터페이스 대신 API와 MCP(Model Context Protocol) 서버를 통해 AI 에이전트, 슬랙(Slack) 봇, 외부 코파일럿이 세일즈포스 데이터에 접근하는 방식을 점점 더 많이 채택하고 있기 때문이다.

세일즈포스 최고매출책임자(CRO) 미겔 밀라노는 헤드리스 360 전략을 설명하며 “우리는 업계 최고의 에이전틱 CRM을 고객이 있는 모든 접점으로 확장할 것”이라며 “고객과 파트너와 협력해 우리 플랫폼에 접근하는 새로운 사용자와 새로운 상호작용을 공정하고 합리적인 방식으로 수익화할 방법을 찾을 것”이라고 말했다.

예측 불가능한 비용에 대한 우려

업계 분석가들은 세일즈포스의 변화하는 가격 정책이 헤드리스 360 도입을 주저하는 기업 고객들의 우려를 반영한 것이라고 분석했다. 가장 큰 이유는 사용량 기반 과금으로 인해 비용을 예측하기 어렵다는 점이다.

퓨처럼 그룹(The Futurum Group)의 CIO 프랙티스 책임자 디온 힌치클리프는 “지난 10년간 클라우드 비용이 예상보다 크게 증가하는 경험을 하면서 CIO들은 예측 불가능한 사용량 기반 과금에 매우 민감해졌다”라며 “기업들은 헤드리스 CRM과 에이전틱 워크플로우의 전략적 가치를 이해하고 있지만, 동시에 핵심 시스템에서 머신이 생성하는 활동이 통제 불가능한 수준으로 늘어날 가능성도 우려하고 있다”라고 설명했다.

힌치클리프는 가장 큰 우려가 API 호출 단가 자체가 아니라고 지적했다. 문제는 증폭 효과다. 인간 사용자가 아닌 자율형 AI 에이전트는 영업, 고객 서비스, 마케팅, 분석, 오케스트레이션, 외부 AI 시스템 전반에 걸쳐 수만 건의 CRM 상호작용을 지속적으로 생성할 수 있기 때문이다.

그는 “이는 향후 지출 규모, 권한 관리 확산, 감사 가능성, 운영 책임성 측면에서 정당한 거버넌스 우려를 불러일으킨다”라고 말했다.

크레이머ERP(KramerERP)의 매니징 파트너 로버트 크레이머는 자동화 워크플로우와 AI 에이전트 기반 CRM 상호작용이 늘어나면서 세일즈포스가 상대적으로 예측 가능했던 기존 구독형 라이선스 모델에서 점차 벗어나 API 및 MCP 사용량 중심의 과금 체계로 이동할 것으로 전망했다.

이에 대해 힌치클리프는 헤드리스 360에서 API와 MCP 사용량을 계량화해 과금하기 시작하면 CIO들이 CRM 플랫폼에 대해 기대해왔던 예산 예측 가능성이 사라질 수 있다고 분석했다. 비교적 고정적이던 SaaS 지출이 사용량에 따라 비용이 변동하는 클라우드식 탄력 소비 모델로 바뀌게 된다는 의미다.

발루아(Valoir)의 수석 애널리스트 레베카 웨테만 역시 예측 가능성 부족이 현재 CIO들이 에이전틱 AI 워크로드를 파일럿 단계에서 실제 운영 환경으로 확대하는 과정에서 직면한 가장 큰 장애물 중 하나라고 지적했다.

이와 같은 우려에 공감하며 인포테크 리서치 그룹(Info-Tech Research Group)의 자문 연구원 스콧 비클리는 API와 토큰 기반 CRM 사용 모델이 가격 변동성을 더욱 키울 수 있다고 경고했다. 기업 비용이 모델 라우팅 방식, 컨텍스트 캐싱, 프롬프트 효율성, 그리고 계속 변화하는 AI 모델 가격 구조 등에 따라 크게 달라질 수 있기 때문이다.

도입 전 비용 구조부터 파악해야

비클리는 자동화된 CRM 워크플로우가 기업 비용을 증가시킬 가능성이 매우 높다고 전망했다.

비클리는 “사용량 기반 자동화는 거래량을 늘린다”라며 “통합된 사용자 경험을 제공하기 위해 세일즈포스의 다양한 하위 모듈이 호출되는데, 각 모듈마다 별도의 과금 계층이 존재하기 때문에 비용은 급격히 증가할 것”이라고 설명했다.

이에 따라 CIO들은 자동화된 CRM 워크플로우를 전사적으로 도입하기 전에 해당 활용 사례의 비즈니스 가치를 면밀히 검토하고, 증가하는 비용이 생산성 향상이나 매출 증대 같은 측정 가능한 성과로 연결되는지 확인해야 한다고 조언했다.

비클리는 또한 상업적 과금 모델이 명확하게 정립되고 고객에게 충분히 설명되기 전까지는 CIO들이 성급하게 도입을 결정하지 않는 것이 바람직하다고 강조했다.

그는 “구매자는 무엇이 과금 대상 호출로 간주되는지, 내부 AI 에이전트 호출과 고객 또는 외부 대상 호출의 가격이 다른지, 사용량 상한선이나 경고 기능이 있는지, 예상치 못한 사용량 급증 가능성은 없는지 등을 반드시 확인해야 한다”라고 말했다.

IT 협상 자문 기업 어퍼엣지(UpperEdge)의 세일즈포스 부문 상업 자문 책임자 애덤 맨스필드 역시 비슷한 의견을 내놨다. 그는 CIO들이 사용량 기반 과금 계약을 체결할 때 적절한 가격 체계와 물량 할인 구조는 물론, 충분한 수준의 투명성·유연성·보호 장치까지 확보해야 한다고 강조했다.

맨스필드는 “세일즈포스 같은 IT 벤더는 일반적으로 사용량 증가에 따른 비용 확대를 의도하고 계획한다”라며 “업계에서는 이를 ‘플라이휠 효과(Flywheel Effect)’라고 부른다. 사용량이 증가하기 시작하면 계속 늘어나고, 이에 따라 수수료 수입과 매출도 함께 가속화된다”라고 설명했다.

CRM에도 핀옵스식 거버넌스 필요

힌치클리프는 이러한 가격 정책 변화가 CIO들의 운영 방식에도 영향을 미칠 것이라고 전망했다.

그는 “앞으로는 CRM 자체에도 핀옵스(FinOps) 수준의 거버넌스가 필요해질 수 있다”라며 “토큰 예산 관리, API 사용 한도, 정책 기반 트래픽 제한, 워크로드 우선순위 지정, 비용 이상 징후 탐지, 사업부별 비용 배분 모델 등이 포함될 것”이라고 말했다.

물론 CIO들이 준비해야 할 변화가 이것만은 아니다. IT 컨설팅 기업 카네리카(Kanerika)의 AI 개발 매니저 아밋 제나는 AI 에이전트 승인 체계, 감사 추적(Audit Trail), 데이터 유출 방지 등 거버넌스 중심의 운영 체계도 강화해야 한다고 지적했다.

SaaS 업계 전반으로 번지는 가격 정책 딜레마

반면 HFS 리서치(HFS Research)의 수석 연구 책임자 아시시 차투르베디는 MCP 및 API 상호작용을 사용량 기준으로 과금하는 과정에서 발생하는 더 큰 문제가 있다고 분석했다. 바로 세일즈포스의 이해관계가 충돌할 수 있다는 점이다.

차투르베디는 “모든 MCP 호출과 API 상호작용을 과금하기 시작하면 역설적인 상황이 발생한다”라며 “고객은 비용을 통제하기 위해 AI 에이전트 사용을 제한하게 되고, 이는 세일즈포스가 해당 전략을 정당화하기 위해 필요로 하는 도입 확대의 선순환 효과를 약화시킨다”라고 설명했다.

이어 “세일즈포스는 새로운 접점을 수익화하고 싶어 하지만, 동시에 자신들이 장려하려는 행동에 과도한 비용 부담을 부과하고 싶지는 않은 상황에 놓여 있다”라고 분석했다.

예측 가능한 비용을 원하는 기업 고객과, 기존 사용자 라이선스 성장세가 둔화되는 상황에서 자동화 사용량 증가를 수익으로 연결하려는 SaaS 벤더 간의 이러한 긴장 관계는 세일즈포스만의 문제가 아니다.

비클리에 따르면 AI 에이전트, 내장형 AI 비서, 머신투머신(M2M) 워크플로우가 확산되면서 기존 SaaS 라이선스 모델의 경계가 흐려지고 있으며, 주요 기업용 소프트웨어 업체 대부분이 동일한 가격 정책 딜레마에 직면해 있다.

예를 들어 서비스나우(ServiceNow)는 에이전틱 AI 워크로드에 대해 사용량 기반 과금을 도입하기 시작했으며, 보다 예측 가능한 워크플로우는 계량 과금 대상에서 제외하고 있다. 마이크로소프트(MS)는 코파일럿 스튜디오(Copilot Studio)에서 에이전트 단위 과금 모델을 시험하고 있으며, 워크데이(Workday) 역시 여전히 사용자 수 기반 라이선스 모델에 의존하고 있지만 AI 중심 사용 패턴에 맞춰 가격 정책을 조정해야 한다는 압박을 받고 있다.

비클리는 세일즈포스가 실행력과 마케팅 측면 모두에서 상당수 SaaS 벤더보다 앞서 있다고 평가했다. 세일즈포스가 이미 에이전틱 AI, API, MCP 서버, 크로스 플랫폼 워크플로우 통합을 아우르는 일관된 엔터프라이즈 아키텍처 비전을 제시했다는 설명이다.

복잡해지는 가격 체계

차투르베디는 이러한 변화의 가장 큰 문제로 라이선스 구조의 복잡성 증가를 꼽았다.

차투르베디는 “세일즈포스 고객들은 이미 기업용 소프트웨어 업계에서 가장 복잡한 라이선스 체계 가운데 하나를 관리하고 있다”라며 “사용자당 과금 모델 위에 사용량 기반 계량 과금이 추가되고, 여기에 플렉스 크레딧(Flex Credits)과 기업 라이선스 계약(ELA)까지 더해지면 가격 체계를 이해하기 위해 스프레드시트가 필요하고, 계약 협상을 위해서는 변호사까지 동원해야 하는 수준이 된다”라고 설명했다.

이어 “가격 체계가 복잡해질수록 최고재무책임자(CFO)가 도입 결정을 늦출 이유도 늘어나게 된다”라고 덧붙였다.

세일즈포스는 현재 헤드리스 360 환경에서 API와 MCP 상호작용에 어떤 방식으로 과금하고 있는지에 대한 구체적인 입장을 밝히지 않았다.

다만 업계 분석가들은 현재 대부분의 API 및 MCP 호출이 단일한 ‘MCP 호출당 과금’ 모델로 청구되는 것은 아니라고 보고 있다. 기존 API 사용량 과금, 에이전트포스(Agentforce) 사용량 기준, 플랫폼 이용 권한, 그리고 개별적으로 협상된 기업 계약 등이 복합적으로 적용되는 방식이라는 분석이다.

이 같은 불확실성에도 불구하고, 미겔 밀라노는 실적 발표에서 아데코(Adecco)와 앤트로픽을 API 및 헤드리스 기반 세일즈포스 활용이 빠르게 증가하고 있는 대표 사례로 소개했다.

세일즈포스 최고매출책임자(CRO) 미겔 밀라노는 “앤트로픽은 CRM과 세일즈 클라우드(Sales Cloud), 그리고 슬랙의 주요 고객 가운데 하나”라며 “현재 앤트로픽은 헤드리스 방식으로 세일즈 클라우드를 활용하고 있으며, 그 결과 1분기 사용량이 5배 이상 증가했다”라고 밝혔다.
dl-ciokorea@foundryco.com

For years, enterprise software vendors have fought to keep users inside their applications, but the rise of AI agents and automated workflows is changing that equation. Salesforce has been moving quickly to adapt, with last month’s launch of its new Headless 360 offering.

During its earnings call on Wednesday, Salesforce top executives positioned Headless 360 as both a major AI-era architecture shift and a fresh monetization opportunity, as enterprises increasingly move towards using AI agents, Slack bots and external copilots to access Salesforce data through APIs and MCP servers, rather than its traditional application interfaces, for use in automated workflows .

“We’re going to bring our number one agentic CRM to every surface, meeting customers where they are,” Miguel Milano, Salesforce chief revenue officer, told analysts during the call, explaining the company’s strategy around Headless 360. “And we’re going to work together with our customers and with our partners to find the right ways in a fair way to monetize those new interactions and those new users that are accessing our platform.”

Concerns over unpredictable costs

That evolving pricing strategy, analysts say, reflects customer enterprises’ hesitation around adoption of Headless 360, mainly driven by worries about unpredictable consumption costs.

Dion Hinchcliffe, CIO practice lead at The Futurum Group, said, “CIOs have become highly sensitive to unpredictable consumption pricing after a decade of cloud cost overruns. Enterprises understand the strategic power of headless CRM and agentic workflows, but they are also seeing the possibility of runaway machine-generated activity inside core systems of record.”

The biggest concern, Hinchcliffe pointed out, is not necessarily that of the unit price of an API call, but rather the multiplication effect, wherein autonomous agents, unlike human users, could generate tens of thousands of CRM interactions continuously, across sales, service, marketing, analytics, orchestration, and external AI systems.

“That creates legitimate governance anxiety around future spend, permissions sprawl, auditability, and operational accountability,” he said.

In fact, Robert Kramer, managing partner at KramerERP, sees the rise of automated workflows and agent-driven CRM interactions gradually pushing Salesforce away from the traditional subscription licensing models that were more predictable, and toward more consumption-based pricing when it comes to API and MCP usage.

Thus, according to Hinchcliffe, that metering of API and MCP use for Headless 360 will result in CIOs losing the budget predictability they traditionally associated with CRM platforms, replacing relatively fixed SaaS spending with cloud-style elastic consumption economics, where spend is driven by usage volume.

And predictability, said Rebecca Wettemann, principal analyst at Valoir, is currently one of the biggest hurdles CIO are facing while they try to move any agentic workloads from pilot to production.

Echoing those concerns, Scott Bickley, advisory fellow at Info-Tech Research Group, added that API- and token-driven CRM consumption models could introduce further pricing volatility, because enterprise costs may increasingly fluctuate based on factors such as model routing, context caching, prompt efficiencies, and constantly shifting AI model pricing structures.

Understand costs before adoption

In fact, he sees automated CRM workflows almost certainly increasing enterprise costs.

“Automation based on consumption metrics increases transaction volumes. As the underlying modules of Salesforce are called upon for an integrated experience, each with its own billable layer, costs will explode higher,” Bickley said.

As a result, the analyst advised CIOs to carefully evaluate the business use case and check whether those higher costs can be tied to measurable productivity or revenue gains before broadly adopting automated CRM workflows at scale.

CIOs, Bickley warned further, should be hesitant about committing until the commercial model is formalized, communicated, and well understood.

“Buyers should be asking questions like:  What counts as a billable call?  Are internal agent calls priced differently from customer/external facing calls?  Are there caps or alerts? Can consumption spike unexpectedly?” Bickley said.

Similarly, Adam Mansfield, commercial advisory practice leader in the Salesforce practice at IT negotiation advisory firm UpperEdge, noted that CIOs should ensure that they “negotiate the right pricing and volume discount structures along with the right level of transparency, flexibility, and protections into their contracts for consumption-based pricing.

IT vendors such as Salesforce typically intend and plan for increasing consumption costs, Mansfield said: “They refer to this as the ‘flywheel effect’. Once usage starts to spin, it keeps spinning more and the fees keep coming in and their revenue accelerates with it.”

FinOps-style governance for CRM

According to Hinchcliffe, the shift in pricing models will drive operational changes for CIOs as well.

“They may soon need FinOps-style governance for CRM itself, including token budgets, API quotas, policy-based throttling, workload prioritization, cost anomaly detection, and business-unit chargeback models,” he said.

Those won’t be the only adjustments for CIOs. Amit Jena, AI development manager at IT consultancy firm Kanerika, noted that other operational changes that CIOs need to make would revolve mostly around governance, including agent approval systems, audit trails, and data leakage prevention.

The broader SaaS pricing reckoning

For Ashish Chaturvedi, executive research lead at HFS Research, however, the bigger challenge with metering MCP and API interactions lies in the conflicting incentives it creates for Salesforce itself.

“If you start metering every MCP call and API interaction, you create a perverse incentive: customers will throttle agent usage to control costs, which kills the very adoption flywheel Salesforce needs to justify the strategy,” Chaturvedi said. “Salesforce is caught between wanting to monetize a new surface and not wanting to tax the behavior it’s trying to encourage.”

That tension between enterprise buyers seeking predictable costs and SaaS vendors trying to monetize rising automation volumes as traditional seat-license growth slows is not unique to Salesforce.

According to Bickley, most major enterprise software vendors are now grappling with the same pricing dilemma, as AI agents, embedded assistants, and machine-to-machine workflows increasingly blur the boundaries of traditional SaaS licensing models.

ServiceNow, for example, has begun introducing usage-based pricing for agentic AI workloads, while keeping more deterministic workflows outside metered billing, he said, while Microsoft is experimenting with per-agent pricing models in Copilot Studio, and Workday, though still largely reliant on seat-based licensing, is also facing growing pressure to adapt its pricing strategy for AI-driven usage patterns.

Salesforce, Bickley pointed out, is ahead of many SaaS vendors both in terms of execution and marketing, having already “articulated a coherent enterprise architecture” around agentic AI, APIs, MCP servers and cross-platform workflow integration.

Increased pricing complexity

The caveat, according to Chaturvedi, is the increased complexity around licensing.

“Salesforce customers already navigate one of the most complex licensing structures in enterprise software. Layering consumption-based metering on top of per-seat pricing on top of flex credits on top of ELAs creates a commercial model that requires a spreadsheet to decode and a lawyer to negotiate. Every layer of pricing complexity becomes a reason for a CFO to slow down adoption,” Chaturvedi explained.

Salesforce declined to comment on how API and MCP interactions under Headless 360 are currently being billed. Analysts, however, agreed that most API and MCP calls are currently being billed through a mix of existing API consumption, Agentforce usage constructs, platform entitlements, and negotiated enterprise agreements rather than a single clean “per MCP call” pricing model.

Despite this uncertainty, during the earnings call Milano pointed to customers such as Adecco and Anthropic as examples of rising API- and Headless-driven Salesforce usage. “Anthropic is one of our biggest users of CRM, of Sales Cloud, and obviously Slack. Their usage through Q1 has exploded fivefold because now they’re using Sales Cloud from a Headless perspective,” Milano said.

Cloud was designed to transform how companies operate, shifting infrastructure from fixed, capital-intensive investments to flexible and consumption-based services. For many organizations, it has delivered exactly that: greater agility, faster innovation and the ability to scale in ways that were previously impossible.

At the same time, the flexibility that cloud provides has also changed the economics of technology in ways that many organizations are still struggling to govern.

As cloud and AI-driven workloads accelerate, cost has become dynamic, distributed and tightly coupled to engineering decisions made each day. What was once a predictable IT expense has evolved into a variable input that can shift dramatically which changes in usage or model demand. Traditional budgeting cycles and after-the-fact approvals are no longer sufficient for this environment.

In my work with organizations navigating this shift, one thing has become clear: cloud spending is not just a technology or finance challenge. It’s a governance issue that sits at the intersection of multiple organizations within the business.

From cost to growth engine

Today, global public cloud spending exceeds $700 billion and is projected to approach $2 trillion by the end of the decade, reflecting the expanding role cloud plays across business operations.

When managed efficiently, cloud enables instant scaling, faster product launches, market expansion without physical infrastructure and lower risk innovation, making it material to the income statement. Though without clear accountability, costs can outpace value.

And in fact, industry research suggests that 20–30% of that spend may be inefficient, often due to overprovisioning or unused resources.

For technology leaders, this creates tension. Engineering teams are asked to deliver new capabilities fast, while finance teams are expected to maintain predictability and discipline. When those goals are managed in isolation, both suffer.

Why finance is being pulled deeper into cloud decisions

For CFOs, this is a strategic opportunity to shift from approving budgets after the fact to shaping how the organization optimizes one of its biggest investments. Increasingly, I see CFOs moving from downstream approvers to active partners in establishing a new operating model that aligns financial discipline with operational decision making.

This is where FinOps is gaining traction, as it creates a shared operating model for finance and technology teams.

FinOps: Enabling accountability at scale

FinOps brings financial accountability to cloud spending by linking cost to ownership and outcomes while aligning finance, engineering and business teams around shared metrics and goals.

At its core, FinOps is about making cost visible with context, pushing it into a factor of everyday operational decisions rather than something reviewed after the fact. To yield the most return on shifting to FinOps, technology and finance teams must align on two core principles:

FinOps principles

Ownership and financial discipline

One of the most important principles of FinOps is ownership. Every dollar of cloud spend should be tied to a team, product or business function, with a clear owner responsible for its performance. This shifts the conversation from “what did we spend?” to “what did we achieve?”

For CIOs, I’ve seen this level of transparency improve architectural decision-making, as trade-offs around performance and scalability are now grounded in unit cost and business impact. When accountability is distributed across the organization, financial discipline becomes part of day-to-day decision-making rather than a periodic review.

Navigating complexity while unlocking value

Companies are processing more data, delivering more digital services and innovating at a faster pace than ever before. Cloud and SaaS enable this shift through real-time analytics that improve decision-making, and AI workloads add another layer of volatility.

In this context, governance cannot rely on static controls. Instead, it requires shared metrics between finance and technology for each set of leaders to understand how usage translates to cost and whether or not that cost is justified by the value created.

The metrics that matter

To lead effectively in this environment, CFOs need a new set of metrics—ones that connect technology spend to business performance.

• Cost allocation coverage is foundational. When most cloud spend can be mapped to specific owners, accountability becomes actionable. This clarity helps IT leaders identify which platforms are driving cost, and it gives finance teams confidence in the numbers they’re reporting.
• Forecasting accuracy is equally important. While cloud spend is variable, it is not unknowable. Organizations that align forecasts with actual usage gain a significant advantage in planning, budgeting and investor communication.
• Unit economics is perhaps the most powerful metric. Instead of looking at total spend, leading organizations measure the cost of delivering a specific outcome: cost per transaction, cost per customer, cost per feature or cost per model inference. This creates a direct link between spend and value. As AI adoption accelerates, this becomes critical. AI workloads can scale rapidly, and without a clear understanding of unit cost, it is easy for innovation to outpace returns.
• Efficiency metrics, such as idle resource usage and savings realization, help identifying where optimization efforts are translating into real financial impact.

Turning governance into an advantage

One of the most significant benefits of cloud and FinOps is cultural. When cost is visible and ownership is clear, finance and technology teams create a shared language. Engineers begin to understand the financial impact of their decisions. Finance gains insight into the technical drivers behind spend.

This alignment enables faster, better decisions.

Organizations that focus only on controlling costs will struggle with cloud systems. Those who focus on governing value will turn uncertainty into strategic advantage. I feel strongly that the technology and finance leaders who embrace that shift will define how their organizations innovate, scale and compete in an increasingly AI-driven environment.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Over the past decade and a half, cloud computing has become a foundational technology. It started as a way to rent servers but has evolved into a complex ecosystem that supports everything from basic infrastructure shifts to transformative AI initiatives. Having advised enterprises on thousands of cloud projects over the years, I have seen that most projects fall into a handful of categories. I can say with certainty that success depends less on hype and more on understanding each project’s nature, risks, costs, and lessons.

Cloud migrations

Enterprises continue to migrate existing workloads from data centers to public, private, or hybrid environments. This can involve rehosting (lift and shift), replatforming with minor changes, or full refactoring into cloud-native architectures. The goal is usually cost reduction, scalability, or the end of hardware refresh cycles. The risks here are well documented. Many projects underestimate dependencies, leading to performance surprises or integration failures. Data egress fees and unexpected operational costs can wipe out projected savings.

Cost profiles vary widely. Initial migrations often run 20% to 50% over budget due to discovery gaps and testing. Ongoing expenses can decline through rightsizing and reserved instances, but poor management often leads to 25% to 35% waste from idle resources. These lessons underscore the importance of modeling the total cost of ownership up front, including people, training, and change management.

What we’ve learned: Pure lift-and-shift rarely delivers the promised ROI. Organizations that succeed treat migration as an opportunity for modernization rather than a simple move. Phased approaches with strong governance and finops practices minimize overruns, which have historically plagued most efforts.

Cloud-native applications

Teams build microservices, serverless functions, or containerized apps on platforms such as Kubernetes, AWS Lambda, or Azure Functions. This approach leverages elasticity, devops pipelines, and managed services to accelerate time to market.

Risks focus on architectural complexity and skills gaps. Overengineering with too many microservices creates operational nightmares, while underengineering leads to unscalable monoliths. Distributed systems need constant security vigilance. New apps often begin well but gain technical debt when teams prioritize features over observability and resilience. Entry costs are usage-based, which sounds attractive, but they often spike at scale due to poor design.

What we’ve learned: Based on my years of observation, successful teams embed cost awareness in CI/CD, use spot instances strategically, and design for observability from day one. Cloud-native development accelerates innovation when paired with disciplined architecture.

Business analytics projects

Enterprises are moving data lakes, data warehouses, and ETL processes to services such as Snowflake, BigQuery, or Redshift. Real-time analytics, dashboards, and predictive modeling become possible at scale. The primary risks are data gravity and quality issues. Moving petabytes is expensive and complex, while poor governance leads to compliance headaches or “garbage in, garbage out” results. Integrating with legacy systems often delays the realization of value.

What we’ve learned: Fifteen years later, we know that centralized data strategies outperform fragmented ones but only when paired with strong data mesh or data fabric approaches that respect domain ownership. Cost profiles include storage, compute for queries, and egress. Optimization through partitioning and materialized views pays off, but many organizations waste money on unused data. Lessons emphasize starting small with high-value use cases and building governance early rather than bolting it on later.

Artificial intelligence projects

Artificial intelligence and machine learning projects represent the current frontier of cloud. This includes training models, deploying inference endpoints, and integrating ML into applications. Managed services lower barriers, but custom needs often require GPU clusters or specialized hardware. Risks are significant: model drift, explainability issues, high compute demands, and ethical concerns. Many projects stall after the proof of concept because production deployment exposes scalability or cost issues. Managed AI offerings from providers help, but enterprises still struggle to integrate them into core business processes.

Costs run high, especially for training. Inference can be optimized, but it often dominates bills. What we have learned is that AI succeeds when treated as part of a broader cloud-native architecture, not as a standalone science project. Hybrid approaches and cost controls are essential.

Generative AI projects focus on large language models, image generation, code assistants, and custom agents using services like Bedrock, OpenAI integrations, or fine-tuned open source models. Enterprises are experimenting with retrieval-augmented generation for grounded responses and agentic workflows. Risks include hallucinations, data privacy leaks, intellectual property issues, and runaway token costs. Many early adopters built impressive demos only to face governance and compliance walls in production.

What we’ve learned: After observing the wave, the lessons are clear. Start with narrow, high-value use cases and layer in strong prompting, evaluation, and human oversight frameworks. Cost profiles are usage-driven and can escalate quickly with volume. Optimization through caching, smaller models, and hybrid on-prem inference helps. Generative AI delivers ROI fastest when embedded in existing workflows rather than used as standalone tools.

Other project types

Modernization of legacy mainframe or monolithic applications falls between migration and new development. Internet of Things (IoT) initiatives use the cloud for device management and edge analytics. Disaster recovery and backup projects leverage the cloud to improve resilience. Edge computing projects move processing closer to users or devices. Compliance-focused sovereign cloud deployments address data residency requirements. Finally, sustainability initiatives focus on reducing carbon footprints by implementing efficient architectures.

What we’ve learned: Each approach carries tailored risks and cost dynamics. Modernization often uncovers hidden dependencies. IoT requires reliable connectivity. Edge computing introduces latency considerations. Lessons across all types highlight the value of multicloud strategies for negotiation leverage and risk diversification, though they increase complexity.

Common themes

Most projects do not fail because of technology itself but from inadequate planning, cultural resistance, or neglect of operational realities. Cost overruns are often caused by the absence of strict finops discipline. Security and compliance issues remain ongoing and require integrated design considerations. Skills shortages hinder progress, which makes managed services appealing despite concerns about vendor lock-in.

Successful cloud stories share common traits: strong executive sponsorship, iterative delivery, cross-functional teams, and continuous optimization. Enterprises that treat the cloud as a business transformation rather than an IT project perform best. They measure outcomes using business metrics, such as revenue impact, customer satisfaction, and speed to market—not just uptime or instance counts.

The cloud landscape continues to evolve as capacity markets, neoclouds, and AI-driven operations offer new options. Yet cloud fundamentals endure. Choose the right project type for your cloud maturity and goals. Understand risks thoroughly. Model costs realistically. Apply lessons from the thousands of cloud deployments that came before.

My advice sounds simple, but it will determine which cloud projects and enterprises will thrive in the next decade of cloud computing. Those who chase hype without discipline will only become another cautionary tale.

Enterprise cloud teams are trained to act on utilization data.

If a virtual machine is idle, resize it.
If storage is overallocated, reclaim it.
If a GPU appears underused, move the job to a smaller instance.

That logic is central to modern FinOps. It helps organizations reduce waste, improve forecasting and keep cloud spending under control.

But secure AI training introduces a different problem: sometimes the utilization signal is technically true and operationally misleading.

A GPU can look underused even when the workload is not over-provisioned. In privacy-preserving machine learning, low accelerator utilization may indicate a memory-bound bottleneck, not excess capacity. If a cloud optimization process treats that signal as ordinary waste, the recommended fix can make the job slower and more expensive.

For CIOs, this is not just a GPU tuning issue. It is a cloud governance issue. As I have noted previously, IT leaders must look beyond the cloud bill to understand the hidden operational costs of AI governance

The utilization number does not explain the bottleneck

Traditional cloud right-sizing depends on a simple assumption: low utilization usually means unused capacity.

That assumption works for many enterprise workloads. It can work for web services, batch jobs, databases and standard compute jobs. But secure AI training can break that assumption because the workload shape changes.

In my IEEE systems research on privacy and robustness in machine learning, I profiled what happens when trust controls are added to model training. The important lesson for CIOs was not only that secure training costs more, but it was that secure training can change what infrastructure metrics mean.

On a controlled NVIDIA V100 GPU setup, privacy-preserving training increased cost by 3.55x on a vision workload and 2.96x on a tabular workload. Robustness training increased cost by 4.07x on the vision workload.

Those cost multipliers matter. But for FinOps teams, the deeper finding is this:

The workload became less aligned with the hardware signals that cloud teams often use for rightsizing.

Why privacy-preserving training can look inefficient

Modern AI accelerators are very good at large, dense mathematical operations. Standard model training often keeps these accelerator units busy because the work can be organized into large blocks of computation.

Differential privacy training often requires per-example gradient computation and clipping. Instead of pushing most of the work through large, efficient operations, the system performs more fine-grained steps across individual training examples.

That changes the performance profile. In my study, this pattern created memory-bound behavior and reduced effective use of specialized GPU compute units such as Tensor Cores. To a dashboard, that can look like underutilization.

To a systems engineer, it means something more specific: the job is not waiting because the GPU is too large. It is waiting because the workload is constrained by memory movement and per-example operations, simply those are not the same problem.

The FinOps risk: Right answer, wrong context

Automated cloud recommenders are useful because they identify resources that appear oversized or idle. The problem is not that these tools exist. The problem is applying a generic right-sizing rule to a specialized AI workload.

A standard recommendation workflow might ask, “Is the accelerator busy?: For secure AI training, CIOs need the team to ask, “Why is the accelerator not busy?”

If the answer is idle capacity, downsizing may save money.

If the answer is memory-bound privacy computation, downsizing may increase total cost.

A smaller instance may have a lower hourly price, but cloud bills are not based only on hourly price. They are based on hourly price multiplied by runtime. If the smaller instance extends the training job enough, the total bill can rise.

That is the FinOps blind spot: a recommendation can look correct on a utilization dashboard but fail when measured against the full training job.

Secure AI needs a different exception policy

Enterprise IT already treats some workloads differently. Regulated databases, security-sensitive systems and latency-critical applications often have special infrastructure policies.

Secure AI training needs similar exception handling; a model training job that uses differential privacy or adversarial training should not be evaluated the same way as an idle development server. These workloads can produce unusual utilization patterns because the algorithm itself changes the way hardware is used.

1. Tag secure-AI training jobs

FinOps teams need to know when a training job uses privacy-preserving or robustness-oriented methods.

A simple workload tag can prevent the job from being evaluated as ordinary compute. The tag should tell cloud teams:

Low utilization may be caused by the algorithm, not by waste.

This gives FinOps, MLOps and infrastructure teams a shared signal before any right-sizing decision is made.

2. Treat rightsizing as a review trigger, not an automatic action

For secure AI jobs, an automated recommendation should start an investigation. It should not automatically become a change request.

Before moving the workload to a smaller instance, the team should answer four questions:

• Is the workload compute-bound or memory-bound?
• Is the bottleneck caused by data loading, memory bandwidth or per-example privacy operations?
• Would the smaller instance reduce total job cost, or only reduce hourly rate?
• Has the team measured runtime impact before approving the change?

This shifts FinOps from simple utilization management to workload-aware cost governance.

3. Bring MLOps into FinOps decisions

FinOps teams understand pricing, commitment plans, chargeback and utilization. But secure AI workloads require another layer of interpretation.

Someone must understand what the training algorithm is doing.

DP-SGD and PGD do not merely consume more GPU time. They change the computation pattern. That means utilization percentage alone is not enough to make an infrastructure decision.

CIOs should connect FinOps, MLOps, AI governance and infrastructure engineering before applying cost recommendations to secure AI training workloads.

4. Measure total job economics, not only instance utilization

The cheapest instance is not always the lowest-cost option. For secure AI training, CIOs should require teams to compare:

• Hourly cost
• Total runtime
• Energy use
• Job completion time
• Model utility impact
• Infrastructure bottleneck profile

To truly optimize these economics, teams must look beyond the hardware and apply model-level deep cuts to slash AI training costs. Ultimately, a GPU that looks underused may still be the better economic choice if it completes the workload faster and avoids a longer memory-bound run. Failing to account for the model utility impact during these infrastructure changes can easily lead organizations into the AI accuracy trap, where cost savings inadvertently ruin real-world performance.

The CIO takeaway

The next phase of enterprise AI will require more than model accuracy and fast experimentation. Organizations will need AI systems that are private, robust, governable and economically sustainable.

In ordinary cloud operations, low utilization often means waste. In secure AI training, low utilization may mean the workload has exposed a hardware-software mismatch.

The rule for CIOs is simple: Do not right-size secure AI training jobs until you understand why the accelerator is underused.

In trustworthy AI, utilization is not always truth.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Para la mayoría de los CIO, la implementación de la IA ya es la prioridad número uno. Así lo recoge la encuesta State of the CIO 2026 de CIO.com, que confirma una tendencia consolidada: los CEO sitúan la investigación y adopción de IA en la cúspide de sus agendas tecnológicas, en línea con los resultados ya observados en 2025.

Sin embargo, el enfoque ha cambiado. Los CEO han dejado atrás el interés por pruebas de concepto o experimentos limitados y demandan ahora iniciativas capaces de generar valor tangible. Los más estratégicos van un paso más allá: buscan utilizar la IA para transformar el modelo operativo y redefinir productos y servicios, esperando que el CIO lidere este proceso.

Shanky Viswanathan, director de innovación empresarial de Tata Consultancy Services, explica que “los directores generales quieren que los CIO den un paso al frente y lideren cómo liberar el valor real de la IA, pasando de mejoras de productividad a nuevas propuestas de valor”, y añade: “Existe una oportunidad real para que los CIO demuestren cómo se puede utilizar la IA en el negocio”.

De la experimentación al valor real

Este reto, sin embargo, está lejos de ser sencillo. Muchos CIO siguen teniendo dificultades para identificar casos de uso transversales que generen impacto significativo.

Para Jennifer Carter, analista principal sénior de Gartner, “muchos directores de sistemas de información (CIO) siguen teniendo dificultades para identificar casos de uso en toda la empresa en los que la IA pueda suponer una mejora significativa, así como para detectar los flujos de trabajo, procesos y puntos débiles que permitirían reinventar la organización con IA”.

Y añade: “Las posibilidades son ilimitadas, pero muchos CIO aún están poniéndose al día mientras los CEO les preguntan: “¿Qué podemos hacer con esto?”.

El mandato de extraer valor de la IA no es nuevo. Desde la irrupción de la IA generativa en el entorno empresarial a finales de 2022, esta ha sido una prioridad constante. Lo que sí es novedoso en 2026 es la exigencia explícita de obtener un retorno de inversión (ROI) medible.

De hecho, “establecer políticas de IA y métricas de ROI” figura ya entre las diez principales prioridades que los CEO fijan para los CIO.

Viswanathan lo resume claramente: “Los CEO están frustrados porque el gasto en IA es mucho mayor que los beneficios obtenidos. Sí hay mejoras de productividad, pero han sido fragmentadas”.

IA para crecer, no sólo para optimizar

Tras varios años de inversión, los CEO buscan ahora que la IA impulse directamente los ingresos. Esta exigencia se alinea con otras prioridades estratégicas identificadas en el estudio, como el crecimiento del negocio y el liderazgo en innovación.

Daniel Saroff, vicepresidente de investigación en IDC, apunta en la misma dirección: “Las organizaciones están bajo una presión real para cambiar su forma de competir, desarrollar productos y ofrecer servicios”.

La encuesta C-Suite Tech Survey de IDC refuerza esta idea: más de la mitad de los CIO y CTO sitúan la IA y la automatización como su principal objetivo de negocio.

Para responder a esta presión, los CIO deben evolucionar desde la experimentación hacia despliegues a escala.

“Se trata de un esfuerzo más deliberado, en el que vinculamos las iniciativas de IA a resultados empresariales”, señala Saroff, para apostillar: “El salto de los pilotos a producción ha resultado ser más difícil de lo que se esperaba”.

Entre los obstáculos destacan la calidad de los datos, la deuda técnica, los sistemas heredados y las restricciones presupuestarias. A ello se suma, en algunos casos, la dificultad histórica de TI para posicionarse como socio estratégico del negocio.

Una oportunidad histórica para el CIO

A pesar de los retos, el contexto también abre una ventana de oportunidad. Según Gartner, la tecnología se ha convertido en una de las tres prioridades estratégicas de los CEO, solo por detrás del crecimiento y las finanzas.

En opinión de Carter, “cuando hablamos de prioridad tecnológica, los CEO están hablando específicamente de IA”.

No obstante, la percepción sigue siendo que TI aún no está desplegando iniciativas verdaderamente transformadoras. En parte, esto se debe a que muchos CEO siguen asociando la IA principalmente a la eficiencia operativa: casi todos la utilizan para ahorrar tiempo, pero sólo un 2% la aplica a procesos que impulsan el crecimiento, como la toma de decisiones.

En este contexto, el CIO tiene la oportunidad de liderar el cambio.

En opinión de Carter, “los CIO deben apostar por tecnologías que impulsen iniciativas de alto impacto. Tienen la responsabilidad de mostrar lo que la tecnología puede hacer. Estamos ante la mayor ola de oportunidades que ha visto esta función”.

Algunos líderes tecnológicos ya están avanzando en esa dirección.

Viswanathan tiene claro que “hay CIO que entienden que la IA no es un fin en sí mismo. Se preguntan cómo puede generar valor en áreas como la experiencia de cliente, la cadena de suministro o el rediseño de productos”.

Seguridad y resiliencia: prioridades ineludibles

Junto a la IA, la ciberseguridad continúa siendo un eje central en la agenda de los CEO. De hecho, mejorar la seguridad de TI y los datos es la segunda prioridad más citada en el estudio.

Ajay Sabhlok, CIO y CDO de Rubrik, ilustra esta realidad: «El objetivo es eliminar cuellos de botella operativos y mejorar la eficiencia en todos los procesos».

Para lograrlo, su organización está adoptando una estrategia centrada en IA en ámbitos como ingeniería, FinOps, DevOps o soporte.

«Debemos adoptar una mentalidad de IA en todos los procesos de TI», afirma Sabhlok.

Además, la compañía está reforzando su postura de seguridad mediante la gestión activa de riesgos y la integración de la seguridad en toda la infraestructura.

«Los CEO están priorizando una base sólida de confianza, resiliencia y seguridad», subraya Paul Leinwand, director de estrategia en PwC. «La adopción de IA aumenta la importancia de la gobernanza del dato y la gestión del riesgo».

Más allá de la IA: nuevas palancas estratégicas

Aunque la inteligencia artificial domina la agenda, otras tecnologías emergentes, como la computación cuántica, empiezan a ganar peso en sectores como banca, ciencias de la vida o logística.

Viswanathan es de los que cree que “los CEO buscan entender qué oportunidades puede ofrecer la computación cuántica”.

Al mismo tiempo, demandan a TI avanzar en modernización y eficiencia para liberar recursos que permitan financiar estas nuevas apuestas.

Completan el top de prioridades la mejora de la colaboración entre TI y negocio, la experiencia de cliente y la transformación digital.

Por su parte, Leinwand sostiene que “los CEO quieren que TI conecte datos, flujos de trabajo y decisiones en toda la organización, no en silos”.

El CIO, medido por resultados de negocio

Todo ello está redefiniendo los criterios de éxito del CIO. Según IDC, la generación de ingresos ha pasado en apenas un año del sexto al tercer puesto entre los indicadores clave.

“Cada vez más CIO están siendo evaluados por resultados empresariales, y no sólo por eficiencia operativa”, dice Saroff para concluir.

Un cambio profundo que confirma que el papel del CIO ha dejado de ser técnico para convertirse en claramente estratégico.

Your most-used artificial intelligence feature may be your least profitable corporate asset.

That contradiction does not appear at launch. Early signals almost always point to operational success. Usage increases, user engagement climbs and internal product dashboards trend in the right direction. Your teams report efficiency gains, and executive leadership sees widespread adoption across the business.

Then the cloud computing invoice arrives.

What looked like a scalable feature begins to show a completely different economic reality. The cost required to operate the system grows directly with usage, and in some cases, it grows faster than the actual value it creates. Finance sees rapidly rising, unpredictable spend. Engineering sees strong adoption and feature validation. Both departments are correct, and that is the exact problem threatening enterprise margins today.

Artificial intelligence does not scale like traditional software. It behaves more like labor. Every single interaction has a discrete cost.

Why traditional software margins are collapsing

For the last two decades, software economics followed a simple, highly predictable model. You build the architecture once, and you scale it cheaply. Once the core infrastructure was in place, each additional user added minimal marginal cost to the operation. Growth guaranteed improved profit margins.

Generative AI fundamentally changes that equation.

Each interaction triggers variable compute, and that compute has a premium price tag. This creates a direct, unyielding relationship between usage and cost at the feature level. Scaling your user base no longer guarantees improved margins.

Research from Andreessen Horowitz highlights that AI-native companies operate under vastly different margin structures than traditional SaaS businesses. Compute is no longer a background expense hidden in the IT budget. It is a primary driver of corporate profitability and must be managed as a direct cost of goods sold.

The danger of unmanaged feature success

In a recent advisory engagement, I reviewed a document-processing workflow used by a back-office operations team to extract critical data from complex invoices and vendor contracts.

The system worked incredibly well. It handled inconsistent formatting effortlessly, reduced manual data entry work and improved document turnaround time. Adoption spread quickly across multiple internal teams.

Operationally, the deployment was a success. From a margin perspective, it was completely unsustainable.

Every single request was handled the exact same way, regardless of the underlying complexity. Simple tasks and complex tasks incurred the same premium cost. As usage increased naturally, total cloud spend accelerated rapidly. The most engaged, loyal users became the most expensive cohort to support.

The system delivered the expected results, but it operated at the wrong cost structure for the business.

Why excess capability drives unnecessary cost

Most engineering teams default to using the most capable frontier systems available on the market. This reduces frustrating edge cases, ensures high-quality outputs and simplifies the overall development process.

In traditional software engineering, that decision carries very little operational downside. With generative AI, it carries a financial penalty.

Using high-cost capability for low-complexity work creates inefficiency. You are paying a premium for cognitive performance you simply do not need, and you are paying that premium repeatedly on every single API call.

Analysis from Sequoia Capital points to a rapidly growing gap between global AI infrastructure costs and the actual revenue value generated at the application layer. A key driver of this economic imbalance is the misalignment between task complexity and system usage.

Organizations are vastly overpaying for routine, administrative work. At scale, this is not just an IT budget issue. It becomes a board-level margin problem.

The false promise of hardware deflation

When confronted with these escalating costs, many technology leaders assume that hardware advancements will naturally solve the problem. They believe that if they simply wait, the cost of compute will drop dramatically, and their margins will automatically correct themselves over the next few quarters.

This is a dangerous economic assumption. While base infrastructure costs may decrease eventually, enterprise usage and token consumption are increasing at a much faster rate. Users are demanding larger context windows, faster response times and more complex reasoning steps. You cannot wait for hardware deflation to fix a flawed software architecture. You must fix the unit economics today.

Why leadership cannot see the margin bleed

This issue is difficult to manage because it is not immediately visible to the executives responsible for the budget.

The FinOps Foundation reports that most organizations lack visibility into where AI costs are actually incurred at the feature level. Cloud spend is tracked in aggregate, not where the strategic product decisions are actually made.

Without granular financial detail, it is impossible to determine whether a feature is economically viable. By the time the answer becomes clear during a quarterly financial review, the system is already deeply embedded in critical business operations.

Aligning task complexity with compute spend

AI systems require an entirely different management discipline. They are not static software components. They are dynamic, variable cost systems.

The necessary operational shift is straightforward: not every task should incur the same computational cost.

Many enterprise workflows are highly predictable and perfectly repeatable. They do not require advanced reasoning or deep synthesis. Treating them as if they do creates unnecessary expense. More complex tasks can absolutely justify a higher cost, but those architectural decisions should be deliberate and mathematically modeled.

Why no one owns the variable cost

This is not just a technical architecture issue. It is a severe governance issue.

When AI features are deployed without strict cost constraints, organizations introduce open-ended variable cost into their core systems. This creates immediate cross-functional tension: engineering optimizes for raw capability, finance sees rising and unpredictable spend, and leadership lacks the visibility required to make informed trade-offs.

Without absolute alignment across these departments, costs will naturally drift upward.

The bottom line

Usage alone is no longer a reliable measure of product success.

You need to understand exactly what a feature costs to operate, how that cost scales alongside user adoption, and whether that usage actively creates or destroys enterprise value. In this new economic model, your most successful software feature can be your least profitable corporate asset.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

거의 모든 CIO에게 AI 도입은 최우선 과제로 자리 잡았다. CEO가 직접 내려보낸 핵심 지시사항이다.

CIO.com의 ‘2026년 CIO 현황 조사’에 따르면, CEO들은 CIO의 최우선 과제로 AI 연구와 도입을 꼽았다. 이러한 결과는 다른 여러 조사와도 일치하며, AI 구현을 IT 부문의 최우선 과제로 지목했던 2025년 조사와도 같은 흐름을 보인다.

다만 CEO들의 기대는 한층 높아졌다. 더 이상 AI 실험이나 개념검증(PoC)에는 관심이 없으며, 정량적으로 측정 가능한 가치를 창출하는 AI 프로젝트를 요구하고 있다. 일부 전략적 CEO들은 여기서 한 걸음 더 나아가, 조직의 운영 방식과 제품·서비스 자체를 AI로 재편하려는 움직임을 보이고 있다. 또한 CIO가 단순히 실행에 협력하는 수준을 넘어, 이러한 기회를 주도적으로 발굴하고 창출하길 기대하고 있다.

타타컨설턴시서비스의 비즈니스 혁신 총괄 샨키 비스와나탄은 “CEO들은 CIO가 AI의 진정한 가치를 어떻게 끌어낼지에 대해 주도적으로 나서길 원한다”라며 “단순한 생산성 향상을 넘어 새로운 가치 제안으로 전환해야 한다”고 말했다. 이어 “CIO가 AI를 실제 비즈니스에 어떻게 활용할 수 있는지를 보여줄 수 있는 중요한 기회”라고 덧붙였다.

하지만 이러한 요구는 결코 쉽지 않은 과제다. 많은 CIO와 경영진이 아직 이를 충분히 이행하지 못하고 있는 것이 현실이다.

가트너의 CIO 및 경영진 리더십 부문 수석 애널리스트 제니퍼 카터는 “여전히 많은 CIO가 AI를 통해 기업 전반을 획기적으로 개선할 수 있는 활용 사례를 찾는 데 어려움을 겪고 있다”라며 “업무 흐름과 프로세스, 문제 지점을 파악하고 이를 AI로 어떻게 재설계할지 정의하는 데도 어려움을 겪고 있다”고 설명했다.

이어 “가능성은 무한하지만, CEO들은 ‘이걸로 무엇을 할 수 있는가’를 묻고 있는 상황에서 많은 CIO가 아직 AI의 전체 잠재력을 이해하는 단계에 머물러 있다”고 덧붙였다.

CEO가 AI에 기대하는 것

AI를 통해 성과를 창출하라는 CEO의 요구는 올해 새롭게 등장한 것은 아니다. 2022년 11월 챗GPT 출시 이후 생성형 AI가 기업 환경에 본격적으로 확산되면서, 이는 이미 많은 조직에서 핵심 전략 과제로 자리 잡아 왔다.

다만 올해 들어 달라진 점은, CIO에게 AI 투자에 대한 가시적인 투자 대비 수익(ROI)을 요구하는 목소리가 한층 커졌다는 것이다. 실제로 ‘2026년 CIO 현황 조사’에서 CEO들은 ‘AI 정책 수립과 ROI 지표 구축’을 CIO의 10대 핵심 과제 중 하나로 꼽았다.

타타컨설턴시서비스의 비스와나탄은 “CEO들은 AI에 투입된 비용이 성과보다 훨씬 크다는 점에 점점 더 불만을 느끼고 있다”라며 “일부 생산성 향상 효과는 있지만, 여전히 단편적인 수준에 머물러 있다”고 말했다.

수년간 AI에 투자해 온 CEO들은 이제 AI를 통해 실제 매출을 끌어올려야 한다는 긴박감을 느끼고 있다. 이러한 요구는 매출 성장 목표 달성 지원과 혁신 주도 등 다른 IT 우선 과제와도 맞닿아 있다.

IDC의 엔드유저 리서치 및 컨설팅 부문 그룹 부사장 다니엘 사로프는 “CEO들은 IT가 단순한 생산성 향상을 넘어, AI를 통해 매출 성장을 이끌어내길 요구하고 있다”고 말했다.

IDC의 C-레벨 기술 조사에 따르면, 전 세계 CIO와 CTO의 절반 이상이 AI와 자동화를 최우선 비즈니스 목표로 꼽았다.

사로프는 “기업들은 경쟁 방식, 제품 개발 방식, 고객 서비스 제공 방식을 바꾸지 않으면 안 되는 압박을 받고 있다”고 설명했다.

이러한 요구에 대응하기 위해 CIO는 기존의 실험 중심 접근에서 벗어나, 대규모로 적용 가능한 AI 이니셔티브를 설계해야 한다.

사로프는 “AI 프로젝트를 명확한 비즈니스 성과와 연결하는 보다 체계적인 접근이 필요하다”라며 “많은 조직이 실험과 파일럿 단계에서 실제 운영 환경으로 넘어가 측정 가능한 가치를 창출하는 데 어려움을 겪고 있다”고 말했다. 이어 “이 전환 과정은 예상보다 훨씬 어렵다”고 덧붙였다.

이 같은 어려움에는 여러 요인이 작용한다. AI의 기반이 되는 데이터 품질 문제가 대표적이며, 기술 부채와 레거시 환경 역시 혁신 속도를 늦추고 비용을 증가시키는 요인으로 지목된다. 여기에 예산 압박까지 더해지면서 상황은 더욱 복잡해지고 있다.

또한 일부 조직에서는 IT가 여전히 비즈니스 전략 파트너로 자리 잡지 못한 점도 문제로 꼽힌다.

CIO에게 열린 기회

가트너 조사에 따르면 CEO들이 IT에 기대하는 방향에서도 유사한 흐름이 나타난다. 기술은 CEO의 3대 전략 우선순위 중 하나로, 1위인 성장과 2위인 재무(비용 관리 등)에 이어 세 번째로 중요한 요소로 꼽힌다.

가트너의 제니퍼 카터 수석 애널리스트는 “CEO들이 기술을 우선순위로 둔다고 할 때, 실제로는 AI를 의미하는 경우가 많다”고 설명했다.

카터는 다만 아직까지 IT 조직이 혁신적인 AI 성과를 충분히 보여주지 못하고 있다고 지적했다. 그 원인 중 일부는 CEO에게도 있다고 봤다. 여전히 AI를 생산성 향상이나 효율화 관점에서 바라보는 경향이 강하다는 것이다. 실제로 대부분의 CEO가 시간을 절약하는 용도로 AI를 활용하는 반면, 의사결정 지원처럼 성장으로 이어지는 영역에 활용하는 비율은 2%에 불과하다는 조사 결과도 있다.

카터는 이러한 상황이 CIO에게 기회가 될 수 있다고 강조했다. AI를 통해 조직의 운영 방식과 생산 구조를 근본적으로 재편할 수 있는 영역을 찾아낸다면, CIO가 기업 경쟁력 강화의 핵심 역할을 맡을 수 있다는 설명이다.

카터는 “CIO는 영향력과 주목도가 높은 전략적 기술 스토리를 적극적으로 강화해야 한다”라며 “기술 리더로서 해당 기술이 무엇을 할 수 있는지 조직 전반에 알리고, 필요한 기술 이해도를 구축할 책임이 있다”고 말했다. 이어 “지금은 CIO 역할 역사상 가장 큰 기회의 물결 속에 있다는 점을 인식해야 한다”고 덧붙였다.

타타컨설턴시서비스의 샨키 비스와나탄 역시 일부 CIO가 이러한 역할을 실제로 수행하고 있다고 평가했다.

비스와나탄은 “AI를 단순한 목적이 아닌 수단으로 이해하고, 그 안에서 기회를 발굴하는 기술 리더들이 있다”라며 “이들은 ‘AI가 과거 해결하지 못했던 고객 대응 방식이나 공급망 관리, 제품 설계 영역에서 새로운 가치를 만들어낼 수 있는가’라는 질문을 던지고, 그 해답을 AI 중심으로 찾고 있다”고 말했다.

기업 보안 강화도 핵심 과제

데이터 보호와 사이버 복구 기업 루브릭의 CIO 겸 최고데이터책임자(CDO) 아제이 사블록에게 내려진 기업 전략 역시 이러한 흐름을 반영하고 있다.

사블록은 “CEO의 목표는 비즈니스 운영의 병목을 줄이고 제거하는 것”이라며 “IT에 부여된 목표는 전사 업무 전반에서 효율성과 생산성을 높이는 것”이라고 말했다.

이에 따라 IT 조직은 스스로를 ‘AI 우선 조직’으로 전환하고 있다. 사블록은 “모든 IT 프로세스와 개인 생산성 향상에 AI 중심 사고를 적용해 자원 최적화를 달성하는 것이 목표”라고 설명했다.

사블록은 엔지니어링, 아키텍처, 핀옵스(FinOps), 비즈니스 셀프서비스, 데브옵스(DevOps), 사용자 지원 등 전 영역에 AI 기반 프로세스를 도입하고 있다. 그는 “핵심 AI 플랫폼을 구축하고, 복잡한 활용 사례에 대해서는 IT의 AI 엔지니어링 조직과 협력해 사용자들이 이를 효과적으로 활용할 수 있도록 지원하고 있다”고 덧붙였다.

또 다른 핵심 과제는 보안 강화다. 사블록은 “모든 식별된 위험과 취약점을 효율적으로 해결하고, 데이터센터와 클라우드, 네트워크 전반의 인프라를 보안 중심으로 재설계하고 있다”고 말했다.

실제로 많은 CEO가 같은 우선순위를 공유하고 있다. ‘2026년 CIO 현황 조사’에서도 IT 및 데이터 보안 강화는 기업 리스크를 줄이기 위한 두 번째 주요 과제로 꼽혔다. 데이터 유출이나 사이버 공격이 가져올 재무적·법적·평판 리스크를 고려하면, 사이버보안이 CEO의 핵심 관심사로 부상한 것은 자연스러운 흐름이다.

PwC의 기업 및 기능 전략 부문 책임자 폴 레인완드는 “AI 도입이 확대되면서 데이터 무결성과 거버넌스, 리스크 관리의 중요성이 더욱 커지고 있다”라며 “CEO들은 신뢰와 회복력, 보안을 핵심 기반으로 삼고 있다”고 말했다.

비스와나탄 역시 사이버보안이 여전히 CEO의 최우선 과제 중 하나로 자리 잡고 있다고 강조했다.

AI·보안 넘어선 추가 우선순위

AI와 보안 외에도 양자컴퓨팅과 같은 차세대 기술이 일부 CEO의 주요 관심사로 떠오르고 있다. 특히 금융, 생명과학, 물류 산업에서는 이미 양자컴퓨팅이 영향을 미치기 시작하면서 관련 논의가 활발해지고 있다.

타타컨설턴시서비스의 샨키 비스와나탄은 “이들 산업의 CEO들은 양자컴퓨팅이 가져올 잠재적 기회에 대해 IT 조직이 적극적으로 설명해주길 기대하고 있다”고 말했다.

또한 그는 CEO들이 CIO에게 최적화와 현대화를 우선 과제로 요구하고 있다고 설명했다. 이를 통해 절감된 비용을 신기술 투자로 전환할 수 있기 때문이다.

‘2026년 CIO 현황 조사’에서 나타난 IT 관련 CEO의 상위 5대 과제를 보면, IT와 비즈니스 간 협업 강화, 고객 경험 개선, 디지털 비즈니스 및 디지털 전환 주도 등이 포함된다.

PwC의 폴 레인완드는 이러한 흐름이 현장에서 확인되는 것과 일치한다고 말했다.

레인완드는 “CEO들은 IT가 부서별로 분절된 방식이 아니라, 데이터와 워크플로, 의사결정을 조직 전반에 연결해 운영 모델을 전사적으로 혁신하길 원한다”라며 “파일럿 수준이 아닌 핵심 운영 프로세스에 실제로 적용하는 것이 중요하다”고 강조했다.

그는 이러한 요구의 배경으로 기업 경쟁 방식의 근본적인 변화와 지속 가능한 성장 확보의 어려움을 꼽았다.

이어 “CEO들은 기술이 고객 참여 확대, 인사이트 고도화, 보다 명확한 혁신 전략 수립을 지원하고, 나아가 새로운 수익 창출 채널을 여는 핵심 수단이 되길 기대하고 있다”고 덧붙였다.

IDC의 다니엘 사로프에 따르면, CIO에 대한 평가는 점점 이러한 기대를 실제로 얼마나 실현하는지에 초점이 맞춰지고 있다. IDC 데이터에 따르면, CIO 성과 지표에서 ‘매출 창출’은 단 1년 만에 6위에서 3위로 상승했다.

사로프는 “일부 CIO는 이제 단순 운영 성과가 아니라 비즈니스 성과를 기준으로 평가받고 있거나, 스스로를 그렇게 평가하기 시작했다”고 말했다.
dl-ciokorea@foundryco.com

For nearly every CIO, implementing AI is their No. 1 task — that’s the directive they’re getting from the corner office.

CEOs have pegged researching and implementing AI at the top of their priority lists for their CIOs, according to CIO.com’s 2026 State of the CIO Survey. That finding mirrors the results in multiple other surveys and echoes CIO.com’s 2025 survey, which also found AI implementations as the top CEO priority for IT.

CEOs, however, have indicated that they’re no longer interested in AI experiments and proofs of concepts. They’re looking for AI initiatives that deliver quantifiable value. The most strategic CEOs are going further, seeking to leverage AI in transforming how their organizations work and what products and services they offer. And they expect their CIOs to create those opportunities and not merely collaborate on seizing them.

“CEOs want CIOs to stand up and lead on how to unlock the real value of AI, to shift from productivity gains to different value propositions,” says Shanky Viswanathan, head of business innovation at Tata Consultancy Services. “There’s a real opportunity for CIOs to show how AI can be used in the business.”

That, though, is a tall order — one that many CIOs and C-suites more broadly aren’t yet fulfilling.

“A lot of CIOs still struggle with identifying use cases across the enterprise where AI can make them so much better, and they still struggle with identifying the workstreams and processes and the pain points and how they can reinvent how the organization operates with AI,” says Jennifer Carter, a senior principal analyst in the CIO and executive leadership practice at research firm Gartner.

She adds: “There are limitless possibilities, but many CIOs are caught doing some catch-up in understanding the full potential of AI even as CEOs are looking at them and asking, ‘What can we do with this?’”

What CEOs want from AI

The CEO mandate to capitalize on AI is not new this year. It has been a high-level goal at many organizations since generative AI muscled its way into the enterprise with the November 2022 release of ChatGPT.

What’s relatively new this year is the CEO requirement for CIOs to deliver tangible ROI for the organization’s AI investments. In fact, CEOs listed “establish AI policies and ROI metrics” as a top 10 priority for CIOs this year, according to the State of the CIO Survey.

Viswanathan says CEOs have become frustrated that “the amount of money they spend on AI is far, far bigger than the returns. Yes, they’re getting some productivity gains. but it’s been quite fragmented.”

Now, after years of AI investments, CEOs have a sense of urgency to use AI to drive revenue, he and others assert. That directive aligns with other CEO priorities for IT identified in the State of the CIO survey, including help in reaching revenue growth targets and leading innovation, at No. 6 and 7 respectively.

Daniel Saroff, group vice president of end-user research and consulting at IDC, says his firm’s research also shows chief executives pushing IT to use AI not just for productivity gains but to drive revenue growth.

IDC’s C-Suite Tech Survey found over half of CIOs and CTOs globally cite AI and automation as their primary business objective.

“Organizations are under real pressure to change how they compete, how they develop products, and how they deliver services to customers,” Saroff says.

To deliver on that priority, CIOs need to move beyond the experimentation they have been doing and instead design initiatives that can be implementated at scale.

“It’s a more deliberate effort where we link [AI initiatives] to business outcomes,” he says. Organizations “have struggled getting from experimentation and pilots to something that actually runs in production and delivers measurable value. The transition turns out to be harder than it initially looked.”

There are various reasons for those struggles, Saroff says. Problems with the data that fuels AI is one. Technical debt and legacy environments also slow innovation and make it more expensive than anticipated. Budget pressures compound the challenges.

Additionally, he says, IT still struggles to be a business strategy partner in some organizations.

Opportunities for the CIO

Gartner research has identified similar trends in what chief executives want from IT, with technology being a top 3 strategy priority for CEOs, coming in just behind growth at No. 1 and finance (e.g., expense management) at No. 2.

“When we say they’re prioritizing technology, we find according to CEOs it’s about AI,” Carter says.

Carter, like others, says CEOs aren’t yet seeing IT deliver transformative AI initiatives. She puts some of that on CEOs, though, saying that they still think about AI in terms of productivity gains and optimization. She points to research showing that nearly all CEOs use AI to save time while only 2% are using AI for tasks, such as decision support, that drive growth.

This creates an opportunity for CIOs, Carter says. By identifying where AI can remake how the organization operates and what it produces, CIOs will help their CEOs win in the market.

“CIOs should double down on the story of the technology that will fuel high-impact, high-spotlight initiatives,” she says. “As tech execs, they have the responsibility to raise awareness on what the technology will do and to build the needed tech literacy. It’s important for CIOs to remember that they’re in the biggest wave of opportunity the role has ever seen.”

Some CIOs are, indeed, delivering on this, Viswanathan says.

“There are some tech leaders who show how AI is not a means unto itself, and they’re able to unravel the opportunities,” he says. “They’re asking, ‘Can AI unlock value for me in areas where I struggled in the past, like responding to customer demands in a different way, or rethinking how supply chain management can happen, in reimagining products?’ These technology leaders are responding to those questions with AI front and center.”

Securing the enterprise

The corporate priorities handed down to Ajay Sabhlok, CIO and CDO at tech company Rubrik, reflect the findings from CIO.com’s State of the CIO Survey.

“Our CEO’s goal is to reduce and eliminate the business operations bottleneck,” Sabhlok says. And the CEO’s goal for IT is “to help Rubrik gain efficiency and productivity across all business processes.”

IT took that message to heart, says Sabhlok, explaining that the IT team itself is the first “to pivot over to an AI first organization. The pivot means that we must adopt an AI mindset in all of our IT processes and personal productivity improvement, with the goal of achieving resource optimization.”

Like some CIOs who are bringing AI to IT, Sabhlok is establishing AI-powered processes across engineering, architecture, FinOps, business self-service, DevOps, and user support. “That includes rolling out core AI platforms and enabling users to use them effectively in partnership with IT AI engineering for complex use cases,” he adds.

Another key CEO objective for Sabhlock is strengthening Rubrik’s security posture, something he’s doing in part by ensuring “efficient resolution of all identified risks and vulnerabilities” and transforming the “infrastructure across data center, cloud, and network with embedded security.”

Many CEOs share that agenda, as the State of the CIO Survey’s No. 2 CEO priority for IT is upgrading IT and data security to reduce corporate risk. CIOs, IT advisers, and other researchers aren’t surprised that cybersecurity is so high on CEOs’ lists, given the financial, legal, and reputational risk associated with a data breach or cyber incident.

“CEOs are prioritizing a strong foundation of trust, resilience, and security, especially as AI adoption increases the importance of data integrity, governance, and risk management,” says Paul Leinwand, principal of enterprise and functional strategy at PwC US.

Viswanathan likewise has seen cybersecurity remain a top priority for CEOs.

Priorities beyond AI and security

Next-wave innovations such as quantum computing are also making appearances on some CEO priority lists, particularly among chief executives in banking, life sciences, and logistics — industries where quantum computing is already making an impact, Viswanathan says. “Those CEOs are looking for IT to talk about the potential opportunities with quantum,” he notes.

And he sees CEOs asking CIOs to prioritize optimization and modernization “because that gives them a significant opportunity to funnel [savings from those moves] into emerging tech.”

Rounding out the top five CEO priorities for IT from the State of the CIO Survey are strengthening IT and business collaboration; improving customer experience, and leading digital business/digital transformation initiatives.

Leinwand says those mirror what he’s seeing.

“[CEOs] want IT to enable enterprisewide transformation of the operating model by connecting data, workflows, and decision-making across the organization rather than operating in functional silos — and doing this in core operations and processes, not just running pilots,” he says.

A fundamental shift in how companies compete is what is driving these CEO priorities, as are the challenges that CEOs face in generating sustainable growth, he notes.

“CEOs are expecting technology to be a big enabler of expanding customer engagement, better insight development, clearer innovation programs, and to open up new revenue-creating channels through technology,” Leinwand adds.

CIOs are increasingly judged in their ability to deliver on all this, according to IDC’s Saroff. He points to IDC data showing that in just one year revenue generation jumped from sixth to third place as a top CIO success metric.

“So some CIOs are starting to be measured — or measure themselves — on business outcomes rather than just operational performance,” he adds.

IT budgeting has gotten a lot trickier as vendors begin to adjust their pricing to include variable charges for agentic AI usage in addition to seat-based licensing fees.

A case in point is the licensing model for ServiceNow, which has introduced usage-based pricing for its AI components. As part of its AI transformation, the company last week announced Action Fabric, part of its AI Control Tower, which meters agent usage measured in “assists” and charges for it on top of customers’ subscription fees.

Customers receive a set number of assists with their subscription and can choose to pay for more if they need them, said ServiceNow COO Amit Zavery.

The number of assists used in any given agentic interaction varies, however, making it difficult for users to predict their usage, and therefore their bills.

This model is no surprise to industry watchers. “As AI agents begin to move into the heart of the enterprise, we’re moving beyond the age of SaaS into a far more granular era where every last detail of a given workload is monitored, metered, and monetized,” said Carmi Levy, independent technology analyst.

This may not sit well with organizations. “For CIOs and other senior leaders making the strategic decisions and approving the budget, the prospect of paying additional usage-based fees on top of existing subscriptions, and then having to closely monitor usage and spend as AI adoption spreads across the organization, could be an additional irritant as organizations as a whole look for ways to trim spending,” he said. 

ServiceNow’s model is similar to those introduced by SAP and Salesforce, said Info-Tech Research Group advisory fellow Scott Bickley: a base license with entitlement to some level of usage, then consumption-based charging at the data layer and at the AI layer. “With ServiceNow, they’re going to now break out levels of AI capabilities, and each tier will encompass a certain level of functionality, and they each have different levels of capabilities attached to them, and I’m sure different pricing attached to them.”

This will not make CFOs happy, he said; they don’t like variability in pricing, nor unpredictable expenses in the monthly budget. And there’s the potential for things to go expensively wrong if, for example, an autonomous agent goes into a retry loop when its first attempt to perform a task fails, gobbling assist credits with each iteration.

Adoption of the service, he said, will depend on “the ability to decipher the pricing model and match it to business use cases, so that you can accurately predict usage based on what you want to accomplish as an outcome.” If enterprises can’t predict costs and maintain budget versus value over time, they won’t stick with it, he said.

This means that customers now need to pay particular attention to their contracts and find that “line of demarcation where the meter starts running,” Bickley said, noting that historically, ServiceNow’s licensing metrics have lacked clarity on what falls under eligible objects or how things are metered.

“If you can’t manage and predict and build the capabilities to see through what these consumption metrics are going to cost you, then you need to have very flexible contract commercial terms that can help buffer the unanticipated upticks in usage,” he said. “But you really need to have a combination of FinOps maturity, the ability to build clarity in your use cases for AI, the ability to then estimate consumption against those use cases, and a very detailed understanding of the license or subscription metrics.”

Now it has become imperative for customers to take the time to extract those details from ServiceNow, appending them to the contract in a way that’s understandable, he advised. “And if you can’t get them to that point, then you should not be signing the contract.”

Bickley said he feels some sympathy for ServiceNow: “They’re dealing with a moving target themselves. They have to pay for this consumption to the LLM providers as well, but they need to do better in terms of simplifying it for their customers.”

Optimizing artificial intelligence pipelines requires moving beyond surface-level hardware adjustments to fundamentally alter how models process data. While engineers often implement basic toggle-away efficiencies inside the training loop, achieving permanent cost reductions requires architectural changes directly inside the neural network. As I have previously argued, the science is solved, but the engineering is broken; true FinOps maturity demands deep, model-level interventions. The following 12 architectural cuts will drastically lower the unit economics of your AI pipeline.

Redesigning the training foundation

1. Fine-tune, don’t train from scratch

Training a foundation model from scratch is computationally prohibitive and rarely necessary for standard enterprise applications. Instead of burning millions of dollars on raw compute, engineering teams should download highly capable, publicly available open-weight models. This baseline transfer learning approach is the mandatory first step when building internal corporate chatbots or domain-specific classifiers. Leveraging existing neural architectures instantly bypasses the massive energy and financial costs associated with initial pre-training phases.

2. Parameter-efficient fine-tuning (LoRA)

Even standard fine-tuning of a massive language model requires immense VRAM to store optimizer states and gradients. To solve this hardware bottleneck, engineers must implement parameter-efficient fine-tuning (PEFT) techniques like low-rank adaptation (LoRA). By freezing 99 percent of the pre-trained weights and injecting incredibly small trainable adapter layers, LoRA drastically reduces memory overhead. This mathematical shortcut is ideal for deploying highly customized generative AI features, allowing teams to fine-tune billions of parameters on a single consumer-grade GPU.

python
from peft import LoraConfig, get_peft_model

config = LoraConfig(r=8, lora_alpha=32, target_modules=["q_proj", "v_proj"])
efficient_model = get_peft_model(base_model, config)

3. Warm-start embeddings/layers

When you must train specific network components from scratch, importing pre-trained embeddings ensures that only the remaining layers require heavy computational lifting. This warm-start approach slashes early-epoch compute because the model does not have to relearn basic, universal data representations. It should be used immediately in specialized domains, similar to how healthcare startups leverage AI to bridge the health literacy gap using pre-existing medical vocabularies.

python
# PyTorch warm-start example
model.embedding_layer.weight.data.copy_(pretrained_medical_embeddings)
model.embedding_layer.requires_grad = False

Memory optimization and execution speed

4. Gradient checkpointing

Memory constraints are the primary reason engineers are forced to rent expensive, high-VRAM cloud instances. Introduced by Chen et al., gradient checkpointing saves memory by recomputing certain forward activations during backpropagation rather than storing them all. Engineers should deploy this technique when facing persistent out-of-memory errors, as it allows networks that are 10 times larger to fit on the same GPU at the cost of approximately 20 percent extra compute time.

python
# Enable in Hugging Face / PyTorch
model.gradient_checkpointing_enable()

5. Compiler and kernel fusion

Modern deep learning frameworks frequently suffer from memory bandwidth bottlenecks as data is constantly read and written across the hardware. Using graph-level compilers like XLA or PyTorch 2.0 fuses multiple operations into a single GPU kernel. This architectural optimization yields massive throughput improvements and faster execution speeds without requiring manual code changes. Engineers should enable compiler fusion by default on all production training runs to maximize hardware utilization.

python
import torch

# PyTorch 2.0 compiler fusion
optimized_model = torch.compile(model)

6. Pruning and quantization

Deploying a massive, fully precise 16-bit neural network into production often requires renting top-tier cloud instances that destroy an application’s profit margins. Applying algorithmic pruning removes mathematically redundant weights, while quantization compresses the remaining parameters from 16-bit floating points down to 8-bit or 4-bit integers. For instance, if a retail enterprise deploys a customer service chatbot, quantizing the model allows it to run on significantly cheaper, lower-memory GPUs without any noticeable drop in conversational quality. This physical reduction is critical for financially scaling high-traffic applications, directly lowering the carbon cost of an API call when serving thousands of concurrent users.

python
import torch
import torch.nn.utils.prune as prune

# 1. Prune 20% of the lowest-magnitude weights in a layer
prune.l1_unstructured(model.fc, name="weight", amount=0.2)

# 2. Dynamic Quantization (Compress Float32 to Int8)
quantized_model = torch.ao.quantization.quantize_dynamic(
    model, {torch.nn.Linear}, dtype=torch.qint8
)

Smarter learning dynamics

7. Curriculum learning

Feeding highly complex, noisy datasets into an untrained neural network forces the optimizer to thrash wildly, wasting expensive compute cycles trying to map chaotic gradients. Curriculum learning solves this by structuring the data pipeline to introduce clean, easily classifiable examples first before gradually scaling up to high-fidelity anomalies. For example, when training an autonomous driving vision model, engineers should initially feed it clear daytime highway images before spending compute on complex, snowy nighttime city intersections. This phased approach allows the network to map core mathematical features cheaply, reaching convergence much faster and with significantly less hardware burn.

8. Knowledge distillation

Deploying a massive 70-billion parameter model for simple, repetitive tasks is a severe misallocation of enterprise compute resources. Knowledge distillation resolves this by training a highly efficient, lightweight “student” model to strictly mimic the predictive reasoning of the massive “teacher” model. Imagine an e-commerce company needing to run real-time product recommendations directly on a user’s smartphone, where battery and memory are strictly limited. Distillation allows that tiny mobile model to perform with the accuracy of a massive cloud-based architecture, permanently cutting inference costs and avoiding the AI accuracy trap.

9. Bayesian optimization and hyperband

Standard grid search algorithms waste massive amounts of cloud budget by blindly testing and completing network configurations that are doomed from the start. Smarter hyperparameter search methods, like Bayesian optimization and Hyperband, act as a ruthless financial governor by mathematically predicting and pruning bad trials during the very first epochs. For instance, if a bank is tuning a fraud detection model, Hyperband will instantly kill configurations that show poor early accuracy, redirecting all compute power only to the most promising setups. To further bound these costs, teams can integrate my RES-Cost-Aware-Retraining-Framework, which is based on recent peer-reviewed IEEE research.

Infrastructure and data efficiency

10. Model vs. data-parallel right-sizing

Improper cluster configuration creates massive network bottlenecks. If you split a moderately sized model across too many GPUs (model parallelism), the processors will spend more time waiting for data to travel across the network cables than actually doing math. Conversely, replicating the entire model across nodes (data parallelism) is highly efficient for processing massive datasets, provided the batch sizes are tuned correctly. A real-world FinOps team must dynamically right-size these parallel strategies based on the specific architecture, ensuring GPUs are never left idling while the network catches up.

11. Asynchronous evaluation

Standard training pipelines constantly pause the primary, expensive GPU cluster just to run routine validation checks on the model’s progress. Stopping a massive hardware cluster for twenty minutes every epoch to calculate accuracy metrics is a catastrophic waste of hourly rental fees. By implementing asynchronous evaluation, engineers can offload these validation checks to a separate, much cheaper CPU or low-tier GPU instance. Keeping the primary high-cost GPUs 100 percent busy is a mandatory architectural separation that helps mitigate the hidden operational costs of AI governance.

12. Intelligent data sampling and selection

Blindly processing massive datasets forces the optimizer to waste expensive compute cycles on highly redundant, low-quality information. If a visual model has already seen ten thousand identical photos of a standard stop sign, processing the ten-thousand-and-first photo provides zero mathematical value. Using algorithmic sampling to curate an information-rich subset achieves the exact same model performance at a fraction of the hardware cost.

Conclusion

Implementing these 12 model-level deep cuts transitions your AI strategy from a brute-force hardware approach to an elegant, software-defined discipline. By combining efficient training loop configurations with the architectural redesigns outlined here, engineering teams can stop throwing expensive GPUs at poorly optimized networks. However, even the most optimized training code will fail if the surrounding enterprise infrastructure is fragile. True operational maturity requires scaling these localized efficiencies across robust deployment architectures, which you can begin building today using the implementation scripts in my open-source git repository.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Teradata has launched its Autonomous Knowledge Platform, a new flagship offering that brings together data, analytics, AI development, agent orchestration, and governance across cloud, on-premises, and hybrid environments.

The target customer is an enterprise that has moved beyond testing AI assistants and is now asking harder questions: which data agents can use, what actions they can take, how much they will cost to run, and who is accountable when something goes wrong.

The company said the platform builds on its existing database engine and governance infrastructure, while adding new capabilities and more tightly integrating existing ones, including AI Studio, the Tera natural-language workspace, Tera Agents, Elastic Compute on Teradata Cloud, and the upcoming Teradata Factory for on-premises AI workloads.

Teradata is entering a competitive market with this. Snowflake, Databricks, Microsoft, Oracle, and Salesforce are all trying to persuade customers that their platforms should become the operating layer for enterprise AI agents.

Strategic consolidation

Teradata is positioning the Autonomous Knowledge Platform as a product evolution rather than a simple rebranding of existing tools.

AI Studio is designed to help enterprises build and govern AI workflows, while Tera serves as a natural-language workspace. Tera Agents are intended to handle operational tasks such as sizing, tuning, provisioning, telemetry, and FinOps. The company is also adding Elastic Compute to Teradata Cloud and plans to offer Teradata Factory for on-premises AI workloads in regulated environments.

The launch brings together several capabilities under one broader platform, according to Greyhound Research’s chief analyst Sanchit Vir Gogia.

He described the platform as “a meaningful strategic consolidation rather than a clean-sheet invention,” pointing to Tera, prebuilt platform agents, Elastic Compute, and the company’s Global Identity framing as the most clearly new or newly emphasized pieces.

The harder problem for buyers, he said, is whether these systems can remain governed once agents begin operating continuously across enterprise environments.

Gogia said the prebuilt Tera Agents may be one of the more interesting parts of the launch because they focus on infrastructure operations rather than user-facing assistants. If they work as described, agents that manage sizing, tuning, compute, telemetry, and FinOps could help Teradata make the cost and efficiency case for the broader platform.

Addressing governance requirements

Governance is a key part of the pitch that Teradata would want enterprise buyers to notice. The company said autonomous agents require different controls from traditional analytics users because their activity can extend from repeated data queries to tool use and actions across enterprise systems.

Sumeet Arora, Teradata’s chief product officer, said every tool call made by an agent passes through Enterprise MCP, which Teradata describes as its governed context interface. The company said the system includes authentication, role-based and attribute-based access controls, schema validation, and a full audit trail.

Agents can invoke only the systems they are authorized to access, Arora said, while enterprises can configure human-in-the-loop approval workflows for actions they consider sensitive or high risk.

Teradata is also tying that governance model to its Connected Data Foundation, which it says allows data to be stored once and accessed consistently. The company said the architecture is designed to make interactions traceable across analytics, AI, and autonomous agents, supporting auditability and compliance.

That control layer could become increasingly important as enterprises move from AI assistants that generate recommendations to agents that act on business data.

“Enterprises are ready to put tightly scoped, policy-governed, high-value agents into production, but they are not ready for open-ended autonomy with vague permissions and fuzzy accountability,” Gogia said. “Bounded autonomy is a deliberate, governed expansion of what software can do without supervision. Open-ended autonomy is an aspiration in search of a control plane.”

Teradata said the Autonomous Knowledge Platform will be available on Teradata Cloud in Q3. Teradata Factory is expected to follow later this year, while Tera Claw, the company’s multi-agent orchestration mode, is scheduled to enter research preview by the end of the year. AI Studio and AI Services are available now.

A few years ago, enterprise cloud conversations followed a familiar pattern. Teams discussed migrating legacy applications, modernizing infrastructure and reducing data center costs. The goal was clear: Move workloads to scalable cloud platforms and gain operational flexibility.

But in recent months, the tone of these conversations has shifted dramatically.

In architecture reviews and infrastructure planning sessions I’ve participated in, the questions now sound very different:

• Where will the model training run?
• Do we have access to GPU clusters?
• Can our data pipelines support real-time inference?

The reason is simple: Artificial intelligence — particularly generative AI — is pushing enterprise infrastructure beyond what traditional cloud architectures were designed to handle. What many organizations are discovering is that the future isn’t just cloud-first. It’s AI-native.

When AI becomes the workload that breaks the cloud

In many organizations, the turning point arrives when a team attempts its first large-scale generative AI deployment.

A business unit might want to build a document intelligence system, an internal knowledge assistant or a predictive analytics platform powered by large language models. On paper, this looks like just another cloud workload. But implementation quickly reveals the difference.

AI workloads behave nothing like traditional enterprise applications. They require massive datasets, GPU-accelerated compute and high-throughput data pipelines capable of feeding machine learning models continuously. Infrastructure designed for transactional systems often struggles under these conditions.

I’ve seen teams discover this firsthand when their existing cloud environments suddenly become bottlenecks — not because of application traffic, but because of AI model training workloads. This is the moment many organizations realize: AI isn’t just another application in the cloud. It’s a new infrastructure paradigm.

In some cases, even well-architected microservices environments fail to keep up, exposing limitations in storage I/O, network latency and workload isolation. These hidden constraints often only surface under sustained AI workloads, making them difficult to predict during initial planning phases.

AI-native infrastructure: GPU clusters and high-performance compute

Traditional enterprise cloud environments were optimized for CPU-based workloads and transactional applications. AI systems, by contrast, prioritize GPU-accelerated compute, high-bandwidth networking, distributed storage and scalable training pipelines.

Tools like AMD ROCm highlight this shift toward GPU-native ecosystems, offering a full-stack platform designed specifically for high-performance AI workloads. But adopting GPU infrastructure is not just about provisioning capacity — it is about using it efficiently.

Many organizations underestimate the complexity of GPU scheduling, memory fragmentation and workload contention. Unlike CPU workloads, which can be easily distributed, GPU workloads require careful orchestration to avoid underutilization.

These platforms demonstrate that AI workloads are reshaping how cloud infrastructure is designed — from CPU-centric compute layers to AI-native architectures optimized for massive parallelism and high-throughput data processing.

Additionally, emerging innovations such as specialized AI accelerators and custom silicon are further complicating infrastructure decisions. Architects must now evaluate not just performance, but portability and vendor lock-in when selecting hardware strategies.

The rise of distributed AI across hybrid environments

Another pattern emerging in enterprise AI deployments is the move toward distributed infrastructure.

Early cloud adoption encouraged organizations to consolidate workloads within a single cloud provider. This simplified governance and reduced operational complexity.

But AI workloads often introduce new constraints. Certain datasets must remain within private infrastructure for compliance reasons. Training large models requires specialized GPU clusters available only in specific cloud regions. Real-time inference may need to run close to where data is generated. As a result, many enterprises are now operating hybrid and multi-cloud AI environments.

Platforms such as Google Cloud Vertex AI are explicitly designed for hybrid AI pipelines, enabling organizations to train and deploy models across on-premises systems and multiple cloud environments.

In these environments, AI is not confined to a single cloud environment. Instead, intelligence is distributed across infrastructure layers.

The challenge shifts from deploying applications to orchestrating AI systems across multiple environments.

This distribution also introduces new challenges around data consistency, model versioning and latency management. Ensuring that models behave consistently across environments becomes a critical requirement, particularly in regulated industries.

Intelligent orchestration is becoming essential

As AI infrastructure grows more complex, manual cloud management becomes increasingly impractical.

Modern enterprise environments can involve thousands of containers, distributed datasets and multiple compute clusters running across different cloud platforms.

To manage this complexity, organizations are beginning to rely on intelligent orchestration platforms. These systems use machine learning to monitor infrastructure usage, predict compute demand and dynamically allocate resources.

Frameworks like UCUP illustrate the next generation of orchestration — systems capable of coordinating multiple AI agents, monitoring performance and adapting execution strategies in real time. These platforms move beyond simple scheduling into intelligent decision-making layers.

Ironically, artificial intelligence is not only transforming enterprise workloads — it is also becoming the system that manages cloud infrastructure itself.

Over time, this may lead to largely autonomous infrastructure environments where human operators focus more on policy and oversight than direct system management.

The cost reality of enterprise AI

For all the innovation AI promises, the financial implications are impossible to ignore.

Large language models require enormous computational resources. GPU clusters are expensive and often scarce. Training a single model can consume substantial cloud budgets.

This has forced many organizations to rethink their financial approach to cloud computing.

Practices such as FinOps — which focus on managing and optimizing cloud spending — are becoming essential in AI-driven environments.

Teams are experimenting with strategies such as:

• Model optimization and compression
• Distributed training architectures
• Serverless inference models
• Workload scheduling across cost-efficient regions

In some cases, organizations are even reconsidering hybrid strategies that bring certain AI workloads back on-premises when economics favors private infrastructure.

AI innovation, it turns out, requires as much financial architecture as technical architecture.

FinOps teams are increasingly collaborating directly with data scientists and ML engineers, creating a new cross-functional discipline focused on balancing performance with cost efficiency.

The emergence of the AI-native enterprise cloud

Perhaps the most significant shift underway is conceptual.

For more than a decade, the cloud served primarily as infrastructure for hosting applications.

But AI is transforming the cloud into something far more powerful.

It is becoming a platform for machine intelligence.

Instead of simply running software, cloud environments are now supporting systems that learn from data, generate insights and automate decisions.

Forward-looking organizations are beginning to design their infrastructure with this reality in mind.

They are not just migrating workloads.

They are building AI-native cloud ecosystems designed to support data-driven intelligence at scale.

This also means embedding AI considerations into every layer of architecture — from data ingestion and storage to security, compliance and user experience.

The next chapter of enterprise cloud architecture

The first wave of cloud transformation focused on modernization.

The next wave is about enabling intelligent systems that augment human decision-making, automate operations and unlock entirely new digital capabilities.

That shift is forcing enterprise architects to rethink the foundations of cloud infrastructure — from compute architecture and data pipelines to orchestration and governance.

The organizations that adapt fastest will not simply run AI workloads in the cloud.

They will build cloud environments designed specifically for intelligence.

And in the process, they will define what the next generation of enterprise infrastructure looks like.

Those that fail to adapt, however, risk being constrained by legacy architectural assumptions that no longer align with the demands of AI-driven innovation.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Picture this. Thursday morning. The CFO’s assistant just sent you a calendar invite for Q3 AI Infrastructure Spend at 2:00 pm. No agenda. Just that number from last month’s cloud bill, 40 percent above forecast. You have five hours. Do you own the narrative, or does finance own it for you?

Those who escaped that conversation had a governance architecture in place before the bill arrived.

The training budget was the wrong number all along

Training is a project. Inference is a utility. When an AI agent is embedded in a workflow, it runs every time that workflow runs, around the clock, at scale, with no natural stopping point.

Inference workloads are set to overtake training revenue in 2026, with Deloitte Tech Trends 2026 estimating inference will account for two-thirds of all AI compute this year. Public cloud API pricing has fallen nearly 80 percent year over year, yet Gartner places AI spending at $2.52 trillion in 2026. A volume problem, not a unit cost problem. PwC’s 29th Global CEO Survey of 4,454 chief executives finds 56 percent report AI has produced neither increased revenue nor decreased costs; only 12 percent have achieved both. The differentiator is governance architecture, not model choice.

The triple convergence: 3 forces you cannot fight separately

The inference cost crisis would be manageable in isolation. What makes it genuinely difficult is that it arrives simultaneously with two other structural forces, each carrying its own financial and legal consequences.

Convergence #1: The agentic cost amplifier

The FinOps Foundation’s State of FinOps 2026 report, covering 1,192 organizations and $83 billion in cloud spend, finds AI workloads account for 18 percent of cloud spend at AI-forward enterprises, up from 4 percent in 2023. A three-hour recursive loop generates approximately $3,700 in unplanned compute before any guardrail activates; at ten agents simultaneously, $37,000 per incident. Analytics Week’s March 2026 analysis documents an estimated $400 million absorbed annually from recursive loop failures alone. McKinsey’s 2024 Global Survey on the State of AI finds 78 percent of knowledge workers use unsanctioned AI tools, generating inference costs and compliance obligations FinOps teams cannot see.

Convergence #2: The compliance architecture you cannot defer

Article 5 prohibited practices have been enforceable since February 2025, with penalties up to 7 percent of global annual turnover. The Digital Omnibus on AI, approved in committee on March 18, 2026, extends the compliance window for new Annex III high-risk system deployments under Articles 9-15, covering risk management (Article 9), audit logging (Article 12), and human oversight (Article 14), to December 2027. Building that architecture takes 12 to 18 months, and at 3 percent of global annual turnover, the maximum Annex III exposure for a $10 billion enterprise is $300 million. A credit decision through a public cloud endpoint may simultaneously violate GDPR Articles 44-49 (international transfers), Article 22 (automated decisions), and EU AI Act lineage requirements. The US CLOUD Act compounds this: choosing Frankfurt over Virginia does not solve your sovereignty problem if your provider is headquartered on California Avenue.

Convergence #3: The data gravity reversal

AI follows data. When egress costs plus transfer restrictions plus sovereignty exposure exceed owned inference capacity costs, the placement decision has been made for you.

Infrastructure is a placement discipline, not a platform choice

Five questions classify every workload before any platform is selected: Where should this run? How fast must it respond? Who owns its cost and compliance trajectory? What regulations govern where inference can legally execute? And at what volume does owned capacity beat pay-as-you-go cloud?

Ask those five questions, and three tiers emerge naturally. Public cloud for variable, burst and experimental workloads. Private on-premises for predictable high-volume production inference, where owned capacity consistently delivers 4x to 8x lower cost per token on Hopper-generation or later GPU hardware (H100 or equivalent at 75 to 85 percent utilization, GPT-4-class model, production batch sizes above 32). Edge for latency-critical and sovereignty-constrained decisions, where round-trip latency is a disqualifier. Some workloads will stay in the public cloud indefinitely. The goal is to stop letting infrastructure decisions make themselves.

Placement in practice

Those five questions are not theoretical. A single case shows how they play out under real compliance pressure.

One Tier 1 North American financial institution, processing more than 1 million credit decisions per month, saw cloud bills exceed forecast by 3x. A compliance audit identified two exposure points: the CLOUD Act made EU customer data accessible to US law enforcement, and audit logging failed to capture the lineage trail required under Annex III, Point 5(b), of the EU AI Act (AI systems assessing the creditworthiness of natural persons).

Applying the five questions took two hours. At 1.2 million decisions per month, on-premises was the obvious tier (cloud latency 340ms versus 22ms, same GPT-4-class model, both environments). Both compliance exposure points required moving inference to an EU-headquartered private stack. The workload migrated in 83 days. Monthly spend fell from $85,000 to $35,000. CLOUD Act exposure was eliminated. EU AI Act lineage requirements were met. The cost reduction per decision, combining compute, compliance overhead and latency cost, was 59 percent (GPT-4-class model at production batch sizes).

What to put in front of the CFO

The CFO’s question is whether the investment is working, provable in a number that someone is accountable for. The answer is a different denominator: cost per unit of business output. Four numbers: (1) compute cost per decision (the institution above: $0.071 on public cloud, $0.029 on private infrastructure, GPT-4-class model); (2) compliance overhead per decision (audit logging and regulatory evidence management, fixed regardless of tier); (3) latency cost per decision (340ms versus 22ms is measurable in abandoned transactions and SLA penalties); (4) human-equivalent benchmark (if your loaded analyst rate puts a human decision at $1.80 to $3.20, the CFO needs to be shown how to scale it).

Resilience is a cost line, not a design philosophy

In building the cloud outage database at whencloudsfail.opey.org, I have tracked more than 400 enterprise-impacting AI platform incidents since 2023. Duration of disruption correlates more strongly with provider dependency concentration than with incident severity. Claude AI experienced three major incidents in the first two weeks of March 2026, peaking at 4,700 down detector reports. Azure OpenAI logged a confirmed 20-hour degradation across seven regions on March 9 and 10. The difference between those bills is not a resilience philosophy. It is a number. Build resilience into the architecture or pay for it in the incident.

Resilience and governance are the same problem. The architecture question and the ownership question have the same answer.

Stop the organizational blame game

Deloitte’s 2026 State of AI in the Enterprise, across 3,235 senior leaders, finds only 1 in 5 companies has a mature governance model for autonomous AI agents. Three fixes: (1) a cross-functional governance body meeting quarterly, per-decision cost by workload class as its single agenda; (2) a named owner for every inference endpoint accountable for cost and the Article 14 model card; (3) real-time guardrails with automated kill switches. Gartner reports only 44 percent of organizations have adopted financial guardrails for AI.

Leaders who act vs. leaders who react

Gartner’s 2026 CIO Agenda finds 94 percent of CIOs expect major changes within 24 months, yet only 48 percent of digital initiatives meet their targets. Score yourself:

Question	Act	React
Cost per inference call named for top 3 workloads?	Yes	No
Named owner per production AI endpoint?	Yes	No
Cloud DPAs reviewed for EU AI Act data lineage?	Yes	No
Hard budget guardrails auto-stopping agents?	Yes	No
All AI workloads classified by 5-dimension frame?	Yes	No
Per-decision cost with compliance overhead to CFO?	Yes	No
Cross-functional AI governance body (quarterly)?	Yes	No
Shadow AI deployments inventoried across all BUs?	Yes	No

Predominantly NO: the 90-day sprint below is your path forward.

Your 90-day reckoning

Execute these phases sequentially. You cannot move a workload to the correct tier in Phase 3 if you have not classified it in Phase 1.

Phase	Focus	Owner	Deliverable
Days 1-30	Expose the bill	FinOps lead	Inventory all workloads; name a cost owner for each; calculate cost per decision for top 10; audit DPAs for EU AI Act class.
Days 31-60	Wire the guardrails	AI Eng lead	Deploy cost monitoring; set hard budget limits per agent; activate zombie alerts; first governance meeting; present dashboard to CFO.
Days 61-90	Move first workload	CIO	Migrate highest-cost predictable workload; complete EU AI Act gap assessment; brief board on per-decision cost; publish placement policy.

The competitive consequence of waiting

McKinsey’s Global Tech Agenda 2026, surveying 632 business leaders, finds that nearly two-thirds of top performers have technology leaders deeply involved in enterprise strategy, compared with 52 percent at others. PwC’s AI Vanguard, the 12 percent achieving both revenue and cost gains, carries nearly four percentage points higher profit margins. The separation is governance architecture, not model choice. The CIOs who navigate this most effectively are not managing AI as a technology initiative. They are managing it as a financial and regulatory obligation. The CIO who built this architecture before Thursday’s meeting does not dread that calendar invite. They sent it.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

>For many enterprises, cloud cost optimization has become a persistent challenge. Despite investments in FinOps tools, reserved instances, and cost monitoring platforms, AWS spend often continues to rise in ways that are difficult to predict or control. This phenomenon, often described as “cost drift,” is typically attributed to pricing models or workload growth.

>>However, the real cause is often less visible and more systemic: operational behavior.As organizations scale in AWS, complexity increases across environments, services, and teams. Over time, this complexity introduces inefficiencies that are not always captured by traditional cost management approaches. Idle resources, overprovisioned infrastructure, fragmented ownership, and inconsistent governance all contribute to gradual cost increases that accumulate over time.These issues are rarely the result of a single decision. Instead, they emerge from day-to-day operational patterns. Environments evolve, workloads expand, and teams make incremental changes, each of which may seem justified in isolation. But without consistent operational discipline, these changes compound into structural inefficiencies that drive cost drift.A key challenge is that many organizations still manage cloud environments using reactive operating models. Teams respond to incidents, performance issues, or new requirements as they arise, often prioritizing speed over optimization. While this approach may support short-term agility, it can lead to long-term inefficiencies as resources are added but rarely removed or rightsized.This dynamic is becoming more pronounced as cloud environments grow more complex. In fact, as explored in “>Why running AI is now harder than building it>”, many organizations are discovering that operationalizing modern workloads introduces new layers of cost and complexity that traditional models were not designed to manage.Another contributing factor is the disconnect between cost visibility and operational accountability. While finance and FinOps teams may have detailed insights into spend, the decisions that drive that spend are often made across distributed engineering teams. Without clear ownership and alignment, it becomes difficult to enforce consistent cost controls or identify the root causes of inefficiency.Automation, or the lack of it, also plays a critical role. Manual processes for provisioning, scaling, and incident response can introduce variability and delay optimization efforts. In contrast, environments that leverage automation and AI-driven operations are better positioned to continuously monitor usage, identify anomalies, and take corrective action in real time.This shift toward more intelligent operations is increasingly important. Organizations that embed automation and operational intelligence into their cloud environments can move from reactive cost management to proactive optimization. This not only helps control spend but also improves performance, resilience, and overall operational efficiency.Importantly, addressing cost drift requires more than financial oversight. It requires rethinking how cloud environments are operated.Leading organizations are adopting more structured operating models that integrate cost management into daily workflows. This includes establishing clear ownership of resources, enforcing governance policies, and embedding cost considerations into engineering decisions from the outset. Rather than treating cost optimization as a periodic exercise, it becomes a continuous discipline.These organizations also focus on improving visibility across environments. By correlating operational data with cost data, they can better understand how specific actions or inefficiencies impact overall spend. This enables more targeted optimization efforts and helps prevent cost drift before it becomes significant.The impact of this approach can be substantial. In environments where operational inefficiency is a major contributor to spend, organizations can achieve meaningful cost reductions while also improving recovery performance and governance consistency.For CIOs and technology leaders, the takeaway is clear. AWS cost drift is not just a financial issue. It is an operational one. Without addressing the underlying behaviors and processes that drive inefficiency, even the most advanced cost management tools will have limited impact.The path forward lies in evolving from reactive cloud operations to more proactive, intelligence-driven models. By embedding automation, improving accountability, and aligning teams around shared operational and financial goals, organizations can bring greater predictability to cloud spend while supporting continued innovation.As cloud environments continue to scale and as new workloads, including AI, place additional demands on infrastructure, the ability to operate efficiently will become a key differentiator. Organizations that address the root causes of cost drift will be better positioned to optimize performance, control costs, and maximize the value of their cloud investments.To learn more about handling AWS cost drift, check out the Run AWS at Scale e-book.

Google didn’t so much announce products at Cloud Next ’26 as it tried to reframe the real bottleneck to scaling AI as the architecture that CIOs have been building while trying to piece it together.

For years, enterprises have treated AI like a kit, with models, infrastructure, and data spread across different vendors and heterogenous environments, an approach that worked well enough in pilot mode, but has proven harder to scale into something dependable.

That, at least, is the problem that Google Cloud CEO Thomas Kurian chose to name, and own, on stage. “You have moved beyond the pilot. The experimental phase is behind us,” he said, before posing the more uncomfortable question for CIOs: “How do you move AI into production across your entire enterprise?”

His answer: “A unified stack.”

What that “unified stack” amounts to in practice, though, is Google stitching together layers it has historically sold and marketed separately into an architecture that represents a single operating fabric for enterprise AI.  

Kurian cast it as the “connective tissue” binding what are typically siloed layers, such as custom silicon, models, data, applications, and security, into a single, coordinated system. That translates into workload-specific TPUs to run and scale AI, Gemini Enterprise and the Gemini Enterprise Agent Platform to build and embed agents into business workflows, the Agentic Data Cloud to ground them in enterprise context, and a parallel push to secure both agents and the infrastructure they run on.

A turnkey answer to integration fatigue?

It’s a neat and a timely argument for enterprises, said independent consultant David Linthicum, especially for those that are frustrated with stalled pilots as a result of fragmented AI stacks,.

In addition, noted Ashish Chaturvedi, leader of executive research at HFS Research, most CIOs are drowning in integration tax, which compounds the costs of scaling an AI initiative. “The average enterprise has spent the last two years stitching together models from one vendor, orchestration from another, data pipelines from a third, and governance as an afterthought,”  Chaturvedi said. “Google, in contrast, is pitching a turnkey solution.”

That turnkey solution, said Shelly DeMotte Kramer, principal analyst at Kramer & Company, could be attractive on a number of fronts if CIOs are building on Google Cloud. It could reduce integration risk, offer faster pilot-to-production trajectories, and democratize AI across the organization and beyond IT via the Workspace Studio no-code agent builder. 

Concerns around execution and clarity

However, Kramer is not confident about Google’s execution of its unified stack vision. “Google Cloud has consistently come in in third place in terms of enterprise cloud share, with what could, in all candor, be called thinner organizational muscle for large-scale professional services engagements than what you might expect from AWS and Microsoft,” he said.

HyperFRAME Research’s leader of the AI stack Stephanie Walter, also has doubts. She questioned the clarity of the offerings that Google is packaging and marketing as part of that vision.

“While the pitch will resonate with enterprises tired of stitching together products to scale AI, it lacks clarity,” she said. “Google announced a lot at once, and the way the AI product portfolio fits together is still somewhat unclear, so CIOs will like the ambition while still asking for a cleaner map of where Gemini Enterprise, the Agent Platform, the Application, and the data layer begin and end.”

Converging vendor visions add complexity

That ambiguity, analysts say, will be further deepened for CIOs as they try to evaluate Google’s pitch against converging visions from rivals AWS and Microsoft, who, since last year, have been promoting their own visions of moving AI pilots into production.

While the convergence in vendor pitches will simplify choices at a high level, it will add complexity in practice because the control planes, pricing, ecosystem depth, and interoperability across offerings vary meaningfully, Linthicum said.

“CIOs still have to map those differences to their existing estate, talent base, and governance model. Similar narratives do not mean equivalent operating realities,” he added.

That, according to Walter, risks leaving CIOs comparing architectures that sound strikingly alike on paper, even as their underlying trade-offs remain difficult to parse at an operational level.

The convergence in vendor pitches could also backfire on Google, Chaturvedi noted. “The more similar the top-line narratives become, the more the decision swings on non-technical factors such as existing relationships, migration costs, and trust,” he said.

If anything, that dynamic may push enterprises toward a more pragmatic split. Paul Chada, co-founder of agentic AI startup Doozer AI, expects CIOs to end up standardizing on two distinct layers when scaling AI: a primary agent control plane aligned with where enterprise applications and user workflows reside, and a separate data reasoning layer anchored in governed data environments.

“The dream of a single vendor owning both likely won’t survive procurement,” he said.

“Unified” could still mean complex pricing

Further, analysts pointed out that Google’s unified stack pitch could introduce concerns for CIOs that go beyond architectural clarity.

For example, Linthicum noted that bundling infrastructure, models, data services, and agents into a single narrative doesn’t necessarily simplify costs, rather it makes pricing harder to predict and optimize,.

“A unified product story can still produce a highly fragmented bill. CIOs should expect more pricing complexity,” he said.

And Mike Leone, principal analyst at Moor Insights and Strategy, added that the problem of pricing complexity around AI offerings, doesn’t change with CIOs switching vendors. “Every hyperscaler is walking in the same direction,” he said.

That, said Dion Hinchcliffe, lead of the CIO practice at The Futurum Group, leaves CIOs with fewer levers to simplify costs at the vendor level and more responsibility to manage them internally. To that extent, he added that enterprises will need to lean more heavily on FinOps disciplines to regain control over increasingly complex and opaque AI spending.

Different strengths

There is, however, a more nuanced upside for CIOs willing to look past the unified vision pitch.

Kramer, for one, pointed to Google’s control over its own AI silicon as a potential differentiator. “That makes the comparatively better performance-per-dollar pitch for AI workloads at the infra level somewhat defensible,” he said.

At the same time, the analysts agreed, the competitive field, at least for CIOs, is far from settled.

“Microsoft looks best positioned on enterprise distribution and workflow adjacency. AWS is strongest on operational breadth, developer familiarity, and cloud maturity. Google is strongest where AI infrastructure, analytics, and model-platform integration matter most,” Linthicum said.

CIOs, in turn, should align  vendor strengths with enterprise priorities, whether that’s driving user adoption, scaling operations, or deepening AI and data platform capabilities, he added.

Cloud computing is a key foundation of modern business, yet many approach learning it in overly complicated ways. New learners often believe they need costly boot camps, certification bundles, or long technical courses before they can get a job in the field. This approach discourages potential entrants and creates false barriers around a discipline that’s already difficult to navigate. The truth is simpler: Free cloud courses are among the best starting points because they reduce risk, boost confidence, and introduce learners to the vocabulary, platforms, and models that define the cloud era.

The first stage of any cloud journey is orientation, not mastery. People need to understand what cloud computing means in practice, how infrastructure differs from platform services, why elasticity matters, where governance fits, and how major providers organize their offerings. A well-rounded exposure to the depth and breadth of a subject matter is a proven benefit of traditional higher education models. However, the traditional approach to course investigation and experimentation has become too costly for many prospective cloud students.

Free courses allow learners to explore without financial pressure. If someone discovers they prefer architecture over administration, or are more drawn to security than to development, the learning experience still creates value. Nothing is wasted.

Do cloud providers offer their free foundational learning as a charity? Of course not. This is ecosystem development. When AWS, Microsoft, Google Cloud, Oracle, IBM, and others publish free learning paths, they are hoping to cultivate future architects, engineers, analysts, and decision-makers.

Where to start

Start your cloud career by reviewing free introductory courses from vendors or leading educational platforms. These courses aim not only to teach features but also to foster the mental models providers want new users to develop. Free courses are also a good starting point because they let learners compare platforms before choosing one. This matters because beginners often hear strong opinions about the “best” cloud provider. The better question is which provider suits a learner’s goals. Someone focused on enterprise Windows may prefer Microsoft Azure. Those interested in startups or market demand may choose AWS. Those focused on data, analytics, or Kubernetes may opt for Google Cloud. Free courses enable this comparison without forcing early specialization.

The list below is a practical starting point. It includes reputable, free or free-to-start courses and learning paths from major providers and platforms. Some offer entirely free access to core material, while others allow enrollment at no cost but may charge separately for certificates or advanced lab features. That distinction is not a drawback for beginners. Early on, what matters most is understanding the landscape, learning the terminology, and gaining enough fluency to decide what should come next.

Courses from AWS

• Cloud Practitioner – Digital and Classroom Training
• Getting Started with AWS Cloud Essentials

Courses from Microsoft Learn

• Introduction to Cloud Infrastructure (AZ-900T00-A)
• Microsoft Azure Fundamentals: Describe Cloud Concepts

Courses from Google Cloud Skills Boost

• Cloud Computing Fundamentals
• Google Cloud Fundamentals: Core Infrastructure

Courses from IBM

• Introduction to Cloud Computing (via Coursera)
• Introduction to Cloud Computing (via edX)

Course from Oracle University/Learn Oracle

• Become an OCI Foundations Associate

Course from Alibaba Cloud Academy

• Free for All: New User Learning Path

Why free courses work so well

Effective courses aren’t just about price; they’re about structure. Good introductory cloud courses progress from concepts to examples to platform navigation, teaching learners to think about regions, zones, VMs, storage, identity, networking, and managed services before actual implementation skills are required. Many new learners fail by jumping into tools too soon. They try to deploy before they can explain. Free foundation courses avoid this by establishing context first, making hands-on learning more effective.

People entering the cloud market from nontraditional backgrounds should note that not all future cloud professionals need coding skills. Many successful cloud careers start in systems administration, security, project delivery, business analysis, operations, data management, or technical sales. Free courses help by focusing on concepts and platform literacy rather than deep engineering, making the field more accessible. This accessibility is a strength, helping cloud expand across industries.

Treat free courses as a starting point in a broader strategy, not the whole journey. They provide a good foundation. For example, you could start with an IBM overview, followed by AWS or Azure fundamentals to gain familiarity with a major provider, then Google Cloud to expand horizons. Next, engage in hands-on labs, architecture diagrams, small deployments, and role-based learning in areas like security, networking, AI, data engineering, or finops. Free courses are the launch point, not the end point.

The best first move

Commit. Begin your cloud journey this week. Start with one foundational course from a major provider and finish it. Then take a second course from a different provider to compare terminology, service models, and user experience. That simple approach gives you momentum, perspective, and a much clearer sense of where to invest your time next.

Procrastination is not your friend in an industry that evolves quickly and rewards curiosity. Don’t pay for depth before you earn breadth. Also realize that as the cloud industry matures and skills shortages ease, the availability of these free courses is likely to decline. Carpe diem.

ServiceNow is rolling out a broad set of platform updates designed to bake AI, data, security, and governance into every part of its stack. At the center of the move is a new Context Engine, which pulls together enterprise data, policies, and decision history to give AI-driven workflows a shared understanding of how the business operates and how decisions are made.

“Context Engine is ServiceNow’s new enterprise context solution that captures the why behind decisions, not just the what. Every AI interaction, resolution, approval, and escalation builds a richer understanding of how the business actually operates,” John Aisien, SVP of product management, security, and risk at ServiceNow, told CIO.com.

“It’s grounded in ServiceNow’s incumbent Service Graph and Knowledge Graph, with incremental AI decision tracing that captures decision context persistently, powered by our recent acquisition of Traceloop. It will also be enriched by IP that we acquired from Veza & IP that we announced plans to acquire from Armis,” Aisien added.

Expanding on how it works in practice, Aisien further pointed out that the Context Engine is not a standalone interface, but an embedded capability woven into the broader ServiceNow platform and “surfaces” through the experiences and workflows customers already use, and via published, public interfaces that the ITSM software provider will expose to customers and partners over time.

From ITSM platform to enterprise AI control plane

That embedded design, analysts say, also signals a broader ambition for ServiceNow.

“Service Now is seeking to move beyond the modular capability provider label and to move up the tech stack to be adopted as the enterprise AI operating layer, in turn owning the orchestration and control layer for enterprise AI, while remaining model agnostic beneath the surface,” said Scott Bickley, advisory fellow at Info-Tech Research Group.

However, Bickley pointed out that many vendors are pursuing a similar approach, not just ServiceNow: “Most enterprise scale SaaS providers are feverishly incorporating AI functionality horizontally across their solutions, all seeking to lock their customers in leveraging their own flavors of data fabric and context layers.”

“This can be seen with Salesforce’s AgentForce, Microsoft 365 Copilot, etc.  It is clear to these vendors that customers will want a single execution layer where possible, and their future depends on being the solution of choice,” Bickley added.

Vendor convergence raises stakes for CIOs

That convergence in strategy from multiple vendors, though, comes with trade-offs for CIOs.

According to Bickley, these updates from ServiceNow, akin to newer offerings from other vendors, will force enterprises to decide whether they want ServiceNow to be the control plane for enterprise automation.

“If not, ServiceNow offerings can become one expensive set of modules with built-in AI shelfware and the price to go with it,” Bickley said.

For enterprises embracing ServiceNow and its recent approach, the trade-off will be an “implied dependence upon ServiceNow’s data model, governance model, and platform architecture”, Bickley added.

The Context Engine is currently in preview with select customers, with broader availability details yet to be disclosed.

Build Agent Skills aims to widen developer appeal

Alongside Context Engine, ServiceNow also introduced Build Agent Skills and an SDK that Aisien said will allow developers to use external tools, such as Claude Code, Cursor, or OpenAI Codex, and integrated development environments (IDEs) to build applications and deploy them directly to the ServiceNow platform, while keeping governance and execution within its environment.

For developers, Stephanie Walter, practice leader of AI stack at HyperFRAME Research, said the skills and the SDK will add flexibility and speed.

“Instead of forcing teams into a single development environment, ServiceNow is letting them build with familiar tools and still deploy into a governed enterprise platform. That makes development faster, but it also means ServiceNow becomes the place where those applications ultimately run and are managed,” Walter said.

For Bickley, the skills and SDK are ServiceNow’s strategy to appeal more broadly to platform engineering teams compared to its older approach, where it tried to appeal to the legacy ServiceNow admin ecosystem and low-code user base.

However, the analyst cautioned against the Build Agent skills offering, saying that ServiceNow was not being very forthcoming about its details, especially its pricing.

When asked about more details on skills, Aisen told CIO.com that enterprise customers will receive 100 free Build Agent calls to start with, and developers on personal instances will get 25.

“Beyond that on-ramp, full pricing details are not being disclosed,” Aisen said.

These scant details, according to Bickley, are precisely what introduce cost unpredictability as ServiceNow doesn’t seem to explain how much or what can be accomplished with 100 Build Agent calls.

In fact, Bickley further warned that CIOs should adopt a FinOps mentality if they seek to avoid drowning in the emerging consumption model ocean as Build Agent calls isn’t the only area that will draw charges.

For CIOs, the bigger concern is how multiple consumption-based charges could stack up across Build Agent usage, Workflow Data Fabric, and core platform licenses, creating a layered cost structure rather than a single subscription, Bickley said.

Without clear visibility into how these meters interact, enterprises risk unexpected spending spikes as AI adoption scales, making it harder for CIOs to track what’s driving costs and tie that spend back to business value, Bickley added.

ESM Foundation to ease adoption

Against this backdrop of potential cost complexity, ServiceNow is also trying to simplify adoption for midsized enterprises, at the packaging level, with the introduction of its ESM Foundation offering, which bundles core enterprise capabilities into a more streamlined, faster-to-deploy package.

For Bickley, the packaging reduces confusion for midsized companies trying to choose between its varied offerings and shortens their time to deployment.

Separately, the analyst pointed out that ESM Foundation is also ServiceNow’s strategy to compete with smaller vendors, such as Atlassian.

“If ServiceNow can credibly offer faster deployment for midsize companies while including AI, governance, and workflow executing into the platform price, they can attack the complexity and time to value obstacles their competitors have wielded against them,” Bickley said.

The ESM Foundation package and the company’s new tiered packaging model are now generally available to customers. Meanwhile, the Build Agent Skills are set to become available to developers starting April 15.

For years, cloud strategy rewarded standardization. Treat everything as a workload, abstract the differences, optimize for scale and cost. That mindset helped enterprises modernize faster than any previous infrastructure shift. Applying that same mindset to AI is one of the most consequential architectural mistakes I see senior IT leaders make.

In executive rooms, the logic is understandable. We already have a hardened cloud platform. We have guardrails, FinOps processes, security controls and autoscaling policies. Why not onboard AI into the same architecture and move quickly? Because AI is not just another workload category. It is a different behavioral system. That distinction sounds subtle. In practice, it changes everything.

The assumption that worked for everything else

Traditional cloud architecture rests on three core assumptions:

• Execution paths are largely deterministic
• Resource consumption scales predictably with traffic
• Boundaries between compute, data and policy remain stable

When those assumptions hold, standardization works. We can treat systems as workloads, provision capacity, monitor utilization and optimize after the fact. That model powered the first decade of cloud transformation.

AI systems break all three assumptions. Unlike microservices or transactional applications, AI systems reason, adapt and act conditionally. A single request can trigger multiple inference calls, cross-domain retrieval and tool invocations whose paths are not fully known at deployment time. Prompts, context, model selection and evolving data shape behavior. Cost no longer scales purely with user traffic. It scales with decision complexity. Governance no longer attaches cleanly to static roles and services. It must account for dynamic execution paths.

This is not a minor workload variation. It is a shift from deterministic execution to conditional execution. When AI is treated as just another workload, that shift is ignored.

The slow erosion that follows

The mistake rarely causes immediate failure. Systems run. Dashboards stay green. Pilots appear successful. The erosion happens gradually.

I have worked with CIOs who initially integrated AI into existing cloud platforms without architectural changes. The early wins masked deeper structural mismatches. Over time, we began to see patterns: costs became harder to explain. The FinOps Foundation’s 2024 State of FinOps report notes that AI and machine learning workloads are materially impacting cost governance for large cloud spenders, with inference-driven consumption introducing new unpredictability. Security teams struggled to reason about dynamic data access patterns. The NIST AI Risk Management Framework emphasizes that AI systems introduce unique risk characteristics that require continuous oversight rather than static control checkpoints. Architecture reviews became longer and more anxious. Gartner has warned that a significant share of generative AI initiatives fail to progress beyond pilot stages due to escalating infrastructure costs and insufficient governance maturity.

What made these issues particularly difficult was not that AI was “expensive” or “risky.” It was that the platform had not been designed for systems that change their own execution patterns. The regret I hear most often is not about choosing the wrong model or vendor. It is about assuming the underlying cloud architecture did not need to change.

Where the abstraction breaks

Standardization works when workloads share structural characteristics. AI systems do not. Three architectural fault lines appear repeatedly.

1. Stateless compute versus stateful reasoning

Cloud architectures optimized for stateless services struggle with systems that require persistent context across steps. Memory layers, vector stores and reasoning traces introduce a state that cannot be treated as incidental. When that state is forced into ad hoc storage patterns, observability and governance degrade.

2. Static provisioning versus dynamic execution

Traditional autoscaling policies assume that load is driven by traffic volume. AI systems often expand work internally through iterative reasoning, agent coordination or feedback loops. A single external request may expand into dozens of internal operations. That amplification is architectural, not accidental. Capacity planning models designed for predictable scaling curves fail to anticipate that behavior.

3. Policy at the perimeter versus governance at runtime

Cloud security historically focused on identity, access and perimeter controls. AI systems operate inside those boundaries but make conditional decisions about how to use tools and data. Treating AI like a workload keeps governance external. Effective AI governance increasingly must operate during execution, not only before or after it.

The category error is subtle but critical: assuming that because AI runs on cloud infrastructure, it behaves like traditional cloud workloads.

The conceptual mistake

In conversations with senior leaders, the architectural regret is rarely framed as a technical flaw. It is framed as a mindset issue. Standardization had become a reflex. We had trained ourselves to collapse differences between workloads in pursuit of efficiency. That instinct was valuable. It reduced sprawl and complexity across portfolios of applications.

But AI changes what infrastructure is. AI systems are not passive consumers of compute. They are active decision engines operating within compute. When leaders treat them as passive workloads, governance becomes reactive. Cost becomes opaque. Execution paths become difficult to reconstruct. Teams retrofit controls after problems surface. By the time architectural changes are made, inertia has set in. Platforms are embedded. Budgets are allocated. Organizational roles are defined around outdated assumptions.

The regret is conceptual before it is operational.

What I advise leaders to do differently

When I work with CIOs evaluating AI architecture, I encourage them to pause before defaulting to platform standardization. The key question is not “Can our existing cloud handle AI?” It is “What assumptions about behavior does our cloud architecture embed?” If those assumptions include deterministic execution, predictable scaling and static boundaries, they will eventually be violated.

That does not mean abandoning existing platforms. It means evolving them deliberately. Three shifts consistently make a difference.

Treat context as infrastructure

Persistent memory, retrieval layers and reasoning traces should be first-class architectural components, not bolt-ons inside application code.

Treat cost as a runtime signal

Instead of relying solely on post-billing analysis, instrument inference, token usage and model routing decisions, economic behavior is visible as systems operate. This aligns with broader FinOps guidance that emphasizes continuous cost visibility rather than retrospective reconciliation.

Treat governance as part of execution

Rather than assuming policies can remain external, design for runtime oversight where necessary. The NIST AI RMF reinforces that risk management for AI requires ongoing monitoring and adjustment as systems evolve, not static certification.

None of these shifts requires abandoning cloud discipline. They require acknowledging that AI alters the behavioral profile of infrastructure.

The regret I hear most often

When leaders look back, they rarely say, “We chose the wrong model.” They say, “We assumed the architecture didn’t need to change.” That assumption delays the real work. It postpones difficult conversations about control, cost and accountability. It reinforces the idea that AI is a feature layer on top of infrastructure rather than a force that reshapes it.

In my experience, the organizations that adapt fastest are not those that chase new tools. They are the ones willing to question the abstraction that made cloud successful in the first place. Standardization remains powerful. But it must be applied thoughtfully.

Treating AI like just another workload feels efficient in the moment. Over time, it becomes the cloud architecture decision that many CIOs wish they had approached differently. The regret is not about technology. It is about recognizing that autonomy changes the system it runs on. And that realization is architectural, not operational.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Datacom’s AI and infrastructure experts – Matt Neil (Director – Data Centres), Mike Walls (Director – Cloud) and Daniel Bowbyes (Associate Director – Strategy) – discuss when centralised compute makes sense for AI, and how to orchestrate AI across edge, core data centres and cloud. The team shares governance, readiness and architectural approaches to enable reliable multi-environment AI.

When does centralised cloud or core data centre compute make the most sense for AI workloads?

Mike Walls, Director – Cloud: Centralised compute is sensible when workloads benefit from scale, governance and uniform platform capabilities that are harder to achieve in distributed setups. Think large‑scale training, platforms or workloads requiring a consistent, controlled environment with robust security and regulatory compliance. These can be more cost‑effective or easier to manage in a core data centre or central cloud. Private clouds are also options when organisations need tighter control, governance or data‑handling assurances, or when workloads don’t require the low‑latency edge path.

Are you seeing customers combine multiple environments for a single AI solution, and if so, how does that typically work?

Walls: Yes, AI is increasingly distributed, and edge, core data centres and cloud each have a role. A typical pattern we’re seeing and advising on is organisations placing latency‑sensitive, real‑time tasks at the edge (or near‑edge) and heavier training, model development and data‑intensive processing is being placed in core data centres or the cloud. Public cloud obviously allows for quick experimentation and scale, whereas private or sovereign cloud may be more effective when running persistent production large language models (LLMs) or in meeting compliance needs. This multi-environment approach requires clear orchestration, data pipelines and governance to ensure consistency, security and compatibility across environments. Datacom’s uniquely placed to be able to provide capabilities (infrastructure, governance or applications) as well as offer platforms, tooling or bespoke services to support multi‑environment deployments.

Matt Neil, Director – Data Centres: Customers are already mixing multiple AI components and tools, for example, one tool might generate code (Claude), another reads documents (OpenAI) and they’re brought together for different functions. They’re using different tools and agents that then need to be integrated into an overall workflow. It’s a maturity journey: we’re seeing organisations moving from piecing together separate software to building a cohesive ecosystem. 

How does Datacom’s regional data centre footprint across Australia and New Zealand support distributed AI strategies?

Neil: In New Zealand, our data centres have a genuine regional footprint, serving four of the largest cities and enabling New Zealand–wide coverage (North Island and South Island). That allows workloads to run closer to where they need to be, including localised AI deployments in places like Christchurch. In Australia and New Zealand, we can support distributed AI and help customers operate across borders if that’s what they need. Datacom’s data centre ownership means we can offer end-to-end hosting and infrastructure closer to our customers, which is a strong enabler for distributed AI.

From a cloud and hybrid perspective, how does Datacom help customers design AI architectures that span cloud, data centre and edge?

Walls: We’re able to provide a cohesive, use case to platform, multi‑environment strategy that integrates private cloud with public cloud and edge capabilities, plus governance and tooling to support AI workloads. This involves helping inform on the service models (GPU‑based, bespoke builds or platform/tooling) and helping customers design architectures that span multiple environments while addressing data governance, security and operational consistency.

Daniel Bowbyes, Associate Director – Strategy: To build out strategies for our customers, we draw on our breadth of AI professional and software development services, AI security services, AI sovereign platforms, public cloud partnerships and hosting facilities. Customers can safely and swiftly adopt and infuse AI across their IT landscape with Datacom working alongside them.

If you had to summarise Datacom’s approach to AI infrastructure in one idea, what would it be?

Walls: Datacom’s AI infrastructure strategy is simple: match each use case to the right model, tools and platform – edge, core data centre or cloud – based on the task, business requirements, maturity and governance needs, with clear ownership and scalable tooling to orchestrate across environments.

Neil: Own and operate the core infrastructure to offer an end-to-end, trusted AI infrastructure platform. In other words, our data centre capability is a unique differentiator that lets us deliver the full stack – from infrastructure to governance – so we can act as a trusted advisor and provide a complete, end-to-end AI solution.

With AI evolving so rapidly, how much does uncertainty about the future influence infrastructure decisions being made today?

Neil: A lot. Organisations often don’t know what they want to do with AI or what use cases to pursue, which makes it easy to waste money on the hype. The right approach is to understand potential use cases, adopt a framework and consider a “try before you buy” approach, including sandbox environments, pilot infrastructure and vendor partnerships to help customers experiment safely. This reduces risk and helps shape a practical, scalable path forward rather than rushing into big, expensive bets.

Bowbyes: AI is the fastest-ever adopted technology, with a huge amount of ongoing development and investment that will likely mean the current leaders in both AI software and hardware will change over time. At the same time, the opportunities that AI represents to positively disrupt business are huge and can’t be ignored.    

Every organisation faces a unique set of challenges and opportunities, so how they lean into AI and the risks they are prepared to take will be very different. For organisations that have heavy data processing and research requirements, the risk of infrastructure obsolescence will likely be less than the cost of consuming an ‘as a service’ offering (which has infrastructure obsolescence baked into the price). For many other organisations, consuming ‘as a service’ offerings will be less risky in the short to medium term than investing in infrastructure.

Walls: The uncertainty argues for a flexible, staged and modular approach rather than long‑lead commitments to a single path. To combat some of the concerns organisations may have, we recommend a funnel‑based readiness framework to help organisations identify their AI use cases and goals (training, inference, coding tasks) and then choose appropriate architectures and services. Because AI is changing quickly, decisions today should prioritise adaptability, pilot testing and options that can be extended or re‑configured as requirements sharpen, rather than locking into a single, rigid model.

Learn how Datacom is partnering with organisations to move from AI strategy to scalable practice – designing, piloting, and scaling secure AI across diverse environments.

Glossary

• Edge/near-edge: Compute resources located close to data sources or end users to reduce latency. Near-edge refers to a closely proximate layer, often in metro areas.
• Multi-environment AI architecture: An approach that intentionally uses edge, core data centres and cloud to balance latency, governance, cost and data residency.
• Orchestration: End-to-end management of AI models and data across environments, including deployment, data movement and lifecycle operations.
• Governance: Policies and controls governing data handling, model usage, security, compliance, risk management and auditability across environments.
• FinOps: Financial operations practices for AI and cloud spend, including cost visibility, budgeting, optimisation and cost control across environments.
• Data residency: Regulations governing where data is stored and processed, often tied to geographic or regulatory requirements.
• Data sovereignty: Legal authority over data, including access rights and regulatory obligations that can constrain data movement across borders.
• Data locality: Proximity of data to where it is processed, influencing latency, bandwidth and regulatory considerations.
• Latency: Time delay between input and output, typically measured in milliseconds. It’s critical for real-time AI tasks.
• AI workloads: Categories such as training (model learning), inference (runtime predictions) and generative/agentic AI (code generation, chat, autonomous decision-making).
• Service models for AI deployments: Examples include GPU-based infrastructure, bespoke builds or platform/tooling offerings that support multi-environment AI.
• Funnel readiness framework: A structured approach to identify AI goals (training, inference, coding tasks) and map them to suitable footprints, services and governance controls.

이란의 드론 공격으로 이달 초 장애가 발생한 중동 지역 데이터센터를 이용하는 고객을 대상으로, AWS가 한 달 치 사용 요금을 전액 면제하기로 했다고 확인했다. 이는 매우 이례적인 조치로 평가된다.

3월 1일 발생한 공격으로 중동 지역 내 AWS 데이터센터 두 곳, ME-CENTRAL-1(아랍에미리트)과 ME-SOUTH-1(바레인)이 피해를 입었다. 회사는 다음 날 해당 사실을 공식 인정했다.

AWS는 서비스 상태 페이지를 통해 “이번 공습으로 건물 구조에 손상이 발생했고, 인프라에 대한 전력 공급이 중단됐다”며 “일부 구역에서는 화재 진압 작업이 필요했으며, 이 과정에서 추가적인 침수 피해도 발생했다”고 밝혔다.

이번 장애로 해당 리전에서 제공되던 여러 AWS 서비스가 영향을 받았다. EC2, S3, 다이너모DB, AWS 람다, 키네시스, 클라우드워치, RDS는 물론 AWS 관리 콘솔과 명령줄 인터페이스(CLI)도 일부 중단됐다.

3월 26일 AWS 전문가이자 블로거인 코리 퀸은 IT 언론사 더레지스터를 통해, 아마존이 해당 시설을 사용하는 고객에게 3월 요금을 면제한다는 내용의 이메일을 발송했다고 전했다.

퀸이 인용한 이메일에서 AWS는 “AWS는 2026년 3월 ME-CENTRAL-1 리전의 모든 사용량 기반 요금을 면제한다”며 “해당 면제는 고객 계정에 자동 적용되며, 별도의 조치는 필요 없다”고 안내했다.

이어 “처리가 완료되면 비용 및 사용 보고서(Cost and Usage Report)나 코스트 익스플로러에서 2026년 3월 ME-CENTRAL-1 리전 사용 내역이 표시되지 않을 것”이라고 공지한 것으로 전해졌다.

청구서를 넘어선 의미

서비스 수준 협약(SLA) 문제와 관련해 계정에 일부 크레딧이 적용되는 경우는 종종 있었지만, 특정 리전의 한 달 전체 사용 요금을 면제하는 조치는 전례를 찾기 어렵다는 평가가 나온다.

더 논란이 되는 부분은 이번 조치가 컴플라이언스 및 보안 포렌식에 활용되는 핵심 비용 및 사용 보고서(Cost and Usage Report, CUR) 데이터까지 사실상 제거하는 효과를 낳을 수 있다는 점이라고 퀸은 지적했다.

퀸은 AWS의 CUR이 단순한 과금 수단이 아니라고 설명했다. 어떤 서비스를 얼마나 사용했는지를 정밀하게 기록해 비용 배분에 필수적인 자료로 활용되며, 낭비되거나 과소 활용된 리소스를 추적하는 데에도 중요한 역할을 한다는 것이다.

퀸은 “대부분의 조직에서 AWS 청구서는 단순한 인보이스가 아니다. 어떤 인프라가 존재하는지, 어디에서 운영되고 있는지, 얼마나 오랫동안 유지됐는지를 보여주는 기준 기록”이라며 “컴플라이언스 팀이 이를 기반으로 업무를 수행하고, 감사 과정에서도 해당 자료를 요구하며, 핀옵스(FinOps) 팀 역시 이를 토대로 운영 체계를 구축한다”고 밝혔다.

이 사안과 관련해 CSO의 질의에 답변한 AWS는 기존 입장을 보다 구체화했다. 회사는 고객이 3월 기간에 대한 요금을 확인하지 않도록 사용 데이터를 과금 보고서에서 필터링했을 뿐이라고 설명했다.

다만 고객은 여전히 과금 데이터에 접근할 수 있다고 밝혔다. AWS 대변인은 이메일을 통해 “AWS는 2026년 3월 ME-CENTRAL-1 리전의 모든 사용량 기반 요금을 면제한다고 고객에게 안내했다”며 “AWS는 고객의 과금 데이터를 삭제하지 않았으며, 사용 데이터는 요청 시 제공된다”고 전했다.

이번 공격은 샤헤드-136이라는 드론에 의해 이뤄진 것으로 알려졌다. 전쟁으로 인해 미국의 주요 하이퍼스케일러가 직접적인 영향을 받은 사례는 이번이 처음으로, 데이터센터와 디지털 경제가 이러한 유형의 공격에 얼마나 취약한지를 보여주는 사건으로 평가된다.

AWS 상태 페이지에 따르면 3월 말 현재까지도 중동 지역 데이터센터는 여전히 일부 장애를 겪고 있다. 드론 공격의 여파가 완전히 해소되지 않았음을 시사하는 대목이다.

모든 데이터센터가 표적

AWS만의 문제는 아니다. 이번 분쟁에서 양측은 상대를 지원한다고 판단한 데이터센터를 공격 대상으로 삼고 있다. 3월 5일 이슬람 혁명수비대(IRGC)와 밀접한 관계로 알려진 이란 파르스 통신은 성명을 통해, AWS 데이터센터에 대한 공격이 해당 시설이 “적의 군사 및 정보 활동을 지원한” 데 따른 직접적인 결과라고 주장했다.

이어 3월 11일에는 이스라엘이 이란 수도 테헤란의 한 데이터센터를 공격했다는 보도도 나왔다. 이스라엘은 IRGC 구성원에게 자금을 지급하는 데 사용되는 은행 서비스를 교란하기 위해 해당 시설을 겨냥한 것으로 전해졌다.
dl-ciokorea@foundryco.com

Datacom’s AI and infrastructure leaders – Matt Neil (Director – Data Centres), Mike Walls (Director – Cloud) and Daniel Bowbyes (Associate Director – Strategy) – discuss where edge and near-edge deployments add value and how to orchestrate AI across distributed environments while maintaining governance and cost discipline. 

Latency is often cited as a driver for edge or regional deployments. In practice, what types of artificial intelligence (AI) workloads are most sensitive to latency?

Matt Neil, Director – Data Centres: Workloads requiring real-time processing and immediate feedback are the most latency‑sensitive. These include applications that need sub-10 millisecond responses, such as vehicle telematics, control systems, robotics and real-time decision-making in autonomous or semi-autonomous contexts. 

Edge computing reduces the need to transmit data to core data centres, enabling faster responses and lower network dependency. As AI adoption grows, edge will become more important for delivering services close to end users, especially when the data volume or the speed of response makes central processing impractical.

Can you share examples of AI use cases that are best suited to edge or near-edge environments?

Neil: Edge or near‑edge deployments are best suited to AI workloads that require real‑time processing and local decision‑making, where latency, bandwidth or reliability constraints make sending data back to a central data centre impractical.

These use cases prioritise speed, autonomy and the ability to process large volumes of data close to where it is generated. By running AI at or near the edge, organisations can deliver immediate outcomes, reduce network dependency and enable decision‑making in scenarios where milliseconds matter.

Key examples include:

• Gaming and interactive experiences that demand immediate response
• Remote farming and agricultural tech, where local processing supports autonomous or semi‑autonomous operations
• Vehicle telematics and control systems, including safety‑critical or instant‑driven decisions
• Self‑driving vehicles and other autonomous mobility applications
• Warehouse and manufacturing automation, where on‑site AI can optimise operations without round‑trip network delays

Energy consumption and sustainability are becoming board-level concerns. How does AI change the energy equation for infrastructure teams?

Neil: AI workloads are more energy‑intensive than traditional data workloads, driving a need for more, and sometimes newer, data centre capacity. This intensifies trade‑offs between sustainability and cost with organisations aiming for efficiency and lower carbon footprints but also working to balance these goals against budget realities and time to value. 

Location also matters, as naturally cooler climates can improve energy efficiency, so places like New Zealand are attractive for organisations seeking data centres that offer sustainable operations at scale. When comparing options, organisations will favour locations offering comparable service levels at similar prices but with lower energy use or lower carbon intensity. The practical takeaway is to pursue the most energy‑efficient, cost‑effective option that still meets performance, resilience and regulatory needs, rather than pursuing sustainability targets in isolation.

As AI becomes more distributed, what new challenges does this introduce for orchestration and management?

Mike Walls, Director – Cloud: Distributed AI adds complexity in orchestration, lifecycle management and governance across multiple environments. Challenges include:

• Keeping models and data in sync across edge and central environments
• Managing access and security consistently – across human and digital realms
• Maintaining transparency and control over where and how data is processed
• Ensuring data residency and compliance across jurisdictions 
• Managing fluctuating AI model, platform and token use and costs 

Daniel Bowbyes, Associate Director – Strategy: It’s no longer enough to be able to identify a person or an AI agent when it accesses a system. Management solutions will also have to track agent intent to validate the purpose behind the agent’s action to protect against prompt injection attacks and intent hijacking. 

Where systems are using external large language models (LLMs), organisations will need to continually probe and test them for potential supply chain attacks leading to drift and undesirable AI agent decision-making. As agents become more powerful, they will require access to multiple organisational systems and data sources. It’s critical that organisations have the right management systems in place to be able to easily report on which agents have access to which data sources and replay agent actions in the event of an investigation.

Just as organisations harvest unused licences and regularly review system usage to ensure staff are using the most optimal licence for their needs, organisations will have to evolve their AI FinOps capability to not only track if staff are using AI features in a system, but if their usage is appropriate for the system and the LLM employed by that system.

What operational issues are organisations often under-prepared for when running AI at scale?

Bowbyes: AI at scale can be a significant financial cost to the organisation. For those organisations looking to deploy and manage their own infrastructure, there are significant supply chain challenges in just getting hold of compute hardware, let alone the complexity and cost of the hosting, power and cooling systems needed to run the hardware. There are also the ongoing infrastructure running and licensing costs and the significant rate of hardware technology change.

Walls: There’s also a general preparedness gap around:

• The need for mature governance and policy frameworks
• Understanding use cases against the right models and infrastructure
• The challenges of building the right infrastructure to support AI at scale
• Heightened data governance and regulatory pressures
• The risk that current AI, and certainly traditional, security is insufficient

 All of these collectively need proactive planning, investment in processes and flexible, scalable infrastructure strategies.

Bowbyes: Organisations that are looking to consume AI infrastructure as a service shield themselves from large capital outlays but potentially face high running costs, GPU availability risks, latency risks and the need to have very tight financial controls to ensure AI processing costs don’t blow out, causing cashflow issues.

How important is consistency across environments (cloud, data centre, edge) when it comes to deploying and operating AI models?

Walls: It’s hugely important for governance, security and reliability when leveraging or moving models and data across environments. We’re finding that AI infrastructure and the reality of different models for different use cases drives different platform needs is a recurring topic in conversations we’re having, which implies there’s a need for coherent policy, tooling and architecture across the different environments. While edge deployments address latency and locality, centralised environments provide scale and governance. But even within an environment, different model use may drive different infrastructure needs. A managed, consistent approach across all environments helps reduce risk, simplify operations and improve the ability to deploy and maintain AI models at scale.

Find out how Datacom is supporting organisations in optimising and governing AI workloads across distributed environments, while advancing sustainability and compliance goals.

Glossary 

• Edge: Computing resources located close to data sources or end users to reduce latency.
• Near-edge: A closely proximate compute layer to edge devices, often networked to edge data sources.
• Distributed AI: AI workloads spread across multiple environments (edge, data centre, cloud) with coordinated governance.
• Governance: Policies and controls governing data, models, security and compliance.
• FinOps: Financial operations practices for cloud/AI spend, including costing, budgeting and optimisation.
• Data residency and sovereignty: Regulations governing where data is stored and processed and by whom.
• Orchestration: Managing the end-to-end workflow of AI models and data across environments.
• Prompt injection / supply-chain risk: Security concerns around manipulated prompts or compromised models/data sources.

---

The release of the Flexera 2026 State of the Cloud Report provides vital insights into how enterprises are navigating the constantly changing landscape of cloud computing and increasingly AI-driven workloads. The findings show that the enterprise cloud discussion has changed significantly in recent years.

What started as a focus on cost-cutting and simple lift-and-shift migration has evolved into a complex balancing act involving governance, innovation, and measurable business value. This shift is not only logical but also expected, especially considering the rise of AI and the shared experience of enterprises that have faced unexpected cloud costs and unchecked spending for years.

Let’s explore what the report shows, why these findings are expected given industry trends, and what enterprises can do to extract real value from their ongoing—indeed, increasing—cloud investments.

Moving beyond cost-cutting

The main finding from the 2026 State of the Cloud Report is that organizations are clearly moving past an era where “cost-cutting at all costs” was the primary cloud strategy. We see a notable 12% increase in organizations reporting value delivered to business units year over year, even as the emphasis on simple efficiency and savings has decreased by 6%.

This marks a turning point in cloud adoption maturity. For years, cloud evangelists and technology leaders highlighted the cost advantages of moving from on-premises systems to the public cloud, and rightly so. However, the initial enthusiasm faded for many CIOs and CFOs as complexities increased, such as cloud sprawl, unpredictable billing, or wasted resources. According to the report, about 29% of cloud spending is still wasted, a sobering figure for any CFO’s office, but this also marks an improvement compared to years of uncontrolled growth. Now, the focus is on making productive investments and how cloud services can significantly impact business results.

Wiser organizations are trying to understand the cost of each service, align spending with results, and develop the discipline to measure value at every level, from individual projects to large-scale digital transformation efforts.

Oversight and governance models

As cloud complexity increases, so does the need for controls and clear leadership. The State of the Cloud Report shows a growth in the adoption of cloud centers of excellence (CCOEs) and finops teams, with 71% of organizations now using CCOEs. More organizations have dedicated finops teams to advise, manage, and optimize cloud spend. Teams are also more active in overseeing SaaS and cloud software usage.

What unites these efforts is a shift toward centralized accountability. Enterprises have learned the hard way that finops, CCOEs, and asset management cannot function in isolation. Cloud cost management collapses when roles and responsibilities are scattered. The most developed organizations coordinate efforts across teams to maintain shared views on spending, usage, and business priorities.

Some enterprises may worry about adding bureaucracy, but establishing transparency and focus will balance innovation with risk management and connect cloud spending directly to organizational goals.

Opportunities and risks of AI

Perhaps the most important change in this year’s report is the rise in AI-driven workloads, especially the adoption of generative AI. The data is clear: 45% of organizations now use genAI extensively, up from 36% a year earlier. Companies see significant opportunities for innovation and gaining a competitive edge through AI. At the same time, they realize that AI workloads are flexible, can incur unpredictable costs, and are often billed under new consumption-based pricing models that can quickly escalate without strong governance.

While there’s excitement about AI’s potential, there’s also a rapidly growing consensus that strong governance and cost controls must be put in place before spending spirals far beyond projections. We’re starting to see organizations appoint dedicated AI governance leaders who can ensure that innovation is safe, scalable, and firmly tied to business value and operational accountability (unlike the early, chaotic days of cloud).

SaaS spending, too, has exploded, with the most common monthly range among respondents jumping to $200,000 to $500,000. This is a sharp increase from the $50,000 to $100,000-tier that dominated last year, driven largely by the proliferation of AI-powered features and complex, usage-based pricing models. The conclusion: Cloud bills won’t shrink anytime soon, but organizations are determined not to repeat past mistakes. The focus now is on ensuring every dollar has a tangible return.

Three ways to boost cloud value

If you’ve tracked cloud growth as long as I have, these shifts are both natural and expected. Ten years ago, cost savings were the main focus of every cloud business case. As companies moved beyond the initial adoption phase, issues like sprawl, waste, and sticker shock emerged. The rise of AI and its endless demand for compute and data have increased both the opportunities and risks. Enterprises are seeking a balanced approach that carefully considers innovation, costs, and business value.

Cloud cost management is evolving into a smarter, value-driven discipline that’s keeping pace with business priorities and fast-changing markets. Here are three recommendations for enterprises looking to increase value in their cloud services:

1. Double down on centralized governance. Build or strengthen your CCOE and finops capabilities, but don’t let these teams operate independently. Accountability and transparency must be shared and tied directly to business outcomes.
2. Bring AI governance into the fold early. Establish clear ownership, set measurable goals, and don’t hesitate to manage experimental projects with the same rigor as production workloads. AI innovation is too expensive and too important to leave to chance.
3. Treat finops as an ongoing discipline, not a one-time project. Invest in the people, processes, and tools that support continuous tracking, optimization, and reporting. Incorporate cost and value discussions into every cloud project’s life cycle.

The key message from this year’s report is simple: Enterprises are demanding clear value from their cloud and AI initiatives. That’s expected, and it’s exactly where mature organizations should be headed.

In a highly unusual move, Amazon has confirmed that it is waiving an entire month’s usage charges for customers using two Middle Eastern datacenters disrupted by Iranian drone attacks earlier this month.

The attacks on March 1 damaged two Amazon datacenters in the region, ME-CENTRAL-1 (United Arab Emirates) and ME-SOUTH-1 (Bahrain), something the company acknowledged the following day.

“These strikes have caused structural damage, disrupted power delivery to our infrastructure, and in some cases required fire suppression activities that resulted in additional water damage,” Amazon advised on its service health page.

The disruption affected multiple Amazon services at these locations, including EC2, S3, DynamoDB, AWS Lambda, Kinesis, CloudWatch, and RDS, as well as the AWS Management Console and command line interface (CLI).

Last week, AWS expert and blogger Cory Quinn reported in an article on The Register that the company had emailed customers using these facilities with the news that March charges would be waived.

“AWS is waiving all usage-related charges in the ME-CENTRAL-1 Region for March 2026. This waiver applies automatically to your account(s), and no action is required from you,” Amazon wrote in the email quoted by Quinn.

“You will not see any March 2026 usage for the ME-CENTRAL-1 Region in your Cost and Usage Report or Cost Explorer once processing is complete,” the email reportedly continued.

Not just an invoice

While credits are sometimes applied to accounts related to service level agreements (SLAs) issues, waiving charges for an entire month appears to be unprecedented.

More contentiously, according to Quinn, the move would also have the effect of wiping essential Cost and Usage Report (CUR) data used in compliance and security forensics.

Quinn pointed out that the AWS CUR is not only a general billing facility; it gives customers a precise record of which services were consumed, essential for cost allocation. This also helps track wasted or under-used resources.

“For most organizations, the AWS bill isn’t just an invoice. It’s the canonical record of what infrastructure exists, where it’s running, and how long it’s been there,” Quinn wrote. Moreover, “compliance teams rely on it. Auditors request it. FinOps teams build their entire practice on it.”

In response to questions from CSO about this issue, Amazon clarified its statement, saying that usage data was filtered from billing reports so that customers would not see charges for the March period.

However, it said, customers would still be able to access billing data. “We notified customers that AWS is waiving all usage-related charges in the ME-CENTRAL-1 Region for March 2026. AWS did not delete customer billing data and usage data is available to customers upon request,” an AWS spokesperson said in an email.

The attacks, reportedly by Shahed 136drones, are believed to be the first time war has disrupted a major US hyperscaler, underlining the vulnerability of datacenters and the digital economy to this type of attack.

According to Amazon’s status page, the company’s Middle East datacenters are still suffering disruption as of late March, indicating that the impact of the drone attacks continues to be felt.

All datacenters targeted

AWS isn’t alone. Both sides in the conflict are attacking datacenters that they believe support their opposition. On March 5, Iran’s FARS News Agency, which has close ties to the Islamic Revolutionary Guard Corps (IRGC), issued a statement claiming the attacks on Amazon’s datacenters was the direct result of the facilities “supporting the enemy’s military and intelligence activities.”

And on March 11, Israel reportedly attacked a datacenter in Iranian capital Tehran in an attempt to disrupt bank services used to pay members of the IRGC.

In a highly unusual move, Amazon has confirmed that it is waiving an entire month’s usage charges for customers using two Middle Eastern datacenters disrupted by Iranian drone attacks earlier this month.

The attacks on March 1 damaged two Amazon datacenters in the region, ME-CENTRAL-1 (United Arab Emirates) and ME-SOUTH-1 (Bahrain), something the company acknowledged the following day.

“These strikes have caused structural damage, disrupted power delivery to our infrastructure, and in some cases required fire suppression activities that resulted in additional water damage,” Amazon advised on its service health page.

The disruption affected multiple Amazon services at these locations, including EC2, S3, DynamoDB, AWS Lambda, Kinesis, CloudWatch, and RDS, as well as the AWS Management Console and command line interface (CLI).

Last week, AWS expert and blogger Cory Quinn reported in an article on The Register that the company had emailed customers using these facilities with the news that March charges would be waived.

“AWS is waiving all usage-related charges in the ME-CENTRAL-1 Region for March 2026. This waiver applies automatically to your account(s), and no action is required from you,” Amazon wrote in the email quoted by Quinn.

“You will not see any March 2026 usage for the ME-CENTRAL-1 Region in your Cost and Usage Report or Cost Explorer once processing is complete,” the email reportedly continued.

Not just an invoice

While credits are sometimes applied to accounts related to service level agreements (SLAs) issues, waiving charges for an entire month appears to be unprecedented.

More contentiously, according to Quinn, the move would also have the effect of wiping essential Cost and Usage Report (CUR) data used in compliance and security forensics.

Quinn pointed out that the AWS CUR is not only a general billing facility; it gives customers a precise record of which services were consumed, essential for cost allocation. This also helps track wasted or under-used resources.

“For most organizations, the AWS bill isn’t just an invoice. It’s the canonical record of what infrastructure exists, where it’s running, and how long it’s been there,” Quinn wrote. Moreover, “compliance teams rely on it. Auditors request it. FinOps teams build their entire practice on it.”

In response to questions from CSO about this issue, Amazon clarified its statement, saying that usage data was filtered from billing reports so that customers would not see charges for the March period.

However, it said, customers would still be able to access billing data. “We notified customers that AWS is waiving all usage-related charges in the ME-CENTRAL-1 Region for March 2026. AWS did not delete customer billing data and usage data is available to customers upon request,” an AWS spokesperson said in an email.

The attacks, reportedly by Shahed 136drones, are believed to be the first time war has disrupted a major US hyperscaler, underlining the vulnerability of datacenters and the digital economy to this type of attack.

According to Amazon’s status page, the company’s Middle East datacenters are still suffering disruption as of late March, indicating that the impact of the drone attacks continues to be felt.

All datacenters targeted

AWS isn’t alone. Both sides in the conflict are attacking datacenters that they believe support their opposition. On March 5, Iran’s FARS News Agency, which has close ties to the Islamic Revolutionary Guard Corps (IRGC), issued a statement claiming the attacks on Amazon’s datacenters was the direct result of the facilities “supporting the enemy’s military and intelligence activities.”

And on March 11, Israel reportedly attacked a datacenter in Iranian capital Tehran in an attempt to disrupt bank services used to pay members of the IRGC.

This article originally appeared on NetworkWorld.

For the last 20 years, the economics of software were beautifully boring. The business model was predicated on a simple truth: Build once and sell infinitely. 

In the traditional SaaS era, the marginal cost of adding a new user was negligible. Whether a customer logged in once a month or once a minute, the cost to the vendor, a tiny slice of database storage and server capacity, remained relatively flat and predictable. This predictability allowed companies to scale aggressively, offering unlimited seats and all-you-can-eat plans with confidence. Margins were high, costs were fixed and scale was the ultimate solvent for all problems. 

Generative AI has broken that model. 

We have entered a new era where software has a variable cost of goods sold. Every time a user interacts with a Gen AI feature, cash leaves the building. It leaves in the form of computing power, database searches and third-party API fees. Engagement, once the North Star metric for product success, has become a double-edged sword. In this new reality, a highly engaged user is no longer guaranteed to be your most profitable customer. They might actually be your biggest liability. 

I call this the AI Volatility Tax. It is the silent erosion of gross margins caused by unmanaged, variable-cost intelligence, and it is currently the single biggest blind spot in enterprise innovation budgets. When inference costs rise faster than revenue per user, model performance becomes irrelevant because the business collapses before the model does. 

FOMO and the rush to negative margins 

Why are companies rushing into this trap? The driver is fear of missing out (FOMO). 

The pressure from boards to “do AI” is suffocating. This urgency triggers a collective suspension of disbelief regarding unit economics. We saw this in the dot-com bubble and we are seeing it again. Leadership teams are so terrified of being perceived as laggards that they are greenlighting features that are fundamentally structurally unprofitable. 

I recently advised a legal-tech firm that had integrated a powerful large language model (LLM) to help lawyers summarize case files. The product worked beautifully. It was accurate, fast and the users loved it. Usage skyrocketed post-launch. 

But when the first quarterly financial review arrived, the celebration ended. The team had routed every single query, from complex legal reasoning to simple keyword searches, through a high-end, reasoning-heavy model. When we modeled the unit economics, the math was brutal. For every $1.00 of subscription revenue the feature generated, the company was spending $1.20 on processing and infrastructure costs. 

They had achieved product-market fit but failed business model fit. They were effectively subsidizing their customers’ work with their own venture capital. This wasn’t a software business anymore; it was a charity for law firms. This is not innovation. It is wealth transfer. 

Sequoia Capital has highlighted this massive gap between the billions spent on AI infrastructure and the actual revenue realized by applications, dubbing it “AI’s $600B Question”. The gap exists because too many organizations are treating AI as a feature to be bolted onto existing fixed-price contracts rather than a consumable resource that requires a fundamentally different pricing and architectural strategy. 

The verification penalty 

There is another, more insidious layer to this inflation that rarely appears on the architecture diagram: The human cost of verification. We often assume AI output is “free” once the model is paid for, but in high-stakes B2B environments, that is a dangerous fallacy. 

I worked with a customer support platform that implemented an AI agent to draft responses to complex technical tickets. The goal was to reduce agent handling time by 50 percent. The model was expensive, but the projected labor savings were massive. 

Six months later, the savings hadn’t materialized. In fact, handling time had gone up. 

When we audited the workflow, we found the problem. The AI was generating responses that were 90 percent accurate. That sounds good, but it meant 10 percent of the responses contained subtle, hallucinated technical errors that could cause data loss for customers. Because the agents couldn’t trust the AI blindly, they had to read and verify every single line of the generated text against the documentation. 

It turns out that reading and fact-checking a confident-but-wrong paragraph often takes longer than writing the correct answer from scratch. We had traded “creation labor” for “verification labor,” and verification is harder to scale. The AI wasn’t a replacement for the human; it was a burden on the human. This “verification penalty” acts as a hidden tax on every transaction, eating away the margin gains we thought we had secured. 

The unit economics trap. This diagnostic from the AI Margin Audit breaks down the “variable cost of goods sold” for AI features. It highlights how infrastructure costs (LLM tokens, vector DBs, third-party APIs) can silently erode gross margins if not governed. 

The vendor trap: Why models are not commodities 

Compounding this volatility is the uncomfortable fact that you do not own the supply chain. In traditional software, you owned the server or rented a standardized slice of computing power. You knew exactly what a CPU cycle cost. 

In the Gen AI ecosystem, you are renting intelligence from a fluctuating oligopoly. The price of a processing token is not set by physics. It is set by business strategy. A model provider can change their pricing structure, deprecate a model or alter their rate limits with little notice. 

I have seen product roadmaps crumble overnight because a provider shifted their API pricing, instantly turning a profitable feature into a loss leader. This introduces a new layer of vendor risk that most product managers are ill-equipped to handle. We are used to worrying about uptime but now we have to worry about yield. 

If your entire product strategy relies on a specific proprietary model maintaining its current price point, you don’t have a strategy. You have a dependency. 

The multiplier effect of autonomous agents 

If basic “chat with your data” features are expensive, the next wave of AI, autonomous agents, threatens to multiply this volatility tax exponentially. 

Agents are designed to be independent. They don’t just answer a question. They reason, plan, execute tools and critique their own work. A single user prompt like “Plan my marketing campaign” might trigger a chain of 50 or 100 internal reasoning loops. The agent might search the web, read a PDF, write a draft, critique the draft and rewrite it, all while the billing meter is spinning. 

In a traditional software environment, loops are cheap. In a Gen AI environment, loops are expensive. Without strict governance, an agent getting stuck in a reasoning loop is the cloud equivalent of leaving a tap running in a drought. 

Governance is not just about safety or bias. As the National Institute of Standards and Technology (NIST) emphasizes in their AI Risk Management Framework, it is essential for economic viability. Organizations that fail to implement circuit breakers and cost caps on their autonomous workflows risk waking up to cloud bills that obliterate their quarterly earnings. 

The governance imperative: Dynamic orchestration 

So how do winning organizations avoid this tax? They stop treating intelligence as a monolith. 

The mistake the legal-tech firm made was using a PhD-level model to do intern-level work. Not every query requires the most expensive, smartest model on the market. 

The emerging best practice is dynamic model orchestration. This strategy treats intelligence like a supply chain. When a request comes in, a lightweight router assesses the complexity of the task. 

• Is it a simple classification task? Route it to a cheap, fast, specialized model. 

• Is it a summarization task? Route it to a mid-tier workhorse model. 

• Is it complex, multi-step reasoning? Only then do we authorize the expense of a frontier model. 

By matching the cost of the model to the value of the query, organizations can protect their margins. Gartner research on AI FinOps confirms that organizations implementing this type of cost governance early are able to accelerate adoption responsibly, while those who ignore it are often forced to shut down popular features due to runaway costs. 

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

For many organisations, the central question is no longer whether to modernise their organisation’s infrastructure, but how to do it in a way that benefits the business and its people.

Leaders are weighing these considerations as they determine if the time and investment on cloud migration is worth it. How can they position transformation as part of a broader commercial strategy, and not just a technical one?

This requires the strategic sequence of migration before any decommissioning of existing systems, said Google Cloud A/NZ Strategic Pursuits Lead Stu Turner.

That urgency and complexity are especially evident when organisations exit data centres, and they need to do so without triggering a long-term cost blowout.

“When you’re evacuating a data centre, it’s not just a migration. You’re trying to get out as quickly as possible,” explained Turner. “From a commercial perspective, you can use that as an opportunity to move out in year one, modernise onto something else, and repurpose that committed spend onto cloud-native services. But I’d caution against just lifting and shifting and think about the cost profile.”

How the cloud enhances IT operations

In a world where business demands are accelerating, decisions around what to modernise, what to keep, and when to move are critical to ensuring a smooth and effective transition. Migrating to a cloud-managed infrastructure platform allows workloads to be rapidly provisioned, scaled, and consolidated. It enables rationalisation of redundant virtual machines and software licenses, reducing maintenance overhead and improving operational efficiency.

The process can also uncover inefficiencies and opportunities, such as redundant virtual machines, obsolete software licenses, and gaps in disaster recovery processes.

By consolidating workloads onto cloud-managed platforms, organisations can reduce cognitive and operational load on IT teams, enabling them to focus on differentiating activities rather than maintaining non-core infrastructure.

Cloud’s human impact

Adopting a hybrid cloud model for critical enterprise systems and keeping legacy applications on premises is a strategy for stability, performance, and compliance. Applications that benefit from elasticity, high availability, and remote access—such as digital services, collaboration tools, and analytics platforms—are deployed to public cloud environments.

This is where the human benefits of hybrid adoption become most visible.  Hybrid cloud also reduces the need for overnight maintenance, urgent patching, or firefighting. These are the necessary but routine tasks every organisation must perform: manual processes, duplicated reporting, and legacy system maintenance. Over time, this fragments organisational effort across low-level work.

Reducing cognitive load means simplifying, modernising, and automating what doesn’t set the organisation apart. In doing so, the organisation can refocus its energy on creating value, driving innovation, and delivering better customer experiences.

By clarifying responsibilities and consolidating workloads on cloud-managed platforms, organisations streamline operations and reduce unnecessary effort for both IT teams and the broader business.

Managing migrations

For organisations managing cloud migration without operational interruption, a phased, staged approach is essential. Migration sequencing allows workloads to be consolidated, redundant infrastructure to be reduced, and licensing and maintenance costs to be optimised. It also enables rapid deployment of new workloads without extended project timelines.

This approach supports quick responses to peak demand or new business opportunities. By freeing operational capacity, a hybrid cloud model enables IT teams to focus on strategic initiatives rather than non-differentiating maintenance tasks.

This model also improves resilience and regulatory readiness. Having these efficiencies in place allows organisations to embed risk, security, and regulatory compliance into every phase of the migration.

For heavily regulated industries, requirements for data sovereignty, portability, and operational resilience must guide architectural decisions.

This means strategies focused on reducing single points of failure—including dependencies on third-party telecom providers—and ensuring continuity during regional outages. Importantly, governance structures, FinOps practices, disaster recovery procedures, and cost management policies also must be implemented gradually to support continuity and scalability.

This requires implementing shared responsibility models, SaaS backup requirements, and resilience testing to ensure long-term data protection, regulatory compliance, and operational continuity.

Continuous monitoring of costs, performance, and resource utilisation enables leadership to optimise infrastructure, manage risk, and adapt strategy as business needs evolved. Systems in cloud-native environments are generally more resilient, require less ongoing maintenance, and reduce operational risk compared with on-premises legacy applications. Having hybrid cloud as a value enabler rather than an inherently cheaper option requires active governance, cost optimisation, and visibility.

Choosing the right hybrid cloud to match an organisation’s business operations allows for a smoother transition to a modern infrastructure.

Try the Google Cloud migration assessment tool to start your organisation’s journey towards a modern cloud.

Shares in several prominent public SaaS companies fell approximately 10% heading into February, wiping out $300 billion in value. One of the instigators was Anthropic’s release of Claude Cowork with plugins in legal, marketing, and other business functions. Investors also read how AI writes 90% of Claude’s code, while technologists noticed that Claude Opus 4.5 and GPT-5.2 Codex hit 80%+ on the SWE-bench Verified benchmark.

Watching the news on those days, I heard financial analysts suggest that enterprises might walk away from their expensive SaaS contracts and replace them with AI capabilities, including in-house developed AI agents.

While a collapse in the SaaS business model seems improbable, recent advances in AI are a paradigm shift in how organizations develop and procure software capabilities. Last year, I asked whether AI is the end of IT as we know it and provided suggestions for what world-class IT looks like in the AI era. While markets have stabilized somewhat, CIOs must consider whether AI is the end of SaaS as we know it.  

“I don’t see AI agents taking over the functions of traditional SaaS apps, but they are currently redefining the role of software in the enterprise,” says Udo Sglavo, VP of applied AI and modeling at SAS. “Agents will increasingly act as autonomous operators across systems, abstracting away traditional graphical user interfaces and exposing capabilities through natural language and intent. That doesn’t mean SaaS will disappear; it will just become more composable, embedded, and invisible.”

AI’s software development capabilities and its ability to gain business function expertise raise several questions. Should CIO’s build more and buy fewer new SaaS capabilities? When should CIOs renew SaaS contracts rather than consolidate their existing SaaS investments? Below are five questions worth reviewing.

When should vibe coding replace SaaS?

Top CIOs will embrace AI’s democratization as the evolution of no-code and low-code development capabilities. Many will experiment with vibe coding to learn where they are effective in prototyping and whether they can deliver capabilities that meet their release criteria for AI agents.

A simpler, lower-cost build option may be palatable to some CIOs facing SaaS sprawl and seeking a more integrated user experience. For example, there are more than 15,000 marketing solutions, where integrating customer data and multiple SaaS solutions can be challenging.

There may also be cost considerations. Across all departments, large enterprises average more than 600 SaaS applications and spend $280 million annually on SaaS.

AI isn’t just coding; it can also help write requirements, maintain documentation, and simplify some multicloud complexities. The 2026 Agentic Coding Trends Report by Anthropic states, “Engineering teams discovered that AI can now handle entire implementation workflows: writing tests, debugging failures, generating documentation, and navigating increasingly complex codebases.”

So, should CIOs build more AI agents and applications because of AI’s coding capabilities, rather than buy or retain SaaS solutions?

Some CIOs may dismiss AI’s development capabilities as overly hyped or point to the added work (and cost) for evaluating whether an AI’s code meets coding requirements. More optimistic CIOs will seek ways to leverage AI code-generating tools to simplify the tech stack, reduce costs, or accelerate innovation. 

“Building makes sense when you have proprietary data or workflows no vendor can replicate, but only when your delivery pipelines, automated testing, and security controls can match the pace AI generates code,” says Ashwin Mithra, global head of information security at CloudBees. “Without that foundation, you’re not innovating faster; you’re compounding risks you can’t yet see.”

Before shifting to a build mentality, CIOs should evaluate whether their teams have the practices to support the full software development lifecycle (SDLC) and whether there’s sufficient funding for it. CIOs thinking about building more than they’ve done in the past should ask:

• Which employee workflows and customer experiences warrant the development of proprietary solutions, and what are the evaluation criteria?
• What are the new requirements for testing AI agents and evaluating the accuracy of AI models?
• What are the data governance non-negotiables, data privacy considerations, nonfunctional requirements, minimal DevSecOps standards, and other compliance requirements?
• What is the organization’s capability to plan, develop, test, deploy, and support applications, and where are AI capabilities improving this capability?
• How should the total cost of ownership be properly considered, especially in organizations that have historically underfunded app maintenance and support?

“The latest models make it easier for teams to prototype and build targeted tools quickly,” says Priya Vijayarajendran, CEO at ASAPP. “But most enterprise value comes from systems that can execute reliably across complex environments, with governance, integrations, and auditability built into the platform.”

What AI capabilities should I add to my SaaS evaluation?

I suspect far fewer CIOs will shift to building AI agents just because coding is easier. That said, CIOs should also raise the bar for the AI capabilities they expect from existing SaaS solutions and those under evaluation.

Experts suggest extending the enterprise evaluation around SaaS applications to include AI criteria, providing several examples:

• Srikrishnan Ganesan, co-founder and CEO at Rocketlane, suggests evaluating whether the product offers the most ambitious AI capabilities in its category and whether you can extend them with vibe coding to ease the building and maintenance of custom applications. 
• Titus Capilnean, VP at Civic Technologies, says employees are already using agents to access SaaS tools, so CIOs need to consider agent auditability, access governance, revocation, and how it fits into their infrastructure.
• Ronak Sheth, CEO at Pricefx, says to look for providers that embed governed, explainable AI directly into core business workflows and that orchestrate decisions across systems of authority, not those that layer chat on top of legacy screens.

When a SaaS platform is strategic and deeply embedded in existing operations, CIOs should review its product roadmaps, send staff members to its conferences, invest in training, and become active in customer advisory boards.

What should I expect around SaaS pricing?

CIOs are unlikely to abandon SaaS providers as fast as some investors sell their stocks. It’s also unlikely that SaaS companies will pass AI’s productivity gains on to customers in the form of lower prices.

“AI is materially changing development economics; the productivity gains are real, but the assumption that efficiency gains flow automatically to customers underestimates how SaaS pricing actually works,” says Bryan Gibson, VP of operational excellence at Teramind. “What CIOs should push for is more value at the same price point, not necessarily lower prices. The right pressure to apply at renewal is: Show me what AI has changed about your platform’s capability and my team’s productivity, and if the answer is thin, that’s negotiating leverage.”

Others suggest reviewing how SaaS companies are adjusting their pricing structures as work shifts from people to AI agents.

“CIOs should evaluate whether their SaaS providers are evolving beyond seat-based pricing toward outcome-based value,” says Adi Kuruganti, chief AI and development officer at Automation Anywhere. “Traditional SaaS models assume humans execute workflows, but AI agents increasingly perform work autonomously. If pricing is still tied to user access instead of measurable results, that’s a warning sign.”

If businesses continue to lay off people driven by AI productivity gains, it will affect SaaS companies with per-user licensing and subscription models. CIOs should expand their FinOps responsibilities to track shifts from per-user to other usage-based pricing models and their associated cost implications.

How should I prepare my organization for workflow changes?

One certainty is that CIOs must prep their organization for workflow changes. There are three scenarios to consider that all require change management efforts:

• Building internal capabilities to replace SaaS or consolidating SaaS platforms will need a change management plan to support the transition.
• Potential SaaS market impacts, such as provider acquisitions, reduced support offerings, or vendor closings, will require CIOs to develop risk mitigation and change plans.
• As SaaS solutions offer more AI agents with increased sophistication, ensuring adoption of those capabilities will also require change management efforts.

“The future of some SaaS platforms is not safe, just as the future of hardware, foundational models, and the next great innovation we haven’t yet conceived of will not be safe,” says Piyush Patel, chief ecosystem officer at Algolia. “CIOs must prepare their teams for massive SaaS changes by focusing on only one objective: delivering value to customers.”

Where should I seek differentiating capabilities?

One final question is how SaaS platforms market their differentiating capabilities. CIOs should look for these value adds that are not easy to quantify in build-versus-buy decisions or when comparing alternative solutions.

“There’s an uncomfortable question confronting those of us who sell software for a living: If everyone can build, why would anyone buy?” says Chuck Ganapathi, CEO at Gainsight. “The moat isn’t code anymore — it’s context, domain expertise, and the trust you gain from serving thousands of customers for decades.”

One important area SaaS platforms need to improve is their data strategy. Providing forms, reports, and workflows against siloed data sources is no longer viable. SaaS must demonstrate that it delivers value using the enterprise’s proprietary data, wherever it resides, and in accordance with the company’s data governance and compliance requirements.

“The winners in an AI-driven world apply AI to proprietary data sets that continually update, and embed AI into existing workflows so adoption doesn’t require changing everything,” says Jaime Meritt, chief product officer at Verint. “They will provide deep domain knowledge baked into every model, bot, and automation.”

CIOs should also review their SaaS platforms’ AI capabilities and ensure they enable multi-agent workflows with support for MCP server integrations.

“The warning sign for any SaaS company is whether it exposes an MCP server,”  says Andy Berman, CEO and co-founder at Runlayer. “The ones that become agent-accessible infrastructure survive, while the others clinging to human-only UIs are already being routed around.”

The challenging part for CIOs is that AI models and agentic AI capabilities continue to evolve. Today’s build-versus-buy decisions need to be future-proofed, but it’s highly unlikely we’ll see the end of SaaS because of AI.

When Amazon Web Services launched its Simple Storage Service (S3) in March 2006, it sparked the imagination of IT leaders worldwide. I remember that era well. It was a time when the enterprise was feverishly searching for a way out of restrictive, on-premises silos. S3 and the emerging concept of public cloud promised almost unlimited scalability, pay-as-you-go economics, and the freeing of IT departments from the shackles of hardware, data centers, and routine maintenance. The vision was that enterprises could offload their IT headaches and focus on business outcomes, letting cloud providers do the heavy lifting.

Twenty years later, S3 has ballooned into a monster-scale system of more than 500 trillion objects stored, hundreds of exabytes under management, and operations spanning every corner of the planet. Netflix, Spotify, and other companies have used S3 and the wider AWS ecosystem to reinvent whole industries, scaling to dimensions that would have seemed impossible in the pre-cloud era.

But as we light the candles on S3’s birthday cake, the reality for most enterprises does not match the sleek simplicity once promised. Far from outsourcing all their IT to the cloud, most organizations today find themselves facing greater complexity, reduced transparency, and spiraling costs. Cloud hasn’t eliminated traditional IT problems; it has merely shifted and, in many cases, compounded them.

The failed promise of savings

It turns out, in the vast majority of cases, that moving workloads to the cloud does not inherently reduce costs or complexity. Many enterprises naively expected a simple equation: Moving infrastructure to the cloud equals lower costs plus greater agility. Instead, organizations gradually discovered that the pay-as-you-go model could quickly balloon budgets when left unchecked.

Cloud spending often began as a tiny line item within IT budgets, but two decades on, it’s frequently one of the highest and fastest-growing costs, sometimes eclipsing the very expenses it was meant to replace. Enterprises face a jungle of service tiers, intricate pricing metrics, unexpected data egress fees, licensing quirks, and rapid consumption of compute and storage. The quest for scale and innovation, fueled by cloud computing, often leads to sprawl: hundreds or thousands of workloads distributed across multiple cloud accounts and regions, each adding yet another layer of expense.

The real concern for CIOs isn’t just surprise costs but the struggle to implement cloud discipline. Even for organizations that embrace finops (the emerging practice of cloud financial operations), the speed of innovation outpaces their ability to govern usage. Business units spin up workloads on a whim only to forget or abandon them. Cloud cost visibility is confounded by opaque billing dashboards, and the containerization trend has made it even harder to pin down exactly where money is going.

This runaway spending is not the result of malfeasance, but rather the product of the cloud’s core attribute: enabling rapid, frictionless innovation in exchange for complex, often unpredictable billing. In recent years, the pendulum has begun to swing back, with many organizations repatriating some workloads to on-premises infrastructure just to regain cost control and predictability.

The cloud giveth and taketh away

Early cloud pioneers believed that entrusting security to hyperscale providers would mean fewer headaches. After all, who better to patch, monitor, and defend IT infrastructure than the companies running the largest, most sophisticated data centers on earth? To an extent, this is true. Cloud providers have invested untold billions in every flavor of physical and software security.

But the paradox is that by its very flexibility and openness, cloud introduces enormous security and operational complexity. The infamous rash of open S3 buckets left exposed to the world due to default configurations or simple oversight testified to the challenges of managing distributed, cloud-native architectures. Enterprises must now invest in new skills, new tools, and new processes just to manage the endless stream of updates, permissions, encryption keys, and access policies. Instead of outsourcing pain points, many organizations just replaced one set of hassles with another.

Moreover, the notion of “set it and forget it” in the cloud has proven dangerously outdated. The constant drumbeat of threats, from ransomware to nation-state actors, combined with the proliferation of APIs and services, makes the cloud a shifting, ever-expanding attack surface. Enterprises are forced not only to upskill but also to adopt whole new mindsets around zero trust, observability, and resilience engineering.

The future: more of the same

The original fantasy of cloud was that it would be a single pane of glass: one provider (often AWS), powering an enterprise’s every workload, integrated from edge to core to SaaS. In reality, as we reach this 20-year milestone, we’re in a multicloud reality whether by design, accident, or necessity. Enterprises are now managing portfolios that span AWS, Microsoft Azure, Google Cloud, and sometimes dozens of SaaS or niche providers and their own private clouds.

This shift actually magnifies all previous challenges. Not only do organizations have to master the idiosyncrasies of each provider’s architectures, costs, and security models, but they must also contend with interoperability, data movement, compliance, and the talent gap across every platform in use. The modern IT estate is a patchwork, not a seamless fabric.

As the next chapter of the cloud era unfolds, three trends are set to dominate. First, finops will become inseparable from devops and IT operations as enterprises seek to assert financial discipline over their cloud estates. Second, continuous investment in security will be essential: not just tools, but human capital and process change, with automation serving as a key enabler. Third, complexity won’t disappear; the goal will be to manage and mitigate it, not magically eliminate it.

The 20th anniversary of S3 isn’t just a celebration of a technological achievement; it’s a sobering reminder that the journey to the cloud, for most enterprises, is more marathon than sprint. The dream of outsourced, seamless IT has, for most, become managed, governed, orchestrated complexity. The next 20 years will see continued investments in cost control, security, and managing the multicloud labyrinth. Cloud may have transformed technology forever, but for the enterprise, the work—and the surprises—is just beginning.

For more than a decade, application modernization has been viewed as a blueprint challenge or roadmap discipline. Organizations mapped their assets, created transformation frameworks, developed cost models and pushed execution through human-led programs. With external uncertainties, changing regulatory demands and competitive trends, CIOs’ strategic priorities have shifted between enterprise architectures, cloud and hybrid cloud models, automation, cybersecurity, compliance and now AI/GenAI. The agenda is straightforward and unchanged, continuous modernization for operational efficiency, model resilience and value creation.

Despite years of investments in cloud, Kubernetes, DevOps and platform engineering, many CIOs realize that the modernization acceleration largely remained static, planned by committees, executed as projects and governed by constrained, project-centric roadmaps. A BCG 2025 study reveals that only 5% of companies have achieved AI value at scale, while 60% report no material returns despite substantial investment. Even with an average GenAI spend of $1.9 million in 2024, fewer than 30% of AI leaders say their CEOs are satisfied with the AI investment returns.

The underlying application modernization pattern is now at a straining point as enterprise IT has entered a structural transition. With the advent of agentic AI, application modernization will see autonomy extend at the automation layer across the decision to execution journey. These systems bring self-assembling abilities that can organize, sequence and reconfigure modernization workflows across broad architectural layers and granular operating models. Yet the risk is structural, not technical. Gartner signals that over 40% of agentic AI initiatives will be discontinued by 2027 due to weak governance, unclear ROI, cost overruns and role–skill mismatch. The real crux lies in whether modernization success will stand on technology access and maturity, or how enterprises calibrate cultural and organizational readiness, governance mechanisms and the trust models to let autonomy actually work responsibly.

Organizations are now recognizing that modernization speed is no longer limited by strategic goals, access to technology or execution models. It is the human ability to understand and redesign a complex, interdependent stack faster than it evolves. Cloud reveals this issue. It simplified the infrastructure but increased the number of fragmented components. It raised abstraction but also expanded integration points. It streamlined deployment but increased architectural choices. Complexity spread faster than simplification. McKinsey’s State of AI 2025 global survey shows that while nearly nine in ten organizations now use AI regularly, only about one-third have scaled beyond pilots and experimentation.

Companies that once refreshed their systems every few years now feel quarterly pressure from cloud costs, customer experience expectations and shifting regulations. Application estates have become too large and heterogeneous for human-led modernization to keep pace. Modern enterprises are already churning the improvement levers, expanding cloud adoption, refactoring monoliths, enabling APIs, automating test and deployment pipelines and decomposing operational backlogs. Agile sped up delivery. DevOps automated pipelines. FinOps controlled cloud spending. Cloud gave flexibility and optionality. Yet the modernization gap persists between the pace of modernization and the rate of change. By the time modernization starts materializing, the business context has already shifted. With AI, this pattern is no different. Accenture’s survey of 2,000 companies finds that only about 8% have scaled AI at an enterprise level and embedded it into core business strategy.

Application modernization today is emerging beyond the unvarying roadmap-led, plan-and-control model. Modern estates are telemetry-rich, policy-driven and increasingly capable of autonomous reasoning and decision-making, which can be broadly classified as Agentic AI. The point is not that AI takes over modernization. It means the system becomes self-aware enough to refactor dependencies, adjust routing or optimize placement with bare human intervention or authorization chains. Here, the application stack self-examines its performance and makes adjustments based on cost, compliance, latency or demand.

Modernization becomes continuous, autonomous and dynamic, not periodic, human-managed and project-based. This shift is rather misconceived as technical optimism, but interestingly, its deeper implications are cultural and psychological. Technology tends to move faster than culture adapts and agentic models challenge long-standing assumptions about authorship, control and accountability in enterprise IT. For decades, architects have authored plans, developers have built them, committees have validated them and change management protects the timelines. Leaders held sovereignty through sign-off. Agentic autonomy breaks this equilibrium. Architects become policy stewards, setting constraints rather than planning detailed blueprints. Developers become validators rather than makers. Change management loses time as a control mechanism.

This raises a new leadership conundrum; when AI-driven systems reconfigure itself then who will own the outcomes? The real debate is not new versus old technology, nor the outdated autonomy versus human control narrative. It is about how enterprises pair autonomous technology with the cultural, organizational, governance and trust conditions required for autonomy to work. The accountability shift caused by autonomy aggravates the leadership readiness tension. McKinsey finds that employees are more prepared for AI than their leaders imagine, while a Gartner survey reports that only 15% of IT leaders are piloting fully autonomous agents and just 13% believe their governance structures are adequate to manage them.

Foundry’s State of the CIO research shows that as 82% of CIOs now define their role around digital and innovation leadership and 75% collaborate closely with business units on AI initiatives, modernization increasingly hinges on cross-functional governance and shared accountability. CIOs can argue the efficiency benefits of autonomy and boards can argue its competitive advantage, but the accountability structure changes in ways that are more fundamental.

Unlike the conventional model, where architects led execution and owned the outcomes, the autonomous model distributes ownership across humans, policies and machine agents. BCG reports that agentic architectures can deliver 20–30% faster workflow cycles and reduce tedious manual burden by up to 40%, but only when autonomy operates within governed, interoperable and policy-driven enterprise platforms. Autonomy does not override governance; it recalibrates it. Governance shifts from command-led to outcome-led, from plan sign-off to policy sign-off and from architectural authorship to architectural stewardship. The control surface also changes. The system becomes self-observing and self-correcting based on feedback loops rather than human foresight.

The shift to autonomous modernization flips the traditional question. CIOs once asked, ‘What is the business case to modernize?’ In today’s scenario of self-optimizing estate, the more relevant question becomes, ‘What is the business case to stop?’ When modernization becomes continuous, pausing it becomes the anomaly. Competitive advantage no longer lies in how quickly workloads move to cloud, but in how effectively the organization governs autonomous change. In that scenario, the modernization stack itself becomes a strategic differentiator.

For CIOs, this shift also forces a change in mental models. The prevailing logic has been plan-and-control: design, approve, execute and then measure. The agentic model works on sense-and-respond: observe continuously, decide autonomously, adjust incrementally and govern through policy. One depends on upfront completeness; the other depends on ongoing feedback. An empirical BCG study reinforces this shift, showing that nearly 70% of AI failures stem from people and process issues, with just 20% attributed to technology and 10% to algorithms, emphasizing why governance design must evolve in step with autonomous ambition. The organizational challenge is not only technical readiness but also cultural readiness to operate in an environment where modernization no longer pauses for meetings.

In earlier AI waves, the constraint was technical capability. Today, technical competency is largely a matter of accessibility and continued investment, but the real barrier is governance, culture and trust. These institutional disciplines require new organizational skills, new accountability structures and policy frameworks that define how autonomy is monitored, constrained and escalated. The problem is no longer whether systems can modernize; it is whether leadership can tolerate modernization that does not stop.

The question ahead for CIOs is not how to modernize faster, but how to govern autonomy at scale and close the cultural readiness gap before unlocking the efficiency, scale and responsiveness agentic modernization enables.

오라클(Oracle)은 AI가 자사 제품 포트폴리오의 핵심 요소로 자리 잡는 새로운 시대에 진입하면서 소프트웨어 개발 인력을 감축할 계획이다.

다만 오라클은 이번 조치가 이른바 ‘SaaS 아포칼립스(SaaSpocalypse)’, 즉 새로운 AI 구현이 기존 서비스형 소프트웨어(SaaS) 운영의 확산을 저해하는 현상 때문은 아니라고 선을 그었다. 대신 내부 개발 프로세스를 개선하고 효율성을 높이기 위한 전략적 선택이라는 설명이다.

오라클 최고경영자(CEO) 마이크 시칠리아는 분기 실적 발표 자리에서 “AI 도구와 그 코딩 역량은 우리가 이를 도입하지 않는다면 위협이 될 수 있다고 본다”라며 “하지만 오라클은 이미 이를 도입했고, 그것도 매우 빠른 속도로 진행하고 있다”라고 밝혔다. 이어 “오라클은 최고의 AI 코딩 도구와 최고의 개발자를 활용해 SaaS 사업을 가속화하는 동시에, 다양한 산업 전반의 생태계를 지원하는 솔루션을 제공하고 있다”라고 설명했다.

그러나 이 과정에서 상당한 규모의 인력 감축이 불가피하다는 점도 분명히 했다. 올해 1월 투자은행 TD 코웬은 오라클이 데이터센터 개발 자금 확보에 어려움을 겪으면서 최대 3만 개 일자리를 감축할 수 있다고 전망했다. 오라클은 수개월 전 재무제표를 통해 16억 달러(약 2조 3,000억 원) 규모의 구조조정 비용이 발생할 것이라고 밝힌 바 있으며, 이는 주로 고용 종료 및 계약 해지와 관련된 비용이라고 설명했다.

또한 오라클은 이번 분기 AI 혁신을 뒷받침할 신규 데이터센터 개발 자금 마련을 위해 500억 달러(약 74조 원)의 추가 부채를 조달했다.

그레이하운드 리서치(Greyhound Research)의 CEO 산칫 비르 고기아는 고객이 오라클의 접근 방식 변화에 주목할 필요가 있다고 말했다. 고기아는 “오라클은 현재 AI 데이터센터 확장과 맞물린 자본집약적 인프라 투자 사이클의 한가운데에 있다”라며 “벤더가 새로운 성장 동력에 수백억 달러를 투자할 경우, 포트폴리오의 다른 영역에서는 운영 최적화가 이뤄지는 경우가 많다”라고 분석했다. 이어 “이는 인력 구조조정이나 제품 로드맵의 우선순위 재조정 형태로 나타날 수 있다”라고 덧붙였다.

다만 오라클은 이러한 변화가 고객에게 부정적인 영향을 미치지는 않을 것이라고 강조했다. 시칠리아는 “오라클 내부에서 AI 코딩 도구를 활용함으로써 더 작은 엔지니어링 팀이 고객에게 더 완성도 높은 솔루션을 더 빠르게 제공할 수 있게 됐다”라며 “AI를 활용해 완전히 새로운 SaaS 제품을 개발하는 동시에, 기존 애플리케이션과 제품군에도 AI 에이전트를 직접 내재화하고 있다”라고 밝혔다.

전략적 전환

산칫 비르 고기아는 오라클의 엔지니어링 조직 재편을 단순한 인력 감축이 아닌 전략적 전환으로 해석해야 한다고 밝혔다. 최근 재무 실적을 보면 오라클의 성장은 이제 클라우드와 AI가 주도하고 있다. 이러한 불균형은 향후 수년간 오라클 경영진의 관심과 자본 배분, 엔지니어링 역량이 어디에 집중될지를 보여주는 신호라는 점에서 의미가 있다.

그렇다면 이는 오라클 고객에게 어떤 의미를 가질까.

인포테크 리서치 그룹(Info-Tech Research Group)의 자문 연구원 스콧 비클리는 “오라클의 지원 기반은 정체 상태에 있다”라며 “이는 일부 고객이 레거시 플랫폼을 떠나 클라우드 기반 솔루션으로 이동하고 있음을 시사한다. 그중 일부는 오라클로 옮기지만, 그렇지 않은 경우도 있다”라고 설명했다. 이어 “오라클은 AI 인프라를 주요 매출 성장 동력으로 삼는 방향으로 초점을 옮겼고, 그 과정에서 AI를 활용해 자사 소프트웨어를 보다 효율적으로 개발하고 있다”라고 평가했다.

고기아는 고객이 변화를 체감하더라도 그 속도는 점진적일 것이라고 내다봤다. 고기아는 “오라클 제품이 갑자기 품질 저하를 겪을 가능성이 당장 크다고 보기는 어렵다”라며 “대규모 설치 기반을 보유한 엔터프라이즈 플랫폼은 하루아침에 무너지지 않는다”라고 진단했다. 다만 “보다 현실적인 우려는 혁신 속도의 점진적 변화”라며 “일부 제품 영역은 개발이 가속화될 수 있지만, 다른 영역은 기능 개선이 줄어들거나 릴리스 주기가 느려질 수 있다”라고 분석했다.

이어 “오라클 데이터베이스, 엔터프라이즈 애플리케이션, 미들웨어에 대한 의존도가 높은 고객은 해당 제품이 오라클의 장기 로드맵에서 여전히 핵심 전략 우선순위로 유지되는지 면밀히 살펴볼 필요가 있다”라고 조언했다.

지원 공백에 대비해야

인포테크 리서치 그룹의 스콧 비클리는 오라클의 기존 소프트웨어 제품을 사용하는 고객이 향후 거래 방식에 변화를 모색할 필요가 있다고 봤다. 비클리는 “현재 소프트웨어 시장은 AI 투자 비용을 반영해 가격이 상승하는 인플레이션 환경에 놓여 있다”라며 “오라클 고객은 다년 계약을 체결해 조건을 고정하는 전략을 고려해야 한다”라고 조언했다. 이어 “ERP는 머지않아 핵심 범용 플랫폼으로 인식되고, 그 위에 산업별 특화 기능이 AI 기반으로 구현되는 구조가 될 수 있다”라며 “이에 따라 상업적 계약 구조는 소비 기반 모델로 전환될 가능성이 높으며, 비용을 효과적으로 관리하기 위해 핀옵스(FinOps) 체계가 요구될 것”이라고 전망했다.

산칫 비르 고기아는 계획된 인력 감축이 가져올 수 있는 또 다른 영향도 경고했다. 고기아는 “고객은 지원 및 엔지니어링 조직의 연속성을 면밀히 살펴야 한다”라며 “구조조정 과정에서 숙련된 개발자가 회사를 떠나면 레거시 시스템에 대한 조직 차원의 지식이 약화될 수 있다”라고 설명했다. 이어 “엔터프라이즈 소프트웨어 환경은 복잡하고 기업 운영 전반과 깊이 통합돼 있다”라며 “AI 코딩 도구가 엔지니어를 지원할 수는 있지만, 수년간 축적된 제품 전문성이나 아키텍처에 대한 이해를 자동으로 대체할 수는 없다”라고 분석했다.
dl-ciokorea@foundryco.com

Oracle is set to shed software developers as it enters a new era: one where AI is an integral part of its product portfolio.

However, the company is emphasizing that this move is not due to the so-called SaaSpocalypse, where new AI implementations damage the rollout of traditional SaaS operations. Instead, it is seeking to improve its internal development processes.

“I do think that AI tools and their coding capabilities would be a threat if we were not adopting them, but we are — and very rapidly,” said Oracle CEO Mike Sicilia, during the company’s presentation of its quarterly results. “Oracle Corporation is using the best AI coding tools and the best developers not only to accelerate our SaaS business, but to deliver solutions that enable entire ecosystems across numerous industries.”

However, the company has made it clear that there will be some hefty job losses along the way. In January this year, a report from investment bank TD Cowen predicted that the company could be looking at cutting 30,000 jobs as it struggles to find funding for data center development. Oracle had issued a warning of this a few months earlier, when it produced a financial statement talking of $1.6 billion restructuring costs, mainly related to “employment severance and contract termination”.

The company also secured another $50 billion in debt this quarter, to fund development of new data centers to drive AI innovation.

Customers should look out for changes in the company’s approach, said Sanchit Vir Gogia, CEO of Greyhound Research. “Oracle is currently in the middle of a capital-intensive infrastructure cycle tied to the expansion of AI data centers,” he said. “When a vendor is investing tens of billions of dollars into a new growth engine, other parts of the portfolio often experience operational optimization. This can manifest through workforce restructuring, and tighter prioritization of product roadmap.”

However, the company insists that its customers will not be adversely affected by these changes. “The use of AI coding tools inside Oracle Corporation is enabling smaller engineering teams to deliver more complete solutions to our customers more quickly,” said Sicilia. “We are building brand new SaaS products using AI and also embedding AI agents right into our existing applications and suites.”

A strategic pivot

Oracle’s decision to restructure engineering should be interpreted by customers as a strategic pivot rather than simply a workforce reduction story, Gogia said. Its most recent financial results show that the company’s growth is now driven by cloud and AI. This imbalance matters because it reveals where Oracle’s management attention, capital allocation, and engineering energy will be directed in the coming years.

But what does this mean for Oracle customers?

Scott Bickley, advisory fellow at Info-Tech Research Group, said, “Oracle’s support base is stagnant, which indicates that customers may be leaving the legacy platforms for cloud-based solutions — some moving to Oracle, some not. Oracle’s focus has shifted to AI infrastructure as the major revenue growth driver, rightfully so, and in the process, is leveraging AI to more efficiently build its own software.”

Gogia added that customers would see some change, but very gradually. “The immediate risk is not that Oracle products will suddenly degrade,” he said. “Enterprise platforms with large installed bases rarely collapse overnight. The more realistic concern is gradual changes in innovation velocity. Some product areas may accelerate, while others receive fewer enhancements or slower release cycles. Customers that depend heavily on Oracle databases, enterprise applications, or middleware should therefore watch closely whether those products remain core strategic priorities inside Oracle’s long-term roadmap.”

Beware the support discontinuity

Info-Tech’s Bickley agreed that customers of Oracle’s established software products should be looking to make changes to the way that they deal with the company. “Oracle customers should lock in deals for multi-year terms, as the current environment for software is highly inflationary, with prices driven higher to support these AI investments,” he said. “ERP may soon be viewed as a core commodity, whereby industry vertical specialization is AI-created around the core. This will shift commercial constructs to a consumption model requiring FinOps discipline to manage costs effectively.”

Gogia also warned about one effect of the planned layoffs: “Customers should monitor support and engineering continuity,” he said. “When experienced developers leave during restructuring cycles, organizations sometimes lose institutional knowledge about legacy systems. Enterprise software environments are complex and deeply integrated into business operations. AI coding tools can assist engineers, but they do not automatically replace years of product expertise or architecture familiarity.”

지난해 AI에 대규모 투자가 이뤄졌지만, 실제로 측정 가능한 성과를 낸 기업은 많지 않았다. PwC의 2026년 1월 글로벌 CEO 설문조사에 따르면 CEO의 56%는 지난 12개월 동안 AI로 매출이 늘거나 비용이 줄었다고 답하지 않았다. 가트너 조사도 비슷하다. AI로 비용을 절감했다는 CFO는 5%, 매출이 증가했다는 CFO는 6%에 그쳤다. 그렇다면 이런 저조한 수치의 배경에는 무엇이 있을까?

중고차 유통 기업 카맥스(CarMax)의 EVP 겸 CITO 샤밈 모하마드는 “많은 기업이 완전히 잘못된 것을 측정하는 데 지나치게 집중하고 있다. AI를 어떻게 측정해야 하는지에 대한 근본적인 오해가 있다”라고 지적했다.

기업이 비즈니스 목표를 잘못 설정하는 경우도 많다. 대표적인 예가 직원 생산성 향상이다. 소프트웨어 개발자 1인당 2시간을 절약해주는 AI가 있다고 해도, 그 시간이 실제로 어떤 사업 성과로 이어졌는지 CFO에게 설명하지 못하면 큰 의미가 없다. 하지만 그 연결고리를 입증하는 일은 쉽지 않다. 일부 기업은 효율 개선을 실현하는 데 필요한 조직 변화관리의 수준도 과소평가했다. 여기에 성과 중 얼마가 AI 덕분인지 가려내거나, AI 프로젝트를 대규모로 운영할 때의 지속 비용을 예측하는 문제까지 겹치면서 측정은 더 어려워진다.

AI 생산성 향상이 인력 감축이나 채용 축소로 이어질 것이라고 기대했던 CEO는 많았지만, 실제 결과는 기대에 못 미쳤다. 가트너에 따르면, 인력 감축이 가능하려면 최소 50~70% 수준의 생산성 향상이 필요하다. 가트너의 애널리스트 네이트 수다는 “이 정도 수준에 도달한 사례는 많지 않다. 대부분 사례는 전혀 개선이 없거나, 있어도 30% 안팎에 머문다”라고 설명했다.

반면 일부 기업은 전략적 사업 성과와 AI를 정렬하고, ROI를 장기적으로 바라보며, 전통적인 재무 지표 안에 꼭 들어가지 않더라도 핵심 사업 목표에 집중해 성과를 내고 있다. 다음은 AI 추진 과정에서 적용하거나 점검해야 할 5가지 핵심 기준이다.

1. 올바른 프로젝트를 고르고 전략적 사업 목표와 맞춰라

성공 지표와 이정표를 논하기 전에 먼저 해야 할 일은 명확하다. 사업 목표와 맞는 사용례를 고르고, 가장 전략적으로 중요한 사업 성과를 우선순위에 두는 일이다. 동물용 의약품 기업 조에티스(Zoetis)의 EVP 겸 최고 디지털·기술 책임자 키스 사보는 “이사회와 함께 연구개발과 커머셜 부문 사용례의 우선순위를 정했다”라고 밝혔다.

사업 성과 자체를 기준으로 비교해야 하며, 업계 선도 기업과의 투자 수준도 비교해야 한다. 금융서비스 업계 선도 기업을 조사한 결과를 보면, 데이터와 AI에는 전체 IT 예산의 15~20%가 투입됐다. IT 예산 자체는 기업 매출의 10~12% 수준이었다. 프랙티셔너스 포 프랙티셔너스(Practitioners for Practitioners)의 최고 임원이자 에드워드존스(Edward Jones)의 전임 최고 데이터·AI 책임자였던 자르 툴란은 “수치는 기업마다 다를 수 있지만, 핵심 경쟁사가 어디에 얼마나 투자하고 있고 또 어디에서 자원을 줄이고 있는지 파악하는 것이 중요하다”라고 강조했다.

네이트 수다는 기술 부문이 아닌 경영진이 AI 지출을 결정하는 경우가 많고 실제 구현은 기술 리더가 책임진다며, 이 때문에 기대 가치와 시간표에 대한 공동 이해가 필요하다고 봤다.

카맥스는 실제로 그렇게 하고 있다. 모하마드는 “사업 부문 책임자가 기대 효과를 약속하고, CFO와 기술 리더가 해당 사용례를 검토한다”라며, “비용은 해당 사업부 예산에서 집행되고, 책임은 사업부장이 진다”라고 설명했다.

조에티스는 고객서비스팀의 생산성을 높이기 위한 AI 파일럿을 추진하면서 통화당 소요 시간과 후속 조치 생성 시간을 함께 측정했다. 통화 시간은 거의 변하지 않았지만, AI가 후속 조치 추천을 생성하면서 후속 업무 시간은 크게 줄었다. 고객 경험의 질은 좋아졌고, 팀은 더 많은 고객에게 대응할 수 있게 됐다. 이것이 조에티스가 가장 중요하게 본 성공 지표였다. 조에티스는 마이크로소프트 코파일럿과 추가 AI 기능도 도입해 AI 활용을 확산했지만, 현재는 공급망과 계약 라이프사이클 관리 등 더 큰 변화를 만드는 영역에 집중하고 있다.

결국 조직의 사업 전략과 맞물린 전사적 AI 전략이 중요하다. 툴란은 에드워드존스에서 데이터·AI 전략을 수립하는 데만 2년이 걸렸다고 전했다. 에드워드존스는 자사 데이터로 학습한 생성형 AI 도구를 자문 인력에게 제공했고, 미팅 노트와 CRM 데이터에 기반해 고객 포트폴리오 계획을 빠르게 작성할 수 있도록 지원하는 자문 에이전트도 개발했다.

툴란은 “사내 리서치를 고객 계획과 대조한 뒤, 고객에게 그 계획을 어떻게 실행할지 추천안을 제시한다”라며, “자문팀은 주당 약 하루 분량의 업무 시간을 절감했고, 고객에게 더 빠르게 대응할 수 있게 됐다”라고 설명했다. 이어 “고객과 더 깊이 있는 상담이 가능해졌고 고객 만족도 점수도 높아졌으며, 고객 성과 역시 고객 목표에 더 잘 부합하게 됐다”라고 덧붙였다.

고객서비스를 개선하는 AI는 손익계산서에도 직접 영향을 줄 수 있다. 고객 이탈이 줄면 매출 손실을 막을 수 있고, 전환율이 올라가면 매출이 늘어난다. 관건은 매출 변화 자체를 측정하는 것과, 그 영향 중 얼마가 AI와 직접 연결되는지 구분하는 일이다.

재무 효과가 크지만 눈에 잘 띄지 않는 프로젝트도 있다. 예를 들어 더 정확한 판매·매입채무 예측을 통해 자본 활용도를 높이면 운영 자본 사이클과 평균 회전성 부채 활용도를 크게 개선할 수 있다. 이는 사실상 유동성을 늘리는 효과다. 수다는 “정확도가 높아질수록 필요한 운영 자본 규모나 회전성 부채 이자 지급액이 줄어든다”라며, “둘 다 잉여현금흐름을 늘릴 수 있어 기능적으로는 비용 절감과 비슷하게 보지만, 재무제표상 나타나는 위치는 다르다. 운영 자본 축소는 현금흐름표에, 회전성 부채 이자비용 절감은 손익계산서에 반영된다”라고 설명했다.

어떤 AI 프로젝트는 목표가 수익이 아니라 기본 방어선 구축일 수도 있다. 이미 챗GPT 같은 도구에 익숙한 사용자를 따라잡기 위해서다. 기업이 기본적인 생성형 AI 도구를 제공하지 않으면, 직원이 회사 데이터를 공개형 도구에 넣어 분석할 위험이 생긴다. 자체 코파일럿이나 GPT 환경을 갖추는 비용보다 이 위험이 더 클 수 있다.

생성형 AI는 이제 사무직 직원의 기본 도구로 자리 잡아가고 있다. 콜로니얼 파이프라인(Colonial Pipeline) 전 SVP 겸 CTO 압시언 탈라사즈는 “조직에서 엑셀의 가치를 어떻게 측정하겠는가? 모두가 사용하지만, 이제는 그 필요성을 따로 묻지 않는다. 생성형 AI가 아직 그 단계까지 온 것은 아니지만, 일하는 방식과 비용, 기업 내 기대치가 바뀌면서 충분히 그런 결과로 갈 수 있다”라고 말했다.

2. 실제 비용 구조를 정확히 파악하라

ROI를 추정할 때 가장 까다로운 부분은 투자, 즉 비용 분모를 정확히 파악하는 일이다. 전통적인 IT 프로젝트와 달리 AI는 구축 비용보다 운영 비용, 특히 대규모 확장 이후의 운영 비용이 더 크다. 수다는 “AI는 기존 공식을 뒤집기 때문에 그 점을 감안해 계획해야 한다. CIO에게는 익숙하지 않은 비용 구조다”라고 짚었다.

문제는 판 자체가 크다는 점이다. 개별 AI 프로젝트의 비용뿐 아니라, 이를 뒷받침하기 위해 선행돼야 하는 데이터·인프라·거버넌스 투자까지 감안하면 리스크는 더 커진다. 사보는 “25년간 기술 분야에 있었지만, 지금까지 해본 것 중 가장 비싸고 복잡한 일”이라고 털어놨다.

다만 모든 프로젝트가 고비용인 것은 아니다. 탈라사즈는 “큰 비용이 들지 않는 프로젝트도 봤고, 수백만 달러가 드는 프로젝트도 봤다”라고 말했다. 프로젝트 비용은 내부 인력이 직접 구축·개발할 수 있는지, 외부 파트너에 의존하는지, 데이터와 인프라 요건을 이미 충족했는지, 전체 시스템이 디지털화돼 클라우드에 올라가 있는지 등에 따라 달라진다.

성과 측정 방식은 ROI 계산에도 직접 영향을 준다. 탈라사즈는 대부분의 프로젝트가 공통 플랫폼 위에 올라가는데, 플랫폼 구축 비용이 상당할 수 있고, 그 비용을 어떻게 배분하느냐에 따라 개별 AI 프로젝트의 경제성이 달라진다고 설명했다. 그래서 프로젝트별 경제성도 중요하지만, 전체 그림을 보기 어려운 경우가 많다. 혁신성과 불확실성이 큰 프로젝트는 제약업의 신약 개발이나 석유·가스 탐사 같은 리스크 자본 프로젝트의 성격을 띠기도 한다는 것이다. 탈라사즈는 “데이터와 AI 인프라 투자, 플랫폼화, 확장성, 도입 속도에 대한 불확실성, 다른 사용례와의 연결성을 함께 봐야 하기 때문에 AI 프로젝트의 재무 지표는 개별 과제보다 포트폴리오 차원에서 설명하는 편이 더 효과적”이라고 분석했다.

핀옵스 재단의 AI 워킹그룹도 AI 프로젝트 가치를 더 세밀하게 측정하는 방법을 논의 중이다. 재단의 최근 현황 조사에 따르면, AI 지출을 관리하는 기업은 98%로, 2년 전 31%에서 크게 늘었다.

재무 보고에 쓰이는 지표 자체는 같지만, 그 지표를 산출하기 위해 필요한 데이터는 AI에서 전혀 다르다. 게다가 그 데이터를 얻는 일도 쉽지 않다. 핀옵스 재단의 펠로우 로브 마틴은 “AI는 사용 시간 대신 토큰, 사용 시간과 분 대신 API 호출 수로 성과를 측정한다. 문제는 비용과 사용량 데이터가 청구 데이터와 함께 제공되지 않는 경우가 많다는 점”이라고 지적했다. 결국 기업은 API 프록시나 서드파티 제품을 통해 별도로 수집할 수밖에 없다.

문제는 여기서 끝나지 않는다. 모델이 실제 사용된 토큰 수를 제대로 알려주지 않는 경우도 있다. 마틴은 “AI 비용과 서비스 가용성은 변동성이 더 크기 때문에, 모델을 대규모로 운영할 때의 비용을 정확히 예측하지 못할 수도 있다”라고 말했다. 이 때문에 많은 IT 임원이 고정 수치 대신 범위로 비용을 전망하고 있다. 마틴은 CIO가 의장을 맡는 AI 투자위원회나 태스크포스를 만들고, AI 지출과 관련된 모든 이해관계자와 함께 핀옵스 범위를 정의해야 한다고 조언했다. 또 경쟁하는 프로젝트를 단계적으로 자금 지원하고, 데이터 수집·분석 계획을 수립하며, 성과 지표를 이사회 언어로 번역해줄 수 있는 경험 많은 임원이 필요하다고 덧붙였다.

3. 성공 가능성이 큰 지표에 우선순위를 둬라

가트너가 제시한 10가지 AI 가치 지표 가운데 생산성은 하위권에 속한다. 자본 활용도를 높이거나 손실을 줄이고, 고객 경험을 개선하거나, 신제품 개발에 기여하는 프로젝트가 매출 성장 측면에서 훨씬 큰 잠재력을 가진다.

운영 지표인 순추천지수(NPS), 시간당 산출량, 백로그 감소는 모두 직원 대비 수익성과 관련이 있다. 반면 직원 1인당 평균 인건비, 매출과 전환율, 회피된 손실 같은 재무 지표는 ROI를 보여준다. 트래픽과 클릭 수, 시장점유율 성장 같은 선행 지표는 가트너가 말하는 ‘미래 대비 수익’과 연결된다.

툴란은 모든 기업이 따라야 할 AI 스코어카드 기준이 있다고 본다. 다만 조직 상황에 맞게 조정해야 한다는 전제를 달았다. AI 전략을 평가하고, 기술 스택이나 플랫폼을 점검하며, 기술을 도입하는 직원의 사고방식과 역량 측면에서 AI 준비도를 확인하고, 최종적으로 원하는 사업 성과와 실제 결과를 비교해야 한다는 것이다. 툴란은 “이 기준은 산업과 업종 특성에 맞아야 하고, 조직이 AI 여정의 어느 단계에 있는지도 반영해야 한다”라고 강조했다.

다만 원하는 사업 성과를 설명하는 데 전통적인 재무 지표만이 항상 최우선은 아니다. 예를 들어 목표가 고객만족도 개선이라면 NPS 설문 같은 지표가 중요할 수 있다. 그러나 이 역시 한계가 있다. 사보는 “설문 응답에 의존해야 하기 때문에, 개선 가치가 실제보다 부풀려질 가능성이 있다”라고 지적했다.

카맥스는 두 개의 주요 AI 프로젝트에서 고객만족도, 전환율, 매출을 가장 중요한 지표로 본다. 이 온라인 자동차 유통업체는 고객이 구매 과정을 더 쉽게 이해할 수 있도록 돕는 AI 어시스턴트 ‘스카이(Skye)’를 구축했다. 또 ‘로즈(Rhodes)’라는 가상 에이전트는 콜센터 상담원에게 어떤 질문을 해야 하는지 제안하고, 필요한 문서를 빠르게 찾게 하며, 주별 규정과 정책 탐색도 지원한다.

모하마드는 “시간 절감도 좋은 지표이지만, 우리가 보는 것은 그 시간이 어떤 사업 성과를 만들어내는가”라며, “확보된 시간을 활용해 회사에 더 큰 가치를 어떻게 만들고 있는지가 핵심”이라고 설명했다.

NPS 점수는 고객 경험 개선을 보여준다. 스카이와 로즈를 함께 운영한 결과 전환율은 높아졌고, 매출도 늘었다. 모하마드는 “핵심은 상담원의 역할이 단순 정보 검색자에서 신뢰할 수 있는 조언자로 고도화되고 있다는 점”이라며, “역할은 서로 융합되고 있고, 사람들이 하는 일은 재정의되며, 프로세스도 다시 설계되고 있다”라고 말했다.

4. 사용자를 준비시키고 실제 수용률을 추적하라

아무리 잘 설계한 AI라도 사용자가 받아들이지 않으면 실패한다. 그래서 사용자 수용도는 사전 준비가 필요한 또 하나의 핵심 지표다. AI 모델만 학습시키는 것으로는 부족하다. 조직 내 역할에 맞게 AI를 개인화하고, 사람들이 실제로 AI를 활용하는 방법까지 교육해야 한다. 툴란은 “업무 흐름 안에서 훌륭한 경험이 돼야 한다. 그렇지 않으면 만족도 점수는 낮아지고 AI 도입률도 떨어진다”라고 경고했다.

조에티스도 초기에 변화관리 투자 규모를 과소평가했다. 사보는 “초기에는 얼마나 빨리 움직일 수 있느냐에만 초점이 맞춰져 있었다”라며, “만들기만 하면 사람들이 사용할 것이라고 생각했지만, 사용자가 일상 업무에 어떻게 녹여야 하는지 이해하지 못하면 가치는 나오지 않는다”라고 덧붙였다.

5. 장기 가치까지 보되, 과장은 피하고 판단을 믿어라

카맥스가 최고경영진에게 보고하는 AI 프로젝트 지표는 크게 네 가지다. ROI, 매출 영향, 비용 효율성, 그리고 경쟁우위 확보 역량으로서의 전략적 가치다.

AI 프로젝트의 사업 가치를 설명할 때는 ‘가치 노출도’ 개념도 포함해야 한다. 각 AI 사용례는 데이터·프로세스·플랫폼의 변화를 요구할 수 있고, 그 과정에서 다른 프로젝트도 활용할 수 있는 새로운 역량이 생길 수 있기 때문이다. 탈라사즈는 “하나의 프로젝트가 다른 기회를 여는 경우가 많다”라며, “다른 프로젝트의 비용과 편익을 아직 세부적으로 알지 못하더라도, 현재 프로젝트가 전략적으로 새로운 역량을 열고 있다는 사실 자체에 가치가 있다”라고 설명했다. 또한, 경쟁 차별화 요소가 될 프로젝트라면 그것을 평가할 성공 지표도 별도로 필요하다고 덧붙였다.

탈라사즈는 프로젝트를 제안할 때 기대치를 투명하게 설정한다며, “단일 재무 지표 하나만 제시하지 말고, 여러 시나리오를 함께 보여주는 것이 중요하다. 각 결과에 영향을 주는 전제와 변수까지 함께 설명해야 한다”라고 강조했다. 예를 들어 도입률이나 구현 속도에 따라 기대 성과가 어떻게 달라지는지까지 포함해 그림을 그려준다는 것이다. 탈라사즈는 “리더들은 각각의 점이 어떻게 연결되는지, 더 큰 그림이 무엇인지 이해하고 싶어 한다”라고 말했다.

결국 가장 중요한 성공 지표는 손익계산서에 미치는 영향과 해당 AI 사용례가 직원 경험에 어떤 변화를 주는지를 보여주는 지표다. 사보는 “프로세스 어느 단계에서든 정량 지표를 붙일 기회가 있다면 반드시 붙여야 한다. 다만 AI는 아직 초기 도입 단계이고 새로운 영역이기 때문에, 지금은 측정할 수 없는 요소도 분명 존재한다. 그래서 때로는 사업을 잘 아는 사람들의 판단을 믿어야 한다. 다만 상식적으로 접근하고, 결과를 과장하지 않는 것이 중요하다”라고 강조했다.
dl-ciokorea@foundryco.com

Despite massive investments in AI last year, most businesses have struggled to achieve measurable results. In PwC’s January 2026 Global CEO Survey, 56% of CEOs reported neither increased revenue nor decreased costs from AI in the last 12 months — a statistic backed by Gartner figures that show only 5% of CFOs have reported cost reductions due to AI, and only 6% have reported revenue increases. So what’s behind those dismal numbers?

“They’re really laser-focused on measuring the wrong things,” says Shamim Mohammad, executive VP and CITO at CarMax. “There’s a fundamental misunderstanding of how to measure AI.”

Companies also tend to focus on the wrong business goals, such as boosting employee productivity without fully capturing business outcomes. An AI that saves two hours of time per software developer means nothing unless you can tell the CFO what they did with that time, and that can be hard to do. Also, some corporations have underestimated the level of organizational change management required to achieve efficiency gains. And the metrics to assess performance, such as what percentage of any gains are directly attributable to AI and predicting the ongoing costs of running AI projects at scale, can be difficult to nail down.

Some CEOs who thought AI productivity gains might demonstrate value by reducing headcount or new hires have also come away disappointed. Organizations need at least a 50 to 70% productivity gain before headcount can be reduced, according to Gartner. “We’re not seeing many use cases this high,” says Nate Suda, the research firm’s senior director analyst, with most falling between no gain at all to about 30%.

But some organizations are achieving results by aligning with strategic business outcomes, taking a long view on ROI, and focusing on critical business goals that may or may not fall inside the purview of traditional financial metrics. So here are five key benchmarks to apply to, or check against, your AI pursuits.

Choose the right projects and align with strategic business goals

Before considering success metrics and milestones, make sure you have use cases aligned with business goals, and you’ve prioritized the most strategically important business outcomes. The business cases for AI should come from the top down, says Keith Sarbaugh, EVP and chief digital and technology officer at animal health firm Zoetis. “Working with the board, we prioritized use cases in R&D and commercial business areas,” he says.

Also, benchmark against strategic business outcomes, and benchmark spend against best-in-class organizations in your industry, adds Zar Toolan, former chief data and AI officer at Edward Jones, and current executive-in-residence at Practitioners for Practitioners, a network of expert AI and data advisors. Based on his research of category-leading organizations in the financial services sector, for example, data and AI consumes 15 to 20% of overall IT budgets, which itself constitutes 10 to12% of topline revenue for the business. “While these numbers will vary by organization, it’s important to know where and how much your key competitors are investing and divesting,” he says.

Non-tech leaders are often the ones deciding on AI spend, while tech leaders are responsible for implementation, Suda says, which necessitates a shared understanding of value expectations and timescales.

That’s what’s happening at CarMax. “The business owners sign up for the benefits, and the CFO and I review the use cases,” Mohammad says. “The cost comes out of the budget for that business unit, and accountability lies in the hands of the business unit head.”

When Zoetis decided to pilot an AI project to make the customer service team more productive, it measured time spent on each call, and the time required to generate a follow up. The former stayed constant while the latter improved dramatically due to AI-generated follow up recommendations. The quality of the experience improved, and the team was able to reach more customers, which was the primary success metric. Zoetis also deployed Microsoft Copilot and additional AI capabilities to democratize AI, but is now focused on bigger transformative things in the areas of supply chain and contract lifecycle management.

So having an overall AI strategy aligned with your organization’s business strategy is crucial. At Edward Jones, the process of setting up its data and AI strategy stretched over two years, says Toolan. The company armed advisors with gen AI tools trained against the firm’s own data, and developed advice agents to help its financial advisors quickly create plans for client portfolios using inputs from meeting notes and data in the CRM system.

“It takes internal research, matches that with the client’s plan, and gives recommendations about how to implement the plan for the client,” he says. Advisor teams saved about one person day per week and could get back to clients faster. “They could go deeper with clients, had better client satisfaction scores, and client outcomes were better aligned with what was most important to their goals,” he adds.

AI that improves customer service can also have a direct impact on the P&L sheet. For example, a reduction in customer churn avoids revenue losses, while an increase in conversions leads to higher sales. The trick lies in measuring the change in revenues and determining what percentage of any impacts are directly related to AI.

Still, other projects may have strong financial benefits that are less visible. For example, using AI to improve capital use through better sales and AP forecasting can substantially improve the working capital cycle and average revolving debt utilization, effectively increasing liquidity. “As you increase accuracy, the amount of working capital or revolving debt interest payments decreases.

“Both can increase free cash flow and therefore are often considered functionally the same as cost savings, even though they show up in different places,” Suda says, “like working capital reduction in cash flow, and revolving debt interest expense reduction on the income statement/P&L.”

For some AI projects the goal may be simply keeping ahead of users already familiar with tools like ChatGPT. There’s the risk that if you don’t provide basic gen AI tools in the enterprise, employees will push company data into publicly available tools for analysis. That risk may be a larger one than having your own Copilot or GPT solutions.

But gen AI is becoming a must-have part of every office worker’s toolset. “How do you measure the value of Excel in an organization,” asks Afshean Talasaz, former SVP and CTO at Colonial Pipeline. “Everyone uses it, but no one asks if you need it anymore. We’re not there yet with gen AI, but it’s certainly a possible outcome as ways of working, costs, and expectations around AI change in the enterprise.” 

Know your true costs

When projecting ROI, the investment or cost denominator can be tricky to nail down. Unlike traditional IT projects, the costs to build an AI are smaller than the ongoing run costs, especially at scale. “AI flips the script, and you need to plan for that,” says Suda. “For CIOs, this isn’t a cost dynamic they’re used to.”

That’s especially problematic because the stakes can be so high as the cost of both individual AI projects and the underlying data, infrastructure, and governance work that must be completed to support those efforts heighten risks of failure. “I’ve been in technology for 25 years and this is the most expensive and complex thing I’ve ever worked on,” says Sarbaugh.

But not all projects are expensive, says Talasaz. “I’ve seen projects that don’t cost a lot and I’ve seen others in the millions.” The cost of a given AI project depends in part on if an organization has internal staff that can build and develop AI projects or rely on external partners; if it’s already addressed data and infrastructure requirements or if it’s fully digital and in the cloud.  

How you measure success matters when it comes to ROI, says Talasaz. Most projects sit on top of common platforms that can be costly to set up, and how those costs are allocated affects the economics of AI projects. That’s why, he says, project economics matter, but it can be challenging to get the full picture depending on the project. There’s a degree of innovation and uncertainty in those that can take on characteristics of risk capital projects, similar to drug discovery in pharma, or oil and gas exploration. “Articulating financial metrics for AI projects is more effective at a portfolio level, where data and AI infrastructure investments, platforming, scalability, expectations, time to adoption uncertainties, and interconnectedness to other use cases can be more effectively measured,” he says.

The FinOps Foundation’s FinOps for AI working group is hashing out how to measure the value of AI projects at a more granular level since 98% of enterprises are managing AI spends, up from 31% two year ago, according to the Foundation’s recent State of FinOps Survey.

While the financial reporting indicators are the same, the data needed to compile those metrics differ, which can be difficult to obtain. “With AI, success is measured in tokens instead of minutes, or API calls instead of usage hours and minutes,” says Rob Martin, FinOps fellow at the Foundation. “And, unfortunately, a lot of the cost and usage data doesn’t come with the billing data.” So this leaves organizations with no choice but to collect it through API proxies or by using third-party products.

But models can’t always tell you how many tokens were used. “AI costs and service availability are more volatile, so you may not be able to predict the costs of operating your model at scale,” Martin adds. That’s forced many IT executives to forecast costs in ranges rather than using fixed numbers. So he recommends forming an AI investment council or tiger team chaired by the CIO that includes all stakeholders involved in AI spending, and an experienced executive who can help create a FinOps scope for spending, incrementally fund competing projects, develop a plan to gather and analyze data, and translate performance metrics to the board.

Prioritize for success 

Of the 10 AI value metrics Gartner has identified, productivity is on the lowest end of the spectrum. Projects that improve capital use, reduce losses, improve customer experience, or help with new products have a much greater potential for revenue growth.

Then operational metrics like net promote score, output per hour, and backlog reduction are all about return on employees, while financial measures such as average labor cost per worker, sales and conversion rates, and losses avoided focus on ROI. Leading indicators like traffic and clicks, and market share growth are all about what Gartner calls return on future.

For Toolan, there are certain AI scorecard benchmarks that every business should follow, tailored to each set of circumstances. Evaluate the AI strategy, technology stack, or platform, assess AI readiness relating to mindsets and skillsets of employees adopting the technology, and measure the results against desired business outcomes. “These need to be very industry- and sector-specific, and tailored to where your organization is on its AI journey,” he says.

But traditional financial metrics aren’t always the most important measures for desired business outcomes. For example, the business goal may be to improve customer satisfaction through measures such as NPS surveys. But they have limits. “You have to rely on survey answers, and it’s tempting to overstate the value of the improvement,” says Sarbaugh.

At CarMax, the most important metrics for its two major AI projects include customer satisfaction, conversions, and sales. The online auto retailer built its Skye AI assistant to help customers navigate the buying process; and Rhodes, a virtual agent, guides call center associates by providing questions to ask customers, quickly surfacing needed documents, and helping them navigate state rules, regulations, and policies.

“Time savings is a good metric to have, but what we look at are the business outcomes it’s driving,” says Mohammad. “What are we doing with the time that’s freed up to create more value for the company.”

NPS scores show a better customer experience, while the combination of Skye and Rhodes has generated higher conversion rates and elevated sales. “It’s about the elevation of the associates’ role from an information retriever to a trusted advisor,” he adds. “Roles are converging, what people do is getting redefined and processes are getting reengineered.”

Prepare your users and track acceptance rates

Even the best laid plans for AI will fail if users won’t adopt it, so user acceptance is yet another critical metric that requires advanced planning. It’s not enough to just train the AI models — you have to train people how to use AI and personalize it to their role in the organization. “It has to be a great experience in their flow of work,” Toolan says. “If it’s not, you’ll see a lower sentiment score and poor AI adoption.”

At first, says Sarbaugh, Zoetis underestimated the investment needed to make in change management since early on it was about how to move quickly. “We assumed if we built it they would come, but you won’t see value if users don’t understand how to incorporate it into their day-to-day work,” he says.

Think long-term value — and trust your judgement

At CarMax, the AI project metrics conveyed to top management fall into four areas: ROI, revenue impact, cost efficiency, and strategic value or the capability to gain a competitive advantage.

When presenting the business value of AI projects, include a value exposure measure, Talasaz says. Each AI use case may require changes to data, processes, and platforms or create new capabilities that may enable other projects to leverage those investments. “It opens the door for other things,” he says. “It’s usually a qualitative element as you may not know the costs and benefits for those other projects in detail yet, but there’s value in knowing that the current project is strategically opening up other capabilities.” And if a project will be a competitive differentiator, you need success measures for that as well.

When pitching a project, Talasaz adds he sets expectations transparently. “It’s important to provide scenarios, not just one financial metric, so provide a range of outcomes and the underlying assumptions and factors that impact those outcomes,” he says. For example, he’ll paint a picture that includes expected outcomes based on different adoption or implementation rates. “Leaders want to understand how all of the dots connect and what the bigger picture is,” he continues.

Ultimately the success metrics that matter are those that show the impact on P&L, and how the AI use case affects the employee experience. “Any chance you get to put a quantitative metric at any step in the process, do it,” says Sarbaugh. “But with the newness of AI, and being in the early stage of adoption, there’s an element to things that can’t be measured at the moment. So there’ll be times when you have to trust the judgments of the people who understand the business. Just use common sense and make sure you don’t overstate the results.”

For years, many of us built infrastructure the same way we built data centers in the 2000s: Pick a “standard stack,” stamp it out and treat exceptions like a paperwork problem. It worked, until it didn’t.

Retail made the breaking point obvious. Demand patterns stopped being “seasonal” and became “event-driven.” A product drop goes viral. A weather system reroutes delivery windows. A supply chain delay changes the entire inventory story overnight. Meanwhile, customer expectations keep climbing: real-time visibility, accurate pickup promises, personalized offers, fraud-resistant payments and consistent performance from the mobile app to the store lane to the fulfillment center.

In that world, fixed stacks turn into friction. They are either too heavy for small workloads or too rigid for fast-changing ones. Teams start to fork the standard build “just this once,” and suddenly the exception becomes the default. That is how sprawl begins.

Composable infrastructure is the most practical way I have found to break that cycle, but only if we stop defining “composable” as modular hardware. The differentiator is not the pool of compute, storage or fabric. The differentiator is the control plane: The policy, automation and governance that make composition safe, repeatable and reversible.

Gartner’s 2026 Infrastructure and Operations trends point to hybrid computing and “a composable and extensible compute fabric” as a way to orchestrate across diverse mechanisms while future-proofing investments. That framing matches what I see in practice: composability is about the operating model more than the equipment.

Why “reference architecture” alone no longer holds

Reference architectures are valuable. They create shared language, predictable security patterns and operational consistency. The problem is that they often assume stable boundaries: one environment, one platform, one dominant workload shape.

Retail environments do not behave that way anymore. We run mixed workloads across stores, fulfillment nodes, edge appliances, private cloud and multiple public clouds. We ship constantly. We experiment constantly. We also carry compliance obligations that cannot be negotiated at sprint speed.

What happens next is painfully familiar:

• Teams build shadow patterns to move faster.
• Security tries to bolt guardrails on after the fact.
• Operations inherits a zoo of one-off configurations.
• Finance sees spend drift, but can’t trace it back to intent.

This is why composable infrastructure must be paired with policy-defined infrastructure. Without policy, composability becomes a sprawl engine.

Composable infrastructure, defined like we actually run it

I like the “composable disaggregated infrastructure” description that treats compute, storage and networking resources as services that can be assembled as required, then returned to the pool when the work is complete. That is the operational heart of the idea: assemble, run, disassemble and recycle.

But “assemble” cannot mean “everyone builds whatever they want.”

In a modern enterprise, composition needs four things:

1. A catalog of building blocks (compute, storage, network, security, data services).
2. A declaration of intent (what the workload needs, not how to wire it manually).
3. A policy engine that evaluates intent against guardrails.
4. Automation that provisions, enforces, observes and retires resources consistently.

This is where platform engineering becomes the bridge. CNCF’s platform engineering work emphasizes internal platforms as a way to deliver reusable capabilities and reduce cognitive load. Composable infrastructure is one of the clearest places to apply that thinking.

The control plane is the product

The moment you move from “stacks” to “building blocks,” the control plane becomes the product you operate.

At a minimum, I expect the control plane to do the following:

• Translate intent into infrastructure using declarative definitions (infrastructure as code) and reusable compositions.
• Enforce policy as code consistently across pipelines and runtime.
• Prevent drift and continuously reconcile desired state.
• Measure outcomes: Availability, latency, change failure rate, security posture and cost.

Open Policy Agent (OPA) is a common example of a policy engine that lets teams specify policy as code and enforce it across Kubernetes, CI/CD, API gateways and microservices. In practice, that means I can write rules like “no public load balancers without approved tags,” “all data stores containing customer identifiers must use encryption and approved key management,” or “no privileged containers,” and have those rules evaluated automatically.

For GitOps-style reconciliation, the CNCF ecosystem has made the “desired state in Git” model mainstream with tools like Flux and Argo CD. Flux, for example, is explicitly positioned as declarative delivery where Git is the source of truth and the system continuously syncs the live environment to match. That reconciliation loop is what keeps composability from turning into configuration drift.

For cross-cloud composition, projects like Crossplane take it further by treating Kubernetes as a control plane framework for platform engineering, letting you design APIs and abstractions for your users. The point is not the specific tool choice. The point is the pattern: abstract complexity, enforce policy and keep the system converging back to a governed state.

A retail use case: “intent-built” infrastructure for peak-week resilience

Here is a pattern I have used in retail because it forces composability to prove its value in the real world.

Scenario: It is the week of a major promotional event. Digital traffic spikes. Store pickup volumes surge. Fraud attempts rise in parallel. Business wants rapid experimentation on offers and checkout flows, but reliability cannot regress.

If I run this on fixed stacks, I end up overprovisioning everything “just in case” or negotiating every exception manually.

With composable, policy-defined infrastructure, I can express this as intent and let the control plane assemble the right building blocks:

Intent: “Create a peak-week commerce lane that is globally distributed, supports real-time inventory reservations, isolates payment services, emits events for fraud scoring and scales predictably within budget.”

Building blocks assembled by policy

• Compute: Autoscaled microservices tier for cart, checkout and pickup promise.
• Network: Segmented service connectivity with explicit ingress and egress controls, plus per-service identities.
• Security: Enforced workload identity, secrets management, mandatory encryption and least privilege access patterns aligned to zero trust principles. NIST’s Zero Trust Architecture highlights continuous authentication and authorization per request and the idea of narrowing defenses to resources rather than perimeter assumptions.
• Data services: A short-lived event streaming pipeline for clickstream and order events, a low-latency cache for pickup promises and a governed analytics sink for post-event learning.
• Observability: SLO-based dashboards for checkout latency, pickup promise accuracy and payment authorization success rate, wired automatically as part of the composition.
• FinOps guardrails: Budget ceilings, tagging and cost allocation enforced at provisioning time and monitored continuously, using a shared accountability model consistent with FinOps practices.

The “sprawl prevention” mechanisms that matter

• Every composed environment has a time-to-live by default. If it is not renewed by policy, it is retired automatically.
• Policies require standard tags (application, owner, cost center, data classification). If tags are missing, provisioning fails early.
• Network exposure is deny-by-default. Public endpoints require explicit approval paths and documented intent.
• Data services are tiered by classification, with policy deciding which storage classes and encryption profiles are allowed.
• Drift is corrected by reconciliation. Manual changes are reverted unless policy allows them.

The outcome is not just faster provisioning. It is safer provisioning. Teams can move quickly without quietly creating long-term operational debt.

The governance model that keeps composability from becoming chaos

I have learned to treat governance as a product feature, not a compliance tax. If governance slows teams down, they route around it. If governance is embedded into the platform, it becomes the fastest path.

This is the model I aim for:

1. Policy-defined guardrails, not human gates. Rules are versioned, tested, peer-reviewed and rolled out like any other code.
2. Golden paths that are flexible. Developers should be able to request “an event-driven service with private ingress, managed database and audit logging” without learning every underlying primitive.
3. Reversibility by design. Every composed stack must be easy to unwind, and rollback must be part of the orchestration.
4. Continuous compliance, not quarterly scramble. Compliance is evaluated at build time and runtime, with evidence generated automatically.
5. Outcome-based telemetry. If I cannot tie composition back to reliability, security posture and unit cost, I am just moving complexity around.

What leaders should ask before calling it “composable”

When I talk to peers about adopting composable infrastructure, I ask a few questions that cut through vendor messaging:

• Can we express infrastructure by intent and have the platform translate that intent into consistent builds?
• Do we have a policy engine that enforces guardrails across provisioning and runtime, not just documentation?
• How do we prevent orphaned resources and environment sprawl, automatically?
• How do we measure business outcomes (conversion performance, pickup accuracy, fraud loss avoidance) and not just cluster health?
• Can we run this across hybrid environments without multiplying operating models?

If the answer is “we will standardize later,” composability will likely amplify your current inconsistencies.

The real shift: from building infrastructure to operating a control system

Composable infrastructure is a story about maturity. It is the shift from handcrafted stacks to configurable building blocks, assembled by intent and governed by policy.

When it is done well, it changes the daily experience of IT:

• Teams stop fighting over one-size-fits-all reference architectures.
• Security stops chasing exceptions and starts shipping enforceable policies.
• Operations stops inheriting snowflakes and starts running a reconciling system.
• Finance gets visibility into spend tied directly to intent, not guesswork.

That is what “build-to-fit IT” means to me: the enterprise gets flexibility without losing control, because the controls are part of the platform, not an afterthought.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

The point of agentic AI is for it to act by writing code, running scripts, executing commands, or calling APIs. All of that is more effective if those actions are discoverable, documented, consistent, and designed to be easy for agents to use in the first place.

Agents need slightly different information from people. Both benefit from complete, accurate and up to date documentation or error messages that include the correct commands to use, but, for example, DevOps agents need the full context of the entire CI/CD pipeline, and developers usually don’t.

Generally, though, better management of business logic, code, data, documentation, API design, policies, and best practices will help your human users as well. And if you don’t do the work, you risk a new level of shadow IT as members of staff turn to services their agents can work well with.

“People are starting to believe and buy into agentic AI, but there’s so much work to be done to actually achieve this,” says Forrester VP and principal analyst of enterprise architecture, Charles Betz. Agents need precise, structured, and accessible information, and AI will amplify strengths and weaknesses. “If you have weak system understanding, you’re going to have some awfully confused AI agents,” he adds.

Optimizing the agent experience

Getting your existing enterprise systems ready for agents is part of what Netlify CEO Mathias Biilmann calls agent experience (AX) or what an agent encounters as the user of a product of platform.

Every product and tool already has an agent experience, though, because AI agents already try to use them. “It’s just a question of does it have a good agent experience or a bad one,” he says.

If you expect an agent to work with a product or service you rely on, it’s important to know if it has the structured, predictable interface, the comprehensive error handling, session persistence for workflows with multiple steps, and real-time feedback that it needs.

“How does an agent discover your product,” says Biilmann. “Is it the user that tells them, or does it figure out on its own this might be a good solution? How do you help it understand what it can do with your product, and how do you make it easy for it to get access to the product, ideally, with as little asking the user for permission as possible? Then in that agent loop, how do you give context to the agent to make sure it can get the best possible experience of that product and solve the tasks for its user in the most efficient way?”

The term has already caught on with both AI coding agents and developer tool providers, and Biilmann expects it to become more widely relevant. “As lessons from coding agents, and especially Claude Code, start making their way to agents more oriented at businesses and consumers,” he says, “we’ll start seeing the next layer of tools and services understand that if we don’t work well with those agents, we’re going to start getting routed around.” Akamai’s latest research shows that shift has begun.

In the enterprise, AX is about doing the foundational work to effectively integrate agentic AI with existing systems. So do you bolt them on as an afterthought, like RPA that scrapes data out of legacy applications, or do you make sure workflows and tools are set up for MCP to work against so agents are more effective?

Investors are starting to talk about these principles as part of how they do valuations and predict agent-led growth. Anthropic has guidelines for how to write tools so they work well with agents, and Microsoft is building new accounts with access limitations into Windows just for agents so they run securely. One AI code tool provider even ripped out the CMS it had just paid to set up because its Cursor coding agent couldn’t access it easily, and the marketing team found asking a chatbot to add their content to the website as Markdown easier than a traditional CMS interface.

Of course, as a company building AI coding tools, even Cursor’s non-technical employees are fairly technical, and soon after that provider gave up on the CMS, the vendor released an MCP server designed to give agents access to create, update, and manage a website without such a drastic change. But it’s an example of the impact AI agents can have on traditional software usage.

Beyond MCP

Biilmann suggests four principles for good AX based on if agents can reach a system with the right permissions; the LLM can get the right context to use it effectively; tools like APIs, SDKs or the command line interface are built so agents can act as an interface to use them; systems make it easy to trigger and coordinate a favourite agent.

“There’s a whole field of context engineering emerging that involves MCP, skills, context files, and tweaking tool responses to make sure agents have the right context when they’re using your product,” he says, adding that a single line of output added to the error message for a Netlify CLI command fundamentally transformed the AX from not being able to use the tool, to deploying it in one go.

But it’s not enough to just make an MCP that wraps an API. “Think about the MCP as a UI for an agent that gives it the right context to not just do API calls but accomplish tasks efficiently with your API,” he says. “Give it context, structure and how API endpoints are typically used together.”

Sean Blanchfield, CEO of AI infrastructure company Jentic, agrees that AI needs context, not more integration glue. “If you give an LLM clean documentation for a well-designed API, it can already interface with it directly,” he says. “That makes high-quality API management the real foundation of enterprise AI capabilities. Existing investments in OpenAPI, gateways, authentication, and governance will pay serious AI dividends.”

Agents also need APIs that match their specifications, which many don’t. Jentic’s free AI Readiness Scorecard tool is one way to check that.

Common mistakes are broken references, malformed schemas in OpenAPI specs, or APIs that don’t specify the server that hosts them and only have authentication information written for human developers not available through the API. Human developers might be able to laboriously work around those but agents will struggle.

API specifications alone have no concept of operational sequence, says David O’Neill, COO of SaaS platform APIContext, so you need to use OpenAPI’s Arazzo workflow standard to encode those. “Suddenly OpenAPI specifications and Arazzo workflows are important because those are the things MCPs and agentic systems use to validate if something’s going to work,” he says.

Forrester’s Betz refers to this kind of work as generative engine optimization to help agents get details about services.

“Documenting APIs, getting robust business definitions of your data and information, understanding unambiguously where that data and information live, and what system is authoritative are absolutely critical,” he adds. “All the things your data and enterprise architects have been trying to build for the last 20 years, AI needs all that stuff to do what it does.”

Testing AX ground rules

Most organizations will use older code and architectures they aren’t ready to get rid of but don’t want to replicate, says Michael Coté, staff technologist at Broadcom. “Make sure to go through and mark up what you think is a well behaved database and data architecture versus a functional one you don’t like,” he says.

Some of this is basic IT hygiene but it’s still critical, adds Martin Heyder, director of IT at data analytics platform KNIME, especially if you’re automating workloads that have relied on staff manually collating data from multiple sources that haven’t had to be kept up to date or available before. “If inventories, logs, or documentation are unreliable, any AI system will simply automate bad information,” he says.

Also, agents will often initially expose where tacit knowledge exists, so establishing standards across code, enforcing code reviews, and keeping a single reference for system definitions and documentation gives agents an easy framework to work within.

Microsoft CVP for apps and agents Amanda Silver refers to that as an agentic constitution, a natural language way to specify requirements or common expectations across the organization or code base. “You make sure the agent always has that in its context,” she says.

This can apply much more broadly and be used as a meta prompt, that can include specific ways an agent should do things when it needs to manage identity, create a human in the loop interface, or build something that allows you to observe the agent’s operations.

Context and connection

Identity, access management, and permissions for existing infrastructure are fundamental. Most organizations likely need to start with an inventory, to make sure they know about everything they want agents to interact with, and that they can update it if necessary.

That may mean adding new APIs or even replacing legacy apps where core logic and user interface are so tightly coupled, they’re hard for agents to use with SaaS that has APIs built in, or composable, headless architectures. Almost 30% of organizations IDC talks to, for instance, are working through how to modernize their entire software portfolio to take better advantage of AI and agents.

“The highest value ROI task agents are capable of is backend workflow processing,” Silver says. “You might use a protocol like MCP to expose data to agents, but that doesn’t mean they can take actions. Think about what the actions are you want to automate, that you can expose as tools to agents, that they can invoke to go not just from intent to planning, but to actual execution and action.”

If you want agents to be useful to resolve an outage, they need access to an API that lets them add information to the dashboard where you collate incident details. Workflows will also need to include agents so they can subscribe to events like whether an order has shipped or an invoice has been disputed, and they need to be able to trigger the right actions in response.

Plus, policies may be arranged in code rather than written down, and extracted into natural language policy documents agents can access. As organizations start to use more agents, Silver believes they’ll need not just sequential orchestration to cover an entire workflow, but adversarial evaluation, where workflow needs to follow multiple policies, all trying to deliver specific outcomes. “For that, you might implement multi agent orchestration with policies, then fan out where you consult multiple expert agents, and then those expert agents come back and make a judgment call, solving for multiple policies codified in natural language.”

FinOps for agents

Early adopters are already finding that agents can be relentless and prone to issuing multiple queries. “They keep trying, they’ll do anything,” Biilmann says. “They won’t stop and they can overwhelm a service.” If you can’t redesign an API to return hints because you don’t own it, you may need to implement quotas or prioritize queries.

“I think there’s going to be a lot of manually created guardrails for scenarios because agentic stuff is really bad at policing itself,” O’Neil says. “It’s designed to deliver solutions, not turn itself off when it’s failed to deliver a solution.”

Enforce idempotence, retries, quotas, and limits to prevent runaway or repeated API consumption, Betz adds. “Agents aren’t an unlimited resource, and if they’re not getting the right answer, they need to know when to abandon the attempt,” he says.

Part of governance, Silver says, is understanding which MCPs are exposed to agents. “You could revoke access to them, govern token consumption, and enforce governance polices that make sense for you and your organization,” she says.

So AX is a similar discipline to UX in that it’s iterative, and it’s about understanding what users or agents are trying to accomplish, says Biilmann. “You have to staff a team that does the research and figures out the problems and opportunities,” he says. That means looking at session replays, identifying failing agent behaviors, and building responses and interfaces to make them successful.

As agent models have improved, Netlify doesn’t have to rely as much on adding context files that guide agents to the most recent API, but that just means they’re moving targets. “There’s a new audience of agents you constantly have to work with and iterate on,” he says.

APIContext users already using MCPs find that the numbers of transactions, the APIs, and even the specific services used can change unexpectedly, O’Neill says. “The services returned by the MCP have changed, and it’s trying a different way to create a record, and that doesn’t work anymore,” he says. “It’s not like a gateway where you’re defining everything. It’s more of a black box providing you with a list of tools you can use.”

A new MCP server performance monitoring tool lets you check and set alerts, and create governance rules based on performance thresholds, specifications, network functionality, or data transfer rules for data sovereignty. Agents require paying more attention than ever to API management. “It’ll force people to take this API governance seriously,” O’Neill adds.

Also, lean on your API gateways in addition to governance tools, monitoring, and observability, says Betz. “An agent is a service that happens to have an LLM involved, and maybe some chain of thought, intention management, and goal seeking behaviors,” he says. “But it’s all still just software.”

That means your logging infrastructure will be placed under load. “If you fully embrace agentic, and you’re tracking all the agents, this traffic is going to bounce around in somewhat nondeterministic ways,” he says. In the end, measuring whether agents are successful is about outcomes as well as observability, Silver says. “Over time, you’re going to need to evaluate whether the agent is actually executing the thing you want it to execute, including not going off the rails,” she says.

Microsoft is already using agents for Site Reliability Engineering to reduce the cost of responding to live site incidents, and improve remediation time. “To be able to do that, you need labeled, timestamped, traceable data you can look over,” she adds. “You also need to have rich, structured signals, and a clear sense of what’s good and bad from an outcomes perspective.”

When was the last time you killed a “green” project?

If the answer is “never,” you are likely still managing projects. If the answer is “last quarter, because we found a 3x better use for that capital,” then you are allocating capital. That distinction isn’t just semantic, it’s the gap between being a cost center and becoming a value engine.

For decades, the benchmark for technology leadership was the master of delivery. Success was measured by the triple constraint: on time, on budget and within scope. We built project management offices to track these metrics, celebrated when a project hit a milestone and treated the technology budget as a bucket of funds to be spent before the fiscal year expired.  Even as PMOs have downsized or evolved into agile centers of excellence the underlying mindset, tracking delivery rather than allocating capital, persists.

2026 has made this model obsolete. We’re navigating a massive anxiety gap in the enterprise. According to Gartner’s latest forecast, global IT expenditures are expected to hit $6 trillion in 2026, a 9.8% increase over 2025, driven heavily by AI Infrastructure and mobile devices. Yet, despite this surge, few organizations feel they are meeting the board’s ROI expectations. The business doesn’t need another great project manager. They need a CIO who acts as a master of capital allocation.

This isn’t about cutting costs or fighting with stakeholders. It’s the opposite; it’s about moving technology from a cost center that consumes budget to a value engine that allocates capital. Leading this shift comes down to four disciplines.

1. Make every dollar re-qualify for its job

In most organizations, the annual budget is an exercise in incrementalism. You take last year’s spend, add a percentage for inflation and layer new projects on top. You end up with a sedimentary layer of technology, platforms that survive year after year simply because they were there yesterday.

Strategic investors don’t do this. Instead, we move toward a zero-based portfolio. This doesn’t mean zeroing out the budget; it means adopting a mindset where every asset must re-qualify its place based on current market yield. You shift the conversation from “How much do you need?” to “What is the yield on this capital compared to our other opportunities?”

Recent McKinsey research emphasizes that building an effective strategy requires the CEO to lead capital allocation as a fundamental responsibility, reserving at least 10 percent of their calendar for these decisions. Effective leaders do not treat allocation as a “one and done” annual event; instead, they ensure strategic initiatives are followed through in regular reviews, with funding often timed to and conditioned on reaching specific benchmarks.

A zero-based portfolio requires a rigorous value realization audit. Every six months, lead a transparent review with business partners. We aren’t looking for fault; we’re looking for fit. If a platform that was strategic three years ago now offers diminishing returns, don’t just keep managing it; plan its divestiture. This signals to the board that you’re a fiduciary. By harvesting resources from businesses that no longer fit, you free up the capital to seed high-growth initiatives.

2. Compress ‘the rent’ to fuel ‘the mortgage’

One of the biggest barriers to innovation is the blended budget. When you lump cloud consumption and legacy maintenance in with AI transformation, the true economics of the department stay hidden. You have to decouple the budget into two distinct lanes:

• Lane 1: The rent (the cost of performance). The OpEx required to run the existing business. The goal here is Deflation.
• Lane 2: The mortgage (the build of equity). The investment in new IP and proprietary data loops. The goal here is ROI.

In the turnaround environments I lead, “the rent” has become a lead anchor on the business. Roughly three-quarters of the typical IT budget is consumed by run activities, operational sludge that keeps the lights on but delivers no competitive advantage. When 75% of your capital is trapped in maintenance, you lack the dry powder needed for the grow and transform initiatives that actually expand margins, increase exit velocity and build enterprise equity.

Your job: compress Lane 1 to fuel Lane 2. I recently worked with a portfolio company where 68% of the IT budget was going to cloud costs that were allowed to run away during a new project inception. We built out a FinOps practice to cut that spend by 30% and redirected it to focus on features that had direct links to profitability. That focus allowed the teams to deliver real value 3 months ahead of schedule. That is what paying “the rent” through efficiency looks like.

3. Find the courage to pivot green projects

The most common failure in portfolio management is the sunk cost trap. We’ve all seen it: A project is 12 months in, the status is green and the team is working hard, but the market has shifted. Perhaps a new AI model made your proprietary tool redundant.

In the old model, you finish the project anyway because you already spent the money. The disciplined investor understands opportunity cost. Every dollar spent on a green project that is no longer optimal is a dollar stolen from a higher-yield opportunity.

Leadership IQ, citing research from Harvard and Oxford, calls this commitment bias the irrational urge to stick with an investment simply because you’ve already spent the money. Recent 2024 neuroimaging studies show that emotional processing regions can override logic when personal responsibility is high, causing managers to “double down” on failing paths. This psychological trap is a major contributor to why digital transformation initiatives often fail to meet their stated objectives.

Having the courage to kill a green project is the ultimate sign of leadership maturity. Frame it as a triumph of alignment. When you tell a business lead, “Your project is performing perfectly, but I’m recommending we pivot those resources because the ROI is now 3x higher elsewhere,” you are speaking the language of a CEO. This creates a culture of high-velocity alignment.

4. Insist on architectural liquidity

In finance, an illiquid asset is a risk. If you can’t exit the position when the market turns, you’re trapped. In technology, we call this legacy lock-in. You must insist on architectural liquidity, evaluating strategic investments on their exit velocity.

The business value is stark. Gartner forecasts that through 2027, organizations that prioritize reducing technical debt and managing for flexibility through modularity will be able to report 50% fewer obsolete systems.  By choosing modular, task-specific architectures over bloated, general-purpose ones, you aren’t just making a technical choice; you are making a financial one to lower the rent and keep the organization liquid.

In late 2026, this is also how you bypass the energy wall. Compute is no longer just a budget line item; it is a finite utility constrained by power grids and rack space. Small, task-specific models (SLMs) provide the green execution path, allowing you to scale without hitting the power ceiling that is poised to stall many general-purpose AI initiatives.

Ask three questions before any major investment:

1. Can we swap components without rebuilding the core? (Modular design)
2. Is our data trapped in a proprietary format, or can we move it? (Data portability)
3. And the killer: If a better AI model drops tomorrow, are we locked in for years or can we pivot in weeks? (Model agnosticism)

Architecting for liquidity ensures capital is never trapped. It allows the business to move at the speed of the market rather than the speed of its legacy debt.

Monday morning: Start the pivot

Moving from managing projects to allocating capital rewires the entire organization. It stops being a department that asks for money and starts being one that deploys capital.

The job now demands bilingual leadership, the ability to discuss a unified data plane in one breath and the impact on the exit multiple in the next. You’re no longer the gatekeeper who says No; you are the value Architect who says, “Let’s find the capital to make the biggest impact.”

Start this week: Pull your top 5 green projects and hold a 30-minute investment review with your business partners. Frame the conversation around portfolio yield rather than status. Ask them one question:

“If we were starting from zero today with the remaining budget for this project, would we still vote to fund it or is there a new initiative with a higher projected ROI that deserves this capital?”

If the only defense is “we’ve already spent so much” or “we’re almost there,” you’ve identified a sunk-cost trap. If they do propose a new alternative, don’t just take their word for it; subject that new initiative to the same rigorous ROI analysis as the existing project. The goal isn’t just to stop; it’s to ensure your most expensive resources are always working on the asset that will move the needle on the exit multiple.

The era of the IT project is over. The era of the strategic asset has begun.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

I’ve walked into infrastructure review meetings expecting to talk about AI acceleration, only to spend the entire time on a different problem: Why the cloud footprint kept growing even though application demand had flattened. Teams had modernized aggressively. Platform leaders were confident, and contracts were up to date. Yet, spend curves no longer matched business growth.

More concerning, new AI workloads were forcing questions we thought had already been answered about where systems belonged. That shift changed how I think about cloud strategy. The issue wasn’t whether we were “cloud-first” or not. It was whether we had designed for movement at all. That was the moment I stopped treating workload placement as a destination and started treating it as a reversible operating capability.

When the cloud stopped feeling permanent

Early cloud programs were driven by urgency. On-prem provisioning was slow, capital cycles were painful, and engineering teams needed speed. Cloud solved those problems almost immediately. What it didn’t solve was discipline. We built for velocity, not longevity. Cost attribution lagged. Data gravity went unmeasured. Compliance controls were layered on after the fact, and once workloads stabilized, few teams revisited the original placement assumptions. Over time, cloud quietly shifted from a friction reducer to another fixed cost.

When I began mapping placement decisions to operational behavior, a pattern emerged. Only a fraction of workloads truly benefited from elasticity. Most were steady-state systems with predictable demand, fixed data gravity, and tightening regulatory requirements. IDC’s research on missed expectations in cloud computing validated our internal observations: most repatriation is selective, not ideological, with organizations moving specific workloads to improve cost predictability, governance, and operational fit rather than abandoning cloud altogether. That insight forced a reset. We weren’t reversing decisions; we were correcting assumptions. I no longer believe the cloud was wrong—permanence was the flawed assumption.

How AI and regulation rewired infrastructure assumptions

Nothing exposed the limits of default cloud placement faster than production AI. Early experimentation worked beautifully with burst training jobs, proof-of-concept pipelines, and ephemeral datasets. Once models moved into daily operations, the economics changed. Inference loads stabilized, data volumes exploded, and GPU utilization became a first-order variable. Teams found themselves paying for capacity that wasn’t elastic at all.

At the same time, regulatory expectations tightened. It was no longer sufficient to claim that data was encrypted or compliant. Leaders had to demonstrate where encryption keys were controlled, how cross-domain data flowed and which systems retained sensitive artifacts. Those were not policy questions. They were platform questions. BCG’s research on cloud sovereignty and governance mirrored this experience, showing that placement decisions are increasingly shaped by regulatory posture and operational waste as much as by technical capability. McKinsey’s analysis of AI-driven infrastructure demand further clarified what many teams were struggling to quantify: high-density compute behaves differently, with power efficiency, data locality and predictable utilization mattering more than theoretical elasticity. For us, hybrid stopped being transitional and became structural.

Turning replatforming into an operating capability

After the debate over workload location faded, the real work began. The priority shifted from cloud versus on-prem to enabling the organization to change its mind without starting over—and designing for reversibility.

To bring rigor without ideology, I began evaluating major systems across five dimensions: cost behavior under steady demand, data gravity and movement friction, compliance sensitivity, performance profile and operational maturity. The score didn’t dictate placement. It dictated attention, with systems showing volatile cost behavior or tightening regulatory exposure flagged for deeper replatforming investment.

Cost also became an architectural constraint. For years, cost management had lived in finance. That had to change. We embedded cost visibility directly into engineering workflows, so platform decisions were informed before spend occurred rather than after. McKinsey’s FinOps research reinforced this direction, arguing that sustainable cloud governance only works when cost controls are embedded in delivery pipelines rather than retrofitted during quarterly reviews.

We decoupled data from compute wherever possible, not just for portability, but to preserve placement optionality. Movement became expected, and we assumed workloads would move again and designed them accordingly.

To understand whether this was becoming a real operating capability, we also changed what we measured. Instead of tracking how many systems were “in the cloud,” we tracked placement reversals executed without incident, the time required to relocate high-value workloads, unit economics stability over six-month cycles, reductions in compliance exceptions tied to infrastructure , and AI workload cost predictability. Those indicators revealed whether replatforming was becoming a true operating capability rather than a one-time project.

What this all adds up to

Repatriation is not retreat. Replatforming is not indecision. Together, they signal maturity, not ideology. As 2026 approaches, outperforming organizations will be defined by how deliberately they decide and how easily they adapt as conditions shift. That is the cloud story no one wants to tell.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Cloud technology deployments are maturing as global enterprise digitises and emerging technology such as agentic AI becomes a key priority.

According to PwC’s 2025 EMEA Cloud Business Survey, 80% of organisations reported medium or high cloud maturity in 2025 and 86% of respondents plan to increase their budgets over the next 12 months.

The rise of the sovereign cloud

However, the shape of the cloud is changing. Geopolitical tensions and new regulations are reshaping how data is stored, processed and secured, with many governments mandating localisation and “sovereignty-by-design” models. 

As PwC’s report sets out, multinationals are, as a result, complementing global cloud platforms with regional or national solutions. New sovereign cloud platforms will run alongside public cloud deployments, serving specific use cases even if that means compromising on factors such as service range and cost.

Olivera Majdandzic, Partner, Cloud Transformation, PwC France & Maghreb comments: “Digital sovereignty is not just a regulatory requirement; it’s a strategic advantage. For our clients, it means maintaining control over their data while still leveraging the full power of the cloud. Our mission is to design hybrid and sovereign architectures that balance trust, performance and innovation — enabling organisations to navigate complex environments without ever compromising their agility.”

Managing cloud complexity

According to PwC’s research, 94% of organisations plan to adjust their cloud architecture in the year ahead, reflecting a move towards greater flexibility — for example, by adding multi-cloud capabilities or integrating sovereign solutions for specific use cases.

In this model, enterprises may select to migrate sensitive or regulated data to sovereign environments, while keeping other workloads in public or private clouds. Doing so requires integrating sovereign solutions as an additional layer within already complex hybrid, multi-cloud environments.

These challenges underscore the need for unified cloud management and governance to provide visibility, consistency, and control across all platforms. Additionally, the ability to seamlessly port workloads across public, sovereign, and private-cloud environments will be essential as it enables organisations to remain agile in the face of regulatory change. The approach will also help enterprises maintain business continuity, optimise costs and leverage the strengths of each platform, while retaining operational and compliance control.

Moving from compliance to innovation and resilience

As PwC makes clear in its report, the cloud is built for adaptability and is already well primed to meet sovereignty requirements. What’s more, CIOs recognise that their sovereign cloud initiatives can deliver innovation in addition to regulatory compliance.

Sebastian Paas, Partner, EMEA Cloud Transformation Leader, PwC Germany, comments: “The cloud was built for change – and today, that purpose matters more than ever. It empowers organisations to respond to disruption, scale innovation and build the resilience needed to thrive in a shifting landscape.”

By unifying public, private and sovereign clouds, organisations can adapt faster, optimise performance, and access best-in-class services. PwC’s research reveals that just 18% of businesses now rely on a single cloud environment; a model that’s increasingly linked to lower maturity and slower progress in areas such as AI and FinOps. Conversely, four out of five enterprises are using a multi-cloud strategy infrastructure to maximise their innovation potential and source services with the best cost-benefit ratio from each cloud vendor.

A new partnership ecosystem

In this new world, trusted partnerships are emerging as a critical enabler. Hyperscalers are building new sovereign solutions and dedicating resources to local regions. Meanwhile regional and national providers strengthen local trust. As a result, a powerful ecosystem is falling into place where clients benefit from active competition and massive investment — with flexibility, multi-cloud models and new partnership approaches giving them more choice than ever.

To learn more about how enterprises and cloud vendors are adapting in the age of sovereign cloud, download PwC’s 2025 EMEA Cloud Business Survey.

To watch CIO’s webcast with PwC on this topic, click here.

To find out more about Sebastian Paas, click here.

To find out more about Olivera Majdandzic, click here.

Your board is going to ask you a question in the next twelve months, if they haven’t already: “What’s our AI strategy, and why should we believe it’s enough?”

I’ve been in those rooms. I’ve been asked those questions. And I’ve also watched other CTOs and CIOs give answers that sound reasonable in the moment but miss the magnitude of the stakes. They talk about copilots and chatbots and efficiency gains. They present roadmaps with timelines and metrics like “Hours Saved”. They frame AI as a technology initiative, when what’s really on the table is something closer to an existential bet.

AI is not just another technology cycle. It’s a bet that we can unlock productivity gains large enough to fundamentally change the trajectory of our organizations and the broader economic system they operate within.

The bet most boards are missing

In November, the US launched the “Genesis Mission,” A Manhattan Project-scale effort to harness AI for scientific discovery. It involves the Department of Energy integrating 17 national labs, decades of federal data, and the world’s most powerful supercomputers into an AI platform designed to double research productivity within a decade. That’s not a small pilot program. That’s not an experiment. That’s the federal government placing a very large bet that AI is the most consequential productivity technology since electrification.

This isn’t really a technology bet. It’s an economic one. And that distinction should fundamentally change how you think about your own AI investments.

The Genesis Mission isn’t just about faster science. It’s a policy response to a deeper economic problem most boards never see: the economic system we’re operating in increasingly depends on productivity breakthroughs that haven’t materialized yet.

The economic context your board hasn’t been told

Economist and former IMF consultant, Richard Duncan has spent decades studying what he calls “creditism.” His thesis will make you uncomfortable: we don’t live in a capitalist economy anymore. Since the U.S. left the gold standard in the early 1970s, global economic growth has been driven primarily by the continuous expansion of credit.

You don’t need to agree with Duncan’s framing in full to see the pattern. What matters is the direction of travel, not the label.

Consider the scale of the shift. Total U.S. debt was $1 trillion in 1964. Last year, it crossed $100 trillion, a hundredfold increase in roughly sixty years. That expansion funded venture capital, enabled cloud infrastructure, created unicorn startups, and underwrote the digital economy most of us have spent our careers building. Every enterprise system I’ve ever architected runs on top of this structure. It’s the water we swim in.

But credit based systems have a constraint: credit must keep expanding. When it doesn’t, instability follows. Duncan documents this pattern repeatedly. Credit contraction reliably precedes recession.

We saw it in 1930. A credit bubble popped, policymakers stepped back, and the economy shrank by 30%. Unemployment hit 25%.

In 2008, we faced a similar moment. This time, the government intervened with trillion-dollar deficits and the Fed created trillions more through quantitative easing. That kept the system alive, but it didn’t solve the underlying problem. It bought us time.

Time for what?

Time to grow our way out of the problem. Time to generate productivity gains large enough that the debt becomes sustainable. Time to create real economic expansion, not just more credit layered on top of the last cycle.

That pressure is no longer abstract. It’s landing directly on your desk.

Why this lands on your desk

For decades, economists have tracked declining productivity growth. Despite massive investments in technology, overall output per worker has stagnated. At the enterprise level, the pattern is painfully familiar: more researchers produce fewer breakthroughs, drug approvals have declined, and R&D efficiency has deteriorated across industries.

I’ve been on both sides of this. I’ve led large-scale transformations, and I’ve been the person other CTOs call when the results don’t match the investment. It’s why I’ve spent so much time helping shape industry standards through the DevOps Institute, the FinOps Foundation and the CIO Executive Council.

The pattern is always the same: companies pour eight figures into digital transformation, cloud migration, SRE or DevOps maturity, only to present incremental improvements to a skeptical board. The technology worked. The systems stabilize. Costs may even come down. But the productivity needle barely moved. I’ve lost count of how many times I’ve had that hushed conversation over quiet sips of rarefied bourbon, trying to help them figure out what to tell their board.

AI is different. Not because of the hype, but because of the mechanism. When AI can analyze patterns across decades of data, design experiments, run simulations, and surface insights that would take humans years to find, you’re not optimizing existing processes. You’re operating on a different curve entirely.

The Genesis Mission is a $100 billion bet that this different curve is real. That AI accelerated discovery in energy, materials science, biotech, and quantum computing can generate the productivity breakthroughs the economy needs. Washington is treating AI as the technology that might actually move the needle on growth.

Which brings us back to your board meeting. The question isn’t whether AI will transform your industry. The question is whether you’ll be the one doing the transforming or the one getting transformed.

The pattern underneath it all

The name “Genesis” isn’t an accident.

The credit system Duncan describes looks stable on the surface, but it contains the seeds of its own collapse. The question is whether we can create enough genuine productive capacity before the next contraction hits.

I’m not making a theological claim. I’m making a practical one. Every major initiative I’ve ever led started as chaos: competing stakeholders, unclear requirements, legacy decisions that take time to unwind. The work was creating order from those challenges. Turning noise into signal, ambiguity into architecture. AI lets us do it at a scale we couldn’t before.

That’s what the Genesis Mission is betting on. Not faster chatbots. The capacity to build something real that can bear the weight of the system we’ve constructed.

That’s not just government policy. That’s a pattern you should be replicating in your own organization.

What this means for your AI strategy

Here’s what I’d actually tell you if we were working side by side:

Stop treating AI as a line item in your modernization budget

It’s a platform bet on par with your cloud migration. Maybe bigger. If the macro thesis is right, if AI is the technology that enables genuine productivity gains at the scale the economy needs, then underinvesting is an existential risk. Not because competitors will ship features faster, but because the companies that figure out AI-native operations will have structural advantages that compound over time.

Think bigger than insights

The Genesis Mission isn’t summarizing PDFs. It’s simulating physics, designing experiments, running scenarios that would take human researchers years. Your AI strategy shouldn’t be summarizing meetings. It should be simulating your supply chain before you change it. Modeling customer behavior before you launch. Testing pricing strategies in silico before they hit the market. The companies treating AI as a faster way to read documents are missing the point. The real leverage is using your proprietary data to simulate futures your competitors can’t see.

Finally, build for continuous learning

Simulation requires people who can ask the right questions. But, we’re automating faster than we’re reskilling. That’s an unseen form of technical debt and it will come due. The Genesis Mission gets this right: its AI architecture runs experiments, evaluates outcomes, and improves continuously. That’s not a chatbot. That’s an operational system.

The same principle applies to your organization. Without the infrastructure and observability to measure what works and feed learnings back into the system, you’re building on sand. Without investing in your people’s ability to learn alongside the tech, you’re optimizing for the short term.

I could be wrong about this. Maybe AI plateaus. Maybe the productivity gains don’t materialize at scale. But I’ve been doing this long enough to know that the bigger risk is usually inaction.

A new beginning

Duncan frames the choice starkly. With the right investments, we may grow our way out of the credit trap. Without them, history suggests long term stagnation, instability, and conflict. That’s not alarmism. It’s precedent.

The Genesis Mission is the government’s attempt to make the right bet. To create a new beginning. To leverage unique federal assets and emerging AI capabilities to create genuine productive capacity.

Your job is to make the same bet at your scale.

I think about the ripple effects of these decisions constantly. The choices you make in the next twelve months will compound. They’ll affect whether your engineers feel like they’re building something that matters. Whether your company is positioned to thrive or scrambling to catch up. Whether the people who trusted you with their careers made the right bet. That’s the weight of the decision.

Because when your board asks what your AI strategy is and why they should believe it’s enough, “we’re being thoughtful and deliberate” is not an answer that will age well.

Invest like it matters. Because it does.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Imagine opening your monthly cloud invoice and seeing a 200% spike in a single line item. This is the new reality for AI-native companies. What was once a predictable compute budget has been upended by the massive computational hunger of large language models (LLMs).

The financial cost of running LLMs is astonishing. In response, the industry has rushed toward FinOps for AI, the practice of meticulously tracking and optimizing every dollar spent on computation. FinOps is necessary, responsible and a sign of a maturing industry.

But tracking dollars is solving yesterday’s problem.

The next frontier of competitive advantage lies in a metric that barely registers on most dashboards today: the energy consumption of your AI models. A fundamental shift is underway from FinOps (economic cost) to GreenOps (energy cost). Instead of asking, “How much does this model cost to run?” the critical question is becoming, “What is the carbon intensity of this API call?”

This isn’t a philanthropic sidebar; it is the next battleground for regulatory compliance and brand value. Here is why the shift to GreenOps is inevitable, as well as how savvy IT leaders can get ahead of the curve.

The 3 forces making GreenOps mandatory

For years, the energy footprint of AI was an academic footnote. Now, three powerful forces are turning it into a commercial imperative:

1. The regulatory vise is tightening

Regulators are turning carbon disclosure into a legal obligation. The EU’s Corporate Sustainability Reporting Directive (CSRD) requires large companies to publish audited greenhouse-gas data starting with FY2024 reports. Crucially, this scope expands to SMEs and non-EU multinationals by 2028.

In the United States, California’s Climate Corporate Data Accountability Act (SB 253) mandates that corporations with over $1 billion in revenue disclose Scope 1, 2 and 3 emissions. Electricity feeding a Google Cloud us-east1 cluster is Scope 2; re-billed SaaS workloads are Scope 3. Either way, they hit the ledger. Companies that fail to report AI-related emissions will face fines and exclusion from enterprise supply chains.

2. The demand for ‘ethical gigawatts’

Procurement teams are beginning to screen vendors based on energy efficiency. Major European players already utilize ESG ratings from EcoVadis to evaluate suppliers.

Investors are following suit. Under the EU’s Sustainable Finance Disclosure Regulation (SFDR), Article-8 and Article-9 venture funds now request emission baselines before deploying capital. Just as security questionnaires became table stakes a decade ago, carbon emission dashboards are becoming standard in enterprise RFPs. For an AI startup, demonstrating a low-carbon inference stack is no longer a nice-to-have, it is a competitive moat.

3. Performance-per-watt as a metric

 We are entering an era where efficient engineering trumps brute force. An equally accurate model that consumes half the energy is objectively better engineering. Investors and CTOs will soon assess watts-per-inference with the same scrutiny they once applied to daily active users. This efficiency translates directly into higher profit margins and brand prestige.

Decoding the carbon cost of an API call

Measuring the carbon footprint of a single API call sounds abstract, but GreenOps turns it into a concrete key performance indicator (KPI) based on three variables:

1. Model architecture: Is it a dense, 100-billion-parameter behemoth or a lean mixture-of-experts (MoE) model that only activates specific neurons?
2. Hardware selection: Is the inference running on a power-hungry legacy GPU or a specialized AI accelerator chip designed for low-wattage throughput?
3. Carbon intensity: This is the most overlooked variable. A data center in Sweden (powered by 98% hydro) might have a carbon intensity of 16g CO₂eq/kWh. The same GPU running in a coal-heavy region of the US could exceed 800g CO₂eq/kWh, a 50x difference in carbon impact for the exact same compute task.

A company practicing GreenOps doesn’t just know its cloud bill. It knows that routing job A to a hydro-powered region reduces the carbon cost by 90% without impacting latency.

A practical example: Stopping the zombie retraining cycles

The biggest source of waste in MLOps isn’t always the model itself — it’s the process we use to update it. In standard industry practice, companies often retrain models on a fixed schedule (e.g., weekly) regardless of whether the new data actually improves performance.

In my recent research on sustainable MLOps, I developed a new metric called the retraining-efficiency score (RES). Instead of blindly retraining models, RES acts as a green guardrail. It calculates the real-time trade-off between the expected accuracy gain and the carbon cost of training. If the efficiency score doesn’t meet a specific threshold, the retraining job is killed before it burns energy.

Across 2,320 controlled experiments on large-scale datasets (including energy grids and retail sales), this approach reduced annual carbon emissions by 47% compared to the industry standard always-promote baseline. Crucially, it achieved this massive carbon reduction while maintaining the same forecast accuracy. This is the essence of GreenOps: using intelligence to eliminate waste, not performance.

The entrepreneurial opportunity: The GreenOps stack

This shift presents one of the most significant opportunities in the AI ecosystem. Just as MLOps gave us deployment tools and FinOps gave us cost controls, the GreenOps stack is waiting to be built.

• Observability: We need a Grafana for energy — dashboards that visualize carbon impact alongside latency and accuracy.
• Efficiency-as-a-service: There is a market for consultancies that specialize in model quantization, pruning and distillation to reduce energy overhead.
• Energy Star for AI: We need a trusted certification body to validate model efficiency. A likely scenario is a joint scheme where technical standards (drafted by ISO/IEC JTC 1/SC 42) are audited by nonprofits like the Green Software Foundation.

Hugging Face has already set the precedent by adding estimated emissions to model cards, fueled by the CodeCarbon library. The market appetite for these numbers is real.

The verdict

The past decade proved AI can work. The next decade must prove it can work sustainably. The founders and architects who grasp this shift will not only build more responsible companies; they will build the most valuable ones. The time to start measuring your carbon cost is now, before your customers or your regulators do it for you.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Electronic components distributor Avnet oversees supply chains for major corporations, but more importantly, the Phoenix-based multinational leverages intelligence insight from its data to help understand what’s important for customers to move product for maximum profitability.

“Everything we do from an AI standpoint helps to fulfil that philosophy,” says CIO Max Chan. “Leveraging AI means cleansing data so customers can make the right decisions.”

With over 100 years of history to look back on, Avnet has always been able to prioritize technological investment as its ecosystem has grown more complex. Fundamentally important is adhering to what’s most important to the business. “Instead of having my own technology or approach to digital AI, the strategy is how do we enable the business,” he says. “So every capability we have, we look at technology, digital enablement, and AI transformation to help accelerate, redesign, or reimagine them. It’s all about helping to transform the business.”

Of course, ROI from AI can be elusive, but Chan sees missteps or flawed strategies as evidence oflooking at the wrong place. “Some people look for ROI from an investment in AI itself,” he says. “It’s like the traditional ways of looking at FinOps, for instance, to look at how much you’re spending, improving, and making out of it. We look at it differently. To us, AI is transformational, so when we implement something with AI in mind, we look at what business outcome are we hoping to drive. We get the right pricing and a more complete quote to the customer to help them learn what that converts to in terms of top and bottom line.”

But just like everything else regarding technology investment or digital enablement, success comes down to change management and governance. “Change management is key, but the overall governance of going back to whether something is contributing to a business outcome, or is directly supporting a business strategy, is essential,” he adds. “Otherwise, people will look at different POCs and use cases. We’re only looking for what directly links to strategic capabilities and the business outcome we’re looking for.”

Chan also details modernizing legacy systems with greenfield architectures, and partnerships that build resilience and customer value across industries. Watch the full video below for more insights, and be sure to subscribe to the monthly Center Stage newsletter by clicking here.

How AI helps distribution: We see very strong leverage in the sales enablement site, engineering design, managing inventory and forecasting, and orchestrating the supply chain. The common thread across all these areas is the actionable insight and data we have. So from a sales enablement perspective, what comes to mind is quoting, which is the most important thing as a distributor in terms of being informed and passing that on as quickly as we can to customers. For them, they’re able to get their products at the point they need. For us, we’re able to win the business and improve conversion. AI has helped us with pricing, getting the right information on end of life and country of origins, and putting it all together so the customer can make the best decision for what they do. It’s also about how we can help our customer service agents have readily available information to advise people. So we use it internally and externally.

On the heavy lift of legacy systems: This has been a long journey we’ve been on. Avnet continues to reinvent and apply the same mentality to modernize with technology. Over 30 years ago, we decided we wanted to go to a major ERP to run everything, but within the last 10 years, we realized that such a monolithic environment isn’t good enough. So we started building, just like everyone else, to get benefit from cloud transformations and build on top of it. But what my team and I quickly learned was that wasn’t going to cut it. We had support from the organization to start from scratch, and build a modern architecture that’s digital and AI first, which allows us to leverage different capabilities. The mentality of continuous improvement, and not to get hung up on what we’ve built over the last 30 years, has helped us with that success in driving AI and the transformation we see today.

On the changes AI brings: It comes back to the culture and learning agility we want everyone in the organization to have. Interestingly, AI is probably a lot easier than most other technologies that came before it because of ChatGPT, gen AI, and the many different tools that suddenly came up in the last few years. Everyone got excited. Trying to create that learning pathway, and getting people systematically upskilled to be able to approach and leverage AI the right way, is what we’re doing across the organization. We see it like there are three different types of AI to grapple with. One is productivity tools like ChatGPT that we give people to do what they need to do. The second is what comes with all the software you have, since all major software comes with AI components. Then last are the things my team would develop and build in accordance with what we want in order to drive the company forward, and how we transform. So we have more than enough tools that we allow the organization to leverage, and we have a governance process to request what people can use, or we give them an alternative. If it comes with the software we own, if we already have the license, then go for it since it’s embedded and will help us better leverage the software. The focus we have on AI is what we’re doing to transform the way we work, the workforce, the work itself, and in some cases, the business and how we can better serve our customers and employees. One way is reimagining some end-to-end processes to see if they can be fully autonomous. If so, what would it look like? Once that’s done, we bring people back in the loop to augment it and make it even more powerful for our business.

On AI impacting workflows: As far as disruption and resiliency from a supply chain standpoint, focus is on relationships with customers, both upstream and downstream, and understanding what they are, what they have, what they need to do, and what they want to do. And the signals we send around the industry help strengthen that resiliency. We get asked how can we help avoid the next supply chain debacle, and it comes down to partnerships, availability of data, and connectivity. In order for us to do that internally, from a tech stack standpoint, we need to target the modern architecture that drives microservices and allows us to have strong API connections. We created a platform called the Partner Digital Exchange, which helps bring data downstream, and combines it with what we have to drive orchestration. And that allows us to bring AI into the mix and help customers with the information they need. It also helps Avnet create that stickiness in the ecosystem.

Global IT spending will rise 10.8% in 2026, but the increases will be incredibly uneven, with huge spikes in AI and data center outlays far outpacing other categories, Gartner predicts.

Worldwide IT spending will reach $6.15 trillion this year, despite fears of an AI bubble and concerns about inconsistent tariff policies from US President Donald Trump’s administration, Gartner projects.

The increase will largely be driven by AI spending, projected to rise by 80.8% from 2025, and by data center system outlays, up 31.7%. While Gartner sees spending increases in all five IT categories it tracks, spending on communications services will rise by only 4.7%, and spending on devices, PCs, and laptops will increase by only 6.1%, with skyrocketing memory costs prompting many IT buyers to delay device purchases.

Services feel the squeeze

Services providers, meanwhile, are getting squeezed by AI, says John-David Lovelock, a vice president analyst at Gartner. Runaway AI spending, coming from both large hyperscalers and other enterprises, has put pressure on CIOs to ratchet down spending elsewhere, and many have turned to their services budgets to pinch pennies, he adds.

At the same time, IT buyers expect that services providers are using AI to assist their efforts and cut costs, and they are demanding that those savings be passed on to them, he says.

“Services companies are almost penalized because the expectation is that they are going to be using some form of AI or agents or assistance within the delivery,” Lovelock says. “CIOs need to find somewhere that they have control of their budget, and they can pick on the services companies because they’re using AI.”

The AI spending hike, meanwhile, is happening while many observers fear that a stock market bubble is about to pop. Disillusionment about generative AI is high right now, Lovelock says, and concerns about AI agents are building.

But over the longer term, a major shift from an old information technology model to a new intelligence technology model is happening, creating value for AI firms, he adds.

“We’re going to have some people limping along for a while, but we are at the very early years of the new super cycle, which is intelligence technology,” he says. “It’s going to rewrite the rules of value creation, it’s going to rewrite the rules of revenue, and it’s going to rewrite where growth is.”

From Jan. 28 to Feb. 5, the US S&P 500 software and services index dropped 4.6%, losing nearly $1 trillion in value, on fears that AI would upend the traditional software sector. Some of the biggest losers, however, included companies heavily invested in AI, including Microsoft, Salesforce, and ServiceNow.

AI in the trenches

The Gartner prediction on AI spending rings true for several IT leaders.

Software development firm Innowise will see its IT budget increase in 2026 between the high single digits and the low double digits, says Dmitry Nazarevich, CTO there. About half of the budget increase will come from AI, with the rest related to security, modernization, and cost-related initiatives, he adds.

However, the increase in other IT spending is also related to AI. “The increase in spending on security is directly related to the increase in exposure and risk to data associated with the increased attack surface resulting from the introduction of generative AI,” Nazarevich says. “The increase in spending on modernization is partly a result of the fact that legacy or outdated systems limit the effectiveness of AI technology and delay deployment schedules.”

In addition, Innowise is spending more on FinOps because of the unpredictability of computing bills created by AI workloads, he adds.

Duanex, another software development firm, has increased its 2026 IT budget by a whopping 70%, says Oleg Danyliuk, founder and CEO. About 10% of the increase comes from the cost increases in collaboration, security, and other IT tools, he says.

“All the rest is AI,” he adds.

For example, Duanex purchased a corporate ChatGPT subscription, as well as the IntelliJ Idea AI package and Claude Code for software development. The company also hired an additional IT professional for its AI agent team.

A bursting AI bubble shouldn’t affect the company’s IT spending, Danyliuk adds.

“It is important to be flexible in the current dynamic world,” he says. “If AI appears to be a bubble, that would mean that companies will need more developers to code and we will grow. If AI indeed automates as much as everyone expects, we are prepared as well, as we are selling automation projects and consulting.”

Many enterprise customers of Southworks, a third software development firm, are reporting IT budget increases of 15% to 30%, with AI accounting for half to two-thirds of the hikes, says Johnny Halife, CTO at Southworks.

AI-related projects like platform modernization and data foundations are also driving up budgets, he says.

“The lion’s share of that growth is tied directly to AI implementation projects — everything from agentic systems and custom/fine-tuned models to the supporting infrastructure, data centers, GPUs, and cloud capacity that makes it all run,” he says. “It’s the single biggest line item pulling dollars right now, especially as organizations move from pilots and PoCs into scaled production deployments.”

2026년 IT는 수십 년 만에 가장 큰 전환기를 맞고 있다. 디지털 트랜스포메이션의 가속, 끊임없는 보안 위협, 경제적 불확실성이 맞물리면서, 기업이 기술을 구축하고 보호하며 운영하는 방식 자체를 다시 정의하고 있다. IT 리더에게 주어진 과제는 분명하다. 혁신의 속도를 따라가는 데 그치지 않고, 혁신을 직접 이끌 수 있는 회복력 있고 효율적이며 지능적인 인프라를 설계하는 것이다.

다음 5가지 트렌드는 이런 변화의 핵심을 이룬다. 이 흐름은 IT의 다음 단계에서 주도권을 확보하려는 기업이 나아가야 할 방향을 제시한다.

1. 하이브리드는 새로운 기본값

2026년에는 하이브리드 및 멀티 클라우드가 더 이상 하나의 전략이 아니라 기본 전제가 될 가능성이 높다. 이는 비용 최적화와 사이버 회복탄력성, 규제 준수를 동시에 달성하기 위해서다. 단일 벤더에 묶이는 기존 모델은 점차 힘을 잃고, 환경 전반에 걸친 유연성과 통제력을 중시하는 방향으로 이동하고 있다.

이러한 변화의 핵심 축으로 서비스형 네트워크(Network-as-a-Service)가 부상하고 있다. 이를 통해 데이터센터와 퍼블릭 클라우드, 엣지 환경 전반에 걸쳐 소프트웨어 정의 방식을 온디맨드로 연결할 수 있게 되면서, 기업은 중앙 집중식 가시성을 확보하고 비즈니스 요구 변화에 따라 대역폭을 확장하거나 네트워크 구성을 민첩하게 재조정하고 있다.

이와 함께 컨테이너 플랫폼과 클라우드 네이티브 데이터베이스가 보편적인 인프라 요소로 자리 잡고 있다. 이는 애플리케이션 개발 및 출시 속도를 단축하도록 지원한다. 기존 시스템 역시 API와 마이크로서비스를 통해 지속적으로 현대화되며, 클라우드 네이티브 생태계에 자연스럽게 참여할 수 있는 기반을 마련할 수 있다.

올해 하이브리드 아키텍처의 완성도를 끌어올리는 핵심 요소는 ‘단일 화면 기반 가시성(single-pane-of-glass)’이다. 여러 대시보드와 모니터링 도구를 억지로 연결하는 대신, IT팀은 하이브리드 클라우드 성능과 보안 상태, 거버넌스 제어, 핀옵스(FinOps) 인사이트를 한곳에서 제공하는 통합 플랫폼을 활용할 수 있다. 이러한 통합은 그동안 문제 해결과 위험 평가, 최적화를 지연시켜 왔던 사각지대를 해소한다. 단일 운영 관점을 확보함으로써 기업은 워크로드 배치와 비용 관리, 규제 준수에 대해 더 빠르고 확신 있는 의사결정을 내릴 수 있다.

비용과 복잡성을 통제하기 위해 핀옵스(FinOps) 관행과 자동화된 거버넌스 도구 도입이 점차 확대될 전망이다. 통합 가시성은 클라우드 지출과 정책 준수, 위험 노출에 대한 실시간 인사이트를 제공하며, 운영 전반의 모든 계층에 효율성과 책임이 자연스럽게 내재되도록 한다.

2. 새로운 사이버 방패가 된 AI

2026년의 사이버 보안은 벽을 쌓는 방식에서 벗어나, 잘못된 가정을 제거하는 데 중점을 둔다. 기업은 모든 사용자와 디바이스, 연결을 지속적으로 검증하는 제로 트러스트 아키텍처에 대한 투자를 한층 강화할 전망이다. 앞으로의 보안은 경계 기반 방어 대신, 적응형이고 신원 중심이며 AI가 주도하는 방식으로 진화할 것이다.

AI는 사이버 회복탄력성을 높이는 데 핵심적인 역할을 맡는다. 이상 행동을 탐지하는 행위 분석부터 침해된 엔드포인트를 즉각 격리하는 자동화된 위협 대응까지, 머신러닝(ML)은 기업 보안 전략의 중심 축으로 자리 잡고 있다.

또한 다단계 인증(MFA), 비밀번호 없는 인증, 마이크로 세그멘테이션이 기본 통제 방식으로 자리 잡을 가능성이 높다. 보안팀은 AI 기반 자동화와 실시간 위협 인텔리전스를 활용해 탐지와 대응 시간을 획기적으로 단축할 수 있다. 탐지에서 차단, 복구로 이어지는 회복탄력성 전 과정을 완성하기 위해 기업은 변경 불가능한 백업과 클린룸 복구 환경, 분리된 복구 네트워크에 대한 의존도를 점차 높이게 된다. 이를 통해 시스템을 빠르고 안전하게, 재감염 위험 없이 복구할 수 있다.

그 결과 침해 발생부터 차단까지의 핵심 지표인 위협 체류 시간은 눈에 띄게 줄어들 수 있다. 제로 트러스트 프로그램 역량을 끌어올린 기업은 노출을 최소화하는 동시에, 분산된 하이브리드 환경 전반에서 안전하게 운영할 수 있는 신뢰를 확보할 수 있다.

3. 제품으로서의 데이터

올해 데이터는 전략적 비즈니스 자산으로서의 역할을 본격적으로 확립할 전망이다. 기업은 데이터 레이크와 데이터 웨어하우스, 거버넌스 프레임워크를 하나의 일관된 생태계로 통합하는 통합 데이터 플랫폼에 대규모 투자를 이어갈 것으로 예상된다. 목표는 단순하지만 분명하다. 전사적인 의사결정을 뒷받침할 수 있는 단일 데이터 기준을 구축하는 것이다.

이런 플랫폼은 실시간 데이터 파이프라인과 이벤트 스트리밍, 의미 기반 레이어를 결합해 IT나 데이터 과학팀을 넘어 보다 폭넓은 구성원이 분석에 접근할 수 있도록 한다. 현업 부서는 실시간 운영 데이터를 직접 조회하고 시각화하며, 더 빠르고 근거 기반의 의사결정을 내릴 수 있게 된다.

데이터 활용의 민주화는 신뢰와 투명성에 대한 요구를 함께 높인다. 기업은 정보가 단순히 활용 가능한 수준을 넘어 신뢰할 수 있는 상태로 유지되도록 하기 위해 데이터 카탈로그화, 계보 추적, 데이터 품질 관리에 투자할 전망이다.

이 영역에서 성과를 내는 기업은 데이터를 하나의 제품으로 다루고 있다. 이는 명확한 책임 주체와 서비스 수준 기대치, 재사용성을 전제로 데이터 관리 체계를 설계하는 방식이다. 통합 데이터 관리는 AI 도입부터 운영 자동화에 이르기까지 모든 IT 이니셔티브를 연결하는 핵심 축이 된다.

4. 혁신을 위한 자동화

2026년에도 자동화는 IT 운영 전반을 재정의하는 핵심 요소로 작용한다. 단순한 스크립트나 개별 워크플로우 수준을 넘어, 기업은 자동화를 활용해 프로비저닝과 배포, 패치, 사고 대응 등 복잡한 엔드투엔드 프로세스를 유기적으로 조율하게 된다.

AI옵스(AIOps)는 표준 역량으로 자리 잡고 있다. 이는 모니터링 도구, 로그, 사용자 경험 전반에서 발생하는 신호를 연계 분석함으로써 팀이 이상 징후를 감지하고 장애를 예측하며, 서비스에 영향을 미치기 전에 문제를 해결하는 역할을 수행한다. 특히 단일 화면 기반 가시성 플랫폼을 도입하는 조직이 늘어나면서, AI옵스 엔진은 하이브리드 클라우드 성능과 보안 텔레메트리, 비용 추세, 정책 집행 정보가 통합된 데이터를 활용할 수 있게 된다. 맥락과 영역 간 인사이트가 풍부해질수록 자동화된 의사결정은 더욱 똑똑해지고, 속도와 정확성도 함께 높아진다.

또한 인프라스트럭처 코드화(Infrastructure-as-Code)와 깃옵스(GitOps) 관행은 IT 관리 방식을 근본적으로 바꾸고 있다. 구성 변경 사항은 버전 관리되고 동료 검토를 거치며, 필요할 경우 즉시 되돌릴 수 있어 안정성과 규제 준수 수준이 크게 향상될 수 있다. 통합 대시보드를 통해 제시되는 거버넌스 규칙이 이런 관행을 뒷받침하며, 자동화를 보다 안전하고 예측 가능한 방향으로 이끈다.

이 같은 IT 운영의 현대화가 가시적인 성과로 이어질 수 있다. 시스템 신뢰성이 높아지고 수작업으로 인한 오류는 줄어들며, 새로운 애플리케이션과 서비스의 출시 속도도 빨라진다. IT 리더에게 단일 화면 기반 운영 토대 위에 구축된 자동화는 확장성의 핵심 동력이 되며, 이를 통해 IT팀은 반복적인 장애 대응에서 벗어나 혁신에 더 많은 역량을 집중할 수 있다.

5. 엣지로 이동하는 컴퓨팅

연결된 기기와 실시간 애플리케이션이 폭발적으로 증가하면서 2026년에는 엣지 컴퓨팅 확산이 가속화될 전망이다. 지연 시간과 대역폭 제약이 비즈니스 핵심 요소로 떠오르면서, 기업은 데이터가 생성되는 지점과 가까운 곳에 컴퓨팅 자원을 배치하는 방식을 고려하고 있다. 공장 현장과 리테일 매장, 차량, 스마트 시티 인프라가 대표적인 예다.

이런 전환은 즉각적인 의사결정과 로컬 처리를 가능하게 하며, 모든 트랜잭션을 중앙 클라우드에 의존하던 구조에서 벗어나게 한다. 표준화된 엣지 스택은 장치의 온보딩과 관리를 단순화하는 동시에, 분석과 장기 저장을 위해 클라우드 시스템과의 안전한 동기화를 유지한다. SD-WAN과 멀티 클라우드 연결성은 엣지 아키텍처를 현실적으로 구현하고 관리 가능하게 만드는 연결 고리 역할을 한다. 이를 통해 수천 개에 달하는 분산 노드 전반에 걸쳐 일관된 정책 집행과 안정적인 라우팅, 통합 가시성을 확보할 수 있다. 이런 역량은 클라우드 리전과의 긴밀한 통합, 규제 준수 기준과의 정렬과 결합되며, 워크로드가 물리적으로 어디에 위치하든 데이터 보존과 프라이버시, 주권에 대해 동일한 통제를 적용할 수 있도록 한다.

특히 제조, 물류, 헬스케어, 리테일 업계는 반응성과 회복탄력성 측면에서 큰 성과를 얻을 수 있다. 예측 유지보수, 컴퓨터 비전, 위치 인텔리전스는 데이터를 엣지에서 직접 처리함으로써 효과가 더욱 커지게 된다.

이런 역량이 성숙할수록 디지털 운영과 물리적 운영의 경계는 점차 흐려질 수 있다. 그 결과 자동화와 지속 가능성, 새로운 비즈니스 모델 혁신으로 이어지는 기회가 본격적으로 열릴 것이다.

2026년을 위한 IT 플레이북

5가지 트렌드는 지능적이고 자동화되며 분산돼 있으면서도, 강력한 거버넌스와 보안으로 하나로 통합된 IT 환경의 모습을 분명하게 보여준다. 기술 리더에게 성공 여부는 지금 얼마나 의도적이고 명확한 선택을 하느냐에 달려있다.

기술 리더는 유연성과 통제력을 제공하는 하이브리드 클라우드 아키텍처를 최우선 과제로 삼아야 한다. 모든 접근 지점을 보호할 수 있도록 제로 트러스트 이니셔티브를 성숙 단계로 끌어올리고, 정보를 실질적인 인사이트로 전환하는 통합 데이터 플랫폼에 투자해야 한다. 효율성과 회복탄력성을 높이기 위해 자동화를 한층 강화하고, 디지털 영역을 확장할 수 있는 엣지 컴퓨팅 사용례도 본격적으로 시범 운영할 시점이다.

차세대 IT는 단일 기술로 정의되지 않는다. 핵심은 모든 요소가 얼마나 유기적으로 맞물려 작동하느냐다. 2026년, 성과를 내는 기업은 현대화를 하나의 도착점이 아니라 지속적으로 이어지는 여정으로 받아들이는 조직이 될 것이다.
dl-ciokorea@foundryco.com

As we move forward in 2026, the IT landscape is undergoing its most transformative period in decades. The forces of digital transformation, persistent security threats and economic uncertainty are converging to redefine how organizations build, secure and manage technology. For IT leaders, the mission is clear: Architect resilient, efficient and intelligent infrastructure that not only keeps pace with innovation but also drives it.

The following five trends represent the core of that evolution. Together, they outline the path forward for enterprises determined to modernize, protect and lead in the next era of IT.

1. Hybrid is the new default

In 2026, hybrid and multi-cloud will no longer be a strategy; they will be the default. Enterprises will fully embrace these architectures to balance cost optimization, cyber resilience and compliance. The old model of locking into a single provider is giving way to flexibility and control across environments.

Network-as-a-service will become a cornerstone of this shift, offering software-defined, on-demand connectivity across data centers, public clouds and edge locations. Organizations will gain centralized visibility and the agility to scale bandwidth or reconfigure networks as business needs evolve.

At the same time, container platforms and cloud-native databases will become ubiquitous, supporting agile application development and faster time-to-market. Legacy systems will continue to be modernized through APIs and microservices, ensuring they can participate in a cloud-native ecosystem.

What will truly elevate hybrid architectures this year is the rise of single-pane-of-glass visibility. Instead of stitching together fragmented dashboards and monitoring tools, IT teams will rely on unified platforms that display hybrid cloud performance, security posture, governance controls and FinOps insights in one place. This consolidation will eliminate blind spots that have traditionally slowed down troubleshooting, risk assessment and optimization. With a single operational lens, organizations will make faster, more confident decisions about workload placement, cost control and compliance.

To control cost and complexity, enterprises will increasingly turn to FinOps practices and automated governance tools. Unified visibility will power these practices with real-time insights into cloud spending, policy compliance and risk exposure, ensuring that efficiency and accountability are built into every layer of operations.

2. AI becomes the new cyber shield

Cybersecurity in 2026 will be less about building walls and more about eliminating assumptions. Organizations will deepen their commitment to zero-trust architectures that verify every identity, device and connection continuously. The days of perimeter-based defenses are gone; the future is adaptive, identity-first and AI-driven.

AI will play a pivotal role in enhancing cyber resilience. From behavioral analytics that flag anomalous activity to automated threat response that isolates compromised endpoints, machine learning will become a core pillar of enterprise defense strategies.

Expect to see widespread adoption of multifactor authentication (MFA), passwordless authentication and micro-segmentation as baseline controls. Security teams will leverage AI-powered automation and real-time threat intelligence to dramatically reduce detection and response times. To complete the resilience arc from detect to contain to recover, organizations will increasingly rely on immutable backups, clean-room recovery environments and segmented recovery networks that ensure systems can be restored quickly, safely and without reinfecting the environment.

The result will be a measurable drop in threat dwell time, the critical window between breach and containment. Organizations that mature their zero-trust programs will not only minimize exposure but also build the confidence needed to operate securely across distributed, hybrid environments.

3. Data as a product, not a problem

This year, data will fully step into its role as a strategic business asset. Companies will invest heavily in unified data platforms that integrate data lakes, warehouses and governance frameworks into a cohesive ecosystem. The goal is simple yet powerful: Create a single source of truth that can fuel decision-making across the enterprise.

These platforms will combine real-time data pipelines, event streaming and semantic layers to make analytics accessible beyond IT and data science teams. Business users will gain the ability to query and visualize live operational data, empowering faster, evidence-based decisions.

This democratization of data will come with a renewed emphasis on trust and transparency. Organizations will invest in cataloging, lineage tracking and data quality controls to ensure information is not only available but also reliable.

The companies that succeed in this space will treat data as a product, with clear ownership, service-level expectations and reusability built in. Unified data management will be the linchpin connecting every other IT initiative, from AI adoption to operational automation.

4. Automate to innovate

Automation will continue to redefine IT operations in 2026, moving far beyond simple scripts and workflows. Enterprises will harness automation to orchestrate complex end-to-end processes: provisioning, deployments, patching, incident response and beyond.

AIOps will mature into a standard capability. By correlating signals across monitoring tools, logs and user experiences, AIOps will help teams detect anomalies, predict failures and resolve incidents before they impact service delivery. The effectiveness of these systems will increase significantly as more organizations adopt single-pane visibility platforms, allowing AIOps engines to pull from unified data on hybrid cloud performance, security telemetry, cost trends and policy enforcement. With richer context and cross-domain insight, automated decision-making will become smarter, faster and more accurate.

Infrastructure-as-code and GitOps practices will transform how environments are managed. Configuration changes will be version-controlled, peer-reviewed and instantly reversible, dramatically improving stability and compliance. Governance rules surfaced through unified dashboards will guide these practices, making automation safer and more predictable.

This modernization of IT operations will deliver tangible outcomes: higher reliability, fewer manual errors and faster rollout of new applications and services. For IT leaders, automation built on a single-pane operational foundation will become the engine of scalability, freeing teams to focus on innovation rather than firefighting.

5. Computing moves to the edge

The explosion of connected devices and real-time applications will drive a surge in edge computing in 2026. As latency and bandwidth constraints become business-critical, organizations will deploy compute resources closer to where data is generated, on factory floors, retail stores, vehicles and smart city infrastructure.

This shift will enable instantaneous decision-making and local processing, reducing reliance on centralized cloud resources for every transaction. Standardized edge stacks will simplify the onboarding and management of devices while maintaining secure synchronization with cloud systems for analytics and long-term storage. SD-WAN and multi-cloud connectivity will act as the connective tissue that makes edge architectures viable and governable, ensuring consistent policy enforcement, resilient routing and unified visibility across thousands of distributed nodes. These capabilities will be increasingly paired with deep integration into cloud regions and alignment with compliance standards, allowing organizations to apply uniform controls for data retention, privacy and sovereignty regardless of where workloads physically reside.

Industries such as manufacturing, logistics, healthcare and retail will see major gains in responsiveness and resilience. Predictive maintenance, computer vision and location intelligence will all benefit from processing data directly at the edge.

As these capabilities mature, the boundary between digital and physical operations will blur, unlocking new opportunities for automation, sustainability and business model innovation.

Your 2026 IT playbook

These five trends point toward an IT environment that is intelligent, automated and distributed, yet unified by strong governance and security. For technology leaders, success in this era will depend on taking deliberate steps now.

Prioritize hybrid cloud architectures that deliver flexibility and control. Mature your zero-trust initiatives to ensure every access point is protected. Invest in unified data platforms that turn information into insight. Double down on automation to build efficiency and resilience. And begin piloting edge computing use cases that extend your digital reach.

The next generation of IT will not be defined by a single technology, but by how seamlessly all these pieces work together. In 2026, the enterprises that thrive will be those that treat modernization as a continuous journey, not a destination.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Platform engineering has reached a critical juncture. The discipline has evolved from an emerging trend to an enterprise operating system, fundamentally reshaping how organizations deliver applications. Platform engineering is “eating the world”—absorbing traditional silos like operations, observability, security, data, and FinOps into unified paradigms. Yet this transformation carries significant risk: execution matters more than ever.

The data reveals a stark divide. 40.9% of platform engineering initiatives can’t demonstrate measurable value within their first twelve months, leaving them vulnerable to defunding or deprioritization. Yet 35.2% of teams deliver tangible value within just six months. This gap isn’t about technology or budget. It’s about approach. Success gap is driven by leadership choices and operating models, not just team-level execution.

These insights emerge from the 2025 State of Platform Engineering Report Volume 4, published by platformengineering.org and sponsored by Broadcom as exclusive supporters of the research. Based on insights from 518 engineers, the report examines what separates successful platform engineering initiatives from those that struggle. The findings hold critical implications for CIOs navigating the shift to AI-native infrastructure.

For technology leaders, the question is no longer whether to invest in platform engineering, but how to ensure your investment delivers measurable business value—and how to do it fast enough to stay competitive.

Five critical takeaways for CIOs

1. Culture over technology: The true success factor

Here’s a wake-up call: cultural and organizational barriers outweigh technical ones. The top challenges for platform teams aren’t about technology—they’re about people:

• Driving developer adoption (the #1 challenge)
• Establishing a shared vision or product mindset
• Securing executive buy-in
• Overcoming limited product management capabilities

The report makes it clear: platform engineering succeeds where culture supports it, and fails where it does not. As a CIO, the role isn’t just to approve budgets and timelines—it’s to champion the cultural transformation required, including organization design, funding continuity, executive sponsorship, and accountability. This means driving mindset shifts across the organization, ensuring clear alignment between teams and leadership, and fostering genuine collaboration that breaks down traditional silos.

2. Adopt a platform-as-a-product mindset

The most successful platform engineering initiatives treat the platform as a continuous product, not a one-off project. The report shows that only 36.6% of organizations have dedicated Platform Product Managers, yet those with product-focused approaches consistently outperform those without.

CIOs need to champion the platform-as-a-product mindset:

• Dedicated ownership: Consider investing in Platform Product Managers who own the platform roadmap and user experience
• User-focused development: Ensure platform teams continuously gather feedback from developer users and iterate based on their needs
• Strategic alignment: Platform evolution should be explicitly tied to business goals, not just technical improvements

The data shows that 45.5% of organizations have dedicated, budgeted platform teams, but they remain mostly reactive. The gap between reactive and strategic platform operations is where CIOs can drive platform-as-a-product mindset mandate.

3. Start small, fail fast, scale strategically

The report reveals a powerful insight: 35.2% of the teams deliver measurable value within six months using an MVP (Minimum Viable Platform) approach, while 40.9% of platform initiatives can’t demonstrate value within their first twelve months.

CIOs must ensure teams are empowered to define focused “golden paths” that cover 80% of common needs to standardize and automate quickly. They use an iterative approach completed in weeks, not months. This de-risks the initiative and demonstrates measurable value quickly to key stakeholders.

The organizations that succeed:

• Start with one high-impact use case and prove value
• Iterate rapidly based on user feedback
• Scale gradually as adoption grows organically
• Avoid the “boiling the ocean” trap of trying to solve everything at once

4. Guide teams to metrics that matter

Despite improvements from last year, nearly 30% of platform teams still don’t measure success at all. This is a critical vulnerability that cripples the ability to prove ROI, secure investment, and guide decision-making.

CIOs should guide their platform teams toward measurement excellence. The successful organizations leverage KPI like DORA metrics, time to market, and SPACE metrics to evaluate platform impact. CIO must coach and mandate teams to establish robust measurement frameworks and create urgency around proving value through data.

When platform teams see measurement as their responsibility—not a burden imposed from above—they become invested in demonstrating impact. CIOs who guide their teams to embrace measurement from day one create cultures where teams proactively identify struggling initiatives and course-correct before resources are wasted.

5. The AI-native era demands a dial platform mandate

The most significant finding from this year’s report is the fundamental shift from the cloud-native era to the AI-native era. An overwhelming 94% of organizations view AI as critical to the future of platform engineering, and 86% believe platform engineering is essential to realizing AI’s business value.

CIOs now face a dual mandate:

• AI-powered platforms: Integrating AI tools to augment Internal Developer Platforms (IDPs), enhancing developer productivity and driving automation
• Platforms for AI: Building specialized infrastructure for deploying, training, and scaling AI/ML workloads

With 75% of organizations already hosting or preparing to host AI workloads, the time to act is now. Yet challenges persist: 57% cite skill gaps, and 56% identify hallucination risks as major concerns. CIOs can drive executive ownership of AI risk management, skills strategy, and platform readiness. Platform strategy must address both opportunities and challenges head-on.

How VMware Cloud Foundation (VCF) enables platform engineering success

The challenges outlined in the State of Platform Engineering Report aren’t just industry observations—they’re problems that demand immediate solutions. VMware Cloud Foundation (VCF) delivers comprehensive platform engineering capabilities. Three stand out as particularly critical:

AI-ready infrastructure: VCF includes VMware Private AI Foundation with NVIDIA as a built-in capability. Organizations get production-ready AI infrastructure with NVIDIA AI Enterprise, NIM inference microservices, and GPU orchestration—all managed through the same unified platform. Recent MLPerf benchmarks show performance on par with bare-metal while achieving up to 29% lower TCO.

Rapid time to value: VCF’s automation and self-service IaaS capabilities accelerate platform delivery for all types of applications VM, container, and AI.  Fleet Management automates full-stack lifecycle operations, cutting operational overhead by 60%. According to an aggregate study of 138 customer environments, VCF delivers 61% faster deployment of new workloads—critical when platform teams need to prove ROI within six months.

Built-in observability: VCF Operations provides comprehensive observability with tenant-level utilization tracking, chargeback capabilities, and alert management. This eliminates the “we need to build metrics infrastructure first” delay that prevents teams from measuring success at all.

The path forward: Building your platform engineering future

Platform engineering is the enterprise operating model of the modern decade. The divide is clear: 35.2% demonstrate value in six months and thrive. 40.9% struggle to prove ROI in twelve months and risk defunding.

CIOs should benchmark their organization’s platform engineering maturity, understand the complete landscape of challenges, and develop and execute next steps.

Explore VMware Cloud Foundation to accelerate your platform engineering journey with AI-ready infrastructure, rapid automation, and built-in observability.

The successful 35.2% invested in people, culture, and the right foundation. The choice is yours.

Es una evidencia: las organizaciones no cejan de invertir con fuerza en soluciones en la nube de cara a 2026. El objetivo es claro según el estudio 2025 CIO Cloud Computing Study de Foundry: mejorar la productividad de los empleados en el 31% de los casos, mejorar la seguridad y la gobernanza en la organización en el 30%, y acelerar la adopción de la IA y el ML en el 13%.

La encuesta revela que el 70% de los responsables de la toma de decisiones de TI está de acuerdo en que su organización ha acelerado la migración a la nube en los últimos 12 meses, en comparación con el 62% en 2024 y el 57% en 2023. Además, el 70% reconoce que su organización opta por defecto por los servicios basados en la nube cuando actualiza o adquiere nueva tecnología, y el 71% afirma que las inversiones en la nube han ayudado a su organización a mantener un aumento de los ingresos en los últimos 12 meses.

Este crecimiento en la adopción de la nube también ha provocado un aumento de la demanda de determinados puestos relacionados con la nube. A continuación, y sirviéndonos de la investigación de Foundry, le detallamos algunos de los que las empresas probablemente hayan añadido para respaldar sus inversiones en la nube.

Arquitecto de seguridad

Los arquitectos de seguridad se encargan de crear, diseñar e implementar soluciones de seguridad en la organización para mantener la seguridad de la infraestructura de TI. Para los que trabajan en un entorno de nube, el objetivo es diseñar e implementar soluciones de seguridad que protejan la infraestructura, los datos y las aplicaciones basados en dicho entorno.

Habilidades: diseño de arquitectura de seguridad, seguridad de redes, cumplimiento y gobernanza de la seguridad, respuesta a incidentes y análisis forense, cifrado de datos, gestión de identidades y accesos (IAM), automatización y DevSecOps.

Crecimiento del puesto: el 22% de las empresas ha añadido puestos de arquitecto de seguridad como parte de sus inversiones en la nube.

Administrador de sistemas en la nube

Los administradores de sistemas en la nube se encargan de supervisar el mantenimiento y la gestión general de la infraestructura en la nube. Estos profesionales de TI son expertos en navegar por entornos virtualizados ya sea implementando políticas basadas en la nube, desplegando parches y actualizaciones o analizando el rendimiento de la red,

Habilidades: conocimiento de la implementación e integración, la seguridad y la configuración, así como de las herramientas de software en la nube más populares, como Azure, AWS, GCP, Exchange y Office 365.

Crecimiento del puesto: el 22% de las empresas cuenta con nuevos puestos de administrador de sistemas en la nube como parte de sus inversiones en la nube.

Arquitecto de datos

La función de un arquitecto de datos es asegurarse de que los datos de una organización estén estructurados de manera que se pueda acceder a ellos fácilmente, estén protegidos y se almacenen de manera eficiente, y satisfagan las necesidades empresariales. Los datos se han convertido en la principal forma en que las empresas realizan análisis y ayudan en la toma de decisiones empresariales, y la mayor parte de esos datos se almacenan ahora en la nube.

Habilidades: almacenamiento de datos, escalabilidad y optimización del rendimiento, automatización y virtualización, gobernanza de datos y seguridad en la nube, migración de datos y conocimiento de soluciones de nube híbrida.

Crecimiento del puesto: el 22% de las empresas ha incorporado puestos de arquitecto de datos como parte de sus inversiones en la nube.

Gerente de gobernanza y cumplimiento normativo en la nube

Los gestores de gobernanza y cumplimiento normativo en la nube ayudan a las empresas a navegar por las complejidades de la seguridad, la gobernanza, la normativa internacional y las políticas internas. Se encargan de identificar los riesgos potenciales, implementan herramientas automatizadas para supervisar la seguridad y el cumplimiento normativo, y ayudan a las empresas a mantener operaciones seguras en la nube.

Habilidades: sólidos conocimientos de políticas normativas como el RGPD, la HIPAA, el PCI DSS y otras leyes internacionales de protección de datos. Otras habilidades adicionales incluyen el conocimiento de herramientas como CSPM, Azure, AWS, Microsoft Purview Compliance Manager y otras herramientas de gobernanza de TI.

Crecimiento del puesto: el 20% de las empresas ha incorporado puestos de gestor de cumplimiento normativo y gobernanza en la nube como parte de sus inversiones en la nube.

Ingeniero de seguridad

Los ingenieros de seguridad se encargan de supervisar la seguridad de los sistemas, las redes y los datos de una organización para garantizar que estén protegidos contra las amenazas de ciberseguridad. Se trata de perfiles que pueden ayudar a las organizaciones que invierten en la nube a garantizar que los servicios, las aplicaciones y los datos que se ejecutan en plataformas en la nube sean seguros y cumplan con cualquier normativa gubernamental.

Habilidades: seguridad de redes, IAM, cifrado, gestión de vulnerabilidades, arquitectura de seguridad, seguridad en la nube, automatización y diseño y optimización de infraestructuras.

Crecimiento del puesto: el 19% de las empresas ha añadido puestos de ingeniero de seguridad como parte de sus inversiones en la nube.

Gerente de productos en la nube

La adopción de la nube suele ir acompañada de un aumento del desarrollo interno de servicios basados en la nube. Un gerente de productos en la nube puede ayudar a los equipos de la nube a desarrollar soluciones eficaces destinadas a cumplir los objetivos empresariales. También se encargan de utilizar su profundo conocimiento de la gestión de productos en el entorno de la nube para trabajar en estrecha colaboración con las partes interesadas que son clave en el negocio, identificar y definir los requisitos de los usuarios o clientes, desarrollar hojas de ruta de productos y supervisar el proceso de control de calidad para obtener comentarios sobre cómo mejorar la oferta de productos.

Habilidades: gestión de productos, diseño de UX, comunicación y colaboración, y una sólida formación técnica.

Crecimiento del puesto: el 19% de las organizaciones dispone de nuevos puestos de gestor de productos en la nube como parte de sus inversiones en la nube.

Consultor de nube

Con la rápida adopción y migración a la nube, las organizaciones buscan profesionales que puedan aprovechar las tecnologías de nube para satisfacer las necesidades empresariales, hacer crecer el negocio y mejorar la eficiencia. Estos profesionales son expertos en nube y se mantienen al día de las últimas innovaciones en tecnología de nube para asesorar mejor a los líderes empresariales.

Habilidades: conocimientos de arquitectura y diseño de soluciones, DevOps, automatización, gestión de proyectos, seguridad en la nube, cumplimiento normativo, migración a la nube y conocimientos de las plataformas de nube más populares.

Crecimiento del puesto: el 18% de las empresas ha incorporado consultores de nube como parte de sus inversiones en nube.

Ingeniero de DevOps

DevOps se centra en combinar las operaciones de TI con el proceso de desarrollo para mejorar los sistemas de TI y actuar como intermediario en el mantenimiento del flujo de comunicación entre los equipos de codificación e ingeniería. Es un puesto que se centra en la implementación de aplicaciones automatizadas, el mantenimiento de la infraestructura de TI y nube, y la identificación de los posibles riesgos y beneficios de los nuevos programas y sistemas.

Habilidades: automatización, Linux, pruebas de control de calidad, seguridad, contenedorización y conocimientos de lenguajes de programación como Java y Ruby.

Crecimiento del puesto: el 17% de las empresas cuenta ya con nuevos puestos de ingeniero DevOps como parte de sus inversiones en la nube.

Profesional de FinOps/optimización de costes en la nube

Los profesionales de FinOps y optimización de costes en la nube combinan conocimientos de finanzas, tecnología y negocios para ayudar a supervisar el panorama cada vez más complejo de las inversiones en la nube. La computación en la nube es parte integral de la IA, por lo que, a medida que más organizaciones invierten en ella, también están revisando sus inversiones en infraestructura en la nube. Los profesionales de FinOps y optimización de costes en la nube pueden ayudar a las organizaciones a tomar las decisiones financieras adecuadas en torno a las inversiones en tecnología que afectarán al negocio.

Habilidades: conocimientos de finanzas, negocios y tecnología, junto con habilidades en el uso de herramientas y plataformas como AWS, Azure, GCP y plataformas FinOps nativas de la nube.

Crecimiento del puesto: el 16% de las empresas ha incorporado puestos de profesional de FinOps y optimización de costes en la nube como parte de sus inversiones en la nube.

Responsable de FinOps/gerente de FinOps

Los responsables y gerentes de FinOps se encargan de supervisar la intersección entre la ingeniería, las finanzas y los negocios. A medida que más organizaciones crean servicios y herramientas en la nube, buscan profesionales de FinOps con conocimientos técnicos que les ayuden a salvar la brecha entre las finanzas y la tecnología, que aporten mejores ideas sobre cómo reducir costes y ajustarse al presupuesto, al tiempo que se implementan tecnologías innovadoras.

Habilidades: sólidos conocimientos de ingeniería, finanzas y tecnología. Otras habilidades adicionales incluyen conocimientos de plataformas en la nube, habilidades básicas de codificación y análisis de datos.

Crecimiento del puesto: el 15% de las empresas ha incorporado puestos de responsable de FinOps y director de FinOps como parte de sus inversiones en la nube.

Ingeniero de fiabilidad del sitio (SRE)

Cualquier organización que implemente estrategias en la nube presta especial atención a la fiabilidad y la escalabilidad, con lo que se garantizan el acceso a los datos desde la nube y bajo demanda, según sea necesario. Los ingenieros de fiabilidad del sitio son responsables de supervisar la automatización de la infraestructura de TI, la supervisión de aplicaciones y la gestión de sistemas. La infraestructura en la nube requiere actualizaciones frecuentes de software, y los servicios deben poder escalarse con el crecimiento de la organización.

Habilidades: gestión del cambio, gestión de la infraestructura de TI, respuesta a incidentes de emergencia, mejora de procesos y supervisión de aplicaciones.

Crecimiento del puesto: el 10% de las empresas ha añadido puestos de ingeniero de fiabilidad del sitio como parte de sus inversiones en la nube.

관리형 클라우드 서비스 제공업체(Managed Cloud Services Provider, MCSP)는 기업이 클라우드 환경의 일부 또는 전반을 운영하는 데 도움을 주는 역할을 한다. 여기에는 시스템의 클라우드 이전, 모니터링과 유지 관리, 성능 개선, 보안 도구 운영, 비용 통제 지원 등이 포함된다. MCSP는 일반적으로 퍼블릭, 프라이빗, 하이브리드 클라우드 환경 전반에서 서비스를 제공한다.

기업은 클라우드 환경 가운데 어떤 영역을 제공업체에 맡기고, 어떤 부분을 내부에서 직접 운영할지를 결정한다. 대부분의 경우 기업과 MCSP는 책임을 공유하는 구조다. 제공업체는 일상적인 운영과 도구 관리를 담당하고, 기업은 비즈니스 의사결정과 데이터, 거버넌스에 대한 책임을 유지한다.

사이버보안 컨설팅 기업 사이엑셀(CyXcel)의 북미 디지털 포렌식 및 사고 대응 부문 MCSP 부사장인 브렌트 라일리는 MCSP를 선택하는 과정이 언제나 부담스럽다고 설명했다.

라일리는 “서비스 수준 계약(SLA)에 명시된 수준으로 서비스를 수행할 것이라는 신뢰에 크게 의존하지만, 실제로 이를 충족하고 있는지는 장애나 사이버 보안 사고가 발생해 문제가 드러나기 전까지 검증하기 어렵다”라며 “그 시점에는 이미 피해가 발생한 뒤인 경우가 많다”라고 전했다. 그는 또 “MCSP는 점검할 수 있는 물리적 인프라가 없고, 온프레미스 환경처럼 눈에 보이는 작업도 없어 평가와 선택이 더욱 까다롭다”라고 언급했다.

MCSP의 장점

운영 부담 감소: MCSP는 일상적인 클라우드 관리 업무를 대신 수행해 내부에 대규모 클라우드·인프라 조직을 유지해야 하는 부담을 줄여준다. 특히 내부에 클라우드나 핀옵스(FinOps) 전문성이 충분하지 않은 조직에 효과적이다.

신속한 문제 대응 : 대부분의 MCSP는 24시간 모니터링과 지원 체계를 제공한다. 문제가 발생하면 사용자나 애플리케이션에 큰 영향을 미치기 전에 빠르게 대응할 수 있다.

재해 복구와 복원력 지원 : MCSP는 백업과 재해 복구 환경의 설계, 운영, 테스트를 지원한다. 복구 목표는 고객이 정의하지만, 문제가 발생했을 때 시스템을 신속하게 복구할 수 있도록 돕는 역할을 맡는다.

지속적인 플랫폼 관리 : 클라우드 플랫폼은 변화 속도가 빠르다. MCSP는 인프라 구성 요소를 최신 상태로 유지하고 호환성을 관리해, 오래된 설정으로 인한 위험을 줄이는 동시에 주요 변경 시점에 대한 통제권은 고객이 유지할 수 있도록 한다.

보안 전문성과 도구 제공 : 클라우드 보안에는 수요가 높은 전문 역량이 요구된다. MCSP는 아이덴티티 관리, 모니터링, 규정 준수 도구, 보안 모범 사례에 대한 경험을 바탕으로 일상적인 보안 수준 강화를 지원한다. 보안 책임은 여전히 기업과 제공업체가 공유한다.

신뢰성과 성능 향상 : 대규모이면서 복잡한 환경을 운영해 온 경험을 바탕으로, 보다 안정적이고 확장 가능하며 복원력 있는 클라우드 인프라의 설계와 운영을 지원한다.

기존 시스템과의 통합 : MCSP는 클라우드 자원을 온프레미스 시스템, 애플리케이션, 아이덴티티 플랫폼과 연계해 사용자와 애플리케이션이 중단 없이 클라우드 서비스를 이용할 수 있도록 한다.

비용 절감보다는 예측 가능한 운영 : MCSP를 활용하면 내부 인력과 도구 비용을 줄일 수 있지만, 전체 클라우드 지출이 항상 감소하는 것은 아니다. 현재 MCSP의 가치는 저렴한 클라우드 요금보다는 운영 효율성, 전문성, 대응 속도에 더 있다.

MCSP 선택 시 핵심 고려 사항

IT 관리 소프트웨어 제공업체 커넥트와이즈(ConnectWise)의 최고경영자 매니 리벨로는 조직이 점점 더 자율적이고 AI 기반 서비스로 전환하는 과정에서, MCSP가 자동화를 실제 일상 운영에서 제대로 작동하도록 만드는 중요한 역할을 한다고 설명했다.

리벨로는 많은 조직이 예상보다 중요하게 인식하지 못하는 요소로 운영 투명성을 꼽았다. 그는 클라우드 환경이 어떻게 설계되고, 보안이 적용되며, 운영되고 있는지에 대한 명확한 가시성이 필요하다고 설명했다. 아울러 에이전틱 AI가 시스템을 어떻게 모니터링하고 의사결정을 내리며 실제 조치를 취하는지까지 조직이 이해하고 있어야, 인지하지 못한 상태에서 중요한 일이 진행되는 상황을 막을 수 있다고 언급했다.

리벨로는 “자율성이 높아질수록 운영 성숙도의 중요성도 커진다”라며 “여기에는 체계적인 데이터 거버넌스, 강력한 물리적·논리적 보안, 자동화와 인간 감독의 균형을 고려한 명확한 사고 대응 프로세스가 포함된다”라고 설명했다. 그는 “에이전틱 AI는 문제를 탐지하고 신호를 연관 분석하며 기계 속도로 대응할 수 있지만, 정책 설정과 결과 검증, 예상 범위를 벗어난 상황에서의 판단은 여전히 사람이 담당해야 한다”라고 말했다.

리벨로는 MCSP가 관리형 서비스 모델과 그 주변 생태계에 얼마나 잘 부합하는지도 중요하다고 강조했다. 적합한 제공업체는 자동화와 AI를 활용해 운영을 단순화해야 하며, 자동화가 제대로 작동할 경우 현업 인력을 뒷받침하고 운영의 일관성을 높이며, 팀이 또 다른 도구를 관리하는 데 시간을 쓰는 대신 실제로 중요한 업무에 집중할 수 있도록 돕는다고 설명했다.

소프트웨어 라이선스 활용 가치를 높이고 MS, 오라클, 시스코 등 벤더 감사 대응을 지원하는 NPI의 최고경영자 존 윈셋은 가격 구조의 유연성이 MCSP 선택 과정에서 종종 간과된다고 지적했다. 그는 MCSP와 관련된 위험이 초기 비용 증가보다는, 시간이 지나면서 인지하지 못한 채 협상력이 약화되는 데 있다고 분석했다.

윈셋은 소규모 팀이나 아직 클라우드 경험을 구축하는 단계에 있는 조직에는 MCSP가 큰 도움이 될 수 있다고 덧붙였다. 클라우드 지출을 통합하고 마이그레이션 지원, 리소스 최적화, 비용 통제와 같은 서비스를 패키지로 제공함으로써 낭비를 줄이고 클라우드 운영을 보다 수월하게 만들 수 있다는 설명이다. 내부에 클라우드나 핀옵스 역량이 충분하지 않은 조직이라면 이러한 이점이 일정 부분의 trade-off를 감수할 만한 가치가 있다고 전했다.

그는 “클라우드 환경이 확장될수록 가격 구조는 점점 불투명해진다”라며 “MCSP는 MS나 아마존웹서비스(AWS) 요금 위에 자체 마진을 더하는데, 기본 사용료 기준 최대 8% 수준이며 서비스가 묶일 경우 그 이상이 될 수 있다”라고 설명했다. 이어 “이 같은 관리 계층을 통해 MCSP는 약 30~40% 수준의 수익률을 확보한다”라고 언급했다.

MCSP의 단점

기술 컨설팅 기업 하이라인의 기술 부사장 라이언 맥엘로이는 MCSP를 활용할 때 가장 큰 단점으로 통제력 상실을 꼽았다.

맥엘로이는 “각종 라이선스 할인 혜택을 받더라도 계약에 묶여 필요 이상으로 구매해야 하는 구조라면 실제로는 비용을 절감하지 못할 수 있다”라며 “MCSP를 활용하면 조직의 공격 표면이 확대될 수 있다는 점도 고려해야 한다”라고 설명했다. 그는 또 “MS와 같은 대형 클라우드 벤더가 MCSP를 교육하고 가이드를 제공하더라도, 대규모 사이버 보안 사고 이후 작성되는 근본 원인 분석 보고서를 살펴보면 MCSP가 공격 경로로 작용한 사례가 우려스러울 정도로 자주 등장한다”라고 전했다.

리서치 기업 ISG의 디렉터 아네이 나와테는 MCSP 협업이 많은 이점을 제공하는 동시에 분명한 위험도 동반한다고 언급했다.

나와테는 “MCSP가 조직 내 아키텍처 논의의 중심적인 목소리가 되어서는 안 된다”라며 “핵심 시스템에 대한 지식을 내부에 유지하고, 벤더 종속을 줄이며, 시장 모범 사례와 비교했을 때 제공업체로 인한 아키텍처 편향을 완화하기 위해서는 아키텍처 의사결정을 내부에서 소유해야 한다”라고 설명했다.

그는 또 MCSP가 클라우드 비용 관리에 대해 실제로 클라우드를 사용하는 기업만큼의 압박을 느끼지 않는 경우가 많다고 덧붙였다. 결국 과도한 지출의 영향은 기업이 직접 감내하게 되며, 이러한 이유로 많은 기업이 클라우드 비용에 대한 통제력을 확보하기 위해 핀옵스 역할을 다시 내부로 가져온다고 설명했다.

글로벌 시장에서 주목받는 MCSP 6곳

관리형 클라우드 서비스 제공업체는 수십 곳에 이른다. 조사 부담을 줄이기 위해 독립적인 리서치와 애널리스트와의 논의를 바탕으로, 알파벳순으로 주요 MCSP 6곳을 정리했다. 가격 정보는 각 제공업체에 직접 문의해야 한다.

액센추어

액센추어(Accenture)는 전 세계 주요 지역과 시장에 분포한 팀과 센터를 기반으로 관리형 클라우드 서비스를 제공한다. 기업의 클라우드 환경 설계, 운영, 유지 관리를 지원하며, 초기 클라우드 구축부터 모니터링, 유지 보수, 보안을 포함한 지속적인 운영까지 폭넓게 다룬다. MS 애저, 구글 클라우드, AWS 등 주요 클라우드 플랫폼 전반에서 서비스를 제공하는 것도 특징이다. 기업은 복잡한 클라우드 시스템을 전부 내부에서 관리하는 대신, 액센추어를 통해 일상적인 운영과 기술적 관리 업무를 맡길 수 있다. 시스템 모니터링과 이슈 대응, 환경 업데이트 등 일상적인 인프라 운영을 액센추어가 담당함으로써, 내부 인력은 핵심 비즈니스 과제에 집중할 수 있다.

캡제미니

캡제미니(Capgemini)는 전 세계를 대상으로 관리형 클라우드 서비스를 제공하며, 특히 유럽과 북미를 중심으로 멀티클라우드 환경을 지원한다. 제조, 리테일, 금융 서비스, 보험 산업과의 협업 경험이 풍부하다. AWS, MS 애저, 구글 클라우드 등 주요 클라우드 플랫폼과 일부 특화된 엔터프라이즈 클라우드를 기반으로 애플리케이션과 인프라 운영을 지원한다. 모니터링, 백업, 기술 지원을 포함한 관리형 서비스와 함께, 클라우드 이전이 적합한 워크로드를 식별하고 해당 시스템을 이전·운영하는 과정까지 포괄적으로 지원한다. 중견기업보다는 대규모이면서 복잡한 환경을 가진 대기업에 적합한 서비스 성격을 갖고 있다.

딜로이트

딜로이트(Deloitte)는 전 세계 고객을 대상으로 클라우드 서비스를 제공하며, 북미와 유럽 지역의 비중이 크다. 금융·보험, 공공, 헬스케어 산업에서 특히 강점을 보인다. AWS, MS 애저, 구글 클라우드, VM웨어 클라우드, 오라클 클라우드를 포함한 멀티클라우드 환경을 지원한다. 기업의 비즈니스 목표에 맞춰 클라우드 환경을 기획·구축·운영하는 데 초점을 맞추고 있으며, 프로세스와 운영 개선을 포함한 클라우드 전환이 핵심 영역이다. 컨설팅이 주력 사업이지만, 디지털 전환을 추진하는 대기업을 중심으로 관리형 서비스 영역도 지속적으로 확대하고 있다.

HCL테크놀로지스

HCL테크놀로지스(HCL Technologies)는 전 세계에 분포한 팀과 센터를 통해 관리형 클라우드 서비스를 제공한다. AWS, MS 애저, 구글 클라우드 등 주요 클라우드 제공업체와 협력해 각 기업의 요구에 맞는 클라우드 환경을 설계·구축하고, 이후 안정적인 운영을 지원한다. 구축 이후에는 24시간 모니터링, 성능 관리, 장애 대응 등 일상적인 운영을 담당하며, 반복적인 IT 작업에는 자동화와 AI 도구를 활용한다. 금융, 제조, 헬스케어 등 다양한 산업에서 안정적인 클라우드 시스템 운영을 지원하는 것이 특징이다.

NTT데이터

NTT데이터(NTT Data)는 전 세계 고객을 대상으로 관리형 클라우드 서비스를 제공하며, 제조, 헬스케어, 금융 서비스, 보험 등 폭넓은 산업을 지원한다. MS 애저, 구글 클라우드, IBM 클라우드, AWS를 기반으로 한 멀티클라우드 전략을 채택하고 있다. 애플리케이션의 클라우드 이전, 노후 시스템 현대화, 레거시 기술 전환을 지원하는 한편, NTT 그룹 전반의 역량을 활용해 아이덴티티 및 접근 관리, 네트워킹, 관리형 보안 서비스도 함께 제공한다. 이를 통해 고객이 비즈니스를 보다 효과적으로 지원하는 클라우드 기반 시스템을 구축하도록 돕는다.

타타컨설턴시서비스

타타컨설턴시서비스(Tata Consultancy Services, TCS)는 전 세계 기업과 협력하고 있지만, 관리형 클라우드 서비스 고객은 주로 북미와 유럽에 집중돼 있다. 금융 서비스, 생명과학·제약, 리테일 산업에서 강한 경험을 보유하고 있다. MS 애저, 구글 클라우드, 오라클 클라우드, AWS를 중심으로 멀티클라우드 환경을 지원하며, 일부 IBM 클라우드도 제공한다. 주요 클라우드 파트너별 전담 팀을 운영하며, 대기업을 대상으로 클라우드 이전 전략 수립, 기존 시스템 이전, 애플리케이션 현대화를 지원한다. 서비스의 중심은 대기업에 맞춰져 있으며, 중견기업 대상 비중은 상대적으로 제한적이다.
dl-ciokorea@foundryco.com

Tech industry sentiment suggests that AI agents will automate entire business processes, potentially transforming companies worldwide.

Today’s reality is starkly different.

Fifty-eight percent of enterprise IT decision-makers say their organizations are piloting AI agents, with the majority targeting process automation, workflow efficiencies, or customer service, among other use cases, according to AI adoption research published by Wharton and the GBK Collective.

Again, these are pilots — not production implementations. There isn’t yet a playbook for fully baked human-AI agent workflows.

Still, as IT departments wrestle with the best path forward for using AI to automate operations, close partnership with human resources departments will be essential to minimize disruption and ensure the organization is primed to capitalize on the new roles, processes, and team structures that will arise as true human-AI coworking arrives.

Bringing AI agents into the fold

Tight interaction between IT and HR is crucial for the change management required for responsible AI deployment, says Sophos CIO Tony Young, who is spearheading the deployment of AI at the MDR vendor, including Microsoft Copilot. “The right approach is engaging with your HR pros and understanding how we bring the workforce along,” Young says.

For example, Young envisions more companies will employ automation experts, along with those who understand how to curate content and work with data to smooth the transition to agentic AI. HR can help blend the budding array of specialists.

Moreover, a little anthropomorphization can go a long way toward easing the transition to digital colleagues, Young adds.

The marketing organization at Sophos now includes AI agents in org charts as part of its teams, working alongside humans. New agents get new team member announcements — just like humans, says Young.

And Sophos’ IT service desk function now features a leaderboard that allows humans to see how they stack up against their digital coworkers. Human staffers monitor the AI agents to validate their work, consistent with human-in-the-loop best practices.

“Understanding how to use an LLM, or how to create an agent is like mastering Excel,” Young says. “That’s a new baseline skill that we all need to have.”

To get there, CIOs need to partner with HR leaders to help set the workforce AI training agenda, which could include emerging gen AI certifications as well as coursework for driving AI change.

What the agent-infused organization of the future will look like

What will fully agentic businesses look like in the future? Picture hundreds or thousands of autonomous “bots” working together to facilitate the execution of business processes end-to-end. These worker bots will likely be managed by a “boss” bot that ensures they stay on task.

If this sounds familiar it’s because it’s a symmetrical analogy for how humans have long performed knowledge work.

Yet organizations require a new operating model for working with agents. It will be incumbent on IT departments to stage and manage agent decision trees and the resulting workflows. These workflows will vary by function.

For instance, organizations that choose to automate call center operations with AI will need to train humans to monitor agents — a managerial and technical skill that goes beyond most call center associates’ current toolboxes.

“It requires a new skillset, including understanding the intent of calls and setting boundaries,” says Klemens Hjartar, senior partner at McKinsey. This requires new process management muscles for organizations accustomed to working a certain, human-centric way.

The introduction of AI agents to sales and marketing processes presents different challenges involving various workflows for CRM and other systems of engagement. The same can be said for operations teams and other functions likely to be impacted by agentic AI.

Whatever the workflow, HR can help soften the impact on teams through clear, consistent communication, as well as messaging around how IT and other departments can reskill their teams for the new era.

Microsoft predicted that IT and HR teams will forge new roles such as chief resource officers to help balance human and digital workers, while some organizations may install “agent bosses.” McKinsey envisions new roles for AI ethics and responsible usage, AI quality assurance leads, and agent coaches.

The hurdles are huge but not insurmountable

In short, wholesale changes to organizational dynamics are on the horizon, with IT and HR serving on the front lines of these transformations — mostly in tandem.

While these changes are a ways away, most organizations aren’t ready for it — but need to keep this future in mind as they plan their way forward.

One challenge is the fact that allocating too much decision-making authority to agentic AI architectures poses significant risks, due to technical challenges across disparate platforms and implicit knowledge gaps, says Amit Kinha, field CTO of FinOps platform provider DoiT.

For example, if you give a junior programmer some tasks to accomplish, they can turn to more experienced engineers when they need help. Today there isn’t a mechanism for AI agents to access the same tribal knowledge, Kinha says.

“Where is the source of truth coming from?” Kinha wonders. “Because if it’s not valid the whole decision tree will be invalid as well.” 

The ramifications of agentic actions loom large. A multi-agent system with the power to update across 15 systems could have significant impacts downstream that materially impact the bottom line, Kinha says.

One approach may include instituting checkpoints as part of organizational governance strategies. For instance, while some AI agents may be authorized to make individual decisions, others may have to seek approval from a human.

“The hardest part to master is decision autonomy,” Kinha says. Agents with too little autonomy will regularly check with humans, stunting automation. Those with too much will make mistakes that could be catastrophic. In addition to being explicit with goals and intents, organizations must make sure their data hygiene is sound, Kinha says.

The future looks bright(ish) — but unpredictable

When the technical and process challenges are reconciled, HR and IT partnership will be essential in assisting the transition from humans to human-plus-machine work. Every company introducing AI agents to their organizations must become more intentional about how they execute their business processes and measure outcomes.

“All of us in different functional domains need to up our game in intent-setting, boundary-setting, and measurement,” Hjartar says. “That’s going to take many years for us.”

Young says that every company will proceed at their own pace, which will create new categories of haves and have nots — just like preceding paradigm shifts involving emerging technology. “Some will push hard to automate; others won’t.”

What’s clear is that the challenges of human-machine commingling in the workplace are just beginning.

In my work helping large enterprises deploy AI, I keep seeing the same story play out. A brilliant data science team builds a breakthrough model. The business gets excited but then the project hits a wall; a wall built of fear and confusion that lives at the intersection of cost and risk. Leadership asks two questions that nobody seems equipped to answer at once: “How much will this cost to run safely?” and “How much risk are we taking on?”

The problem is that the people responsible for cost and the people responsible for risk operate in different worlds. The FinOps team, reporting to the CFO, is obsessed with optimizing the cloud bill. The governance, risk and compliance (GRC) team, answering to the chief risk officer, is focused on legal exposure. And the AI and MLOps teams, driven by innovation under the CTO, are caught in the middle.

This organizational structure leads to projects that are either too expensive to run or too risky to deploy. The solution is not better FinOps or stricter governance in isolation; it is the practice of managing AI cost and governance risk as a single, measurable system rather than as competing concerns owned by different departments. I call this “responsible AI FinOps.”

To understand why this system is necessary, we first have to unmask the hidden costs that governance imposes long before a model ever sees a customer.

 Phase 1: The pre-deployment costs of governance

The first hidden costs appear during development, in what I call the development rework cost. In regulated industries, a model needs to not only be accurate, it must be proven to be fair. It is a common scenario: a model clears every technical accuracy benchmark, only to be flagged for noncompliance during the final bias review.

As I detailed in a recent VentureBeat article, this rework is a primary driver of the velocity gap that stalls AI strategies. This forces the team back to square one, leading to weeks or months of rework, resampling data, re-engineering features and retraining the model; all of which burns expensive developer time and delays time-to-market.

Even when a model works perfectly, regulated industries demand a mountain of paperwork. Teams must create detailed records explaining exactly how the model makes decisions and where its data comes from. You won’t see this expense on a cloud invoice, but it is a major part measured in the salary hours of your most senior experts.

These aren’t just technical problems, they’re a financial drain caused by an AI governance standard process failure.

Phase 2: The recurring operational costs in production

Once a model is deployed, the governance costs become a permanent part of the operational budget.

The explainability overhead

For high-risk decisions, governance mandates that every prediction be explainable. While the libraries used to achieve this (like the popular SHAP and LIME) are open source, they are not free to run. They are computationally intensive. In practice, this means running a second, heavy algorithm alongside your main model for every single transaction. This can easily double the compute resources and latency, creating a significant and recurring governance overhead on every prediction.

The continuous monitoring burden

Standard MLOps involves monitoring for performance drift (e.g., is the model getting less accurate?). But AI governance adds a second, more complex layer: governance monitoring. This means constantly checking for bias drift (e.g., is the model becoming unfair to a specific group over time?) and explainability drift. This requires a separate, always-on infrastructure that ingests production data, runs statistical tests and stores results, adding a continuous and independent cost stream to the project.

The audit and storage bill

To be auditable, you must log everything. In finance, regulations from bodies like FINRA require member firms to adhere to SEC rules for electronic recordkeeping, which can mandate retention for at least six years in a non-erasable format. This means every prediction, input and model version creates a data artifact that incurs a storage cost, a cost that grows every single day for years.

Regulated vs. non-regulated difference: Why a social media app and a bank can’t use the same AI playbook

Not all AI is created equal and the failure to distinguish between use cases is a primary source of budget and risk misalignment. The so-called governance taxes I described above are not universally applied because the stakes are vastly different.

Consider a non-regulated use case, like a video recommendation engine on a social media app. If the model recommends a video I don’t like, the consequence is trivial; I simply scroll past it. The cost of a bad prediction is nearly zero. The MLOps team can prioritize speed and engagement metrics, with a relatively light touch on governance.

Now consider a regulated use case I frequently encounter: an AI model used for mortgage underwriting at a bank. A biased model that unfairly denies loans to a protected class doesn’t just create a bad customer experience, it can trigger federal investigations, multimillion-dollar fines under fair lending laws and a PR catastrophe. In this world, explainability, bias monitoring and auditability are not optional; they are non-negotiable costs of doing business. This fundamental difference is why a single version of AI platform dictated solely by the MLOps, FinOps or GRC team is doomed to fail.

Responsible AI FinOps: A practical playbook for unifying cost and risk

Bridging the gap between the CFO, CRO and CTO requires a new operating model built on shared language and accountability.

1. Create a unified language with new metrics. FinOps tracks business metrics like cost per user and technical metrics like cost per inference or cost per API call. Governance tracks risk exposure. A responsible AI FinOps approach fuses these by creating metrics like cost per compliant decision. In my own research, I’ve focused on metrics that quantify not just the cost of retraining a model, but the cost-benefit of that retraining relative to the compliance lift it provides.
2. Build a cross-functional tiger team. Instead of siloed departments, leading organizations are creating empowered pods that include members from FinOps, GRC and MLOps. This team is jointly responsible for the entire lifecycle of a high-risk AI product; its success is measured on the overall risk-adjusted profitability of the system. This team should not only define cross-functional AI cost governance metrics, but also standards that every engineer, scientist and operations team has to follow for every AI model across the organization.
3. Invest in a unified platform. The market is responding to this need. The explosive growth of the MLOps market, which Fortune Business Insights projects will reach nearly $20 billion by 2032, is proof that the market is responding to this need for a unified one-enterprise-level control plane for AI. The right platform provides a single dashboard where the CTO sees model performance, the CFO sees its associated cloud spend and the CRO sees its real-time compliance status.

The organizational challenge

The greatest barrier to realizing the value of AI is no longer purely technical, it is organizational. The companies that win will be those who break down the walls between their finance, risk and technology teams.

They will recognize that A) You cannot optimize cost without understanding risk; B) You cannot manage risk without quantifying its cost; and C) You can achieve neither without a deep engineering understanding of how the model actually works. By embracing a fused responsible AI FinOps discipline, leaders can finally stop the alarms from ringing in separate buildings and start conducting a symphony of innovation that is both profitable and responsible.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Una nueva encuesta del proveedor de FinOps Cloud Capital realizada a 100 directores financieros de compañías SaaS y otras empresas tecnológicas con hasta 1.000 empleados ha determinado que las medianas empresas de TI destinan ya una parte muy significativa de sus ingresos a servicios en la nube, impulsadas en gran medida por el creciente volumen de cargas de trabajo de inteligencia artificial (IA) que se ejecutan en estos entornos.

En concreto, un tercio afirma gastar entre el 5% y el 8% de sus ingresos anuales en servicios cloud, mientras que otro 29% supera el 13%. De media, las organizaciones consultadas destinan el 10% de sus ingresos a la nube.

Las cargas de trabajo de IA y aprendizaje automático representan ya el 22% del gasto total en la nube de estas organizaciones, según el estudio. Como resultado, los costes de la nube se han convertido en el segundo mayor gasto para muchas empresas de TI y SaaS, solo por detrás de las nóminas y otros costes relacionados con el personal.

La compensación de la IA

Por el momento, tanto las empresas de TI como los proveedores de SaaS asumen estos elevados costes de la nube con la expectativa de que la IA aporte mejoras futuras en eficiencia y productividad, según defiende Spencer Pingry, cofundador y CTO de Cloud Capital.

A su juicio, “estamos viendo cómo aumenta el gasto en la nube, especialmente con las cargas de trabajo de IA, y mucha gente está absorbiendo ese incremento por ahora, porque cree que obtendrá determinados beneficios. Pero una vez que esos beneficios se materialicen, no creo que el gasto en la nube disminuya; al contrario, probablemente aumentará”.

La gran incógnita para los CIO clientes de estos proveedores es cuándo empezarán las empresas de TI y SaaS a trasladarles esos costes.

Para Pingry, “a medida que crece el gasto en la nube, las subidas de precios son una herramienta habitual para proteger los márgenes. Sin embargo, en un mercado con una competencia feroz por captar y retener clientes, subir precios puede resultar contraproducente, ya que incrementa la rotación y facilita que los competidores se lleven a los clientes que deciden cambiar de proveedor”.

La encuesta de Cloud Capital pone de manifiesto que los CFO de empresas tecnológicas medianas, junto con sus CIO, tienen dificultades para controlar el gasto en la nube, que presenta una elevada volatilidad mes a mes. Tres de cada cuatro directores financieros indican que sus previsiones de gasto en la nube oscilan entre el 5% y el 10% de los ingresos mensuales de la empresa.

Pingry añade que los costes asociados a las cargas de trabajo de IA son mucho más difíciles de predecir que los de la infraestructura SaaS tradicional. Además, las organizaciones con grandes volúmenes de cargas de trabajo de IA son más propensas a registrar caídas en los márgenes vinculadas al gasto en la nube que aquellas con una exposición más moderada a la IA.

El informe de Cloud Capital señala que “los picos de entrenamiento, la inferencia basada en el uso y el ruido derivado de la experimentación introducen patrones no lineales que rompen los supuestos de previsión sobre los que se apoya la financiación. Este reto se intensificará a medida que la IA represente una parte cada vez mayor del gasto en la nube”.

Un aumento muy significativo

Aunque Cloud Capital no dispone aún de datos históricos sobre el gasto en la nube como porcentaje de los ingresos —la compañía prevé empezar a hacer este seguimiento en el futuro—, los resultados de la encuesta reflejan un aumento muy notable respecto a las tendencias tradicionales.

En 2024, Gartner estimó que el presupuesto total de TI de las empresas medianas de distintos sectores representaba apenas el 3% de los ingresos, mientras que las compañías de software y servicios de Internet destinaban algo más del 6% de sus ingresos a TI.

En opinión de Ed Frederici, CTO de Appfire, que la media de la encuesta sitúe el gasto en servicios cloud en el 10% de los ingresos puede parecer elevado, pero no hay duda de que el gasto en la nube está creciendo. Este proveedor de software destina actualmente alrededor del 1,6% de sus ingresos a computación en la nube.

Aun así, Frederici reconoce que los costes de computación y almacenamiento en la nube están aumentando. “Con un modelo de precios basado en el consumo, se puede pasar fácilmente de gastar unos pocos euros al día a 1.000 euros. Por eso somos extremadamente rigurosos a la hora de monitorizarlo”, explica.

Aunque Appfire no ejecuta muchas cargas de trabajo en la nube con un uso intensivo de IA, Frederici observa cómo los costes pueden dispararse rápidamente a medida que las necesidades de computación y almacenamiento de la IA se retroalimentan.

“Cuanto más conocimiento se quiere obtener de la IA, más almacenamiento se necesita”, afirma, para añadir: “Es una especie de círculo vicioso: cuanto más capaz se vuelve la IA, más aumentan los dos costes más caros”.

Demasiada flexibilidad

Otros responsables de TI consideran que los resultados de la encuesta reflejan de manera bastante realista lo que ocurre en muchas organizaciones. En su opinión, los desarrolladores suelen tener demasiado margen para crear nuevos recursos en la nube destinados a proyectos de corta duración, explica Rick Clark, director global de asesoramiento en la nube del proveedor de transformación digital UST.

A su juicio, “el gasto en la nube alcanza el 10% de los ingresos cuando el consumo se desvincula del valor empresarial y cuando confundimos flexibilidad para los desarrolladores con productividad. En la era de los centros de datos tradicionales, nadie habría permitido a los desarrolladores montar y desplegar hardware. Sin embargo, en la era de la nube les hemos dado opciones de infraestructura casi ilimitadas, sin una orientación económica clara”.

Los servicios en la nube no son intrínsecamente demasiado caros, añade Clark, pero muchas organizaciones se perjudican a sí mismas con un consumo involuntario. “Los costes se disparan cuando el sistema se diseña sin una comprensión clara del valor que se pretende generar”, según destaca este especialista.

Además, el temor a quedarse atrás en materia de IA está impulsando un crecimiento descontrolado del gasto en la nube. Para Clark, “ningún CEO quiere tener que explicar al consejo por qué otra empresa ha utilizado la IA para adelantarles. Esto ha provocado un gasto desenfrenado en entrenamiento, inferencia y movimiento de datos, a menudo superpuesto a arquitecturas que ya eran económicamente incoherentes”.

El papel del CIO y del CFO

Según los expertos, los responsables de TI, en estrecha colaboración con los directores financieros, pueden adoptar diversas medidas para contener el gasto en la nube. Aunque muchos equipos de TI recurren a prácticas de FinOps, Clark advierte de que estas sólo abordan una parte del problema.

“FinOps es útil para detectar despilfarros evidentes, como recursos infrautilizados, pero no deja de ser un parche temporal. El problema más profundo es que FinOps suele trasladar la responsabilidad del coste a los desarrolladores, que no tienen visibilidad sobre los ingresos, los márgenes o los objetivos económicos de la carga de trabajo que están creando. El coste es una decisión empresarial, no una decisión técnica”, prosigue el especialista.

Pingry coincide en que los CIO deben trabajar estrechamente con los CFO para definir objetivos de gasto en la nube alineados tanto con las necesidades del área de TI como con los objetivos del negocio. Dado que los presupuestos cloud consumen una parte cada vez mayor de los ingresos, los directores financieros necesitan visibilidad y control, y una relación sólida entre CIO y CFO puede mejorar la comprensión mutua de las prioridades de cada área.

“El consejo que daría a cualquier responsable de TI es que invierta en la relación con el departamento financiero. A menudo se percibe a Finanzas como un freno, porque su función es recortar gastos, pero en realidad lo único que quiere es que las cosas se ajusten al plan. Si se cumple ese plan, Finanzas estará satisfecha”, afirma Pingry.

Por su parte, Frederici recomienda que los responsables de TI revisen periódicamente el uso que hacen sus equipos de la nube y sean especialmente diligentes a la hora de eliminar recursos que ya no sean necesarios. También sugiere configurar alertas que avisen cuando el consumo o el gasto en la nube se desvíen de los patrones habituales.

En Appfire, la optimización es una prioridad constante y la empresa cierra de forma regular recursos que han dejado de ser necesarios.

“Es muy habitual que los desarrolladores y los equipos de control de calidad tengan capacidad para crear cualquier entorno de no producción que necesiten. «Lo crean para un experimento, luego se olvidan de él y generan otro para el siguiente. De repente, te encuentras con un crecimiento descontrolado”, concluye Frederici.

Midsize IT companies now spend huge percentages of their revenues on cloud services, driven by a growing number of AI workloads running in the cloud, according to a new survey.

While a third of IT companies say they spend between 5% and 8% of annual revenues on cloud services, another 29% spend over 13%, according to a survey of 100 CFOs at SaaS and other IT companies with up to 1,000 employees. On average, the companies represented spend 10% of revenues on the cloud.

AI and machine learning workloads make up 22% of the cloud costs at the organizations represented, according to the survey, commissioned by FinOps vendor Cloud Capital. Cloud costs are now the second largest expense at many IT and SaaS companies, trailing only payroll and other employee-related spending.

The AI tradeoff

For now, IT companies and SaaS providers are swallowing these cloud costs in anticipation of projected efficiency or productivity increases coming from AI, says Spencer Pingry, cofounder and CTO at Cloud Capital.

“With the AI workloads in particular, as we see the cloud spend go up, a lot of people are dealing with the increase for now, because they think there’s a certain set of payoffs that will be realized,” he says. “But once we realize those payoffs, I don’t think cloud spending is going to cut back; it’s going to increase instead.”

The question for their CIO customers then becomes, at what point do these IT and SaaS vendors begin passing on these costs to them?

“As cloud spend rises, price increases are one common lever to protect margins,” Pingry says. “But in a market where competition to land and retain customers is intense, raising prices can backfire by increasing churn and making it easier for competitors to win switchers.”

The Cloud Capital survey shows midsize IT vendor CFOs and their CIO partners struggling to contain cloud spending, with significant cost volatility from month to month. Three-quarters of IT org CFOs report cloud spending forecasts varying between 5% and 10% of company revenues each month, Pingry notes.

Costs of AI workloads are harder to predict than traditional SaaS infrastructure, Pingry adds, and organizations running major AI workloads are more likely to report margin declines tied to cloud spending than those with moderate AI exposure.

“Training spikes, usage-driven inference, and experimentation noise introduce non-linear patterns that break the forecasting assumptions finance relies on,” says a report from Cloud Capital. “The challenge will intensify as AI’s share of cloud spend continues scaling.”

A huge increase

While Cloud Capital doesn’t have historical data on cloud spending as a percentage of revenue — the company plans to track it going forward — the survey’s numbers represent a huge increase from historical trends.

Gartner in 2024 calculated that the entire IT budget at midsize companies across several industries took up just 3% of revenues, with software publishing and internet services firms spending just over 6% of revenue on IT.

The survey’s average of companies using 10% of revenues on cloud services seems high, but there’s little doubt that cloud spending is increasing, says Ed Frederici, CTO at Appfire. The software vendor currently spends about 1.6% of its revenues on cloud computing, he says.

Still, cloud compute and storage costs are rising, he says. “When you’re using consumption-based pricing, you can go from a few dollars a day to $1,000, so we’re very diligent about keeping an eye on it,” he says.

While Appfire doesn’t have a lot of AI-heavy cloud workloads, Frederici sees how cloud costs can ramp up quickly as AI compute and storage needs feed off each other.

“The more AI knowledge you want to have, the more storage you’re going to have,” he says. “It’s kind of this non-virtuous cycle — the more capable you make your AI, the more you drive up your two most expensive costs.”

Too much flexibility

Other IT leaders see the survey’s results as more realistic. At many organizations, developers have too much power to spin up new cloud resources for short-term projects, says Rick Clark, global head of cloud advisory at digital transformation provider UST.

“Cloud spend climbs toward 10% of revenue when consumption is disconnected from business value and when we confuse developer flexibility with productivity,” he says. “In the data center era, no one would have allowed developers to rack and install hardware, yet in the cloud era, we gave them near-infinite infrastructure choices with no economic guidance.”

Cloud services in themselves aren’t inherently too expensive, but many organizations shoot themselves in the foot through unintentional consumption, Clark adds. “Costs rise when the system is built without a clear understanding of the value it is meant to deliver,” he adds.

In addition, the fear of missing out on AI is leading to skyrocketing cloud spending, he says.

“No CxO wants to explain to the board why another company used AI to leap ahead,” Clark adds. “This has created a no-holds-barred spending spree on training, inference, and data movement, often layered on top of architectures that were already economically incoherent.”

IT leaders, working with CFOs, can take several steps to control cloud spending, experts say. While some experts point to IT teams using FinOps practices, Clark says they’re just part of the solution.

“FinOps is helpful for finding obvious waste such as unused resources, but that is a one-time Band-Aid,” he says. “The larger issue is that FinOps often pushes cost responsibility onto developers who have no insight into revenue, margin, or the economic goals of the workload they are building. Cost is a business decision, not a technical decision.”

IT leaders need to work closely with CFOs to set goals for cloud spending that match the needs of the IT team and the goals of the business, says Cloud Capital’s Pingry. CFOs need input on cloud budgets as they eat up a greater portion of revenue, and a good relationship between the CIO and CFO can lead to a better understanding of both departments’ needs, he adds.

“The advice I’d give to any IT leader is to just work on the relationship with finance, because it’s often seen as like a negative, with finance coming to look for ways to cut things, but they just want things to be on a plan, and as long as that plan is being hit, then finance is very happy,” Pingry says.

Appfire’s Frederici recommends that IT leaders regularly check their teams’ cloud use and be diligent about cutting off cloud resources that are no longer needed. IT teams can also set up alerts to tell them when cloud usage or spending is deviating from norms, he says.

Appfire focuses on cloud optimization and regularly shuts down cloud resources that are no longer needed, he says.

“Something that very common is your developers, your QA folks, have the ability to spin up any non-production environment they want,” he says. “They spin it up for an experiment, and then they forget to exist and spin up another one for the next experiment. All of a sudden, you have really extensive sprawl that’s sitting there.”

Infrastructure might be the reason so many organizations report failures when scaling AI from POC to production. Almost every company in Microsoft’s latest State of AI Infrastructure report spoke of challenges scaling and operationalizing AI, and over half of more than 1,500 business leaders from various sectors and regions said they don’t have the right infrastructure to support the AI workloads they want to run — a proportion repeated in other surveys.

Building, deploying, and operationalizing AI models is when you find out how modern your infrastructure really is and where it lets you down. “Running AI on legacy architecture is like streaming 4K video over dial-up,” says Frank Miller, chief AI and platforms officer at digital infrastructure company Colt Technology Services. “You can convince yourself it will work, but the reality is very different.”

If you don’t want to be stuck firefighting just to keep available the AI you’ve spent so much on, you need both governance and modern architecture. “This means replacing rigid legacy systems with hybrid, cloud-native designs that scale for AI workloads,” he adds. “High-bandwidth, low latency connectivity ensures fast data access; redundancy and automated failover provide continuity; and zero-trust security with encryption protects sensitive AI flows. Adding observability and predictive monitoring helps anticipate issues before they disrupt operations, creating an infrastructure that’s resilient, secure, and ready for AI innovation.” 

Think of it as technical debt, suggests IDC group VP Daniel Saroff as most enterprises underestimate the strain AI puts on connectivity and compute. Siloed infrastructure won’t deliver what AI needs and CIOs need to think about these and other things in a more integrated way to make AI successful. “You have to look at your GPU infrastructure, bandwidth, network availability, and connectivity between respective applications,” he says. “If you have environments not set up for highly transactional, GPU-intensive environments, you’re going to have a problem,” Saroff warns. “And having very fragmented infrastructure means you need to pull data and integrate multiple different systems, especially when you start to look at agentic AI.”

Training, RAG, and agent workflows assume that data isn’t only correct but always reachable and not behind a bottleneck. Common API technologies like MCP are emerging as a way to standardize access to data, and legacy systems may not support that easily, he adds.

Get good at GPUs

Resilience is hardly a new idea for enterprise IT. High availability, failover, and disaster recovery are so universally required that one of the first six agents Microsoft added to Azure Copilot is there specifically to improve resiliency in the cloud. On premises, enterprises have decades of experience with infrastructure to draw from, but that rarely includes the expensive GPUs and other accelerators that are key to AI, whether you’re training or running inferencing.

They’re also more demanding, whether that’s the added complication of needing to autoconfigure GPU Kubernetes clusters with the right drivers and operators, or building out dedicated AI infrastructure that’s harder to service, and needs high-speed networking for distributed traffic with unfamiliar and fast-changing patterns.

“Building GPU infrastructure is really hard,” says Jason Hammons, VP of international systems engineering at VAST Data. “It’s brittle in large part to its massively parallel nature, but also because of the componentry. They’re just way more complex.”

AI demands high-bandwidth networks with low and critical predictable latency to deliver large payloads of data and small payloads of inferences and API calls. That might mean at least part of your enterprise network looking more like what’s in a cloud data center, perhaps with SmartNICs, InfiniBand, or RoCE, and programmable network operating systems like SONiC, as well as stable links with direct routes to AI data centers and cloud APIs.

If you have high-speed networking internally to the GPU cluster itself, enterprises can deliver a good AI experience, Hammons says, but building agents is even more demanding in terms of storage and networking. “When you start scaling agentic workloads, because of the complex I/O patterns they exhibit, the complicated nature of keeping those systems up can be exacerbated,” he says.

Intelligent routing and underlay optimization matter more in AI, and load balancing becomes more important than ever, requiring intelligent, adaptive routing and dynamic, multipath I/O so one congested or unhealthy path doesn’t interrupt an AI pipeline. You have to give critical AI traffic high enough priority to support your workloads without getting in the way of critical production systems like ERP and payment services, or VoIP and video meetings.

“AI workflows are much more network-based,” says Artur Bergman, CTO at software developer Fastly. “You have to scale across machines and that’s quite a big shift from enterprise workloads that don’t have those levels of network or latency requirements.”

It’s no longer just about avoiding critical failures or recovering from them fast. You also have to design systems for graceful degradation so they can still perform well enough when there are failures.

Similarly, resilient AI needs more than the synchronous replication you’re used to having for any production workload. “A lot of these systems need to be load balanced across sites and have that redundancy across multiple domains,” Hammons says. The complexity of that has even sophisticated organizations turning to providers like CoreWeave and what he calls AI native neo clouds.

Taking a hybrid approach to APIs is almost universal. Whether you’re bursting out to an AI data center, building on hyperscaler GPU infrastructure and cloud databases, or calling cloud APIs, you need to think about those connections. That means updating legacy networks and considering multiple connectivity providers for redundancy.

And if you’re doing AI at the edge, especially in near real time environments like factories and retail, you also have to think about distributed reliability, and what connectivity and latency is needed to deliver inferencing or update local models across sites for consistency.

“Cross-cloud communication is just going to grow,” Bergman says. Fastly customers are already keeping training set data there so they can use it in multiple clouds. “We can ingress it to all the clouds without the cloud egress charges.”

Authenticating agent access and privileges when acting on behalf of employees may add complexities in future, he suggests. That doesn’t need low-level network changes but at the application layer, he predicts a lot of evolution has to happen for these things to scale out in a secure, reliable way.

Flatten your architecture

Most AI adoption today is happening on architectures never designed for this level of volatility, says Richard Copeland, CEO of cloud services provider Leaseweb. “Everyone wants the magic of AI, but the moment they scale it, they’re confronted with the messy reality of data gravity, latency budgets, and storage economics,” he adds. “Teams are trying to secure endpoints, expand pipelines, add GPUs, and increase bandwidth but none of that stops the operational chaos if the foundation beneath it isn’t intentionally resilient.”

You’ll almost certainly need more storage to support AI and not just for training sets, he points out. “You’re storing embeddings, vector indexes, model checkpoints, agent logs, synthetic datasets, and the agents themselves are producing new data every second,” he says. So spend the time to work out how much of that you actually need to store, where, and for how long.

But designing for continuity means treating resilience as a design principle, not an insurance policy. Organizations that stay ahead are flattening architectures, pushing compute closer to data, automating lifecycle policies, and building environments where AI pipelines can fail over without anyone breaking a sweat, says Copeland.

Flatter architectures also reduce technical debt, but most enterprises have accumulated so many layers of tools, proxies, queues, storage tiers, and checkpoints that their AI pipelines behave like Rube Goldberg machines, he adds. “Data has to climb up and down that stack before it reaches the models that need it, and every hop adds latency, fragility, and operational overhead,” he says.

Find out where delays are coming from and you may find systems you don’t need. “Remove redundant middleware, automate data-placement and lifecycle policies, and shift workloads toward the environments where the data already lives,” he continues. Consolidating storage tiers, moving GPU workloads into simpler regional or on-premises environments, and tuning the network path should allow a system that behaves predictably rather than chaotically.

Data by design

Making AI scale will almost certainly mean taking a hard look at your data architecture. Every database adds features for AI. And lakehouses promise you can bring operational data and analytics together without affecting the SLAs of production workloads. Or you can go further with data platforms like Azure Fabric that bring in streaming and time series data to use for AI applications.

If you’ve already tried different approaches, you likely need to rearchitect your data layer to get away from the operational sprawl of fragmented microservices, where every data hand-off between separate vector stores, graph databases, and document silos introduces latency and governance gaps. Too many points of failure make it hard to deliver high availability guarantees.

“The traditional patchwork of databases, pipelines, and bespoke vector stores simply can’t keep up with AI’s latency, governance, and scale requirements,” says Nadeem Asghar, chief product and technology officer at cloud AI database platform SingleStore. “Unified intelligence planes will replace today’s fragmented stacks, collapsing data, compute, and inference into a single live system.”

Dominik Tomicevic, CEO of graph database provider Memgraph recommends separating the models and agents that form your intelligence layer from your knowledge layer, where truth, data, and information live and require synchronous or near‑synchronous replicas across zones or regions.

Although AI infrastructure means tackling data- and network-heavy distributed systems, he views that as a solvable engineering problem. “A resilient AI stack starts with a strongly‑typed knowledge graph or GraphRAG store that can be clustered, replicated, backed up, monitored, and accessed‑controlled just like any other mission‑critical database,” he says.

That gives you flexibility to scale search and data nodes separately, or even change models and vendors in the future. It also means security and resilience go hand in hand.

“Fine‑grained access control at the graph level means the retrieval layer will never leak data that the underlying database wouldn’t allow, even if an LLM is curious,” he adds. “On top of that, you bake in observability and service-level objectives specifically for AI, like latency and error budgets for GraphRAG queries, quality metrics for retrieval results, and cost budgets for model calls.”

Put platforms in place

The pressure to move from prototypes to production deployments that deliver the value of AI means individual projects need policies and best practices to build on, rather than having to make all the right decisions themselves, so they can focus on technical questions like choosing models rather than building infrastructure.

If this sounds like the principles of platform engineering, that’s how you make AI a capability rather than a series of experiments. IDC’s Saroff argues that a unified platform workflow you’ve already done gives you a backbone of process, APIs, data, and technologies. Instead of solving the same problem over and over, you deliver infrastructure that includes GPUs and accelerators, as well as multiple flavors of compute, observability for models, API calls and applications, as well as cost management and governance.

All these systems need to be feeding into observability and optimization tools with near real time feedback. You can’t wait until you get your monthly cloud bill to discover you’ve blown past your budget, or until you hit an outage to realize the APIs you rely on are returning errors and requiring multiple retries. API management is key to track usage and optimize costs.

And you need all of that to integrate with existing infrastructure and workflows. “Every company has the same problem. You need AI to compete, but all your actual business runs on legacy infrastructure and software that predates the iPhone,” argues Jarrod Vawdrey, field chief data scientist at Domino Data Lab.

He defines forward deployed engineers as translators who navigate the complexity between desired business outcomes, legacy systems, and modern AI capabilities. “They can wrangle a large language model and integrate it with your 20-year-old ERP system that nobody wants to touch.”

The integrations will be new but the fundamentals aren’t. Doing IT right is what will allow you to do AI correctly, says Bola Rotibi, chief of enterprise research at technology research and advisory firm CCS Insight.

The good news is you may already have done the heavy lifting using, for example, well-architected frameworks for cloud as AI applications will inherit that redundancy, exception handling, and chaos engineering. “If your architecture is built for resiliency, then chances are you’ve already started thinking about all the things required to underpin AI,” she says.

All of this, of course, is going to cost money. IDC predicts that by 2027, organizations will realize they’re underestimating the costs of AI infrastructure by almost a third, and will start applying FinOps to it.

But true resilience relies on understanding both business and operational context, making for a more combined, collaborative environment, Rotibi suggests. While CIOs usually struggle to justify infrastructure investments, tying them to delivering reliable and secure AI allows IT to continue providing value that’s aligned with business priorities rather than being seen as a cost center.

En España, este cambio se ha acelerado por tres fuerzas: la rápida expansión de la IA generativa, la convergencia entre ciberseguridad, resiliencia y regulación y una presión financiera: el coste de operar cloud y la IA impactan con fuerza en la cuenta de resultados. Esta tribuna sintetiza los cinco retos que han definido 2025 para el CIO en España: industrializar la IA, construir resiliencia demostrable, gobernar el coste de cloud (FinOps), reforzar el talento y asegurar la soberanía sobre los datos.

1. IA y ‘GenAI’: el exceso de expectativas cae por el abismo del escalado

En muchas organizaciones españolas, 2025 ha sido el año en que la IA generativa ha pasado de la prueba a la expectativa de resultados. Esto desgasta al CIO, porque el escalado se complica precisamente cuando sale del entorno controlado del piloto y extiende a distintos procesos, áreas y fuentes de datos. Por ejemplo, hay muchos asistentes que elevan la productividad individual pero no se traducen en impacto transformador del negocio.

Un dato revelador resonó con fuerza cuando salió el informe The GenAI Divide: State of AI in Business 2025 (MIT NANDA, julio 2025), destacando que, pese a decenas de miles de millones invertidos, el 95% de las organizaciones obtiene un retorno cero y en sistemas GenAI integrados (más allá de herramientas genéricas), solo un 5% llega a producción. El informe añade las razones: el bloqueo está en la industrialización y la capacidad de transformar los flujos de trabajo.

Por otro lado, 2025 ha sido un punto de inflexión, porque la regulación europea sobre IA ha dejado de ser una declaración de principios y se ha convertido en un requisito operativo. El calendario del AI Act exige mecanismos concretos de control: gobierno, trazabilidad y evaluación de riesgos.

En síntesis, el debate para el CIO ha pasado de si usar o no la IA, a escalarla, gobernarla y controlar los datos, calidad y riesgos. Y eso significa decir no a pilotos que no tengan un camino claro de industrialización, aunque brillen mucho.

2. Ciberseguridad: el reto es mantener la continuidad de las operaciones y poder demostrarlo

Si hay un cambio cualitativo de la ciberseguridad en 2025, es este: ciberseguridad, continuidad y cumplimiento han dejado de ser agendas paralelas. Para el CIO, se han convertido en una sola conversación: resiliencia demostrable.

La presión externa se ve en datos y en regulación. En España, Incibe comunicó que su CERT gestionó 97.348 incidentes en 2024, un +16,6% frente a 2023, con un reparto que recuerda que el impacto no es solo en la ciudadanía, sino en la empresa y la cadena de suministro.

Pero lo que muchos CIO de sectores con activos físicos han notado con más intensidad en 2025 es la entrada de OT en la ecuación: digitalizar una planta, red o infraestructura crítica crea valor, pero abre una nueva superficie de ataque. ENISA lo pone negro sobre blanco en su Threat Landscape 2025: en su distribución de categorías, las amenazas de OT representan un 18,2%, y además destaca los riesgos en la cadena de suministro.

En esa línea, los actores externos se han convertido en el perímetro real. La empresa ya no depende únicamente de su CPD o de su SOC, sino de un ecosistema de cloud, integradores, operadores o servicios gestionados. En 2025, la regulación DORA en el sector financiero ha consolidado esta visión: desde el 17 de enero de 2025, exige mantener un registro y un control sistemático de los acuerdos con proveedores de servicios TIC.

En 2025, el CIO ha visto desplazarse su rol: menos foco en la gestión de sistemas para convertirse en el responsable de coordinar la resiliencia dentro y fuera de la organización.

3. ‘FinOps’: tras años desapercibida, en 2025 se ha situado en primera línea

El término FinOps se ha convertido en protagonista en 2025 por una razón simple: muchas cargas ya se han movido a cloud, y el coste no solo se ha disparado. Se ha vuelto más variable y menos explicable de lo que los comités de dirección estaban dispuestos a aceptar.

Lo importante para el CIO es la consecuencia. Ya no sirven medidas puntuales (recortes arbitrarios, apagar instancias o congelar proyectos). Hace falta replantear el uso de cloud de extremo a extremo.

En 2025, FinOps deja de percibirse como una iniciativa exclusivamente de TI y se consolida como una disciplina transversal. Ingeniería y arquitectura son críticas porque el coste comienza por el diseño, pero finanzas es imprescindible para traducir la factura aplicar políticas de costes alineadas. Compras influye directamente introduciendo nuevos elementos en la selección y contratación de proveedores. Finalmente, las unidades de negocio deben asumir su responsabilidad sobre el consumo.

La FinOps Foundation muestra cómo la agenda se amplía: entre las principales prioridades están la aplicación de FinOps a escala, y controlar los costes más allá de la cloud pública. Además, la gestión del coste de la IA/ML se eleva en la agenda.

En 2025, el foco para el CIO se ha desplazado de la reducción del coste a conseguir que la organización aprenda a usar cloud con gobierno, visibilidad y decisiones orientadas a valor.

4. Talento: la contratación junior se enfría cuando se necesitan nuevos especialistas

El contraste ha sido evidente en 2025: titulares de ajustes de plantilla y, al mismo tiempo, puestos vacantes imposibles de cubrir en perfiles concretos. En España, no solo ha sido noticia el ERE Telefónica, también muchas multinacionales tecnológicas y de otros sectores han anunciado recortes de miles de empleados.

Al mismo tiempo, hay una escasez dramática de talento especializado. El World Economic Forum, en su Future of Jobs Report 2025, vuelve a situar IA/big data, redes y ciberseguridad entre las habilidades de mayor crecimiento. La asociación de seguridad ISC2 citó que el 89% de organizaciones de la UE sufre una brecha de capacidades y un 63%, directamente, escasez de personal cualificado de seguridad.

El elemento nuevo y delicado para el CIO en 2025 es el efecto junior: si la IA automatiza tareas intensivas en horas (búsqueda, síntesis, documentación, soporte), muchas empresas frenan la contratación de perfiles jóvenes. Un documento de investigación de la Universidad de Stanford titulado ¿Canarios en la mina de carbón? apunta a caídas de empleo en trabajadores entre 22 y 25 años en las ocupaciones más expuestas a la IA generativa.

Esto crea un riesgo de medio plazo para el CIO: menos juniors hoy implica menos seniors mañana, justo cuando faltan perfiles no solo con habilidades especializadas, sino con conocimiento de la propia organización.

5) Soberanía del dato: diseñar portabilidad y control antes de que lo impongan las reglas europeas

En 2025 ha quedado claro que el dato forma parte de la agenda geopolítica global: condiciona la competitividad, el control de las cadenas de suministro e incluso la seguridad nacional. Por tanto, la soberanía del dato ha dejado de ser un debate teórico y se ha convertido en un debate sobre dependencia tecnológica: quién tiene acceso a los datos de la empresa, bajo qué jurisdicción, y cuál es la capacidad real de repatriar datos o cargas sin disrupción. Este reto aparece de forma sobrevenida, tras haber movido muchas cargas críticas a cloud, y apoyarse en gran medida en los hiperescalares.

La respuesta europea se apoya en dos señales claras:

• El Data Act es aplicable desde el 12 de septiembre de 2025 e incluye el objetivo explícito de facilitar la transferencia de datos y la migración entre proveedores de cloud.
• La Comisión Europea ha impulsado un Cloud Sovereignty Framework, reforzando que la soberanía consiste en control operativo, transparencia y cumplimiento, no solo de ubicación. De hecho, Comisión planea proponer el Cloud and AI Development Act en el primer trimestre de 2026

Para el CIO, el mensaje de 2025 ha sido claro: la soberanía no solo se declara, hay que diseñarla. Esto le está obligando a replantearse la arquitectura, los contratos y la propia operación.

Estos cinco retos han destacado en 2025 porque comparten un patrón: cuando lo digital escala, aparecen las fricciones. La IA se enfrenta al abismo del escalado; la ciberseguridad se convierte en continuidad demostrable. FinOps se eleva al comité porque el coste variable ya es estratégico; el talento se tensiona por habilidades críticas y el freno de talento junior, y la soberanía del dato se vuelve geopolítica.

La referencia a 2026 es simple: no se tratará tanto de temas nuevos, sino de endurecimiento de expectativas. Con Data Act ya en aplicación, marcos de soberanía avanzando y con propuesta europea en preparación, 2026 va a exigir al CIO más capacidad operable para sostener estos cinco frentes sin que la empresa pierda velocidad. En la próxima tribuna, detallaremos lo que tiene por delante el CIO en el año que entra.

---