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.

Databricks is pitching a fix for what it sees as the growing operations mess in enterprise AI. With the launch of Genie ZeroOps, unveiled at its Data + AI Summit, the company is targeting a problem many data teams know too well: it’s no longer building pipelines and models that hurts, it’s keeping them running.

As data estates sprawl and AI workloads multiply, engineering time is increasingly eaten up by maintenance. Meanwhile, AI coding tools are accelerating development, churning out even more assets that need oversight, widening the gap between how fast teams can build and how much they have to manage.

Databricks Genie ZeroOps is a new agentic operations capability that is designed to automate the monitoring, investigation, and remediation of issues across data and AI workloads.

Currently in private preview, ZeroOps uses an AI agent to identify anomalies, trace root causes using metadata and lineage information via Unity Catalog, generate proposed fixes, and then test those fixes in an isolated environment before pushing them out for human review to be applied in production.

Targeting real operational complexity?

Genie ZeroOps addresses a legitimate enterprise challenge around operational complexity, particularly the growing burden of maintaining data and AI workloads in production, analysts say.

“Most data teams spend more time keeping pipelines and models alive than building new ones,” said Amit Chandak, chief analytics officer at IT consulting firm Kanerika.

Echoing Chandak, independent consultant David Linthicum said enterprises continue to grapple with deployment drift, incident response, compliance checks, and root-cause analysis across increasingly fragmented data and AI estates.

Those challenges, echoed Victor Coimbra, CTO of IT consulting firm Artefact, are compounded by the emergence of agentic coding tools that accelerate the development of assets, such as machine learning pipelines and models that need “babysitting.”

That maintenance burden carries a significant productivity cost, said Robert Kramer, managing partner at KramerERP, noting that activities such as managing infrastructure, deployment environments, support processes, and operational workflows consume time without directly creating business value.

Those productivity drains, according to Coimbra, have proven difficult to eliminate despite the emergence and widespread adoption of automated observability and governance tools.

“What is different here is the agentic piece. Databricks is trying to move from tools that alert humans to systems that diagnose issues, propose fixes, and validate them in a governed environment without breaking anything in production,” echoed Stephanie Walter, practice leader of AI stack at HyperFRAME Research.

Shifting the role of platform teams

That shift, according to analysts, could change the way most enterprise platforms and development teams work currently.

“Skilled engineers spend the majority of their time on toil. If the ZeroOps agent, in the background, handles monitoring, investigation, and fix-proposal, engineers shift from doing the operational work to reviewing it. The traditional split between ‘people who build’ and ‘people who keep things running’ starts to blur,” said Ashish Chaturvedi, leader of executive research at HFS Research.

“Additionally, this would also mean that platform teams (engineers responsible for maintenance) can focus on genuinely novel failures rather than the repetitive ones,” Chaturvedi added.

The shift, according to Coimbra, could also affect how enterprises scale platform teams: “They can stop hiring operations staff in lockstep with every new pipeline. The same team can cover a lot more.”

Given that the capability is still in preview, Kanerika’s Chandak pointed out that the headcount reduction claims may be overstated.

ZeroOps could instead pose the risk of “skill atrophy,” Chandak said.

“If engineers stop debugging because the agent does it, the team’s ability to handle the cases the agent cannot handle becomes a real exposure,” Coimbra added.

What ZeroOps could mean for CIOs

Genie ZeroOps could be attractive to CIOs because it links innovation capacity with operational discipline rather than forcing a tradeoff between the two, Linthicum said.

“The appeal is straightforward: reduce operational drag, shorten deployment cycles, improve service resilience, and enforce governance without scaling headcount at the same rate as workloads,” Linthicum said.

That combination of efficiency and reliability could help CIOs rein in one of the biggest costs associated with operating data and AI environments, Chaturvedi said. “ZeroOps attacks time spent on maintenance. CIOs have watched their data engineering budgets balloon while the proportion of that spend going to net-new value shrinks.”

Linthicum warned that CIOs should consider the new offering with calculated skepticism and seek metrics to validate Databricks’ claims.

“The headline metrics are mean time to detect and mean time to resolve, plus the share of incidents the agent closes without a human stepping in. Those tell you whether it is actually removing the operational complexities that it promises,” Kanerika’s Chandak echoed.

“Underneath these metrics, CIOs should track the accuracy of their root cause calls, the false positive rate on proposed fixes, and the proportion of fixes engineers approve without editing, because that last number is the real trust signal. On cost, they should measure cost per incident handled against the human baseline, net of agent compute,” Chandak added.

That scrutiny, Chandak further added, is even more important for CIOs because Databricks is entering an emerging category.

“Most vendor agent announcements target the build and use layers, helping people write code or ask questions of their data. ZeroOps targets the operate layer, which is less crowded,” Chandak said.

ENDS

A federal judge has rebuffed Workday’s claim that it cannot be held liable under California anti-discrimination laws when its tools are used to screen (and potentially reject) job candidates in other states.

This week, US District Judge Rita Lin indicated that she will likely allow additional state discrimination claims against Workday to move forward. This would significantly expand the closely-watched case and likely ratchet up scrutiny of AI recruiting tools and their potentially inherent biases when it comes to age, race, sex, disabilities, and other factors.

