What would happen if access to a major AI provider failed?

Four ways of using AI, four different exposures

• Adopting existing AI

  Using an AI product or service someone else built and trained — a chatbot, a coding assistant, an AI feature inside existing business software — without hosting or fine-tuning a model.

  A small accountancy firm using an AI assistant built into its existing software, or a retailer using an off-the-shelf demand-forecasting tool.

  • Compute access: none directly — the provider hosts it; the organisation needs only a reliable internet connection.
  • Data rights: usually limited to what the organisation feeds into the tool at query time, governed by the provider's terms.
  • Skill: staff able to use the tool and judge its outputs — not machine-learning expertise.
  • Finance: a subscription or per-use fee, typically the smallest financial commitment of the four views.
  • Reliability: dependent entirely on the provider's own uptime and continued willingness to serve UK customers.
  • Evaluation: judging whether the tool's outputs are good enough for the task at hand — no technical benchmarking required.
  • Route to customers: not applicable — the organisation is a customer of AI, not a seller of it.
  • Maintenance: minimal — mostly staying on a supported subscription tier and re-training staff as the tool changes.

  The population most DSIT AI Adoption Research fieldwork describes — self-reported barriers here are typically cost, trust and staff familiarity, not compute or infrastructure.

• Building specialised applications

  Building a product or internal tool on top of someone else's AI model via an API — combining an existing model's outputs with the organisation's own data, workflow and interface.

  A legal-tech firm building a contract-review product that calls a third-party model's API and layers its own document-handling and review workflow on top.

  • Compute access: to run the organisation's own application, not to train or host the underlying model itself.
  • Data rights: to the organisation's own proprietary data, plus clarity on how any data sent to the underlying model provider may be used or retained.
  • Skill: software engineering and product skills, plus enough understanding of the underlying model's behaviour to build around its limitations.
  • Finance: development cost plus ongoing per-use API fees to the underlying model provider — a recurring cost tied to usage volume.
  • Reliability: depends on the underlying provider's API uptime and pricing/access terms, which the building organisation does not control.
  • Evaluation: testing the application's outputs for the organisation's specific use case, including cases where the underlying model performs poorly.
  • Route to customers: the organisation's own — this view is closest to a conventional software business.
  • Maintenance: ongoing engineering as the organisation's product evolves and as the underlying model provider changes its API or pricing.

  This is the population most directly in mind when this page warns against implying every AI business needs a frontier training cluster.

• Adapting and operating models

  Taking an existing pre-trained model and adapting it — fine-tuning on the organisation's own data, or running it on the organisation's own infrastructure — rather than using it purely via someone else's API.

  A public body fine-tuning an open-weight model on its own case records so it can run on infrastructure it controls, for data-governance reasons a pure API call would not satisfy.

  • Compute access: meaningful compute for fine-tuning and for ongoing inference — smaller than training a model from scratch, but a real infrastructure requirement, not zero.
  • Data rights: to a substantial, well-governed dataset of the organisation's own — fine-tuning quality depends directly on this.
  • Skill: applied machine-learning engineering, not just software engineering — evaluating and adapting model behaviour, not only calling an API.
  • Finance: capital or cloud-compute spend for fine-tuning and hosting, larger and more front-loaded than the "building" view above.
  • Reliability: the organisation now bears more responsibility for its own uptime, though it is still building on someone else's base model.
  • Evaluation: technical benchmarking of the adapted model against the organisation's specific task, not just checking application-level outputs.
  • Route to customers: variable — this is often internal capability (e.g. a public service) rather than a product sold externally.
  • Maintenance: retraining/re-adapting as the base model or the organisation's own data changes, plus infrastructure operation.

  The AI Playbook for the UK Government is aimed substantially at this population within the public sector.

• Training frontier general-purpose models

  Training a new, general-purpose foundation model from scratch at the largest scale — the population AIRR (UK Compute Roadmap) and the UK AI Hardware Plan are aimed at supporting, not the population most UK AI businesses belong to.

  A well-resourced research lab or a small number of companies training a new large general-purpose model, requiring public or private compute at the scale AIRR and comparable private infrastructure provide.

  • Compute access: very large-scale compute — the population AIRR (21 AI ExaFLOPS 2025, targeting 420 by 2030) and comparable private infrastructure serve, itself described by its own source as only a small share of total UK compute capacity.
  • Data rights: access to very large, diverse training datasets, with associated licensing and rights-clearance questions at a scale smaller efforts do not face.
  • Skill: specialist machine-learning research and large-scale systems engineering — a small, globally competed-for talent pool.
  • Finance: the largest financial commitment of the four views, by a wide margin — comparable to the scale of public commitments described in the UK Compute Roadmap and the UK AI Hardware Plan.
  • Reliability: building and operating the infrastructure itself, including power and cooling at the scale described in the dependency explorer above.
  • Evaluation: frontier-scale benchmarking against other large models, an active and contested area with no single agreed UK-official measure (see the country-level frontier-model evidence gap).
  • Route to customers: typically via API access sold to the other three populations above, rather than direct end-user sales.
  • Maintenance: continuous retraining, safety evaluation and infrastructure operation at a scale only a small number of organisations worldwide currently sustain.

  Most useful UK AI activity does not require this — it is one view of four, not the population this page is centrally about.

