Worldwide AI spending reached $2.59 trillion in 2026, up 47% from the prior year. Every major technology company is investing at record levels. Enterprise AI budgets have expanded significantly across every sector. 88% of organisations report using AI regularly.

Only 33% have begun scaling AI enterprise-wide.

That number comes from McKinsey's State of AI 2026 report, which surveyed organisations across industries and geographies on the state of their AI programmes. The finding is consistent with Gartner's parallel research, which identified scaling as the primary AI challenge for enterprise leadership teams in 2026, ahead of talent, technology selection, and cost.

The gap between the 88% using AI and the 33% scaling it is not explained by access to technology or size of investment. The organisations in the 33% are not outspending the others. They are not using fundamentally more sophisticated models. They are doing something structurally different in how they approach AI programmes, and the data is now specific enough to describe what that is.

What Scaling Actually Means

Before examining why scaling fails, it is worth being precise about what scaling means in this context, because the term is used loosely in ways that obscure the actual challenge.

Using AI is not scaling AI. An organisation where individual teams have adopted AI tools, where specific workflows have been augmented with AI assistance, and where pilots have demonstrated capability in controlled environments is using AI. It is not scaling AI.

Scaling AI means extending AI from isolated deployments into the core operational processes of the business, across functions and geographies, with consistent governance, integrated data infrastructure, and accountability for outcomes at the business level. It means the third and fourth deployment is happening faster than the first and second. It means AI outcomes are measured in the same business metrics as any other operational investment. It means the organisation is building compounding capability rather than accumulating a collection of disconnected pilots.

By this definition, 33% scaling is not a pessimistic reading of where enterprise AI is. It is an accurate one. Most organisations have AI activity. Very few have AI infrastructure.

The Four Structural Reasons Scaling Stalls

1. Operating model inertia

The single most consistent barrier to AI scaling is not technology. It is the operating model that AI needs to scale into.

Most large enterprises are organised around functional structures — procurement, finance, operations, service, sales — where each function owns its data, its processes, and its performance metrics. AI deployments within these structures improve individual functions. AI that needs to scale across them faces the functional boundaries as friction at every step.

An AI agent that monitors supply chain signals and triggers procurement actions needs to operate across the supply chain function and the procurement function simultaneously. An AI system that connects dealer performance data to sales incentive decisions needs to cross the commercial and the finance functions. The operating model that made sense when work was primarily human becomes the primary obstacle when AI is trying to coordinate across it.

The 33% who are scaling have made deliberate operating model changes that allow AI to operate across functional boundaries rather than within them. They have not reorganised their entire enterprise. They have identified the specific cross-functional processes where AI creates the most value and redesigned those processes around AI rather than constraining AI to fit the existing process structure.

This is the same transition described in the AI-native versus AI-enabled distinction. AI-enabled organisations add AI to existing structures. AI-native organisations redesign structures around AI. Scaling requires the second, not the first.

2. Data foundation gaps that compound at scale

A pilot can be run on clean, curated data. Scaling requires AI to operate on the full breadth of operational data that the enterprise generates — which includes the inconsistent, incomplete, and fragmented data that exists in every large organisation's real systems.

McKinsey's research identifies data infrastructure as the second most commonly cited barrier to scaling, cited by 44% of organisations that have stalled between pilot and enterprise-wide deployment. The specific problems are consistent across industries: data quality issues that produce unreliable AI outputs at scale, data fragmentation across systems that prevents AI from accessing the full context it needs to make good decisions, and data governance gaps that create compliance exposure when AI is operating across the enterprise rather than in a controlled pilot environment.

The organisations scaling AI successfully have treated data infrastructure as the prerequisite for scaling, not as a parallel workstream. They invested in unified data layers, consistent data quality standards, and real-time data availability before attempting to scale AI programmes that depend on those foundations. This investment is unglamorous and does not produce visible AI outputs. It is consistently the work that separates organisations that can scale from those that cannot.

For enterprises running AI alongside legacy ERP systems, this infrastructure work is the difference between AI that operates on the enterprise's actual data in real time and AI that operates on a subset of it processed through batch pipelines that introduce latency and quality gaps.

3. Accountability that ends at deployment

The third structural barrier is ownership. Specifically, the absence of clear accountability for AI outcomes at the business level rather than the technology level.

In most organisations that have stalled at pilot scale, AI is owned by the technology function. The technology team is accountable for deploying AI. Business functions are accountable for their own performance metrics. Nobody is accountable for the line between what the AI does and what the business achieves.

