Sovereign AI vs Hosted Enterprise Assistants for Regulated Work
Where your data lands, who keeps the audit log, and whether the assistant still works when the network does not.

Sovereign AI keeps the model, the data, and the audit log inside your own boundary, while hosted enterprise assistants send your prompts to a provider's cloud for processing. For regulated work, that architectural difference decides who can read your inputs, where the record of every action lives, and whether the assistant keeps running when the connection drops. Hosted assistants are fast to adopt and perfectly sensible for non-sensitive tasks. Sovereign AI exists for the material where the answer to 'where did this data go' has to be 'nowhere it should not'.
- Data location is the real dividing line: sovereign AI processes on hardware you control, while hosted assistants process in the provider's cloud.
- The audit log belongs to whoever runs the model. Sovereign keeps it inside your boundary; hosted keeps the authoritative copy in the provider's tenancy.
- Offline capability is architectural, not a setting. A sovereign system answers with the network unplugged; a hosted one cannot.
- Convenience has a place: hosted assistants are excellent for non-sensitive, everyday work.
- Regulated work rewards the boundary you can prove, not the one described in a contract.
Where does your data actually go?
With a hosted enterprise assistant, your prompt, the documents you attach, and often the surrounding context travel to the provider's infrastructure, get processed there, and return as a response. Reputable providers encrypt that traffic and offer contractual assurances about retention and training. Those assurances are real, and for most work they are enough.
Sovereign AI inverts the flow. The model runs on hardware inside your own environment, so the sensitive material never leaves the boundary in the first place. There is no provider tenancy to trust, no cross-border transfer to reason about, and no third party positioned to read the inputs. For a regulated team, the difference is not a percentage of risk removed. It is a category of risk that no longer applies.
Who holds the audit log?
Regulators rarely ask whether a system is clever. They ask who did what, when, and on whose authority, and they expect a record that cannot be quietly edited. In a hosted arrangement, the fullest version of that record often lives in the provider's systems, and you receive an export or an API view of it.
A sovereign system keeps the log where the work happens. Every prompt, retrieval, and action is written to a store you own and control, which means the evidence sits on your side of the boundary from the moment it is created. When an auditor arrives, the chain of custody does not run through anyone else's cloud.
Does it still work when the network does not?
Hosted assistants depend on a live connection to the provider. If the link is down, the provider is throttling, or the site sits in an air-gapped facility, the assistant is unavailable by design. For a lot of offices that is a minor inconvenience. For a control room, a secure facility, or a field deployment, it can be the difference between a working assistant and a dark screen.
Because a sovereign model runs locally, offline is its normal state rather than a failure mode. The assistant answers with the network unplugged, which is exactly the property regulated and security-sensitive environments tend to require before anything gets deployed at all.
Is a hosted assistant ever the right choice?
Often, yes. For drafting public copy, summarising an open document, brainstorming, or any task where the inputs are not sensitive, a hosted assistant is quick to adopt, well supported, and entirely appropriate. Ruling them out everywhere would be a poor trade dressed up as caution.
The honest position is that the two architectures answer different questions. Hosted assistants optimise for reach and convenience. Sovereign AI optimises for control and provenance. The mistake is not choosing one of them, it is using a convenient architecture for material that demanded a controlled one.
What does sovereign AI look like in practice?
A Sovereign Intelligence Operating System, or SIOS, runs the models, the retrieval, and the workspace on infrastructure the organisation controls, so regulated teams get an assistant without exporting the sensitive material that makes their work regulated. Mickai is a SIOS built on this principle, with the model, the brains, and the audit trail held inside the customer boundary. Its approach is backed by 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, and it was founded by Micky Irons to make sovereign AI practical rather than theoretical.
Teams evaluating this for regulated work can apply for the SIOS beta at mickai.co.uk/beta. Access is selective and not every applicant is accepted, because early deployments are matched to environments where the sovereignty story genuinely matters.
Frequently asked questions
Is my data used to train a hosted assistant's model?
It depends on the provider and the agreement. Many enterprise agreements contractually exclude customer inputs from training, and that commitment is usually honoured. The sovereign answer is structurally different: because the model runs inside your boundary, there is no external training pipeline the data could reach, so the question stops being a matter of trust and becomes a matter of architecture.
Can I get compliance-grade audit trails from a hosted assistant?
Frequently, yes, through admin consoles and export APIs. The distinction is custody rather than availability. With a hosted assistant the authoritative log originates in the provider's systems; with a sovereign system it originates and stays in yours, which is the property most regulators and internal auditors prefer to see.
Do I have to give up quality to run AI sovereignly?
No. Modern models that run inside a controlled environment are capable of the drafting, retrieval, and reasoning that regulated teams need. The trade being made concerns where processing happens, not accepting a weaker assistant, and for sensitive work that boundary is usually the point.
How do I decide which architecture suits a given task?
Sort the work by sensitivity. If the inputs are public or low-risk, a hosted assistant is convenient and appropriate. If the inputs are regulated, confidential, or subject to data-residency rules, keep them inside a sovereign boundary. The decision follows the data, not the other way round.
Where can I try a sovereign assistant for regulated work?
Applications for the Mickai SIOS beta are open at mickai.co.uk/beta. The programme is selective and matched to teams with genuine sovereignty requirements, so the assessment focuses on the environment and the regulatory context rather than on volume of sign-ups.