Design Principles for Embedding AI at Scale

Walk into most large organisations and you will find an AI graveyard. Not of failed technology, but of promising pilots that worked beautifully and then simply stopped, because the moment they needed to scale, the questions nobody had answered all arrived at once. Who owns this now? Who signs off the risk? Where does the money come from? What does success even look like? The technology was never the problem. The design choices were, and they were made, or avoided, long before delivery began.

The organisations that get past the graveyard are not the ones with better models. They are the ones that made a small number of deliberate decisions early. Six of them come up again and again.

The first is direction. Before an organisation reshapes anything, it needs an AI North Star: a clear view of how AI will change its position, how boldly it means to move, where it will concentrate, and where human judgement stays non-negotiable. Without it, every team optimises locally and the investment scatters.

The second is where capability lives. Central labs are wonderful for early experiments and hopeless at scaling, because the capability never leaves the building. The organisations that scale put AI where the work happens, owned by the product teams that ship it, on the normal delivery cadence rather than in a separate stream off to the side. It is not a new idea: Spotify, Capital One and Stitch Fix have all described data science as part of the product rather than a craft kept apart from it.

The third is safety, designed in rather than bolted on. Governance added after pilots reach production becomes debt. Built into the development lifecycle from the start, with risk appetite set by the kind of use case and controls written into pipelines rather than left as good intentions, it lets AI scale without a painful retrofit. HSBC holds its AI models to the same risk discipline as its other models; DBS Bank runs its PURE principles through real deployment gates; the UK Government publishes transparency records as a matter of course. Guardrails as infrastructure, not slideware.

The fourth is a paradox worth sitting with: build a central team whose job is to make itself redundant. A Centre of Enablement accelerates the early climb, holds things together and absorbs the experimental mess, then dissolves into the business as capability matures. The decisions that matter are its mandate, the reusable assets it leaves behind, and, most overlooked of all, the criteria for its own dissolution. Lloyds Banking Group, AstraZeneca and Walmart all run central enablement that feeds capability outward to the teams that own the outcomes.

The fifth is discipline about what gets funded. Most organisations have far more AI ideas than capacity, and the answer is portfolio management, not project management: one front door, honest prioritisation on impact and feasibility, a named executive sponsor with something at stake, and the nerve to stop things at defined checkpoints. John Lewis Partnership, Vodafone and HM Revenue and Customs all prioritise across their use cases rather than letting every function run its own parallel experiment.

The sixth ties the rest together: design for value from day one. Too many initiatives are funded on enthusiasm and judged on novelty. The alternative is to state the value hypothesis, the metric and the kill-or-scale criteria before delivery starts, release money as milestones are met, and stop what does not move. DBS Bank attributes a real value metric to its AI work; ING Bank funds each initiative against a measurable outcome and stops those that stall; Mass General Brigham decommissions clinical AI that fails to deliver. The through-line could not be simpler.