Further, it could indicate that, even if a company is not the final employer, it may be held liable if its tools materially influence who gets rejected. This could set new legal standards for AI hiring systems, and have implications across industries, experts note.

“This case reinforces the importance of actually managing AI risks,” said Valence Howden, advisory fellow at Info-Tech Research Group. “If an AI-enabled model or ATS [Applicant Tracking System] is making decisions based on historical information, it can raise questions about whether bias in outcomes and datasets has been properly addressed.”

The case so far

Mobley v. Workday, Inc. alleges that Workday’s AI screening tools discriminate against job seekers based on age, race, and disability. The suit was filed in 2024 in the US District Court of California by Derek Mobley, a Black disabled man over 40, who claimed Workday’s algorithms continually screened him out as he applied for more than 100 positions on the platform.

The claims alleged discrimination prohibited by several US and California statutes: Race and sex under the Civil Rights Act of 1964 (Title VII); disability under the Americans with Disabilities Act of 1990 (ADA); age under the Age Discrimination in Employment Act of 1967 (ADEA); and race, gender, and age under California Fair Employment and Housing Act (FEHA).

Specifically, the suit centered around Workday’s use of automated, algorithm-driven tools for applicant screening. It alleged that these systems rely on historical data and statistical modeling that can make them susceptible to existing biases, even if protected characteristics like race, age, sex, or disability are not explicitly provided.

Bias may enter these systems in different ways, the plaintiffs argued, including via training data, model design, and evaluation criteria for candidate fit. The system could reproduce discriminatory outcomes by making correlations from data. For instance, years of experience on a resumé may indicate age; long employment gaps may infer a disability or caregiving responsibilities; educational and institutional affiliations could reflect race.

Workday has argued that it is not subject to liability under employment statutes because it does not qualify as the job applicants’ “employer.” But federal judges have allowed key parts of the lawsuit to move forward, ruling that Workday could potentially be treated as an employer’s “agent” for the purposes of anti-discrimination law.

The latest dispute centers on FEHA. According to legal sources, the California statute is among the strongest anti-discrimination laws in the US, in many cases providing broader protections than federal employment laws.

Workday asked the court to dismiss claims brought under California law, saying FEHA should not apply to the hiring decisions of out-of-state employers and applicants. The company’s lawyers argued that enforcing this would effectively allow California law to supersede that of other states, just because a company used their platform.

But Lin disagreed, saying FEHA does apply, and in fact, Workday is directly liable for its “own engagement in FEHA-regulated activities on the employer’s behalf.” Holding businesses liable for “their own discriminatory conduct” is within the scope and purposes of FEHA and consistent with public policy.

However, the issue is still to be decided; Lin did not indicate when she would release a final ruling.

Workday’s defense

A Workday spokesperson called the claims in the suit “false.”

“Workday’s AI recruiting tools don’t make hiring decisions and are designed with human oversight at their core,” the spokesperson told CIO. “Our technology looks only at job qualifications, not protected traits like race, age, or disability. We rigorously test our products as part of our responsible AI program to confirm our tools do not harm protected groups.”

Workday’s platform is meant to provide insights on how well a candidate’s qualifications match the requirements of a posted job, the company said. Those tools focus only on qualifications listed in a candidate’s application, which are compared to qualifications identified by the employer as important for the job.

Workday’s Chief Responsible AI Officer Kelly Trindel said its AI does not make employment decisions, automatically reject candidates, or determine who gets a job; further, she said, there is no evidence that the company’s tools result in harm to protected groups.

Trindel, who is former chief analyst of the Equal Employment Opportunity Commission (EEOC), leads a dedicated team composed of psychologists and PhD-level data scientists whose sole focus is to ensure that its AI is “responsible, fair, and ethical.” She said that the company’s AI systems undergo ongoing reviews throughout their lifecycle to help prevent unintended consequences, and Workday is “committed to accountability, transparency, and trust,” and invests “significant resources” into identifying and mitigating bias.

Further, she said, Workday has a company-wide commitment to ethical AI, and an independently-evaluated AI governance program based on standards from the National Institute of Standards and Technology (NIST) and the International Standards Organization (ISO).

“Workday builds AI to support people, not replace them, and this is of particular importance when it comes to hiring,” Trindel noted. Its platform is designed to help employers “manage high-volume processes more efficiently, surface relevant information, and reduce administrative work so teams can spend more time applying their expertise and judgement to hiring decisions.”

What this means for enterprise leaders

Workday isn’t alone in its legal challenges; other AI hiring tools are also being scrutinized over their methodologies, algorithms, and data-collecting practices. Eightfold, for one, is also facing a California class action lawsuit alleging that its tools unfairly rely on job candidates’ online data to predict whether they’d be a good fit for a position.

This means that enterprises, who are already feeling increased pressure to document hiring decisions, conduct AI bias audits, and maintain human oversight in recruitment and hiring, must be even more diligent in their vetting of AI tools.

Organizations must be actively defining how these recruitment tools should work, identifying bias in their algorithms, and setting up structures to test for bias across the tools’ decision-making logic, Info-Tech’s Howden advised.

