From Pilots to Platforms: Industrialising Enterprise AI

The industry number is by now familiar: somewhere between 70 and 90 percent of enterprise AI initiatives never make it past a proof of concept. Every consulting firm has a version of this figure. What none of them explain well is why the second pilot in a given enterprise fails for exactly the same reason as the first, even when the technology, the vendor, and the sponsor are different.

The reason is that pilots are almost never technical problems. They are organizational, architectural, and financial problems in a technical costume.

A pilot succeeds when a small, motivated team builds something impressive on a curated slice of data, presents it to sponsors, and everyone claps. A pilot fails to scale when that same team is asked to make the thing work for 40 business units, on live data, with proper access controls, an on-call rotation, a procurement-approved model provider, and a finance-approved cost model. That is a different problem, and no amount of iterating on the pilot solves it.

The organisations that break out of the pilot loop stop treating each initiative as a project and start treating the underlying capabilities as a platform. Not a platform in the vendor-marketing sense — a real internal product with an owner, a roadmap, and internal customers who can complain when it breaks.

There are four capabilities that platform, whatever else you call it, needs to provide.

The first is a shared data foundation. Not a single data lake — most enterprises tried that in the 2010s and it did not work — but a set of well-governed, well-documented product data domains that AI teams can access through a consistent contract. If every new AI use case has to negotiate access to customer, transaction, or product data from scratch, you will run out of legal and platform capacity before you run out of ideas. The bottleneck in enterprise AI right now is rarely models. It is trusted, permissioned data.

The second is an evaluated model gateway. A single control plane through which every application in the enterprise consumes language models, embeddings, and speech services — regardless of provider. The gateway does four things: it enforces access policy, it logs every request for audit and cost attribution, it caches where appropriate, and it fails over between providers when one has an outage. Without it, you get 15 teams each holding a separate API key, no view of spend, no view of usage patterns, and no ability to switch providers when your preferred model changes its pricing or its terms.

The third is reusable agent scaffolding. Once you have more than three or four agentic use cases, the shape of the work rhymes: a supervisor loop, a set of tools, a retrieval layer, an evaluation harness, a policy check, an audit trail. Building this once as a platform capability and letting product teams compose against it is the difference between six-week and six-month delivery. It is also the difference between one governance model and 15.

The fourth is a value-tracking layer that finance teams trust. This is the one most technology teams underinvest in, and it is the one that decides whether the platform survives its second budget cycle. For every use case, you need a documented baseline (what did this work cost and take before the AI?), a documented current state (what does it cost and take now, including the AI infrastructure?), and a documented attribution model (how much of the delta do we credit to the AI versus other changes?). If your CFO's team cannot audit that on demand, your AI investment is politically fragile no matter how well it performs.

Those four capabilities are what an AI platform is. Everything else — the choice of orchestration framework, the vector database, the model provider — is an implementation detail that will change three times over the next five years. Build the platform so those changes are contained, not disruptive.

The organisational question is who owns this platform. The answer that works is a small dedicated team, sitting under the CTO or CDO, staffed with a mix of infrastructure engineers, ML engineers, and one product manager who is unusually good at saying no. This team's customer is the rest of the technology organization, and its measure of success is the time and cost for a business unit to get a new AI use case into production. If that number is going down quarter over quarter, the platform is working. If it is not, no amount of use-case delivery will compensate.

The financial question is how to fund it. Platforms are notoriously hard to fund via project accounting, because their benefit is diffuse. The pattern we see working is a two-part model: the platform is funded centrally as core infrastructure, at a level indexed to the number of production use cases it supports; and individual use cases are funded by the business units that own them, at a marginal cost that reflects only their variable consumption. This makes the shared cost visible and the marginal cost cheap, which is exactly the incentive structure that encourages more use cases.

The cultural question is the hardest. Most enterprise technology organizations are still structured around project delivery. Platform work does not fit that shape. It requires product thinking, long horizons, and comfort with the fact that success looks like other teams shipping quickly, not like your own team shipping visibly. Executives who reward the flashy pilot over the boring platform will get exactly the outcome that ratio predicts.

One last observation, because it comes up in every engagement. The teams that succeed at this transition almost always started with one honest pilot that failed to scale, learned the right lesson from it, and used that lesson to secure a platform mandate. The teams that fail keep launching more pilots, each with a slightly different technology stack, hoping the next one will be the one that generalizes. It will not. The generalization has to be built deliberately, and it has to be somebody's full-time job.