Enterprise AI has an adoption paradox. McKinsey’s 2025 global survey found that 88% of organisations now use AI in at least one business function, yet nearly two thirds have not begun scaling it across the enterprise, and only 39% report any earnings impact at all. The technology clearly works in a demo. Turning that into something the whole business actually runs on is where it tends to stall.
Having spent a decade building high-scale product platforms, and now working on the developer infrastructure that enterprises use to integrate AI, I keep seeing the same failure underneath that statistic. The stall almost never happens at the model layer. It happens at integration, where most organisations treat every AI feature as a standalone project and quietly rebuild the same plumbing again and again.
The pattern behind stalled pilots
Walk into a typical enterprise eighteen months into its AI programme and you will find a familiar shape. The recommendations team has embedded model calls directly into its service, with its own retry logic and its own way of swallowing errors. The support team has done the same, differently. So has the document-processing team, and none of the three shares a contract for error handling, latency budgeting, cost attribution or output evaluation.
Each of these worked fine as a pilot, because a pilot can get away with being fragile in a way that production cannot. When a provider has a slow day, three teams discover three different failure behaviours, none of them designed. When finance asks what AI actually costs per feature, nobody can answer, because spend was never attributed. When output quality drifts, no shared evaluation hook exists to catch it, and the people who notice first tend to be your customers.
This is the reason pilots stall instead of spreading across the organisation. The second team cannot build on what the first team learned, because what the first team built is welded inside one service.
A familiar platform problem
Anyone who has run an engineering organisation for a while has watched a version of this before. The pre-AI version was teams independently standing up their own deployment pipelines, their own logging and their own infrastructure glue, piling up divergent technical debt until someone finally funded a platform team to clean it up. The industry response was platform engineering as a discipline: Gartner has forecast that by 2026, 80% of large software engineering organisations will run platform teams as internal providers of reusable services, up from 45% in 2022.
AI integration is repeating the cycle, only faster and with a more volatile dependency. Model APIs are probabilistic, their latency varies by an order of magnitude with load and prompt size, their costs are metered per token, and you have to evaluate their output rather than just trust it. All of that calls for more shared infrastructure than an ordinary dependency would, and yet it usually gets less.
The result is a missing layer in the stack. Companies pay for model access and they pay for the applications built on top, but the connecting layer in between rarely has an owner.
What a shared integration layer provides
None of this is glamorous work. It gives you consistent retry and timeout behaviour, so how a feature fails is a platform decision and not a per-team accident. Cost is attributed to every team and feature by default, so finance conversations start from data instead of guesswork, and it watches latency and output quality for degradation, flagging problems within minutes. And because it exposes the same evaluation hooks to everyone, every team measures quality the same way, behind an interface a new team can pick up in a day or two.
The research now backs the intuition. The 2025 DORA report, drawing on nearly 5,000 technology professionals, concluded that AI acts as an amplifier of existing organisational strengths and weaknesses, and that quality internal platforms are what convert individual AI productivity gains into organisational performance. Teams with strong platforms compound their AI investment. The ones without end up with a scatter of local wins that never add up to much.
Put another way, how fast AI spreads through an organisation depends on the quality of the interface sitting above the model layer. Clear contracts, predictable failure modes and easy onboarding deserve the same attention most organisations currently spend on choosing a model.
Lessons from a shared platform programme
Earlier in my career, at a consumer marketplace serving tens of millions of users, I watched this dynamic play out before AI was involved. Multiple teams were building discovery surfaces, and each was solving the same problems of data fetching, layout and experimentation from scratch. We co-developed a shared discovery SDK with an explicit contract and opinionated defaults, and the first major product built on it shipped in nine weeks against an original estimate of eighteen, with no launch incidents.
The more useful lesson came later. Because that first project pushed the platform hard, it surfaced fixes that made every team after it faster, and the SDK spread because using it was simply easier than the alternative, not because anyone forced teams onto it. We took the same approach to reliability: service-level contracts with the teams we depended on, plus observability that cut degradation detection from hours to minutes, so keeping performance healthy stopped being a heroic effort and became routine.
AI integration responds to the same treatment. The teams I see shipping AI reliably are the ones whose platform made the reliable way to build also the easiest one.
Practical steps for engineering leaders
Start by treating your first three AI integrations as platform discovery rather than as three isolated deliveries. Assign a small team to own the integration layer as a product, with internal developers as its customers and onboarding time as its headline metric. Define the minimum contract early, covering retries, timeouts, fallbacks, cost tagging and evaluation hooks, and resist the temptation to expose raw API access with no platform opinion on top.
Then measure propagation, because that is the number the McKinsey gap is made of. If your second AI feature was cheaper and faster to ship than your first, the layer is working. If every feature costs the same as the last one, you are running serial pilots, and you will hit the same plateau everyone else does.
