AI Platform Strategy

In 2024, Google’s DORA research program, which studies how technology teams deliver software, compared people who use an internal developer platform with people who do not. The platform users reported 8 percent higher individual productivity, and their teams 10 percent higher performance. Yet the same users saw delivery throughput fall by about 8 percent and change stability by 14 percent¹.

DORA studies the platforms software teams use to build and run applications, not AI platforms as such, and its figures are survey associations rather than controlled experiments. The two pairs of figures also measure different things. Productivity and team performance are how respondents rated their own work; throughput and change stability describe what their delivery pipelines actually produced. But an enterprise AI platform is the same idea applied to AI, and the lesson carries over. A platform is not good because it exists. Whether it creates value depends on what is in it, how it was built and whether the people meant to use it are better off.

The platform’s only job is leverage

An enterprise AI platform is a set of reusable capabilities that lets many teams build, test, secure, run and monitor AI solutions without rebuilding the foundations each time. Its purpose is leverage: faster delivery, less duplicated work, stronger control and an easier path to scale. It is a means, not an achievement in its own right.

Two failures sit on either side of that purpose. At one end, every team builds alone. Each moves quickly at first, and the enterprise pays for the same foundations again and again, with a different security review, vendor contract and definition of quality each time. At the other end sits the grand platform: one central program that tries to anticipate every future need and, in practice, serves very few present ones.

The working answer sits between them: build the smallest shared platform that creates meaningful leverage, and let it grow as demand repeats. Centralized vs Federated AI placed the platform at the hub and the decisions about value in the spokes, and introduced Matthew Skelton and Manuel Pais’s idea of the thinnest platform that does the job². This chapter is about what that platform should contain, in what order, and how to tell whether it is working.

Four words that get confused

Platform debates go wrong when four different things share one vocabulary. Infrastructure is compute, storage, networks and databases. Every technology needs it, and most of it already exists in a large company. The AI platform sits on top and adds what is specific to AI: access to models, search over company knowledge, quality testing, safety checks and a record of how AI is used. An application solves one business problem, such as a forecasting assistant for one product category. A product is something a user or customer chooses, judged by the outcome it delivers to them.

The distinction matters because the platform’s value is indirect. It never wins a customer by itself. It wins by making the next ten applications cheaper, faster and safer to build. Engineers at Google made the underlying point in 2015: in real machine-learning systems, only a small fraction of the work is the model code, and the infrastructure around it is vast and complex³. That surrounding work is exactly what a platform can do once instead of many times. Marco Iansiti and Karim Lakhani describe the same foundations as an AI factory, built from a data pipeline, algorithm development, an experimentation platform and software infrastructure, and argue that firms gain most when these foundations are shared rather than rebuilt in each unit⁴.

Eight capabilities to recognize

An executive does not need to design an AI platform, but should be able to recognize what a proposal contains and ask why each piece is there. Many proposals describe some version of eight capabilities.

Model access is one controlled doorway to several models, commercial, open or built in-house. It can send each task to a suitable model: a routine task to a cheaper one, hard reasoning to a stronger one, sensitive data only to an approved one. Enterprises increasingly need that doorway: in a 2025 survey of 100 chief information officers by the venture firm Andreessen Horowitz, 37 percent were using five or more models⁵. A doorway reduces dependence on any single provider, but it does not remove lock-in; data, workflows and provider-specific features can still tie a company in.

Knowledge search finds the right company documents while respecting who may see them. Workflows and agents run multi-step work in production rather than in demonstrations, and are often built before anyone needs them. Quality testing gives every team one way to decide whether an AI answer is good enough, so that “it looked good in the demo” stops being the standard. Safety checks catch harmful output and data leaks in proportion to the risk. A usage and cost view shows who uses what, how well and at what cost. Identity and security should come from the company’s existing sign-in, access rights and audit, not from a separate security world. And builder templates make the right way to build also the easiest way.

