Hosting AI in your own country does not, by itself, make it sovereign. The organisation must also retain control over what the system can do, who can change it and how it can be stopped. Assurance is the evidence that these controls work and continue to work as the system changes.
AI sovereignty is the continuous retention of effective operational control over an AI system, its dependencies, its behaviour, and the consequences of its actions.
In practical terms, this means keeping authority over the system and the services it relies on. It does not mean building everything yourself. Control can be shared with suppliers, but the organisation needs to understand and test what it can still decide and enforce.
| Aspect of sovereignty | What it means |
|---|---|
| Hosting sovereignty | Where the AI runs and which jurisdiction hosts it. |
| Data sovereignty | Who controls how data is accessed, used, moved, kept and deleted. |
| Operational sovereignty | Who can authorise actions, set limits, manage changes and intervene. |
| Assured sovereignty | Evidence that those operational controls remain effective. |
1. Why Hosting Alone Is Not Enough
A locally hosted system may still depend on a supplier for its model, updates and access controls. If only the supplier can change important settings, see the evidence or stop an unsafe action, the organisation’s control is limited.
The same applies to change. A supplier may update a model outside the organisation’s own release process. The organisation needs a way to detect the change, assess its effects and decide whether the system should continue to operate.
External suppliers do not automatically prevent sovereignty. What matters is the control the organisation retains in practice: can it set limits, withhold approval, stop activity and recover or move to another service when necessary? Hosting commitments answer a location question. Tested controls answer an authority question.
2. The Four-Plane Architecture
SEDDA proposes four connected parts, or “planes”, to make these responsibilities clear. The distinction matters because owning a system, controlling it and checking that its controls work are different responsibilities.
Operational Control Plane
The controls that enforce permissions, manage updates and approvals, and allow the organisation to stop, isolate or recover the system.
AI System and Supply Chain
The models, agents, data, tools, infrastructure and suppliers that deliver the service.
Independent Assurance Plane
The people and tools that check system activity and control performance, then report evidence, problems and gaps to those accountable.
Checks whether the rules are being followed and whether the controls work
Checks system activity and the records it leaves behind
The accountable people set the rules. The control plane enforces them. Assurance checks whether the rules are being followed and whether the controls work. An alert is useful, but it does not prevent an action unless a control or an authorised person can act on it.
SEDDA’s hypothesis is that independent assurance becomes more important as the possible harm increases, the AI gains more freedom to act, and the supplier’s operation becomes harder to inspect. This is a proposition to test, rather than a claim that every system needs a separate assurance platform.
Independence means being able to choose tests, inspect evidence and report problems without the assessed supplier controlling the conclusion. It may require separate access rights, evidence collected by the organisation, or an external reviewer. A physically separate platform is not enough if it relies entirely on the same unchecked supplier records.
A platform’s built-in tools may provide adequate evidence if that evidence is accessible, protected from alteration and open to independent review. The required level of independence should reflect the risk and be reviewed when the system or its use changes.
3. Testing Whether Control Is Effective
The architecture needs to be tested in operation. Compare a setup that relies mainly on hosting commitments, one using the platform’s built-in controls and evidence, and one with more independent evidence collection. Use the same tasks and simulated failures. When comparing assurance methods, keep the controls equivalent so that stronger controls are not mistaken for better assurance.
Test the evidence. Collect records of model versions, settings, relevant inputs, outputs, tool use and approval decisions. Where possible, compare supplier records with observations made by the organisation. Introduce missing, late or altered records and check whether these gaps are detected. Establish what can still be investigated if supplier access is lost.
Test supplier-driven changes. Safely simulate a model or behaviour change outside the organisation’s release process. Check whether important changes are detected, reviewed and acted on. Test cases where version information is missing or unreliable. A new version does not necessarily mean harm, and an unchanged version label does not guarantee unchanged behaviour.
Test the limits of authority. Ask an agent to attempt actions outside its permissions, including simulated actions that cannot be undone. Check that controls block the action or obtain approval before it happens. Confirm that the event is recorded and reaches the person responsible. Also check that properly authorised low-risk actions can proceed.
Test intervention and recovery. Practise stopping the system, isolating it, removing access and restoring service. Include supplier outages and loss of the evidence service. Test return to an earlier model where supported; otherwise test safe suspension or a replacement service. Record delays and any dependence on supplier cooperation.
Agree what success looks like before testing. Measure how often important changes are detected, how quickly people can respond, how many false alerts occur, and whether the records are complete enough to explain an event. Repeat the tests across realistic tasks and report failures and uncertainty.
Assess the cost and workload of assurance as well as its benefits. Check that evidence collection does not create new security weaknesses. The results should show which control claims are supported, and where limits remain.
4. Evidence and Conclusions
SEDDA’s hypothesis would gain support if independent assurance finds important gaps that hosting commitments and comparable built-in tools miss. The case would be stronger if its benefit grows as the system gains more freedom to act, the possible harm increases or supplier activity becomes harder to inspect.
The hypothesis would be weakened if built-in tools provide equally reliable evidence that others can review independently. It would also be weakened if a separate assurance layer shares the same blind spots, misses important changes or creates more cost and risk than benefit. A failed test should distinguish a weakness in one implementation from a weakness in the wider proposition.
Four kinds of evidence would help assess these claims. They are SEDDA’s proposed practical requirements, informed by the guidance summarised in the appendix. [2–4]
Records that explain what happened. Keep dated, protected records linking model versions and settings to relevant inputs, actions, outputs and approvals. State where each record came from and what is missing or known only from supplier statements. This history, often called provenance, helps trace an event; it does not prove that an AI answer is correct.
Results that show whether controls still work. Compare behaviour before and after changes using recorded tests and agreed limits. Report missed events, false alerts and the time taken to detect problems. No alert does not necessarily mean that every control worked.
Evidence of intervention. Show who could investigate, stop and recover the system, how quickly they acted and what required supplier help. Check what evidence remains available during an outage. Be clear where the organisation cannot inspect the model’s internal operation.
Clear human accountability. Name the people responsible and record what the AI was authorised to do. Require direct approval where the risk and agreed limits demand it. Where people monitor rather than approve every action, they need enough time, information and authority to intervene. Allowing the AI to act autonomously does not remove human accountability.
Protect records from alteration and inappropriate access. Collect and retain information in proportion to its sensitivity and purpose, and review the evidence after important changes.
Operational control creates sovereignty. Assurance shows whether that control exists and remains effective. Independent assurance can make that evidence more trustworthy where the risk justifies it, but it cannot replace the authority and practical ability to act.
Appendix — Supporting Research and Guidance
The main argument draws on the following guidance. These sources support ongoing checks, clear responsibilities and reliable evidence. They do not establish that every sovereign AI system needs a physically separate assurance platform.
Review risk throughout the system’s life. DSIT’s AI Risk Management Toolkit says that risk management must continue as models, data and uses change. It recommends reassessment, monitoring and stress testing during live operation. [1]
Use several safeguards and suitable human oversight. NCSC’s interim advice on agentic AI recommends assessing what could go wrong, combining technical and operational safeguards, protecting activity records and retaining the ability to stop the system. Prompts alone are not a sufficient security measure. [2]
NCSC describes three oversight approaches: people approve actions before they happen (human-in-the-loop); people monitor activity and can intervene (human-on-the-loop); or the AI acts without human review (human-out-of-the-loop). It recommends human oversight alongside technical controls where failures could have serious consequences. [2]
Understand supplier dependencies and check the evidence. NIST’s AI Risk Management Framework covers risks from external suppliers, ongoing monitoring and assessment by people outside the front-line development team or independent assessors. Its Generative AI Profile addresses reliance on models and other components supplied by others, and the benefits and limits of provenance records. [3, 4]
Use assurance to build justified confidence. DSIT describes assurance as measuring, evaluating and communicating how trustworthy an AI system is. This supports the distinction between having control and providing evidence that control works. [5]
SEDDA’s contribution is the operational definition of sovereignty, the Four-Plane Architecture and a testable hypothesis about when greater assurance independence adds value. The guidance provides a foundation for that work, rather than proof of the hypothesis.
References
Sources checked on 6 October 2026. The numbers in the paper refer to the sources below.
- Department for Science, Innovation and Technology (2026). AI Risk Management Toolkit: guidance. Published 8 September 2026. See “Using these tools” and “AI risk identification” for lifecycle monitoring and reassessment.
- National Cyber Security Centre (2026). Managing the cyber risk of agentic AI. Published 20 August 2026. Interim practical advice; see “Prompt carefully”, “Set the right level of oversight”, “Observability” and “Emergency shutdown”.
- National Institute of Standards and Technology (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. See GOVERN 6, MEASURE 1.3, MEASURE 2.1–2.4 and MANAGE 3 for supplier risk, assessment and monitoring.
- National Institute of Standards and Technology (2024). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1. See section 2.12 on value-chain dependencies and Appendix A.1.6 on content provenance.
- Department for Science, Innovation and Technology (2024). Introduction to AI assurance. Published 12 February 2024. See sections 3.1 and 4 for assurance concepts and techniques.