“Validation of non-biased outcomes also needs to be active and ongoing, rather than a point-in-time exercise,” he said.

While Workday and others say human oversight is paramount, “it’s hard to incorporate humans into the process if the platform does the weeding out before humans have the ability to intervene,” Howden pointed out.

Discriminatory biases can exist in past hiring decisions, so it’s easy to forget that AI can “emulate and adapt those biases as part of its perspective,” he said. That includes how AI looks at language: Different cultures use different phrasing, and AI can capture that and use it to exclude candidates.

Ultimately, he called the case a “cautionary tale” illustrating how lightly some organizations have been treating AI risk. It also highlights the urgency involved in building out more advanced enterprise risk practices, “rather than relying on the limited capabilities they may have employed up until now.”

This article originally appeared on CIO.com.

Beth Tschida, who became Jamf CEO in May after serving as CTO and as interim CEO, is the first woman to lead the company in its near 25-year history. I spoke with her this week at the London Jamf Nation event, where the company introduced its new AI Governance solution.

How the transition to CEO is going 

“It’s been a great privilege and an adjustment,” she said. “Jamf has always been a company deeply focused on culture, which is exactly why I love being here. Having the ability to influence and improve that culture from this role is something I feel very supported in doing.”

The last few years have seen a variety of changes at Jamf, which was briefly a public company. “We’ve come through a period of change, not all of it easy,” Tschida said. “But we now have a great partnership with Francisco Partners. We’re private, we’re focused on solving customer problems, and we’re finding ways to lean into what we’re good at.”

Women in tech and mentorship

Tschida is a good choice to lead a software engineering company, as she’s an engineer herself. She originally joined Jamf as vice president for software engineering in 2018, moving up to CTO in 2022. She’s also one of the few women in leadership positions in tech. (To Jamf’s credit, the company also has CIO Linh Lam on its team.)

“I think it’s important for women to stay deep in the tech, build their skills and find their voice confidently,” Tschida said. “You’ll never know all the technology out there. Nobody does. What matters is the ability to keep adapting and evolving.”

Tschida stressed the importance of mentorship. “I feel very honored to have a chance to be a role model for other women,” she said. “I had women who forged a path for me, including a female CIO early in my career who I asked to mentor me and learned an enormous amount from. I’m certainly not the first woman in tech, but I do want to play my part in helping others grow in their careers.

“Ultimately, I want to be respected for what I do, not for my gender. That’s how everyone should be judged.”

AI Governance

Tschida’s product focus means she knows what matters to Jamf. “If you focus on the problems customers have and how your product can help fix them, that’ll take you to where you want to go.”

For many in the enterprise, both in and beyond the Apple space, the next big problem is AI — how to deploy it, how to manage it, and how to regulate it.

AI Governance is a new Jamf solution that has been developed in response to those pain points. Countless surveys, including Jamf’s own data, show that AI is being widely used across every company, but IT lacks visibility into its use. It’s hard to know what data is being shared with AI tools, which services are being used, and how to report on that use effectively — particularly in regulated industries.

AI Governance is designed to make it possible for anyone managing an Apple fleet to get granular insight into AI use across their Mac, iPhone, and iPad devices. It uses telemetrics to shed light on that use, offers governance and management tools to help IT gain better oversight and control over it, and provides highly comprehensive reporting tools suitable for internal or regulatory review.

“AI is happening whether organizations know it or not,” said Tschida. “That’s the problem. You can try to block it, but that’s very hard to do well. It’s far better to build visibility and governance around it.”

The offering makes it possible for companies to enable the AI use they already know is taking place while protecting corporate interests and enabling fast and accurate reporting. You can find out more details here.

Jamf

Empowering better AI

Jamf’s approach is focused on endpoint management. AI Governance means IT can see what’s running on a device, categorize it, and understand what AI tools and models are in use. “If you know how people are running AI on your fleet, you can open it up safely. Then all of your customers and employees can find their way to figure out how AI is going to optimize their workforce,” she said.

What does that look like in practice? Think of it as an orchestration layer. IT can define different AI configurations for different teams: HR might use one set of models, engineers another. And admins can apply opinionated postures per group: what models are permitted, what cloud services they connect to, what’s visible to IT versus the CISO versus the CFO. “It’s an extension of what Jamf has always done, it just now applies to AI endpoints too.”

What about regulatory complexity across geographies? “A lot of governance controls are shared across regulations; a good base set is a healthy way to run regardless. But each regulation has its own twists. Our mission is to make sure customers operating in different markets can expand on that base and fit the specific models and regulations they need, getting the right configurations to the right devices.”

Managers must prepare for AI cost challenges

There’s a second dimension beyond management — cost. The industry is developing quickly, with new AI models appearing almost every week. Yesterday’s leading LLM is tomorrow’s fading star, even while the cost of AI infrastructure goes through the roof. As that churn slows, investors will want to start seeing returns on their bets, which is why token costs — the price of running AI services, at least in the cloud — are climbing fast.  

