.png){kind=logo}
According to a Gartner survey of 782 infrastructure and operations leaders published in April 2026, only 28% of AI use cases in I&O fully succeed and meet ROI expectations, while 20% fail outright. Thirty-eight per cent of leaders who faced setbacks cited poor data quality or limited data availability as a direct cause. The conclusion increasingly shared across the industry is that the root of most AI failures lies not in the quality of the model itself, but in the underlying level of data and infrastructure. Few practitioners understand this from the inside as clearly as Sushrutha Sreevathsa, a Service Reliability Engineer at Yahoo, where he supports platforms serving more than 200 million daily users. A member of the D2A2 Council — an exclusive thought leadership group in Digital, Data, Analytics, and AI — and a contributing author to the AWS Marketplace publication Build Strong Data Foundations for Agentic Analytics and Intelligent Agents, Sreevathsa recently received the Cases & Faces International Business Award for Achievement in Product Innovation in the Data Analytics & Big Data category. We spoke with him about why enterprise AI keeps stalling, and what it actually takes to build the foundations that make it work.
Sushrutha, the statistics on enterprise AI are striking: near-universal adoption and massive investment show very limited measurable returns. From your vantage point, working inside a global technology company, does the picture on the ground match what the reports describe?
Yes, broadly. What I see across the industry matches what the research is pointing to: the adoption numbers are real, but the value is often not following. Part of that is because a lot of organisations are measuring the wrong thing. They track how many teams are using an AI tool, or how many dashboards have been built, and conclude that adoption is working. But adoption does not necessarily mean impact. The more honest question is: are decisions actually changing because of this data? And in many cases, the answer is no — because the underlying data is not in a state where people trust it enough to act on it.
What I have found while working across infrastructure that supports more than 200 million daily users is that the failure point almost always comes before the AI layer. Teams are generating enormous volumes of operational data, but when different parts of the organisation use different definitions, baselines, and reporting views, the AI ends up amplifying disagreement rather than resolving it — a sophisticated tool sitting on top of an unresolved problem.
When an AI project stalls or gets abandoned after proof of concept, what is usually actually broken — is it the model, the tooling, or something further upstream?
Almost always something upstream. I have seen AI projects stall across different contexts, and the model is rarely the issue. What is broken is usually one of three things: the data is not clean or consistent enough to be trusted, there is no clear ownership of what the data is supposed to mean, or the business question the AI is supposed to answer was never properly defined in the first place. The tooling conversation tends to happen early and loudly, because tools are visible and purchasable. The data foundation conversation is a lot less exciting to have in a board presentation — but it is the one that actually determines whether the project delivers measurable results.
Your chapter in the AWS Marketplace book introduces what you describe as a Connected Intelligence Operating Model — an original framework that integrates six elements often managed in isolation: business decisions, data products, AI models, governance, human judgment, and feedback loops. What gap does bringing those six elements together actually close for an enterprise trying to deploy an AI solution?
Connected intelligence means that AI-enabled decision-making requires more than aggregating data from different sources. It requires building a coherent, governed layer where technical, operational, and business signals are all speaking the same consistent language. When a leadership team looks at a dashboard, every number should have a clear, agreed-upon meaning, and every person in the room should be working from the same version of reality.
That is what "connected" means — and the "intelligence" part follows from it. Once you have data that people actually trust, you can build AI systems that augment decisions rather than generate outputs that then get questioned, debated, or ignored. A lot of organisations go straight to the model, discover that the outputs are not credible, and conclude that the AI did not work. In reality, it just lacked the coherent data layer beneath it. That coherence needs to be established before anything gets built — you cannot govern your way out of a definition problem after the fact.
Your work on the SRE analytics data product at Yahoo, earned the Cases & Faces Award for Product Innovation in 2026 — a recognition given to leaders across industries for commercially significant innovation. The project itself seems to be exactly the connected intelligence problem in practice. What did it actually look like to get teams aligned on a shared version of operational reality inside a company the size of Yahoo?
When every team has its own reporting view, and those views have been in place for a while, people become attached to their version of the numbers. There is usually a legitimate reason why a particular team measures something the way they do, but when the goal is to give leadership a single, reliable picture of what is happening across the organisation, those differences become a problem. To address it, I had to go upstream of the dashboards entirely — asking what exactly we were measuring, what it meant, and who was responsible for it. Once we had agreement on that, the technical work of building curated datasets and standardising reporting inputs became far more manageable. The product that resulted was not valuable because it was technically sophisticated. It was valuable because when leadership looked at it, they could make decisions without first spending time questioning whether the underlying data was right.
You describe the data trust problem as partly a definitions problem — one that arises when teams use the same words to mean different things. How do you actually solve that in a large organisation where different teams have legitimate reasons for measuring things differently?
You do not always aim to eliminate the differences. More often, you make them explicit and agree on what the canonical version is for a specific purpose. Different teams will always have legitimate reasons for tracking things differently at a local level, and that is fine. The problem comes when those local definitions get treated as interchangeable inputs into a shared system. What works is separating the two layers clearly: you can keep your local metrics for your local operations, but here is the agreed definition that feeds the shared view, and here is who owns maintaining it. That ownership piece is critical. Definitions drift when nobody is accountable for keeping them stable. Once you assign clear ownership and document it, you have something that can be maintained and audited rather than argued over every quarter.
You’ve played a leading operational role in Yahoo’s RevMon initiative, the only system within Yahoo providing real-time revenue visibility across its advertising platforms — a business-critical function built around a follow-the-sun model that keeps coverage continuous across time zones, detecting approximately $3 to $6 million in potential revenue exposure every quarter. How much of that capability came down to the monitoring itself, and how much was about finally having data that did not need to be argued over before someone could act?
A significant part of it was the trust. The monitoring infrastructure was important — without real-time visibility into what was happening across Yahoo's ad delivery systems, you simply could not catch revenue-impacting incidents fast enough. But what prevented losses was not the monitoring alone. It was the ability to act immediately when something surfaced — and that became possible because everyone was looking at the same data and could act on it without spending time on additional confirmation. Before the operational data was in a reliable state, there was always a validation step: teams would first confirm whether the signal was accurate before escalating, and that delay has a cost. What RevMon changed was that the data underpinning the monitoring was trusted enough that teams could move directly to response. The protection of that revenue exposure reflects faster, more decisive incident management across global teams.
Most advertising platforms run monitoring and incident response as parallel but disconnected workflows: while anomalies get flagged, but triage, escalation, and cross-functional accountability tend to happen in separate systems, if they happen at all. You helped build a unique coordinated approach at Yahoo that treats abnormal business metrics as operational risks from the moment they appear, rather than as data points to be reviewed later. How did connecting those pieces change what the organisation could actually do when something went wrong?
The core shift was in how the organization treated a business metric anomaly when it surfaced. In most environments, an unusual number in a revenue dashboard triggers a reporting workflow where it gets noted, logged, and may or may not prompt action depending on how serious it appears. What we built treats that same anomaly as the start of an operational response: there is a defined triage process, a clear escalation path, and accountability distributed across the teams who need to act.
In practice that meant Production Engineers, Incident Managers, Account Managers, and AdTech operations teams were all working from the same coordinated model rather than responding to the same event through separate channels. The process became continuous and structured, and because it operated across time zones through the follow-the-sun model, the response capability did not depend on who happened to be online when something surfaced. The broader implication for digital advertising platforms generally is that revenue integrity cannot be protected by passive monitoring alone. Any platform running at scale needs a process that treats metric anomalies as operational risks from the moment they appear, with the triage and cross-functional accountability already in place to act at speed.
You sit on the D2A2 Council, which brings together leaders across Digital, Data, Analytics, and AI. From those conversations, what separates the organisations that are actually getting value from AI from the majority that are not?
The organisations getting real value share a few characteristics that have more to do with discipline than with the specific tools they have bought. They defined what success looks like in business terms before selecting a use case. They treated data as a product — with owners, SLAs, and governance — rather than as an output of their systems. And they built the data foundation before running the pilot, rather than assuming the foundation was good enough and discovering three months in that it was not.
The advice I would give to any enterprise sitting on a stalled initiative is to go back to the data before going back to the model. Not to run another audit, but to ask one specific question: do the people who are supposed to act on this AI output actually trust the data it is drawing from? If the answer is anything other than an unambiguous yes, that is where the work needs to happen. It is slower and less visible than running another proof of concept — but it is the only path to something that holds up in production.
