What is sovereign AI?
Sovereign AI means retaining meaningful control over the data, infrastructure, models and operation of an AI system. For an organisation, that means deciding where information is processed, who can access it and what the system is authorised to do. On-premise and air-gapped deployment can support that control, but are not the whole definition.
Understand the choices, ask better questions and evaluate the evidence. This guide separates deployment terminology from operational control, then explains Mickai's approach and the checks to take into a supplier conversation.
What is sovereign AI?
Sovereign AI means retaining meaningful control over the data, infrastructure, models and operation of an AI system. For an organisation, that means deciding where information is processed, who can access it and what the system is authorised to do. On-premise and air-gapped deployment can support that control, but are not the whole definition.
The term also appears at national level, covering domestic infrastructure, skills, data and the ability to develop and operate AI. At company level, the useful question is practical: which decisions and dependencies remain under your control? Location alone does not answer that. Examine administration, model supply, encryption keys, support access, network connections and the ability to continue operating or change supplier.
Why does sovereign AI matter?
Organisations may want AI assistance without sending confidential documents, customer information or internal decisions to an external service. Others need continuity when connectivity fails, control over upgrades, or an inspectable record of what an assistant was allowed to do. A sovereign approach makes those requirements explicit before choosing a model or a deployment.
It is not a substitute for security or compliance work. An offline system still needs access controls, secure configuration, patching, backups and responsible operators. A cloud deployment is not automatically unsuitable, and a local deployment is not automatically compliant. Evaluate the complete system against your information, operating environment and obligations with your security and compliance teams.
Cloud, private, on-premise or air-gapped AI?
These labels describe different properties, not a ladder from unsafe to safe. A deployment can fit more than one column. Sovereignty is the control you establish across the chosen system, supported by contracts, architecture, operating procedures and tested evidence.
On a smaller screen, scroll the table sideways to compare all four options.
| Buyer question | Cloud AI | Private AI | On-premise AI | Air-gapped AI |
|---|---|---|---|---|
| What the term describes | A service hosted on cloud infrastructure | Restricted access or a dedicated environment | Deployment within your premises | An environment isolated from external networks |
| Where data is processed | The service's configured region and processing chain | Can be in a cloud, private data centre or on premises | Locally, unless connected components send data elsewhere | Inside the isolated environment; transfers need a separate process |
| What to check about access | Provider access, customer-managed key options and subprocessors | Tenant isolation, administrators and key custody | Local administrators, support channels and key custody | Physical access, removable media, administrators and key custody |
| Operation without the internet | Usually depends on connectivity to the provider | Depends on deployment and external dependencies | Possible if the full required workflow is local | Required for the workflows inside the isolated environment |
| Evidence to request | Data-flow map, access policy, retention settings and exportable records | Isolation tests, processing locations and administrator records | Egress tests, dependency inventory and working recovery procedures | Disconnected workflow test and controlled update/import procedure |
| What the label does not prove | How access, governance or audit integrity are implemented | That no external processing or vendor access exists | That every component works offline or that access is safe | That an answer is correct or an action is authorised |
Is sovereign AI the same as on-premise or private AI?
No. On-premise describes location; private describes restricted access or isolation; air-gapped describes network separation. Sovereignty concerns control across the system. These properties can overlap: an on-premise private deployment may also be air-gapped. Neither owning a server nor selecting a private cloud tenancy proves how a model, connector, support account or agent handles your information.
How does Mickai implement sovereign AI?
Mickai brings company knowledge, specialist brains, work studios and AI assistance together in its Sovereign Intelligence Operating System (SIOS), on infrastructure the organisation controls. The proposition goes beyond hosting a local model: connect useful work to permissions, human approval and evidence of execution. Explore the interactive brain catalogue to see how specialist capabilities relate to studios and the patent portfolio.
Mickai's governance architecture includes controlled execution and the Open Audit Record (OAR), a signed, hash-linked record designed for independent verification. Those are Mickai-specific design choices, not requirements built into the general definition of sovereign AI. For procurement, request a demonstration of the configured controls: a permitted action, a denied action, an approval, and verification of the resulting records.
For an air-gapped deployment, define which workflows must remain inside the isolated environment. Email, external meetings, live web information and connected services need an approved connection or a controlled transfer process. A disconnected model cannot retrieve a new external message. An AI Readiness assessment starts with your data, workflows and constraints, then identifies the deployment and evidence your organisation needs.
How do you evaluate a sovereign AI system?
Begin with a real workflow and representative data you are permitted to use. Document what may leave the environment, who may approve actions and what must keep working without a vendor. Test those requirements, including failure cases, rather than awarding points for a label. Use the checklist below to ask every supplier for comparable evidence.
What works offline, and what needs a connection?
Offline means a workflow can run without a connection at that time. Air-gapped describes an environment isolated from external networks. For document search or transcription, confirm that extraction, embeddings, retrieval, speech models, authentication and audit verification are all available inside the agreed boundary. A local model alone does not establish this. New external email, calendar changes and web results require an approved connection or controlled import. Show when imported information was last refreshed; never present an old snapshot as live data.
To assess a zero-egress claim, inventory dependencies and test a clean start with external access blocked. Exercise login, document ingestion, retrieval, transcription, approvals, errors and recovery while observing network and application logs. Include telemetry, crash reports, licence checks, DNS, backups and remote support. Record attempted connections as well as successful traffic, the software versions and the observation period. A quiet capture during one task is evidence about that test, not proof of every possible behaviour. Connected tasks should report that they are unavailable or pending when disconnected, and confirm their outcome before reporting success.
Agree a separate update process for isolated systems: obtain model and software packages through an approved staging environment, verify provenance and signatures against trusted keys, scan and record transfer media, then test before promotion. Keep version records, a known working rollback and an accountable approver. Test recovery after an interrupted update. An air gap does not remove the need for patching or make removable media safe by itself.
How do documents become trustworthy company knowledge?
Retrieval supplies selected document passages to a model when it answers; it does not by itself train those passages into the model's weights. Fine-tuning changes model parameters and needs a separate decision about data use, licences and evaluation. For a retrieval pilot, inventory the sources, classify sensitivity, retain document versions and page references, and send unreadable scans or conflicting records to a data owner. Local extraction and local retrieval both need to be included in the deployment scope.
Apply source permissions before information reaches the model, including retrieved passages, attachments and cached answers. Test the same question using accounts from different departments and an account with no access. Removing a source should trigger review of its index entries, cached copies and retention requirements. For a departed employee, revoke accounts, sessions, tool credentials and delegated access, then test search, direct document access and queued actions. These are acceptance checks to request, not a claim that a particular installation already passes them.
Evaluate a representative set of questions against answers reviewed by your data owners. Include scans, conflicting versions, missing answers and restricted documents. Check the cited passage actually supports the response; count unsupported answers and inappropriate disclosures separately. Measure answer quality and review effort before expanding the corpus. A source citation or valid audit signature does not establish that the answer is correct.
What should a pilot prove before you buy or expand?
Start with one repeatable workflow, an accountable owner and representative data you are permitted to use. Bring a source inventory, example documents, access restrictions, current task volumes and a description of the existing process to the readiness workshop. Agree pass and fail criteria, human approval points and a stop or rollback decision. Keep consequential actions under review, and defer automation where there is no reliable way to check an output or contain a failure.
Measure completed work against the same manual baseline: quality, errors, total handling time including review and rework, and operating cost. Record sample size and test conditions. Size hardware using model memory, context length, simultaneous requests, indexing and recovery needs. Test representative peak load and report response-time distributions, not just the fastest demonstration. Compare cloud and local costs at the same workload and quality, including licences, integration, power, administration, support, patching, evaluation and replacement hardware. A larger model may improve some tasks but use more memory and increase response time; verify the tradeoff on your work.
Ask suppliers to label each required capability as available in the proposed version, needing configuration, or planned, and demonstrate the available functions on that version. Document vendor administration and support access, operator control of encryption keys, backup and key recovery, and access revocation. Review the exact model, software and dependency licences with procurement, including commercial use, redistribution, notices and termination terms. Rehearse exporting documents, permissions, configurations and audit records into usable formats; confirm deletion, transition support and continuing licence rights before relying on an exit plan.
Where should healthcare and regulated teams begin?
For healthcare, start with an agreed document workflow and approved sample records. Involve information governance, clinical safety and the people responsible for the records before processing patient information. Test source accuracy, access restrictions, retention, correction and human review. Transcription and clinical documentation need their own evaluation of omissions, speaker attribution and uncertain terminology. On-premise deployment is an option to assess, not evidence of NHS approval, clinical suitability or certification. NHS England publishes guidance for assessing cloud use with appropriate safeguards; there is no blanket rule that all patient information must stay on a local server.
For a regulated enterprise, start with document retrieval or drafting and a named reviewer before granting authority to change records or send information. Test permitted and denied tool calls, expired approvals, revoked access and an unavailable policy service. Require protected actions to stop when authority cannot be established. Capture the actor, proposed action, policy version, approval decision and observed outcome. Finance teams should assess outsourcing and resilience requirements with their risk owners; FCA guidance permits cloud services where applicable rules are met. A local installation does not remove those responsibilities or establish compliance.
Seven questions. Evidence for every answer.
- 01 / Evidence to request
Where can our data go?
A data-flow map covering prompts, documents, embeddings, logs, backups, telemetry and every connector; verify it against observed network traffic.
- 02 / Evidence to request
Who can access it?
An access matrix, key-custody details and a test showing that one department cannot retrieve another department's restricted documents.
- 03 / Evidence to request
Does the complete workflow work offline?
A disconnected test of the agreed workflow, including authentication, document retrieval and model inference. Record any feature that requires a connection.
- 04 / Evidence to request
Can an assistant act without permission?
A permitted action, a denied action and a human approval using least-privilege access. Confirm that denying or revoking approval prevents execution.
- 05 / Evidence to request
Can we independently check the record?
Exported records, verification instructions and a tampering test. Check event coverage, key trust and missing-record detection, not just whether one signature verifies.
- 06 / Evidence to request
What happens when something fails?
Backup restoration, rollback, failed-model and lost-connectivity tests, plus ownership of updates and incident response.
- 07 / Evidence to request
Can we leave, and what will it cost?
A usable data export, model and software licence terms, and a scoped cost covering hardware, deployment, support, evaluation and ongoing operation.
Sovereign AI: frequently asked questions
What is sovereign AI?
Sovereign AI means retaining meaningful control over the data, infrastructure, models and operation of an AI system. For an organisation, that means deciding where information is processed, who can access it and what the system is authorised to do. On-premise and air-gapped deployment can support that control, but are not the whole definition.
What is the difference between sovereign AI and cloud AI?
Cloud describes a hosting model; sovereignty describes control. A cloud service may offer regional processing, dedicated infrastructure and customer-managed keys, but buyers still need to examine access, dependencies and operating terms. On-premise and air-gapped systems can reduce external dependencies, while still requiring evidence of secure operation.
Is sovereign AI the same as on-premise or private AI?
No. On-premise describes location, private describes restricted access or isolation, and air-gapped describes network separation. These properties can overlap. Data residency alone does not establish control over administrators, encryption keys, models or support access. Running an open-source model does not establish control over the application and its connectors either. Examine the whole system and the applicable licences.
Does sovereign AI automatically make an organisation compliant?
No. Deployment location or network isolation alone does not establish compliance. Organisations must assess their own obligations, data handling, access controls, processes and evidence with their security and compliance teams. A signed audit record can support that work; it does not replace it or certify the organisation.
How should we choose a sovereign AI platform?
Choose against your workflows, data restrictions, permissions, integration needs and operating budget. Request a version-specific demonstration, access-denial tests, audit verification, recovery evidence and a usable exit plan. Separate available features from configuration work and roadmap items. Mickai's SIOS proposition connects company knowledge and studios to governed execution; a local chat interface alone does not demonstrate those controls. Patent applications describe claimed inventions, not granted rights, product readiness or security certification.
Can sovereign AI work completely offline?
Yes, when the required models, data and supporting services are available locally and the workflow has no external dependency. Document extraction, retrieval and speech transcription can run locally with suitable components. Test them with external access blocked. New external email, web results and calendar changes need connectivity or controlled transfer; an isolated assistant can only use information already inside its boundary. Offline operation is an option, not the entire definition of sovereignty.
Does running a local language model keep all company data local?
Not by itself. Embedding services, document parsers, speech services, analytics, backups and connectors may still use external systems. Map and test every component that handles information, including failure paths and support tooling, before describing a complete workflow as local or zero-egress.
What does a cryptographically signed audit record prove?
A valid signature can establish record integrity and association with a signing key, subject to key trust and verification. It does not by itself prove that an AI answer is correct, that every event was recorded or that an action was appropriate. Review completeness, authorisation and outcomes separately.
Where should a company new to AI start?
Start with an inventory of data and a short list of valuable, repeatable workflows. Assess sensitivity, document quality, permissions and what success would look like before buying hardware or choosing a model. Mickai's AI Readiness programme helps scope that assessment and identify a practical implementation path.
How much does on-premise AI cost?
Cost depends on workloads, concurrent users, model requirements, existing hardware, data preparation, integrations and support. Ask for a scoped total cost of ownership rather than a model licence alone. Measure quality and response time with representative workloads before committing to infrastructure.
The sovereign AI library
The pillar in brief, then the depth. Start with a definition or a comparison, take a buyer’s checklist into procurement, or read the analysis by sector.
- How to compare on-premise sovereign AI vendors: a buyer's scorecard
- The UK procurement checklist for sovereign AI
- Sizing the sovereign AI market
- Is my AI sovereign? A self-assessment
- What determines the cost of sovereign AI
- How to deploy sovereign AI
- The sovereign AI landscape in 2026
- Sovereign AI by the numbers, 2026
Sources and scope
Reviewed 20 September 2026. This is Mickai's buyer guide, not a certification or an independent vendor ranking. The checklist is a suggested evaluation method. Consult each supplier's current documentation and test your own deployment.
Your next step does not have to be buying a model. Start with the work you want to improve, the information you need to protect and the evidence your organisation requires. Mickai's AI Readiness programme helps turn those questions into a practical deployment brief.