As costs become more realistic, that’s going to change the nature of AI deployment from the laissez-faire, anything goes approach to a more strategic management of such use. “Models keep dropping fast, but token costs are only going to go up,” said Tschida.

“Organizations will need to decide: just because you can build something with AI, should you? What’s the right model for what work? We’re helping customers move from, ‘We’ll just block it’ or ‘We’ll turn it on and hope for the best,’ toward a place where they have a real viewpoint and can manage and change that viewpoint over time.”

The ever-changing AI world is also prompting Jamf to make more of its APIs externally available. “We’re used across every industry and every geography, at every scale,” said Tschida. “There’s no way we can build every workflow every customer needs, we’d never get to all of them.”

Embracing openness also helps build future foundations. “Thinking about where we’re heading next — agentic endpoint management — having platform APIs allows our customers to build things they can imagine, that we can learn from, in a way that solves their specific problems.”

Apple, WWDC, and the enterprise

Tschida’s comments come shortly after WWDC 2026, where Apple introduced a raft of AI advances that formed a strong foundation for its future, improvements that matter to Jamf. “When Apple innovates, Jamf celebrates,” she said.

“Apple is doing great things in their AI ecosystem, revamping Siri, expanding their AI capabilities, making Apple the platform people want to run AI on because those machines simply perform better. Our job is to take what Apple builds and bring it into the enterprise in the way that enterprises actually need it.”

Most of the industry recognizes that Apple’s enterprise story has changed dramatically as its products see accelerating use, and momentum is not slowing. Tschida reflected on how just a few years ago, Apple in the enterprise was an option in employee choice programs. “Now it’s becoming the clear choice,” she said. “We expect that trend to continue. And the more Apple invests in AI running natively on device, the stronger that argument gets.”

Where is Jamf going?

AI Governance is a unique answer to an increasingly important set of questions that are now beginning to affect the IT management of Apple’s platforms. (It’s not clear whether anything as sophisticated exists for other platforms at al, but as the need to manage AI grows, demand for such solutions will grow.)

Ultimately, the company’s latest move reflects Jamf’s inherent strategy under its new CEO. “Focus on customers, listen to them, solve their problems, and don’t throw tech at it. Ask: what’s the problem? Can we solve it? That focus is what takes you where you need to go.

“We’re on a good trajectory, customers stay with us, and the culture has always underpinned us. Now we’re finding ways to lean into it even further,” she said.

You can follow me on social media! Join me on BlueSky,  LinkedIn, Mastodon and subscribe to The Core.

There’s no shortage of agentic AI tools out there that offer to perform online tasks on your behalf, if only you’ll give them all your passwords and credit card details. The trouble starts when those agents don’t know when to stop — or when others don’t know to stop them.

In Estonia, the country’s AI Council has plans to change that, proposing to issue government-backed digital identities for AI agents that spell out what powers a person or company is willing to delegate to them.

“In the future, AI will increasingly perform digital operations on behalf of a person, company, or institution,” said Estonian Prime Minister Kristen Michal in a news release. “To do this, it must be clear who is acting, on whose behalf, with what rights, and who is responsible.”

He supported the AI Council’s proposal to create a digital identity for AI agents that will define agents’ rights and enable them to act in a verifiable and auditable manner.

The ID could, the council suggests, show whether an agent is only allowed to view data, create or edit documents, or make payments, and if so, up to what limit.

First mover advantage

There’s no telling when the plan will come to fruition — although Michal is keen for his country to take the lead.

“If we act quickly and wisely, Estonia will become the first country in the world to create an official digital identity for AI agents,” he said.

Estonia is already a leader in the use of digital identities for humans. Estonians can use their national digital ID cards for voting, signing documents, accessing medical and tax records. The country also offers foreigners the option of applying for “e-residency,” a digital identity enabling them to create a company in Estonia and digitally sign all related documents online as they interact with the country’s widely digitized administrative processes.

Michal created the AI Council in January, calling on Estonian startups, investment funds, industry and research institutions to systematically implement AI across the country’s industry, education, healthcare, and energy sectors.

AI vendors have already proposed creating digital identities for agents, but so far these are intended only to manage the activities of agents within the enterprise, or for interconnecting enterprise IT platforms, and none of them have the backing of governments.

Estonia’s proposal could put the tiny Baltic country at the cutting edge of agentic AI usage and set an example for others.

First came vector databases, then RAG. Now, the next frontier in enterprise AI is taking shape: context layers that give autonomous agents a shared understanding of the business, a vision Databricks is advancing with Genie Ontology.

Currently in preview, Genie Ontology automatically extracts business context from enterprise data, dashboards, queries, pipelines, documents, and applications and organizes it into a living graph that AI agents can use to understand how an organization operates.

Showcased at the company’s Data + AI Summit, Genie Ontology uses a ranking system inspired by Google’s PageRank to identify the most authoritative business definitions within an organization.

Rather than treating all sources equally, it weighs factors including who created the information, how widely it is used, its links to certified datasets and assets, and how recently it was updated before determining which answer an AI agent should rely on, Databricks CEO Ali Ghodsi said during his keynote late on Tuesday while explaining the new offering.

