Sovereignty in AI is usually discussed as a procurement preference. It is more useful to treat it as a list of dependencies, and to ask which of them you could survive losing.

If the silicon, the weights, the tooling or the hosting sit outside UK control, then availability, export licensing and governance sit outside UK control with them. A sovereign stack is simply the answer to a blunt question: what still works when access is withdrawn?

Silicon

A trusted supply chain, side-channel mitigations, safety islands and trusted execution environments. Provenance of the hardware matters as much as provenance of the data, and is considerably harder to retrofit.

Data

Lineage from the point of capture, and holdings organised so they can be found and reused rather than rediscovered from scratch by the next programme. The Defence Data Ecosystem sets a sensible direction of travel here.

Model

Model cards and factsheets as a condition of release, and red-team evaluation before anything is trusted operationally. The UK AI safety work gives a usable baseline to measure against.

Runtime

Signed artefacts, a software bill of materials, continuous attestation, and zero trust applied to the hosting itself in line with the NCSC cloud principles. If you cannot attest to what is running, you do not know what is running.

Accreditation and access

Governance follows the NIST AI Risk Management Framework, mapped onto MOD safety cases and JSP-aligned accreditation. Interfaces are open by design, with attribute-based access control (XACML) so a coalition partner can be admitted without the stack being rebuilt around them.

How you know it is working

Three numbers are worth watching: how long it takes to get from a frozen model to an accredited deployment; how fast drift is noticed; and how quickly a known vulnerability in the bill of materials is closed. If those are moving in the right direction, the rest of the argument tends to look after itself.