This accountability gap produces a consistent failure pattern. The technology team declares the deployment successful when the system is live. The business function does not change how it operates because the AI has been added alongside existing processes rather than embedded in them. The AI generates outputs that nobody is accountable for acting on. The system is technically live and operationally irrelevant.

The organisations scaling AI have closed this accountability gap by making AI outcomes a shared metric between the technology function that maintains the AI systems and the business function that acts on them. This shared accountability structure is one of the clearest differentiators between organisations seeing revenue outcomes from AI and those seeing only activity metrics.

Scaling requires this accountability to be established before the second deployment, not discovered as a gap during the third.

4. Delivery models that cannot navigate production complexity

The fourth barrier is the delivery model used to build and deploy AI systems. This is the barrier that receives the least attention in scaling discussions and has the most direct impact on whether AI reaches production at the required quality and speed.

Pilot-stage AI deployments are typically run with access to curated data, defined scope, and controlled conditions that allow rapid demonstration of capability. Production-scale AI deployments involve the full complexity of the enterprise's actual operating environment: the ERP customisations that no specification document fully captures, the data quality issues that only appear at production transaction volumes, the compliance requirements that apply in practice but not always in policy, and the organisational dynamics that determine whether deployed AI actually gets used.

Delivery models that are not designed to navigate this complexity produce AI that works in a pilot environment and fails or underperforms in production. The cost of this failure compounds as organisations attempt to scale: each new deployment hits similar integration barriers, each requires similar remediation work, and the scaling momentum that should be building from the first deployment's learnings does not materialise because those learnings are not being captured and applied.

The delivery model that consistently closes this gap is forward deployed engineering: engineers embedded inside the client's actual operating environment, building against real systems and data, staying accountable through to genuine production adoption. The FDE feedback loop that builds across multiple deployments is precisely the mechanism that converts isolated AI success into scaling momentum.

What the 33% Are Actually Doing Differently

The McKinsey research identifies several characteristics that consistently appear in organisations that are scaling AI rather than accumulating pilots.

They treat AI as a programme rather than a collection of projects. Each deployment is designed to build on the previous one, with explicit knowledge transfer, reusable infrastructure components, and governance frameworks that extend rather than restart with each new initiative. The second deployment is faster than the first. The fifth is significantly faster than the second. This compounding dynamic is what distinguishes a scaling programme from a collection of successful pilots.

They measure AI against business outcomes from the first deployment. Not from the point when scaling begins, but from the first production deployment. Organisations that establish outcome-based measurement early develop the feedback loops that reveal what is working and what is not before they attempt to scale. Organisations that establish outcome measurement only when scaling is underway are scaling without the data they need to do it correctly.

They invest in the infrastructure that enables scale before they need it. Unified data layers, AI governance frameworks, integration standards, and the organisational capability to run AI programmes — these are investments that pay off at the second and third deployment, not the first. The organisations that make them early appear to be over-investing relative to their current AI footprint. At scale, they appear to have been exactly right.

They select deployment partners based on production capability rather than pilot capability. The partner that produces the best pilot is not necessarily the partner that can deliver the production deployments required for scaling. Evaluating partners on the basis of demonstrated production outcomes in comparable environments, rather than on demo quality or methodology, is one of the most consequential decisions in building a scaling programme.

The Compounding Advantage of Scaling

The 33% who are scaling AI are not just getting better outcomes on current initiatives. They are building a structural advantage that compounds over time.

Each production deployment generates operational knowledge about how AI works inside that specific enterprise environment. That knowledge, captured and applied systematically, makes subsequent deployments faster and more reliable. The data infrastructure built for the first deployment serves the second. The governance framework established for the regulated deployment applies to the next one. The organisational capability developed through the first several deployments accelerates every initiative that follows.

The 67% who are still accumulating pilots are not standing still. They are generating costs — of pilots that do not reach production, of integration work that gets repeated because the learnings from the previous attempt were not captured, of organisational attention that cycles through AI initiatives without building the compounding capability that scaling requires.

The gap between the 33% and the 67% is not going to close by the 67% spending more on AI. It will close, if it closes, by the 67% making the structural changes that allow AI to scale: operating model redesign, data infrastructure investment, accountability restructuring, and delivery model selection based on production capability rather than pilot performance.

Those are organisational decisions, not technology decisions. And they are available to every enterprise that is willing to make them.

Vishleshan AI's forward deployed engineers work inside client environments across automotive, FMEG, financial services, and supply chain, building the production deployments and the compounding infrastructure that converts AI adoption into AI scale. Book a Consultation