Organizations can also upload their own business definitions or ontologies to Genie Ontology via Databricks’ existing Unity Catalog Semantics platform, Ghodsi added.

Ontology promises consistency, but readiness remains a hurdle

For CIOs, a unified context layer, such as Genie Ontology, will materially improve consistency, trust, and governance for enterprise AI deployments, according to analysts.

“One definition feeding every agent means you stop getting three different answers to the same question,” said Michael Leone, principal analyst at Moor Insights and Strategy.

“Older approaches, such as RAG and vector search, just pull back whatever looks similar to your question, and they don’t actually understand your business. An ontology gives the agent the meaning a catalog can’t, what your terms mean, and which source to trust,” Leone added.

That improvement in consistency, according to Ashish Chaturvedi, leader of executive research at HFS Research, could also improve trust, which remains one of the most critical barriers to AI adoption.

“The single biggest barrier to enterprise AI adoption is that decision-makers don’t trust AI outputs enough to act on them without checking. An ontology that grounds answers in governed business definitions, with lineage back to source, directly attacks that trust deficit,” Chaturvedi said.

Alternatively, Leone was more cautious about the trust argument: “It’s a promising idea, but it still has to prove itself before I’d lean on it for anything that matters.”

Echoing Leone, HyperFRAME Research’s practice leader of AI stack Stephanie Walter pointed out that ontologies have a missing link, and that is verification: “Ontologies can improve context, but they do not guarantee the answer is correct. An agent can still pull incomplete data, apply the wrong logic, skip rows, misunderstand a workflow, or take the wrong action.”

That verification gap becomes even more critical, according to Leone, because most enterprises don’t have the data and governance readiness required to implement an ontology layer for AI deployments: “If your data and governance aren’t already in order, this just speeds up your existing mess.”

Seconding Leone, Walter pointed out that an ontology cannot fix messy definitions, poor lineage, weak ownership, or fragmented permissions on its own.

Additionally, the analyst pointed out that the hard part for CIOs is not creating an ontology once but keeping it accurate as the business changes: “Enterprises will need clear data ownership, metric ownership, domain expertise, governance processes, and a way to resolve conflicting definitions.”

“Otherwise, the ontology becomes another stale metadata project with a more sophisticated name,” Walter added.

A growing risk of CIO confusion

Beyond data and governance readiness, CIOs also face a growing risk of confusion in the wake of several technology vendors pursuing approaches, similar to Genie Ontology, to ground enterprise AI in a business context, according to analysts.

Over the past year, Snowflake, Microsoft, and others have introduced some form of ontology, semantic, and context-layer offerings, but the problem is in how these offerings are named, Leone said.

“Everyone slapped a different name on basically the same idea. It slows people down as it creates confusion,” Leone noted.

That confusion could also backfire on Databricks and other vendors, according to Bhupendra Chopra, cofounder and CRO of IT consulting firm Kanerika: “While the marketing has converged around context-building offerings, most enterprises will choose the platform where their data already resides.”

HFS Research’s Chaturvedi doubled down on that view, saying CIOs should resist evaluating ontology offerings in isolation and asked them to stick to the mantra of context layer follows data gravity: “If your data lives in Databricks, Genie Ontology is your path. If it’s in Snowflake, Horizon Context is. If you’re a Microsoft shop, the IQ family is.”

Additionally, Chaturvedi urged CIOs to look beyond functionality and assess how open and portable these offerings are, particularly in multi-platform environments where business definitions may need to move across data lakehouses, analytics tools, and AI platforms.

This is where Chaturvedi sees Snowflake differentiating itself from rivals, with its focus on open semantic interoperability aimed at reducing the risk of semantic lock-in as enterprises evolve their data and analytics stacks.

The battle for the AI control plane

Snowflake’s efforts to differentiate itself, though, analysts pointed out, at least for CIOs, draw attention to a larger race among vendors, including Databricks, to become the control plane for enterprise AI.

While Snowflake is attempting to position itself as an AI control layer through a combination of Snowflake Intelligence, Horizon Catalog, and its push for open semantic interoperability, Microsoft is embedding business context and governance across its Copilot, Fabric, and broader AI stack through offerings such as Work IQ, Fabric IQ, and Foundry IQ, Chaturvedi said.

Databricks’ Genie Ontology, too, is part of a similar strategy, Chaturvedi pointed out, urging CIOs to view the offering in the context of the company’s wider effort to position its lakehouse platform as the foundation on which enterprise AI agents are built, governed, and eventually deployed.

“It’s absolutely a control-plane play. When you connect the dots across everything Databricks has announced at this summit, including LTAP, OpenSharing, and Genie Ontology, you see a single place where enterprise data, governance, business semantics, and agent execution all converge,” Chaturvedi added.

Further, the analyst noted that the control-plane strategy reflects Ghodsi’s broader vision that data platforms could evolve into what the CEO describes as an “agentic system of record” — an authoritative source that AI agents read from, reason over, and act through.

The concept mirrors earlier platform shifts, Chaturvedi said, where ERP systems became the system of record for business transactions and data warehouses became the system of record for analytics.

The next battle, the analyst said, is over which platform becomes the system of record for enterprise AI agents.

