Resources / Reference guide
What is a sovereign AI platform?
A practical definition of a sovereign AI platform: who controls deployment, data, model routes and access, plus evidence questions for a buyer's review.
A working procurement definition. Sovereignty requirements depend on the organisation, jurisdiction and workload; a product label is not a legal conclusion or certification.
Define the authority before the location.
For procurement, a sovereign AI platform is an AI operating environment in which the accountable organisation can establish and exercise the authority it requires over infrastructure, data use, model execution, access and operational change, within a defined legal jurisdiction.
Write down what that authority means for your workload. It may require local operation, a customer-controlled cloud account, restrictions on foreign support access, or a workable exit from a supplier. This working definition is a way to test requirements, not a universal sovereignty score.
Red Hat describes sovereign AI in terms of ownership and local control of infrastructure and data. A buyer still needs to turn that ambition into specific permissions, dependencies and evidence. A server address alone cannot answer who may read an export or change a model route.
Sources: Red Hat: What is sovereign AI?.
Four deployment arrangements to examine.
These arrangements describe where responsibility begins. They are not a maturity ladder. A poorly administered local installation can expose more data than a carefully configured hosted service.
| Arrangement | Operating responsibility | Evidence question |
|---|---|---|
| Vendor cloud | The supplier operates the service; the customer controls the features and permissions available under its agreement. | Which contractual, residency and administrative controls satisfy the workload, and which powers remain with the supplier? |
| Customer private cloud | The customer or a contracted operator runs a dedicated environment on cloud infrastructure. | Who controls the cloud account, encryption keys, backups, privileged access and external model connections? |
| On-premises | The organisation runs the environment in its own facilities or a specified data centre. | Can licensing, model calls, telemetry, support or recovery send data outside the intended boundary? |
| On-box | A workload runs on a local machine or appliance, with capacity and maintenance constraints. | Which functions still need a network, and what happens when the machine, local model or storage is unavailable? |
Separate the claims.
Data residency describes a location constraint. Sovereignty also asks who has authority and under which jurisdiction. Privacy concerns how information is collected, used and disclosed. Security concerns protection against threats. None of these terms supplies proof of the others.
Local model execution does not make an answer accurate or a business action authorised. Open-source software does not remove the need to review dependencies, permissions and updates. A single-tenant installation does not establish that backup operators or support personnel lack access.
Cloud residency guarantees can have important exclusions. For example, OpenAI documents different boundaries for stored content, GPU inference, other processing and third-party integrations. Review those distinctions for every supplier in a proposed system.
Sources: Example: OpenAI residency scope.
Ask for evidence you can inspect.
Finish with a requirement-by-requirement decision: observed, not demonstrated, failed or outside scope. Give unresolved requirements an owner. Legal and risk reviewers should decide whether the resulting boundary meets the organisation's obligations.
- Map one workload from source to output. Include prompts, temporary files, model requests, logs, backups and support exports. Mark each recipient and location.
- List the people and services with administrative access. Demonstrate a bounded grant, an allowed operation, revocation and a rejected repeat operation.
- Inspect the deployed version and the release-verification record. Establish who can approve a code, configuration or model change.
- Observe outbound connections in an isolated test. Challenge a prohibited destination and document the result. Do not infer an offline guarantee from an idle network trace.
- Retrieve the evidence independently. Agree retention, deletion and access rules for the records themselves; an audit export can contain sensitive data.
- Rehearse the exit. Export an agreed dataset and restore it in an authorised test environment. Record dependencies that still require the supplier.
Questions and answers.
What is the difference between sovereignty and data residency?
Residency concerns where data is stored or processed. Sovereignty also concerns authority, jurisdiction and dependencies. A regional storage setting does not establish all of those conditions.
Must a sovereign AI platform run on-premises?
That depends on the requirement. A customer-controlled private cloud may be suitable for some workloads. Others require local infrastructure or restricted connectivity. Check the actual contract, access and data flows.
Does a local model guarantee private or accurate output?
No. Local execution changes one processing boundary. It does not establish correct permissions, safe logging, accurate answers or authorised business actions.
How can a buyer verify a sovereignty claim?
Define the required boundary, inspect the data-flow and authority maps, test denied actions and outbound destinations, and rehearse evidence retrieval and exit. Record limitations against the exact configuration tested.