AI Power Evidence Should Become Part Of Workload Placement

The Sovereign Cloud

7 September 2026 | By Ashley Marshall

Data residency is only half the sovereignty question. For serious AI workloads, UK leaders now need evidence that the power, region and resilience assumptions behind the workload can actually hold.

Data residency is no longer the whole sovereignty test

For the last few years, most AI sovereignty conversations have started with a simple question: where does the data go? That still matters. A UK business handling client records, employee data, financial information or regulated case notes needs clear answers on jurisdiction, processing, retention and onward transfer. But the more AI moves from experimentation into operational workflows, the placement question has widened. The useful question is no longer only where the data sits. It is whether the region, power supply, network path and failover design can support the workload when demand rises.

The UK government's Cloud Challenge Book 2026 makes that shift explicit. It describes cloud as a critical enabler for UK services and notes that the UK cloud market is worth over £10.5 billion, with 60% of businesses using cloud services and growth of 30% a year. It also says that a single fully featured in-country region is not enough for organisations that need UK jurisdiction and multi-region resilience. That is a direct challenge to any buyer treating sovereignty as a checkbox on a procurement form.

For AI, this becomes even sharper because workloads are not equal. A monthly analytics job, a customer-facing triage assistant, a retrieval workflow in Microsoft 365 and a GPU-heavy document processing pipeline place very different loads on suppliers. Some can tolerate delay. Some need predictable latency. Some need a UK failover region. Some should not run if capacity is uncertain. That means sovereignty needs a placement record: data location, model route, cloud region, power dependency, recovery path and owner. Without that record, the business has a promise, not an operating control.

Power is becoming a practical AI procurement constraint

The uncomfortable point is that AI infrastructure is not just a software choice. It is a power and planning choice. The UK Compute Roadmap says the country needs a compute ecosystem that is diverse, resilient and able to support both AI training and inference. It also notes up to £2 billion of public investment between 2026 and 2030, including expansion of the AI Research Resource and a new national supercomputer service in Edinburgh. Those are policy signals that compute capacity is now strategic infrastructure, not simply another line in an IT budget.

The power numbers explain why buyers should care. The Delivering AI Growth Zones policy says slow and inconsistent planning processes and delays getting access to power are the biggest barriers to domestic AI data centre capacity. It claims the programme could reduce time to power by up to 5 years and save a 500 MW data centre up to £80 million a year in electricity bills. Those are not abstract infrastructure details. They affect price, availability, resilience and the supplier's ability to scale without pushing cost or service risk back to customers.

A common misconception is that this only matters to hyperscalers. It does not. A mid-market firm may never buy a GPU cluster directly, but it will buy services that depend on one. If a supplier cannot explain which regions are used, how capacity is allocated, what happens during constraint, and whether high-priority workloads are protected from low-value experimentation, the buyer is accepting hidden infrastructure risk. That risk may show up as throttling, price shocks, missed processing windows or rushed offshore fallbacks.

Workload placement needs tiers, not slogans

The answer is not to declare that every AI workload must run in the UK. That would be expensive, brittle and unnecessary. GOV.UK's AI Growth Zones policy is clear that the UK's approach is pragmatic, not isolationist, and that some AI workloads can be serviced offshore with allies. That is the sensible position for business too. Sovereignty should not mean forcing every prompt through the most constrained and expensive path. It should mean knowing which workloads deserve that path, why, and what evidence supports the decision.

A practical placement model starts with tiers. Tier one might cover low-risk productivity use: drafting, summarising public material, internal brainstorming and non-sensitive research. These workloads can usually use mainstream SaaS AI with standard contractual and data protection controls. Tier two might cover operational workflows using internal documents, customer records or repeatable decisions. These need stronger audit logs, retrieval boundaries, retention controls and a defined region policy. Tier three covers critical or sensitive workloads: regulated complaints, finance approvals, healthcare-adjacent processing, legal review, incident response and anything that could materially affect a customer, employee or supplier. Those workloads need UK-specific placement evidence, a tested failover path and a named business owner.

What this means in practice is a simple control table that finance, operations, legal and IT can all read. For each AI workflow, record the data classification, model or supplier, primary region, fallback route, expected usage, latency tolerance, monthly cost guardrail, incident owner and power or capacity dependency. For higher tiers, ask suppliers for evidence, not reassurance: region capability, resilience design, capacity commitments, support response, export path and notification rules for material infrastructure change.

Public-sector cloud policy is setting the expectation for private buyers

Private-sector leaders should watch public-sector cloud policy because it often becomes the language of supplier scrutiny. The Cloud Challenge Book points to secure-by-default and resilient-by-default cloud, design for national-scale digital foundations, and a need for environmentally responsible infrastructure that is transparent about energy, water, materials and end-of-life. It also raises the possibility of placing new public-sector workloads in cloud regions outside the south-east of the UK to support geographic resilience. That is a strong signal: location is not just about jurisdiction. It is also about concentration risk.

For businesses, the practical move is to copy the discipline, not the bureaucracy. If a workflow is important enough to automate with AI, it is important enough to document where it runs and what would happen if that route changed. The supplier conversation should include questions such as: which UK regions are available for this service today, which features are missing in each region, whether logs and embeddings stay in the same jurisdiction, whether failover leaves the UK, and how the customer is informed if capacity or placement changes. Those questions are particularly important for AI systems that connect to email, CRM, finance, HR or document management platforms.

