Britain talks a lot about AI leadership, but much of the country’s work to train, adapt and deploy AI models still runs on machines owned by a handful of global providers. That works when capacity is cheap, plentiful and reliable. It becomes a strategic risk when graphics processing units (GPUs) are scarce, cloud pricing is volatile, and public-sector projects depend on infrastructure decisions made outside the UK.
The UK has put real machinery behind its AI ambitions. The AI Security Institute tests advanced systems, advises policymakers and works with leading AI companies, while the Bletchley Declaration set out an international commitment to understand and manage frontier AI risks. The AI Opportunities Action Plan goes further on infrastructure, committing £2bn to expand UK compute capacity twentyfold by 2030, alongside five AI Growth Zones and up to £500m for the Sovereign AI Unit.
The gap is dependency. The Competition and Markets Authority’s (CMA) cloud services investigation has already put the UK cloud market under the microscope. Microsoft, AWS and Google are not just cloud vendors; they are vertically integrated providers of the accelerated compute and AI-related cloud services that many teams now need. The government’s own AI Growth Zones guidance identifies timely electricity grid connections as the single biggest blocker for AI data centres.
A policy document can set ambition. Grid connections, GPU access and cloud pricing decide how fast the work actually moves.
Capital is also flowing toward the companies closest to the infrastructure layer. Anthropic has reportedly attracted investor interest at valuations of up to $800bn, while OpenAI says it has closed $122bn in committed capital at a $852bn valuation.
Those figures reflect a market where access to GPUs and long-term cloud commitments increasingly determines who can build at scale. Capacity tightens and prices rise. A region fails and workloads stop. A provider prioritises larger customers, and UK teams are left redesigning projects around decisions they did not make.
Where centralised compute creates engineering risk
Centralised compute puts too many workloads behind the same regions, facilities and supply chains. A cloud region hits a power or cooling constraint, and workloads slow or move elsewhere. A provider reserves capacity for a larger customer, and smaller teams wait longer. An outage spreads quickly because so many services sit inside the same failure domains. Latency rises when workloads are pushed to distant regions.
Energy is now one of the main limits on compute. High-density GPU racks draw serious power and generate serious heat, which means capacity depends on grid connections, cooling systems and site readiness as much as hardware supply. The International Energy Agency has warned that data-centre electricity use is rising quickly, with AI-focused facilities growing especially fast. New capacity takes time: hardware has to arrive, rooms need refitting, cooling has to be upgraded and networks extended.
AI teams end up adapting the work to the hardware available, rather than choosing the hardware the work needs. Models are made smaller, experiments are delayed, inference is moved to less suitable regions, or deployments are staged more slowly than the use case requires.
Distributed infrastructure needs engineering discipline
Distributed compute lives or dies on visibility. Engineers need to know which GPUs are available, where workloads are running, how hardware is performing and where spare capacity sits. Without that view, a network becomes another blind spot. With it, faults can be isolated before they spread.
Failure also behaves differently when capacity is spread across more than one provider or location. When one site hits a cooling limit or a supplier shifts capacity elsewhere, the disruption can stay local instead of rippling through an entire region. With the right orchestration, workloads can move without forcing teams to rethink their whole architecture. Engineers keep control of the job they are trying to run, rather than working around whatever capacity a single provider happens to have spare.
Most AI work does not run in one neat pattern. Training is intermittent. Adapting models for specific tasks is lighter. Inference is steady and predictable. Batch jobs can move to lower-cost regions. Real-time services need proximity to users. Trying to force all of those workloads through one architecture wastes money and performance. A distributed network gives teams more room to place each job where it makes technical and commercial sense.
The hyperscalers are not going away, and nor should they. The UK still needs a broader base of compute, so its AI ambitions are not constrained by the limits of a few global operators. A distributed foundation gives engineers more control over performance, cost and availability, and gives the country more control over its long-term capability.
The UK’s AI plans will only go as far as the infrastructure underneath them. Researchers, startups and public-sector teams need compute they can schedule, price and trust. Without that, they are not building on a foundation. They are waiting for access.
David Sherman, AI and Financial Inclusion Strategist, IO.NET