Share the plumbing, keep the logic local

Once the capabilities are visible, the harder question is where each one lives. Good candidates to share are the plumbing: model access, identity and security, quality testing, the usage and cost view, and templates. What should stay with the business is the business itself: the rules, the domain workflow, the customer experience and the product decisions, all of which depend on context a central team does not have. As Centralized vs Federated AI showed, sharing also brings costs of coordination, compromise and inflexibility⁶, so the plumbing is worth sharing only where those costs are lower than the cost of rebuilding it.

One of the most useful platform decisions is what the platform will deliberately not provide. Without a written boundary, scope expands, complexity rises and delivery slows. A common breach is the AI platform quietly becoming the company’s data platform; data ownership and quality belong to data strategy, the subject of the next chapter.

Inside the boundary, a mature platform offers a recommended route from idea to running service. Spotify calls its version the Golden Path: an opinionated, supported way to build common kinds of software that teams may leave, though not with the same support⁷.

That last detail matters. A path that teams choose because it is easier tells the platform team that it fits; a path they are forced onto hides poor fit. Skelton and Pais make the same point: a platform should be a compelling internal product that teams want to use². The same route is also the natural place to build in controls, so that a safety check or an approval happens automatically rather than in a queue. Which controls, and at what thresholds, is a governance question for Module 07.

Let repeated demand build the platform

Many platform programs open with the question “which technologies should we build?” It is the wrong first question. The better sequence starts from strategy and the priority use cases in the portfolio, looks for the requirements that keep repeating across them, turns the repeated ones into shared capabilities, and lets the platform grow from those until it speeds up the next wave of use cases.

The working rule is simple. If one application needs a capability, it probably belongs in that application. If several need it, it probably belongs in the platform. There is one honest exception: security, control and visibility of use can justify sharing early, before reuse is broad, because the cost of getting them wrong in many places at once is high. A thin, shared layer of model access, identity and a usage view is often worth building in the first months for exactly that reason.

Platforms then tend to mature in stages: help for individual projects, then shared components, then self-service, then a standard enterprise platform. Building the last stage’s capabilities for an organization at the first stage is how platforms end up unused. Whether each piece is built, bought or taken from what the company already owns is the choice set out in Build vs Buy vs Partner.

Judge the platform as a product

A platform has customers, even if they are colleagues. It needs a product owner, a roadmap, service levels, documentation and a feedback loop, and its team should ask every quarter whether the teams it serves are better off because it exists.

The case for the investment is arithmetic about total effort. Take an illustrative example. Suppose twenty teams each need four months to build their own foundations: eighty team-months. Now suppose a shared platform takes fifteen team-months to build and each team then needs one month to connect to it. Fifteen plus twenty is thirty-five team-months for the same twenty solutions.

The same arithmetic shows the failure. If two teams use the platform instead of twenty, the shared version costs seventeen team-months against eight for building alone. Leverage is not in the design; it is in the adoption.

So measure outcomes, not output. Useful measures include time to the first production launch, components reused, duplicate tools retired, reliability, cost per request and how much of the company’s AI work is covered by shared quality tests. For the delivery side, the four measures popularized by Nicole Forsgren, Jez Humble and Gene Kim (lead time, deployment frequency, time to restore service and change failure rate) remain a common standard⁸. A platform that ships fifty services nobody uses has produced output. It has not produced leverage.

Story: GOV.UK Verify, a platform built ahead of its customers

One of the best-documented post-mortems of a shared platform built ahead of demand comes from a government, and its auditor. In 2011 British ministers agreed on a single, cross-government approach to proving who people are online, and in 2013 the Government Digital Service was approved to build it. The result, GOV.UK Verify, was meant to become the default way for citizens to prove their identity to any online public service, from claiming a tax refund to receiving benefits. Public trials began in October 2014⁹.