Moor Insights and Strategy’s Leone agreed that data platforms are well-positioned to compete for that role because they already own the data, governance controls, lineage, and permissions that agents require to operate safely at scale.

Still, analysts cautioned that context alone will not determine which vendor comes out on top.

“The next enterprise AI battleground is not just context. It is verifiable execution,” Walter said.

As enterprises rush to build AI agents that can reason over business data and take action, Databricks argues that the long-standing practice of separating operational and analytical data systems is turning into a liability.

That separation, the cloud-based data warehouse provider says, is becoming increasingly strained as AI agents require simultaneous access to live operational data and historical context to make decisions and take actions in real time, unlike humans, who traditionally can work with data that is minutes or hours old.

At its annual Data + AI Summit, the data warehouse provider introduced Lake Transactional and Analytical Processing (LTAP), a new architecture designed to unify transactional and analytical data on a single storage layer.

The new approach, according to Databricks, differs from traditional online transaction processing (OLTP) and online analytical processing (OLAP) architectures, which typically store operational and analytical data in separate systems.

Traditionally, OLTP databases are optimized for running day-to-day business operations such as order processing, payments, and inventory updates, while OLAP systems are designed for large-scale analytical queries and reporting.

As a result, enterprises often need to rely on ETL pipelines, data replication, and separate infrastructure to move information between the two environments.

LTAP, Databricks said, seeks to eliminate the reliance on ETL pipelines, replicated databases or separate data copies by storing data once in a shared lakehouse layer while allowing dedicated compute engines to handle transactional and analytical workloads independently.

This approach, the company argued, provides AI-driven agents and applications access to both live operational data and historical analytical context without requiring data movement or duplicate copies.

Developer simplicity in the agentic era

Analysts, too, agree with Databricks’ contention that AI agents place new demands on enterprise data architectures.

“Agents don’t behave like people, or even like the apps we built for people. They read for context, loop, try things, then write something back, thousands of times over in ways you can’t fully predict. At that volume, the constant bouncing between production and analytics systems starts becoming the bottleneck. The pressure to collapse that gap is real, and LTAP is one way to approach it,” said Michael Leone, principal analyst at Moor Insights and Strategy.

Bhupendra Chopra, cofounder and CRO at IT consulting firm Kanerika, pointed out that an autonomous agent’s data access pattern makes the traditional architectures brittle: “We’re seeing this directly with clients deploying multi-agent systems, the pipeline layer becomes the ceiling almost immediately as an agent runs hundreds of times per task.”

The analysts also pointed out that the ability to collapse the gap between OLAP and OLTP is likely to help developers design more robust AI agents or applications that enterprises are currently targeting to deploy.

“The most interesting workflow or application patterns are real-time, context-aware applications that combine transactions, analytics, and AI in one flow,” said Stephanie Walter, practice leader of AI stack at HyperFRAME Research.

“Examples include AI agents that update customer workflows while seeing historical account context and fraud systems that act on live transactions and long-term behavioral patterns,” Walter added.

Designing such applications today, however, according to Leone, would require developers to pull together data from transactional systems, data warehouses, vector databases, and other sources through custom integrations, creating significant engineering complexity and maintenance overhead.

Operational simplicity and governance gains for CIOs

For CIOs,  LTAP’s ability to reduce that engineering complexity, according to Ashish Chaturvedi, leader of executive research at HFS Research, will result in operational simplicity as well as cost savings.

“Most prominent advantage would be fewer data pipelines and everything that cascades from eliminating them. Most enterprises don’t realize how much of their data engineering budget is pure plumbing maintenance,” Chaturvedi said.

Kanerika’s Chopra pointed out that a substantial portion of data engineering capacity in mid-to-large enterprises today is consumed by maintaining synchronization between transactional and analytical systems.

The implications, however, Chaturvedi noted, are not limited to developer productivity, architectural simplicity, or cost savings: “The strategic prize is simplified governance. When you have one copy of data under one governance model instead of the same data scattered across operational stores, replicas, warehouses, and vector databases, you’ve solved the governance fragmentation problem.”

That simplification, according to Chopra, will matter operationally for enterprises deploying multiple AI agents, as these workflows can amplify governance gaps at a speed and scale that no human workflow ever did.

LTAP versus HTAP

Despite all its benefits, though, LTAP isn’t the first effort to unify operational and analytical workloads under a single architecture and for years.

The industry has pursued a similar goal through Hybrid Transactional and Analytical Processing (HTAP) architecture, which sought to combine operational and analytical workloads on tightly coupled infrastructure to serve both workload types from the same system.

LTAP, in contrast, separates storage from compute, allowing different engines to access a common data layer while remaining independently scalable, Databricks said.

That separation of compute engines is why analysts think that LTAP might be a better bet than HTAP.

“HTAP never took off because asking one tightly bound system to be great at transactions and great at analytics usually left it mediocre at both, so customers ended up paying a premium for that compromise,” Leone said.

“I think separating storage from compute is the right instinct, and it’s the same move that made the modern cloud data world work in the first place. It matters because the thing that sank HTAP was one workload starving the other, and giving each side its own dedicated engine is exactly how you keep that from happening,” Leone added.

