In a single quarter, the UK sovereign AI landscape has shifted: Project Mercury delivered the country's first domestically-trained frontier models, the £500M Sovereign AI Fund opened for procurement, BT, Nscale and NVIDIA committed 14 MW of sovereign data-centre capacity, and the CMA opened a strategic market review of Microsoft's cloud and AI position. For UK enterprises, sovereign AI has moved from procurement footnote to board-level architecture decision.
This checklist is designed to be taken into a 60-minute working session with your cloud, security, and data leads. Tick the items you can honestly evidence today — not the ones you intend to evidence next quarter. The scoring at the end translates the result into a concrete next step.
01 Workload Inventory & Classification
You cannot make a workload sovereign if you do not know where it runs or what it touches.
- Inventory of every AI workload in production and pre-production, with owner, business purpose and dependency map
- Data-class label on every workload (public / internal / confidential / restricted / Tier-1 regulated)
- Inference location recorded — physical region, legal jurisdiction, and the entity that operates the inference service
- Refresh cadence for the inventory defined and owned (quarterly at minimum)
02 Data Residency & Sovereignty
Where the data physically lives, and whose courts can compel its disclosure.
- UK-resident storage verified for every dataset classified confidential or above — with documentary evidence, not vendor assertion
- Sub-processor list mapped per dataset, including transitive cloud regions
- CLOUD Act exposure assessed for each provider with US-parented ownership
- Cross-border transfer mechanism (UK IDTA / SCCs / adequacy) documented per data flow
03 Model Provenance & Lineage
Where the model came from, who trained it, on what, and under whose jurisdiction.
- Model card on file for every foundation, domain, and fine-tuned model in use
- Training-data provenance understood at least at category level (where evidence is available)
- Weights location documented — hosted in the UK, in a permitted region, or via UK-sovereign provider (Civo Sovereign Cloud, BT/Nscale, on-prem)
- Fallback model identified for any workload dependent on a single foreign-controlled model
04 Key Management & Encryption Control
Sovereignty over the encryption keys is sovereignty over the data.
- Customer-managed keys (CMK) in use for all Tier-1 datasets — not provider-managed defaults
- Hold-Your-Own-Key (HYOK) or external key store evaluated for the highest-sensitivity workloads
- Key rotation, escrow, and revocation tested in the last 12 months with documented evidence
- HSM jurisdiction recorded (UK FIPS-validated HSM where required by sector)
05 Identity & Access Boundaries
Who can call which model, with whose credentials, under what conditions.
- UK-anchored identity provider for sovereign-tier workloads, with no implicit dependency on a foreign-controlled directory
- Workload identity (no static credentials) for every service that calls an AI model
- Least-privilege RBAC on model endpoints, with deny-by-default for cross-tier calls
- Privileged-access review performed at least quarterly for sovereign-tier admins
06 Network Egress & Traffic Sovereignty
Inference traffic leaving the UK is a sovereignty event whether or not anyone wrote it down.
- Egress policy enforced at the network layer for sovereign-tier workloads (no public-internet inference paths)
- Private connectivity (Direct Connect, ExpressRoute, Cloud Interconnect, or sovereign equivalent) to all permitted model endpoints
- DNS & certificate trust rooted in UK-controlled authorities for sovereign-tier services
- Traffic flow logs retained and queryable for the audit period required by your sector
07 Concentration & Third-Party Risk
The CMA review of Microsoft makes concentration risk a board-level metric, not a procurement footnote.
- Single-hyperscaler exposure quantified across compute, model, and operational dependency
- Operational resilience scenarios include a credible “single provider compromised or withdrawn” test
- Viable alternative provider identified per Tier-1 workload (and tested at least once in 12 months)
- Exit plan documented per provider, with realistic timeline and data-portability evidence
08 AI Governance & Assurance Evidence
What you can hand to a regulator on a Friday afternoon.
- AI risk register maintained, with sovereignty risk explicitly scored alongside model risk
- EU AI Act classification completed for every use case in scope
- Prompt and response logging with PII redaction, retained per sector requirements
- Evidence pack ready for FCA / PRA / ICO / NHS DSPT / MoD-aligned audit (whichever applies)
09 Procurement & Contractual Clauses
Sovereignty written into the paper, not assumed from the marketing.
- Data-residency commitments in every AI-related contract, with audit rights and breach remedies
- Sub-processor change notification required, with right to object
- IP retention on background and foreground — aligned to DSIT Sovereign AI Fund norms
- Foreign-government request notification clause where lawfully possible, with escalation path
10 Hybrid Architecture Discipline
Most enterprises do not need sovereign-only — they need sovereign-capable, with a boundary that does not erode.
- Sovereign tier defined as a distinct architectural zone with its own network, identity, and policy domain
- Policy-as-code prevents drift of regulated workloads back into the hyperscaler default tier
- Consistent observability across sovereign and hyperscaler tiers (no blind spots in the regulated zone)
- CI/CD parity — the same engineering velocity in the sovereign tier as everywhere else
11 Skills & Operating Model
Sovereign AI fails most often on people and process, not technology.
- Named owner for the sovereign AI roadmap, with executive sponsorship
- UK-based engineering & SRE coverage for sovereign-tier workloads, under UK contracts
- Cross-functional working group (cloud, security, legal, data, FinOps) meeting at least monthly
- Training in sovereign architecture patterns completed for senior cloud and AI engineers
12 Roadmap & First Workload Selection
The first sovereign workload sets the precedent. Choose it deliberately.
- Candidate workload list scored on regulatory pressure, value, and migration feasibility
- First sovereign workload chosen — ideally a RAG system over sensitive internal data or a domain-tuned model
- Success criteria defined before migration: residency, performance, cost, audit evidence
- 12-month expansion plan — workload classes to onboard in waves, not all at once
How to Score Your Organisation
Count the checkboxes you can honestly evidence today (each item = 1 point, 48 max):
| 42–48 | Sovereign-ready. You can move regulated workloads onto a sovereign tier now. Focus on optimisation and expanding the tier deliberately. |
| 30–41 | Strong foundation. Choose one Tier-1 workload and migrate it end-to-end within 6 months while closing the residual gaps in parallel. |
| 18–29 | Material gaps. Address inventory, data classification, key management and concentration risk before any migration. 90-day remediation programme recommended. |
| Under 18 | Pre-sovereign. Start with workload inventory and the five-pillar baseline assessment. Sovereign migration without these foundations will overrun and underdeliver. |
Need Help Closing the Gaps?
Our certified architects across Azure, AWS, GCP and the UK sovereign providers run complimentary two-hour sovereign AI readiness workshops with UK enterprises.
Book a consultation at totalcloudai.com/contact or email info@totalcloudai.com