The 2016 business case set the targets: 25 million users by 2020 and 46 government services connected by March 2018, with costs of 212 million pounds and benefits of 873 million over four years. The technology largely delivered. In 2017 a government review called the platform “an innovative technical success” that was “performing to specification”, but added that it was “not producing the promised benefits, which rely on the large numbers of people signing up”⁹.

The customers had never been secured. Using Verify was not mandated at an early stage, so departments kept their own systems. The tax authority, HMRC, offered it alongside its own Government Gateway login, in part because Verify could not handle business customers or agents acting for others, and by 2019 only 4 percent of HMRC’s customers used it. The National Audit Office compared the pattern with an earlier shared-services program, where departments felt that “the central standardised solution offered did not meet their specific needs”⁹. The test of whether departments would commit came only in 2018, five years after approval to build. Of the three large departments asked, only the one whose Universal Credit benefit already depended on Verify committed, and only 38 percent of those claimants could verify their identity online.

By February 2019 Verify had 3.6 million users and 19 connected services, at least 11 of which could also be reached another way. Its verification success rate was 48 percent against a projected 90. The benefits estimate for the four years had fallen by 75 percent, and the government had announced that funding would stop in March 2020. The auditor singled out one piece as valuable: the document-checking service behind the scenes, which lets providers check passport and driving-licence data⁹. Summarizing a report by Parliament’s Public Accounts Committee, the Institute for Government put the cause plainly: the inability “to get buy-in from departments ultimately led to Verify’s failure”¹⁰. The service was reported closed in 2023, to be replaced by a new single login¹¹.

Two details make the case sharper for an AI platform. Identity is exactly the kind of capability this chapter says can justify sharing early, so sharing early was not the mistake; building it without customers whose needs it fitted was. And because Verify was optional, departments’ choices showed how poorly it fitted. A mandate could have hidden that, which is why mandated use is a poor measure of fit on any platform.

The venue, not the show

A concert venue is a useful picture of a healthy platform. A good venue provides what every act needs and no act should build for itself: the stage, the power, the sound rig, security and ticketing. Each act brings what makes it worth hearing: its songs, its set and its audience. Nobody wants the venue writing the music.

A venue is judged by how many acts want to book it and how quickly a show can load in, not by the size of its hall. And the failure everyone recognizes is the grand arena built before anyone booked a date. The picture has one limit, and it is instructive: an act can choose another venue, while an internal team often cannot choose another platform. That is why an AI platform has to earn its use instead of mandating it.

What this means for leaders

The first discipline is to ask for demand before design. When a platform proposal arrives, the opening question is not which technologies it includes but which funded use cases need each capability, and how many of them. A capability with one user belongs in that user’s application for now; a capability with several is a candidate for sharing.

The second is to fund a thin layer early and the rest on evidence. Secure model access, identity and a usage and cost view usually justify early sharing because they control risk and spending. Agent systems, elaborate knowledge services and custom tooling should wait for repeated demand.

The third is to give the platform customers and an owner. A named product owner, named internal customers and a regular feedback loop are what separate a platform from an infrastructure project. Mandated use is a warning sign, not a success measure.

The fourth is to change what gets reported. If the board hears how many services the platform team has delivered, it will get more services. If it hears time to first launch, reuse, duplicate tools retired and cost per request, it will get leverage.

Check yourself

1. An AI platform means everyone uses one standard model.MythFact
2. Having an internal platform reliably improves delivery.MythFact
3. If only one application needs a capability, it can usually stay inside that application.MythFact
4. Requiring every team to use the platform is the surest way to make it succeed.MythFact
5. A platform’s value is mostly indirect.MythFact
6. The number of services a platform team ships is a good measure of its success.MythFact

Reflection: who asked for it?

What comes next

Every capability in this chapter depends on what lies underneath it. A platform can only search, test and route the data the company makes available, in the condition it is in. That makes data, its ownership, quality and access, the next strategic choice. The next chapter, Data Strategy for AI, takes it up.