Another reason for HTAP’s failure, according to David Menninger, executive director of software research at ISG, was its requirement for enterprises to replace existing data platforms with a new architecture.

LTAP, by contrast, builds on the now-common practice of separating compute and storage, making the addition of an operational layer less of an architectural transformation and potentially lowering the barrier to adoption, Menninger added.

Not yet the default architecture for AI agents

However, despite the enthusiasm around LTAP, analysts warned CIOs against viewing this as the inevitable successor to existing data architectures.

“CIOs will still need to choose their data architecture based on latency, reliability, ecosystem fit, cost, compliance, and developer experience,” Walter said.

Echoing Walter, Chaturvedi pointed out that for LTAP to become the de facto standard for the industry, Databricks will need more than architectural elegance: “The architecture looks sound on paper. The proof will be in the commit-to-query latency numbers under real load.”

LTAP, Databricks said, is expected to be released soon as part of Lakebase, without providing any specific timelines.

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.  

AIs struggle to understand documents designed for humans; the DocLang working group seeks to flip that imbalance with its specification for machine-readable business documents “built from the ground up for LLM tokenizers.”

The working group, founded by IBM, Nvidia, and Red Hat and hosted by the Linux Foundation’s LF AI & Data project, aims to create an open, universal, AI-native document format designed to improve how enterprises prepare, exchange, and govern document data for AI systems. ABBYY and Human Signal will also be involved in its development, and other contributors are welcome.

“Enterprises today work across a fragmented landscape of document formats, including PDFs, JPEGs, and other file types built primarily for human consumption rather than AI interpretation,” the group said in its launch announcement.

“This disconnect can introduce complexity, raise costs, and reduce reliability when extracting meaning from business documents,” as organizations increasingly rely on generative AI and agentic systems, it said.

Mark Collier, executive director of LF AI & Data, said the goal of the DocLang Specification Working Group is to “develop a vendor-neutral, interoperable standard that helps organizations prepare document data for AI more reliably, transparently, and at scale.”

DocLang defines a structured, machine-readable format for documents of any type, like JSON for data, that any tool can implement and any pipeline can consume. It builds on DocLing, a document processing toolkit hosted by LF AI & Data that can transform human-readable PDFs, word processor documents or spreadsheets into structured data.

Standards must evolve for AI

Something like DocLang is needed, said independent technology analyst Carmi Levy. “Existing document standards have done an admirable job allowing global stakeholders to confidently collaborate for decades, but it’s becoming increasingly clear that they are in desperate need of an update as AI reshapes the rules around how work gets done,” he explained.

Largely static document types, he said, “can be somewhat limiting when AI is redefining the very word, ‘document.’ In many ways. AI-age documents are far more iterative and dynamic than what they once were, and the definitions need to evolve with the times. The documents we currently live with simply weren’t designed for the AI age.”

Within that context, Levy said, “DocLang represents an early, best hope of achieving some kind of foundational baseline for document standards, one that will hopefully allow more intelligent, more efficient, lower-risk workflows than is currently the case.”

Taking an open-source, vendor-agnostic approach to the process ensures the collective will take precedence over the needs of specific vendors, he said, adding, “earlier standards-setting efforts around networking, documentation, the web, and the cloud powered the free-flowing digital landscape that defines modern life.”

An AI-centric documentation standard will carry that reality into the next generation of technology, said Levy.

A question of governance

The entire concept of LLMs, Jason Andersen, principal analyst at Moor Insights & Strategy said, “involves using natural human languages. The computer is supposed to understand us without us changing our syntax or language. Forcing a syntax on users is exactly what we have today with SEO and more advanced programming languages.”

With something like DocLang, where the standard can be applied to content ingestion, he said, “I would be OK with that being automated, which seems to be the intent. The use case I envision is that when I upload a document to an agent, a skill can be run to preprocess the document into the DocLang standard format, saving tokens.”

That makes sense, he said, adding that he thinks it’s good “if it can help generate outputs, like a visualization, that can be shared outside an AI tool. On that front, that is also why I am liking Web MCP, since you are just adding some code to the page, like CSS or JavaScript, and the consumer, in this case, an AI browser or skill, is better equipped to handle the site.”

The point, he said, is, “these standards need to preserve the fact that humans can still do what they want, and do not need to know any coding to be proficient. In terms of governance, I am not sure if it matters.”

But one analyst did foresee governance problems arising from DocLang’s use.

Yaz Palanichamy, senior research analyst at Info-Tech Research Group, said DocLang adoption will require organizations to implement and review controls in order to scale its use accountably and securely.

This article first appeared on CIO, on June 10, 2026.

For years, the cloud market has made a simple promise: Move workloads to large-scale platforms, gain better resilience, and worry less about downtime. That promise was never entirely wrong, but it is becoming less complete. The latest findings from Uptime Institute’s seventh Annual Outage Analysis suggest that the outage landscape is changing in ways that should concern both cloud providers and cloud customers. The biggest risks are no longer limited to broken physical infrastructure. They are increasingly tied to the complexity of the systems used to run, coordinate, update, and recover that infrastructure.