The counterargument is that smaller firms do not have the leverage to demand infrastructure detail from major vendors. That is partly true, but it misses the point. The goal is not to negotiate like a government department. It is to classify risk properly. If a supplier cannot provide evidence for a high-tier workload, the business can still choose a different design: keep humans in approval loops, restrict the workflow to lower-risk tasks, route sensitive processing through a more controllable platform, or delay automation until the evidence improves.

The buyer evidence pack should include power, capacity and exit routes

An AI supplier evidence pack should now go beyond security certificates and data processing terms. SOC 2, ISO 27001, DPIAs and contractual clauses remain useful, but they do not answer whether the workload can keep running under regional constraint. A better pack includes four extra items: a workload placement map, a capacity statement, a resilience statement and an exit route. These do not need to be long documents. They need to be clear enough that a director, auditor or client can understand the choice.

The workload placement map says where prompts, documents, embeddings, logs, model calls and outputs go. The capacity statement says whether the chosen service has reserved capacity, fair-use limits, throttling rules, priority tiers or dependency on a constrained region. The resilience statement says what happens when the primary route is degraded: fail closed, fail to a lower-grade model, fail to another UK region, fail offshore with explicit approval, or pause the workflow. The exit route says how the business gets prompts, logs, embeddings, evaluation records and configuration out if the supplier changes policy or pricing.

This is where the infrastructure policy evidence becomes directly useful. The AI Growth Zones programme is built around power access, grid connection reform and regional incentives. The Compute Roadmap points to sovereign, secure and sustainable capability. The Guardian reported that DSIT forecast at least 6 GW of AI-capable data centre capacity by 2030, while energy planning assumptions appeared to lag behind that level of demand. Whether that tension is solved or not, buyers should not pretend it is irrelevant. A supplier that understands its power and placement story will be easier to trust than one that hides it behind generic cloud language.

Make placement evidence part of the release gate

The practical step is to turn power and placement evidence into a release gate for meaningful AI workflows. Before a workflow moves from pilot to production, the project owner should answer five questions. What data does the workflow touch? Which supplier, model and region does it use? What happens if the preferred route is unavailable or too expensive? Who approves a fallback that changes jurisdiction, quality or cost? What evidence would we show a client, regulator, insurer or board member if the workflow failed?

This release gate does not need to slow adoption. Done well, it speeds up sensible adoption because teams stop arguing from slogans. A low-risk internal summariser can move quickly with light controls. A customer complaint assistant that reads personal data and recommends responses needs stronger evidence. A finance automation that can trigger payments or supplier changes needs transaction guardrails, logs and a fail-closed design. The placement decision follows the risk of the work, not the excitement around the tool.

The most important habit is to revisit the record. AI infrastructure is moving quickly. Regions gain features, suppliers change terms, model routing changes, capacity tightens, and government policy evolves. A quarterly review of high-tier workflows should check actual usage, cost per completed task, incident history, supplier notices, failover tests and any change in region or model behaviour. For UK businesses, this is the new sovereignty discipline: know which work can run anywhere, which work needs a controlled UK route, and which work should pause rather than quietly drift into a weaker operating model.

Frequently Asked Questions

What is AI workload placement?

AI workload placement is the decision about where an AI workflow runs, which model or supplier handles it, what data it touches, and what happens if the primary route is unavailable. It should cover region, resilience, cost, data controls and business ownership.

Is data residency still important for UK AI systems?

Yes. Data residency still matters for jurisdiction, privacy and client assurance. The point is that it is no longer enough on its own. Important AI workflows also need evidence about capacity, power dependency, failover and supplier change.

Does every AI workload need to run in the UK?

No. Low-risk and non-sensitive workloads may be perfectly suitable for mainstream global AI services. UK-controlled routes should be reserved for workloads where data sensitivity, resilience, regulation, client commitments or business impact justify the extra scrutiny.

What should we ask AI suppliers about power and capacity?

Ask which regions support the service, whether capacity is reserved or fair-use based, what throttling rules apply, how failover works, whether failover changes jurisdiction, and how customers are notified of region, model or infrastructure changes.

How does this affect Microsoft 365 Copilot, Gemini or ChatGPT Enterprise?

The same principle applies. The brand name is not the control. For each workflow, record the data touched, the admin settings, the available region commitments, logging, retention, connector permissions and what happens when the service degrades or changes.

Who should own workload placement in a business?

Ownership should sit with the business process owner, supported by IT, legal, security and finance. AI placement is not only a technical decision because it affects customer promises, cost exposure, operational resilience and regulatory evidence.

What is the simplest first step?

Create a one-page register of live and planned AI workflows. For each one, record data type, supplier, model, region, owner, fallback behaviour and whether the workflow should pause if the approved route is unavailable.

How often should placement evidence be reviewed?

Review high-risk workflows at least quarterly and whenever a supplier announces a material model, region, pricing, security or resilience change. Lower-risk tools can be reviewed less often, but they should still be visible in the AI register.