What the evidence cannot yet answer

• What percentage of the AI compute, models and cloud services available to UK users is under UK operational control, as opposed to being accessed via overseas-controlled infrastructure or platforms?

  Why the data cannot answer it: No official body publishes a comparable national measure of 'UK operational control' over AI supply. Ownership, hosting location, workload allocation authority and software/licensing control are frequently split across different parties for the same facility or service — UK location is not the same as UK control, and no dataset consistently records all four dimensions across the UK AI supply chain. The CMA's cloud services market investigation provides market-definition and switching evidence for specific UK-and-EEA cloud markets, not a UK-operational-control percentage.

  What would close it: An official cross-government or regulator-led survey/register (extending the CMA's market-investigation work, or a DSIT-commissioned equivalent to the AI Sector Study) that records ownership, operator, workload-allocation authority and licensing control per major facility/service, published with a consistent UK-supply denominator.

• What is the UK's total, current, AI-specific data-centre electricity demand?

  Why the data cannot answer it: DUKES and NESO's published materials cover whole-economy/whole-grid generation, capacity and connection-queue data, not an AI-specific data-centre demand figure isolated from data centres serving non-AI workloads (general cloud hosting, telecoms, financial services, etc.). NESO's own background material on data-centre measurement and siting exists precisely because this measurement problem is unresolved, not because a total is available elsewhere. A dispersed fleet of facilities with different reporting practices is not automatically summable into one 'national AI power total' even if every individual facility's demand were known — incompatible measures cannot simply be added together.

  What would close it: A NESO or DESNZ-led classification of connected data-centre demand by workload type (AI vs general-purpose), published as a recurring series alongside the existing generation/capacity/connection-queue data these bodies already publish.

• How have AI service prices actually changed for UK small and medium-sized enterprises specifically?

  Why the data cannot answer it: No official SME-specific AI price index exists. ONS does not publish an AI-services price series, and DSIT's AI Adoption Research and ONS's BICS survey both measure adoption/barriers and business sentiment, not a price index. This site does not construct one from unrelated subscription prices — a bounded illustrative stress-test calculator can model a hypothetical price-shock scenario, but that is explicitly not a substitute for a real, measured SME AI price series and must never be presented as one.

  What would close it: An ONS-developed AI-services price index (analogous to existing producer/consumer price indices), or a DSIT-commissioned recurring SME AI-spend survey with consistent year-on-year methodology.

• What would be the UK macroeconomic loss if a major overseas AI model or cloud AI service were withdrawn from the UK market?

  Why the data cannot answer it: No validated national economic model estimating this loss was located. This site does not invent one, and does not generate an economy-wide loss or replacement time without an applicable validated model. The dependency and substitutability of UK AI usage on any single overseas provider is not comprehensively mapped (this is itself downstream of the uk-ai-supply-operational-control-share gap above), so even the INPUTS to such a model are not currently available, before any modelling assumption is applied.

  What would close it: Official economic modelling (e.g. Treasury/OBR-led, or an independently peer-reviewed academic model) of AI-service dependency and substitution, published with its assumptions and uncertainty ranges — none currently exists.

• How does UK frontier AI model capability compare internationally on an official, comparable basis?

  Why the data cannot answer it: No official, comparable country-level frontier-model performance score series exists. The international programme comparison (EU AI Factories, US NAIRR) covers documented ACCESS ARRANGEMENTS and delivery stages, not model-capability scores, and country rankings built from incompatible FLOPS or funding figures are not a substitute. No comparable official Chinese frontier-capability series has been established at all — this is a genuine absence for that specific comparison, not merely an unresolved methodology question, and must be left absent rather than filled with an industry benchmark presented as official.

  What would close it: An international body (e.g. OECD, an intergovernmental AI safety/capability forum) publishing a methodologically transparent, comparable frontier-model capability series across countries — none currently exists publicly.

How the evidence is classified