The most alarming number in the report is that IT and networking issues accounted for 23% of impactful outages in 2024. Uptime Institute links these increases to growing IT and network complexity; the long-term shift toward colocation, cloud, and third-party digital services; and the resulting increase in change-management failures and misconfigurations. That number is more than a statistical footnote. It points to a structural change in how outages happen and why cloud outages are becoming such a stubborn problem.

Hardware redundancy can protect against component failures, but it doesn’t help much when the outage stems from a bad configuration, an automation error, a faulty network change, or an underappreciated control-plane dependency. In those cases, the infrastructure itself may remain intact while the system that governs it breaks down. The industry is learning that resiliency is less about duplicating equipment and more about managing complexity. Today’s increasingly distributed and software-defined environments cannot operate safely at scale.

Failures at the operational level

Uptime’s findings show that power remains the leading cause of major outages, underscoring that traditional infrastructure engineering still matters a great deal. But even as providers continue to improve physical resilience, outages can still arise from the digital and procedural layers above it. Cloud platforms are now dense stacks of services, APIs, orchestration systems, software-defined networks, identity controls, failover logic, and third-party dependencies. That complexity creates more possible points of interaction and more opportunities for an error in one layer to cascade into several others.

This helps explain why outages can feel more surprising today than they did a decade ago. In older data center models, an outage often had a more apparent root cause, such as a power event, a cooling failure, or a hardware fault. In cloud environments, the trigger may be a small configuration change that propagates across regions, a policy update that unintentionally blocks service communication, or a network control failure that affects seemingly unrelated services. These are not failures of raw infrastructure capacity. They are failures of complexity management.

The report’s language around change management and misconfiguration is especially important because it challenges one of the most common assumptions in the cloud market: that scale automatically produces better operational outcomes. The reality? Scale can magnify both strengths and weaknesses. Large cloud providers have more engineering talent, more sophisticated tools, and more redundancy than almost any enterprise customer. But they also run far more interconnected systems at far greater speeds with far more automation. A single process failure can have a wider blast radius.

Another important lesson from the Uptime analysis is that automation has not removed the human factor. If anything, it has changed its form. Even in highly automated environments, human error remains central to the problem. The report notes that in 2025, the share of outages caused by human failure to follow procedures rose by 10 percentage points compared with 2024. A related industry summary of the report notes that 58% of human error-related outages were caused by staff failing to follow established procedures.

That matters because cloud providers often position automation as the answer to reliability. Automation is essential, but it only works as well as the operational model that surrounds it. If teams deploy changes too quickly, rollback paths are weak, approval chains are bypassed, or procedures are incomplete, automation can accelerate failure rather than prevent it. In a modern cloud environment, a human mistake is rarely just a single keystroke. It is more often a design weakness in process, governance, testing, or accountability.

This is also why customers should resist the comforting notion that outages are somebody else’s problem once workloads move to the cloud. Provider-side mistakes remain real, but customer architectures are increasingly entangled with provider networking, identity, observability, and platform services. When an outage occurs, the customer may not have caused it, but they still bear the business impact. The shared responsibility model does not end with security. It extends to resilience planning as well.

Better change management

The Uptime data points to a clear conclusion: Cloud providers need to treat operational discipline as a first-class design requirement. That starts with better change management. High-risk changes should be tested more aggressively, staged more gradually, and accompanied by stronger rollback mechanisms. Providers also need better dependency mapping to understand how a change in one control layer can affect services far beyond its immediate scope. If the system is too complex to clearly explain, it is too complex to operate.

Providers also need to improve procedural quality. The rise in outages caused by failing to follow procedures suggests that procedures are being ignored under operational pressure or that they are too cumbersome, outdated, or unclear for real production conditions. Neither explanation is comforting. Stronger runbooks, better training, more realistic failure drills, and tighter operational guardrails are not glamorous investments; they are increasingly central to resilience.

Another pressure point is visibility. Uptime notes that software-based and distributed resiliency tools can improve availability, but they also introduce new risks and complicate root-cause analysis. Cloud providers need more transparent and faster incident diagnosis, not just more layers of abstraction. Customers cannot build trust in resilience if every major incident becomes a long exercise in reconstructing opaque service dependencies after the fact.

Design with outages in mind

What’s the financial impact of more frequent problems? Uptime’s 2024 analysis found that 54% of respondents reported that their most recent significant outage cost more than $100,000, and 20% said it cost more than $1 million. These are not edge-case losses. They show that outages remain costly even if they are less frequent than in earlier years.

Customers need to stop evaluating cloud resilience through uptime promises and start evaluating it through failure behavior. How does a provider isolate faults? How transparent is incident communication? How portable are workloads if a major service degrades? How dependent is the architecture on a single region, network path, identity service, or control plane? These are not just technical questions; they are now critical business questions.

The core lesson from Uptime’s data is simple. Outages are becoming a bigger problem for cloud providers and customers because the cloud’s biggest vulnerabilities are increasingly tied to complexity, process failures, and control-plane mistakes, not just broken infrastructure. In addition to adding redundancy, the next phase of cloud improvement will focus on building systems that are easier to understand, safer to change, and more disciplined to operate.