Saurabh Gupta: Why AI Projects Fail to Scale—and How to Fix It
The AI demo worked.
The model produced convincing answers. The pilot impressed executives. The use case looked commercially defensible. Funding followed.
Then the organization tried to scale it.
Suddenly the system needed information from five departments. Definitions conflicted. Permissions became complicated. Nobody could confidently explain where a number came from. Context that had existed implicitly inside one team disappeared when the system crossed organizational boundaries.
The AI did not necessarily get worse.
The environment around it became real.
That distinction may explain one of the defining contradictions of enterprise AI today. McKinsey found in 2025 that 88% of surveyed organizations were regularly using AI somewhere, yet approximately two-thirds had still not begun scaling it across the enterprise. Only 39% reported any enterprise-level EBIT impact from AI.
Saurabh Gupta believes many companies diagnose this problem incorrectly.
“Bad data leads to bad AI,” he says.
It sounds simple. Its implications are not.
Why Do AI Projects Work in Pilots but Fail at Scale?
A pilot is controlled.
Enterprise operations are not.
A team building a proof of concept can carefully choose the dataset, define the problem, supervise outputs and compensate manually for imperfections. Scaling removes many of those protections.
The AI now encounters data created by different departments, software generations and business processes. Definitions may differ. Ownership may be unclear. Information may be incomplete, inaccessible or poorly documented.
And advanced AI needs more than technically correct data. It increasingly needs context: what a value represents, where it originated, how it relates to other information, what rules govern its use and whether the system is authorized to act on it.
That is becoming a mainstream enterprise concern. Gartner reported in 2026 that more than 75% of organizations were prioritizing investment in AI-ready data. Its guidance emphasizes metadata, semantics, governance and use-case-specific readiness rather than assuming that one universally “clean” dataset can support every AI application.
Accenture’s 2026 research reached a similarly uncomfortable conclusion: 72% of surveyed organizations did not yet have trusted data of sufficient quality combined with standardized governance to support advanced AI at scale.
The scaling problem, then, is not simply how to deploy more AI.
It is how to create an environment in which AI can reliably understand and use enterprise information.
Are Companies Solving an AI Problem With More Technology?
Gupta has spent roughly three decades inside complex data environments, beginning with the World Bank, followed by the International Monetary Fund, the Washington, DC government and Thoughtworks before joining The Modern Data Company. Across those environments, he says he repeatedly encountered the same pattern: long implementation cycles, many specialized tools and attention drifting from the outcome toward the infrastructure.
That history explains one of his strongest criticisms of enterprise AI programs:
“People are not focusing on outcomes, people are focusing on technologies.”
This is an especially dangerous habit in AI because the technical menu is almost unlimited.
A company can add another model, vector database, orchestration layer, data-quality product, governance application, integration platform or observability tool. Each component may be excellent individually.
The question executives need to ask is different:
What business outcome requires all of this?
Gupta describes enterprise data environments in which organizations may assemble 10 or 12 specialized products before they can even begin delivering use cases. Each additional component creates integration work, maintenance requirements and another specialized skill set.
Technology designed to create leverage can therefore create its own organizational drag.
What Changes When You Start With the Outcome?
One customer example from Gupta’s interview illustrates the alternative.
A large consumer-products manufacturer had accumulated substantial telemetry data but struggled to turn it into useful business outcomes, including reducing losses related to warranty claims. Its contemplated data-foundation effort was measured in multiple quarters.
Gupta says his team delivered the supporting platform and first use case in less than one quarter. The bigger benefit, in his telling, was not simply speed. It was that the organization could see what was possible quickly enough to experiment and learn before committing itself to a long infrastructure program.
That principle deserves attention far beyond one vendor or architecture.
Instead of asking: What data should we centralize?
an organization can ask:
What outcome are we trying to produce, and what is the minimum trustworthy data required to produce it?
Gupta calls this right-to-left thinking.
His formulation is refreshingly restrained:
“Bring only the minimum data that you need to solve a problem.”
Once that use case works, additional data can be introduced as adjacent problems emerge.
This reverses the instinct to spend years creating an idealized enterprise data environment before producing business value.
Interestingly, KPMG’s 2026 AI-ready data roadmap recommends essentially the same direction: begin with a priority AI outcome and work backward toward the data, context, governance and operating model needed to support it.
Why Context Is Becoming as Important as Data Quality
Traditional data programs often focus on whether information is accurate, complete and consistent.
AI introduces another question:
Does the system understand what the information means?
A number without business context is only a number.
A customer field without ownership, provenance and access rules may be dangerous.
A perfectly accurate document may still be irrelevant to the task being performed.
As AI systems become increasingly agentic—moving from generating answers toward taking actions—the stakes increase further. McKinsey notes that agentic AI places greater operational pressure on data lineage, traceability, access control and the preservation of context across fragmented enterprise systems.
This is why Gupta’s conception of a data product extends beyond a database table or dashboard. He describes it as a package that can include data, metadata, transformation logic, quality controls, governance, lineage and infrastructure definitions.
Whether or not an organization adopts that exact architecture, the strategic principle is valuable:
Context should travel with the data.
AI needs to know not merely what information exists, but how it should be interpreted and what boundaries apply to its use.
Data Alone Will Not Fix Enterprise AI
There is an important caution here.
It would be tempting to replace one oversimplification with another and conclude that every AI scaling failure is really a data failure.
The evidence does not support that.
McKinsey’s research identifies workflow redesign as one of the strongest differentiators of organizations producing meaningful value from AI. Governance, leadership, KPI tracking, adoption practices and organizational change matter as well.
MIT CISR’s enterprise AI maturity research reaches a related conclusion: the largest financial improvement appears when organizations move beyond building pilots and capabilities into a stage where they establish scaled AI ways of working.
The model matters.
The workflow matters.
The people matter.
Governance matters.
But none of them can reliably compensate for data the organization cannot find, interpret, trust or govern.
What Should Leaders Do Before Funding the Next AI Pilot?
Before commissioning another model or adding another AI platform, leadership teams can ask five questions:
What measurable business outcome are we trying to create?
What is the minimum data required to test that outcome?
Can the system understand the context and provenance of that data?
Are quality, permissions and governance embedded into the workflow?
If the pilot succeeds, what changes when 100 people—or 10,000—use it?
The final question may be the most important.
A proof of concept demonstrates that something can work.
Enterprise architecture must demonstrate that it can continue working when the controlled conditions disappear.
Gupta explored this challenge on 21st Century Entrepreneurship through the lens of a career spent inside large data systems and the companies now trying to make AI useful on top of them.
His argument can be reduced to one principle worth carrying into the next strategy meeting:
Do not scale the technology faster than you can scale the conditions that make the technology trustworthy.
This week, choose one active AI initiative and work backward from its intended business outcome. Identify every dataset, definition, permission, owner and decision rule the system depends on.
The gaps you discover may tell you more about your readiness for AI than another demonstration ever will.
Comments