The Governance Gap: Why AI Safety Testing Never Tests for Sovereignty
Every major jurisdiction now mandates AI safety testing before public sector deployment. Every testing framework measures accuracy, bias, robustness, and explainability. Every framework assumes that passing these tests constitutes adequate governance. Every framework is wrong. The thing that determines whether an AI system serves a nation’s long-term interests — sovereignty — is the one variable that no safety testing framework measures. This is not an oversight. It is a structural gap in the architecture of AI governance, and it is widening with every new framework that is adopted without it.
THE SCENARIO
A government ministry procures a cloud-based AI system for processing citizen tax appeals. The procurement contract requires the vendor to submit an independent safety audit demonstrating compliance with the jurisdiction’s AI risk management framework. The audit covers bias testing across protected demographic categories, robustness to adversarial inputs, explainability of model decisions, and data privacy compliance. The audit passes. The system is deployed. Three years later, a parliamentary inquiry into digital sovereignty discovers that the vendor — a foreign corporation — retains unilateral authority to update model weights, modify safety thresholds, and suspend service access. The ministry’s own audit never asked who controls the system. The testing framework had no column for sovereignty. The governance was comprehensive by the standards of the framework. The framework itself was the gap.
The Question
Every leader charged with AI governance, every regulator drafting compliance requirements, and every procurement officer signing deployment contracts must answer one question: why does the global architecture of AI safety testing test for everything except who controls the system, and what does that omission cost the nations that rely on it?
This is not a theoretical concern. It is the structural reality of AI governance as it exists today, and the consequences are already accumulating in government ministries, public hospitals, national statistical agencies, and defence procurement offices across the globe. Understanding the gap requires examining how safety testing frameworks are constructed, what they were designed to measure, what they leave unmeasured, and how nations can close the sovereignty deficit without abandoning safety testing entirely.
Part One: What AI Safety Testing Was Designed to Measure
Contemporary AI safety testing emerged from a convergence of three intellectual traditions. The first is software quality assurance, which asks whether a system performs its specified functions correctly. The second is algorithmic fairness, which asks whether a system produces disparate outcomes across protected groups. The third is cybersecurity, which asks whether a system is resistant to adversarial manipulation. These traditions share a common assumption: the system under test is a technical artefact, and governance consists of verifying that the artefact meets technical specifications. This assumption is appropriate for a compiler, a database, or an email server. It is catastrophically insufficient for an AI system that will make decisions about citizens’ tax liabilities, healthcare eligibility, or border security clearance.
The NIST AI Risk Management Framework, widely regarded as the most comprehensive approach to AI governance, identifies seven characteristics of trustworthy AI: valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. Notice what is absent from this list. There is no category for who owns the system, who can modify it, who can withdraw it, or who sets the terms under which it operates. Trustworthiness, in this framework, is a property of the system’s behaviour, not a property of the governance relationships that surround it. A system can be simultaneously trustworthy by every NIST metric and entirely controlled by a foreign entity that owes no duty of care to the citizens whose data it processes. The framework would call that system trustworthy. The citizens affected by it would call it something else.
The EU AI Act, the most ambitious regulatory framework for AI to date, classifies AI systems by risk level and imposes obligations proportionate to that classification. High-risk systems must undergo conformity assessments, maintain technical documentation, and enable human oversight. But the Act’s entire architecture rests on the assumption that the regulated entity is within the EU’s jurisdictional reach. When a high-risk AI system is provided by a non-EU vendor who controls model weights, training data, update cadence, and service continuity from outside the EU’s enforcement perimeter, the Act’s provisions become administrative exercises rather than governance instruments. The regulator can inspect the documentation. The regulator cannot inspect the training pipeline. The regulator can mandate human oversight. The regulator cannot mandate that the human overseer has the technical capability to override the system. The regulator can require a conformity assessment. The regulator cannot require that the conformity assessor has investigated the sovereignty implications of the system’s ownership structure.
This is the governance gap in its purest form. The frameworks test for what they were designed to test for. They were not designed to test for sovereignty because sovereignty was never placed in the diagnostic frame. The omission is not malicious. It is structural. The people who write safety testing standards are computer scientists, statisticians, and software engineers. They think about systems in terms of inputs, outputs, and performance metrics. They do not think about systems in terms of jurisdiction, dependency, and exit readiness. The result is an entire global architecture of AI governance that measures everything except the one variable that determines whether a system serves a nation or serves a foreign corporation.
Part Two: The Seven-Layer Stack Audit
Understanding what safety testing misses requires examining the AI system not as a single artefact but as a stack of dependencies. The Seven-Layer Stack Audit, developed in the SOVEREIGN framework, maps every dependency layer from infrastructure to governance and asks who controls each layer. At the infrastructure layer, the question is whether the physical compute resources — servers, networking equipment, data centres — are owned, leased, or rented from entities under domestic jurisdiction or foreign control. Many nations operate sovereign data centres. Few own the firmware that runs the networking switches inside them. The infrastructure layer is often the most visible and therefore the most frequently audited. It is also the least determinative of actual sovereignty.
The compute layer sits above infrastructure and asks who controls the processing capacity. A nation may own a data centre but rent GPU clusters from a foreign cloud provider operating within that data centre. The compute is physically local. The control over compute allocation, pricing, and availability sits with the provider. When the provider decides to prioritise a different customer — perhaps one in its home jurisdiction — the nation’s compute resources are degraded without notice. Safety testing does not ask whether compute availability is contractually guaranteed or subject to unilateral provider discretion. It assumes compute is available and tests what happens when it is. That assumption is a sovereignty blind spot.
The data layer is the third level and the one where sovereignty concerns are most commonly acknowledged, if not always addressed. Data localisation laws require that citizen data remain within national borders. These laws are necessary but insufficient. Storing data domestically does not prevent a foreign vendor from training models on that data if the contractual terms permit it. It does not prevent the vendor from creating derived datasets that are not technically the original data but capture its essential patterns. It does not prevent the vendor from using metadata — query logs, interaction patterns, system telemetry — to build intelligence about the nation’s institutional operations. Safety testing checks for data privacy compliance. It does not check for data sovereignty. The distinction is existential.
The model layer is where the sovereignty failure concentrates. Every AI system operates on a model — a set of weights, a training architecture, a deployment configuration. The question of who controls the model is the central sovereignty question, and it is the question that safety testing frameworks systematically avoid. A model can be hosted within a nation’s borders while the entity that trained it, owns the weights, determines the update cadence, and selects the training data operates from outside that nation’s jurisdiction. The model is physically present. The control over it is not. Safety testing evaluates the model’s outputs. It does not evaluate the model’s governance. A model that passes every bias test, every robustness benchmark, and every explainability requirement can still be a model that a foreign entity can withdraw, degrade, or redirect at will. The testing framework would call it compliant. The sovereignty framework would call it captured.
The application layer is where the AI system interfaces with the end user, whether a citizen, a civil servant, or an automated system. Application sovereignty asks who controls the user interface, the integration architecture, and the workflow logic. A foreign vendor may provide an application layer that appears to be tailored to the nation’s requirements while the underlying API calls, data routing, and processing logic are controlled by the vendor’s cloud infrastructure. Safety testing checks whether the application produces correct outputs. It does not check whether the application could be migrated to a different backend without catastrophic disruption. The cost of migration — the exit cost — is a sovereignty metric. Safety testing frameworks do not measure it.
The governance layer is the sixth, and it is the layer at which the entire sovereignty analysis must converge. Governance sovereignty asks who sets the rules, who enforces them, who adjudicates disputes, and who can change the rules without the nation’s consent. A vendor’s terms of service are a governance document. A cloud provider’s acceptable use policy is a governance document. A model developer’s update policy is a governance document. When these documents are written by foreign entities, governed by foreign law, and enforceable only in foreign courts, the governance layer has been outsourced. The safety testing framework may require documentation. It cannot require that the documentation is written by an entity accountable to the nation’s democratic institutions. Governance is not a technical specification. It is a sovereignty question, and safety testing frameworks were never designed to answer it.
The seventh and most overlooked layer is the knowledge layer. Knowledge sovereignty asks who understands the system, who can modify it, who can train the next generation of operators, and who can explain its behaviour to a parliamentary committee without relying on the vendor’s documentation. Knowledge transfer is not the same as training. Training produces users. Knowledge transfer produces sovereign capability. Safety testing frameworks do not measure knowledge sovereignty. They assume that documentation suffices. Documentation written by a foreign vendor for compliance purposes does not produce sovereign capability. It produces documented dependency.
Part Three: The Sovereignty Test Matrix Applied
The TEE Method — Test, Evaluate, Exit — provides an architecture for closing the governance gap, not by replacing safety testing but by adding what it omits. Under this framework, every AI procurement is assessed across five domains, each scored on a scale of one to five, producing a composite sovereignty score out of twenty-five. A system that scores fifteen or above is on a trajectory toward sovereign deployment. A system that scores below ten is a sovereignty liability regardless of what the safety testing framework says about its technical performance.
The first domain is Strategic Alignment. It asks whether the AI system serves the nation’s strategic interests or the provider’s. A system that advances a foreign corporation’s market position while processing citizen data is not strategically aligned, regardless of its accuracy metrics. Strategic alignment requires that the procurement decision be made with reference to a national AI strategy, not merely a technical requirements document. Many nations have AI strategies. Few connect those strategies to individual procurement decisions. The disconnect is a sovereignty vulnerability at the strategic level.
The second domain is Technical Performance, and it is the domain that safety testing frameworks address most directly. Accuracy, robustness, reliability, and fairness are all Technical Performance metrics, and they are all necessary. But Technical Performance must be independently verifiable. A vendor’s self-reported benchmarks are not verification. A certification from a body that the vendor selected and paid is not independent. Technical Performance sovereignty requires that the nation possess the institutional capability to test the system independently — to run its own benchmarks, to audit its own data, to verify its own outputs. If the only entity that can verify whether the system works is the entity that sold it, Technical Performance sovereignty has been surrendered.
The third domain is Ethical Compliance, and it is the domain where the gap between safety testing and sovereignty is most visible. Ethical Compliance asks whether the system’s ethical safeguards are genuine, enforceable, and aligned with the nation’s values. A vendor’s ethics policy is not a safeguard. A terms-of-service prohibition on harmful use is not enforceable if the enforcement mechanism is the vendor’s discretion. Ethical Compliance sovereignty requires that the nation can define, enforce, and update ethical standards without the vendor’s permission. If the vendor can veto an ethical requirement by threatening to withdraw service, the ethical framework is not the nation’s. It is the vendor’s, on loan.
The fourth domain is Sovereignty Impact, and it is the domain that safety testing frameworks ignore entirely. Sovereignty Impact asks whether the system increases or decreases the nation’s control over its own digital infrastructure. A system that is more accurate, more robust, and more fair than any domestic alternative may still have a negative Sovereignty Impact if it entrenches dependency on a foreign vendor. The Sovereignty Impact score is calculated across the Seven-Layer Stack: infrastructure control, compute control, data control, model control, application control, governance control, and knowledge control. A deficit at any layer reduces the overall score. A deficit at multiple layers is a structural sovereignty failure, not a procurement shortcoming.
The fifth domain is Cultural Alignment, and it asks whether the system respects the nation’s cultural, regulatory, and operational context. A system trained on a dataset that reflects the demographic, linguistic, and institutional patterns of a foreign country will encode those patterns in its outputs, even if it passes bias tests. Bias testing measures disparity. It does not measure cultural misalignment. A system can be unbiased by every statistical measure and still produce outputs that reflect assumptions, values, and operational logics that are foreign to the nation that deploys it. Cultural Alignment is not a technical property. It is a sovereignty property, and it must be assessed as such.
Part Four: Closing the Governance Gap
The governance gap between safety testing and sovereignty assessment cannot be closed by adding a sovereignty column to existing safety testing frameworks. The gap is structural, not additive. Closing it requires building a parallel architecture: a Sovereignty Impact Assessment that runs alongside every safety test, evaluates every procurement decision, and produces a score that is given equal weight to the safety score. A system that is safe but not sovereign is not a safe system for the nation that deploys it. It is a safe system for the vendor that controls it.
Red Flag Checklist
Any AI procurement or deployment should trigger immediate sovereignty review if five or more of the following conditions apply. If seven or more apply, the dependency is not a future risk. It is an existing condition that requires immediate remediation.
First, the vendor retains unilateral authority to modify model weights without the deploying entity’s approval. Second, the training data cannot be inspected by the deploying entity’s auditors. Third, the vendor can suspend service access without judicial review in the deploying entity’s jurisdiction. Fourth, the system’s safety testing was conducted by a body selected and paid by the vendor. Fifth, the deploying entity has no independent capability to verify the system’s outputs against a known baseline. Sixth, the vendor’s terms of service are governed by a foreign legal system that the deploying entity cannot enforce. Seventh, the vendor can change the terms of service unilaterally with notice but without consent. Eighth, the deploying entity cannot migrate the system to a different infrastructure provider without vendor assistance. Ninth, the deploying entity’s staff cannot explain the system’s core architecture to a parliamentary committee without vendor documentation. Tenth, the vendor’s home jurisdiction has laws that compel the vendor to provide access to the deploying entity’s data upon request from the vendor’s government. Eleventh, the deploying entity has no contractual right to the model weights, training methodology, or update log. Twelfth, the deploying entity has no exit plan documented and tested within the last twelve months.
If five or more of these conditions apply, the procurement is a sovereignty liability. If seven or more apply, the dependency is structural and requires a phased remediation plan, not merely enhanced monitoring. If ten or more apply, the deploying entity does not control its own AI system. It is operating a system on behalf of the vendor, and the vendor retains sovereign control over the system’s future.
Phased Implementation Framework
Closing the governance gap requires action across four phases, each building on the capabilities developed in the previous phase. Phase One, spanning the first ninety days, establishes the diagnostic baseline. Every AI system currently deployed in public services must undergo a Seven-Layer Stack Audit and a Sovereignty Test Matrix assessment. The audit must be conducted by an entity independent of the vendor and independent of the procurement authority. The output is not a compliance certificate. It is a sovereignty scorecard that identifies which layers are sovereign and which layers are captured. Phase One does not remediate anything. It creates the evidence base that makes remediation possible.
Phase Two, spanning months four through twelve, develops exit capability for the highest-risk systems identified in Phase One. Exit capability requires three elements: a documented migration pathway to a sovereign alternative, a trained workforce capable of executing the migration, and a contractual right to extract all data, model artefacts, and operational knowledge from the vendor without penalty. Exit capability does not mean the migration is executed immediately. It means the option exists and is maintained. A system for which no exit pathway exists is a system for which sovereignty has been permanently surrendered. Phase Two ensures that every high-risk system has an exit pathway that is documented, tested, and maintained.
Phase Three, spanning months thirteen through twenty-four, integrates sovereignty assessment into the procurement process itself. Every request for proposals for AI systems must include a Sovereignty Impact Assessment requirement with equal weighting to safety and performance requirements. Vendors must disclose their ownership structure, update authority, data governance, and service continuity provisions as part of the proposal. Procurement officers must be trained in sovereignty assessment, not merely technical evaluation. The procurement process itself becomes a sovereignty mechanism, not merely a commercial transaction.
Phase Four, beginning at month twenty-four and continuing indefinitely, establishes continuous sovereignty monitoring. Sovereignty is not a one-time certification. Vendor ownership structures change. Terms of service are updated. Model architectures evolve. A system that was sovereign at procurement may not be sovereign two years later if the vendor has been acquired, if the terms of service have been amended, or if the model has been updated in ways that alter the dependency relationship. Continuous monitoring requires annual Seven-Layer Stack Audits, quarterly contract reviews, and a standing capability to initiate exit procedures if the sovereignty score falls below the acceptable threshold.
The Question Revisited
The governance gap between safety testing and sovereignty assessment is not a gap in knowledge. It is a gap in architecture. The frameworks exist to measure technical performance. The frameworks do not exist to measure sovereignty. Building the sovereignty architecture — the Seven-Layer Stack Audit, the Sovereignty Test Matrix, the Red Flag Checklist, the Phased Implementation Framework — is the task that every nation must undertake, not as a supplement to safety testing but as its equal partner. A system that is safe but not sovereign is not safe for the nation that deploys it. The question is not whether sovereignty assessment is important. The question is whether any nation can afford to continue deploying AI systems without it.
This article draws on the TEE Method™ framework and the Seven-Layer Stack Audit from SOVEREIGN: Who Owns the Future?