Resources / Reference guide
What is a sovereign AI platform?
A practical definition of a sovereign AI platform: who controls deployment, data, model services and access. Includes evidence questions for a buyer's review.
A working procurement definition. Sovereignty requirements depend on the organisation, legal 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 lets the responsible organisation establish and exercise the control its work requires. That includes infrastructure, data use, model processing, access and changes to operations. Those powers operate 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 tell you who may read exported data. It cannot tell you who can change which AI model service receives your data or where it runs.
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, data-location and administrative controls meet the workload's needs? 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, administrative access and external model connections? |
| On-premises | The organisation runs the environment in its own facilities or a specified data centre. | Can licensing, model requests, automated usage and diagnostic reports, 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.
Running a model locally 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. An installation dedicated to one customer does not establish that backup operators or support personnel lack access.
Cloud data-location guarantees can have important exclusions. For example, OpenAI documents different boundaries for stored content, model processing on graphics processors, 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. Grant permission for a defined action and demonstrate it. Remove that permission and show that repeating the action is refused.
- 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 where data may go and who may act. Inspect the maps of data flows and permissions. Test refused actions and external destinations. Rehearse retrieving evidence and leaving the supplier. Record limitations against the exact configuration tested.