THE SCENARIO
A government agency deploys a national AI diagnostic system across its public health network. The system is celebrated for reducing diagnostic errors by 34% in its first year. Clinicians praise its accuracy. Administrators celebrate the cost savings.
Three years later, the vendor that built the system is acquired by a strategic competitor of the nation’s closest ally. The new owner restricts API access, changes the licensing model, and begins routing inference logs through servers in a third jurisdiction.
The health ministry cannot switch systems — patient histories, trained adaptations, and institutional workflows are all locked into the original platform.
At what point does a tool you adopted become a system that owns you?
We will not let any technology — no matter how capable — make decisions about us that we do not understand, that we cannot audit, and that we cannot reverse. We will not trade our sovereignty for convenience. We will not let our institutions be governed by systems we do not govern. This is the core of the TEE Method — a commitment to test before trusting, to evaluate before adopting, and to exit before being trapped.
The true meaning of Question 2 — Who controls this system? — The true meaning of Question 2 is the pivot point on which sovereignty turns. It is the dividing line between being a user and being a principal. When an entity adopts an AI system, it typically focuses on what the system does — its accuracy, its speed, its cost savings. The TEE Method insists that the entity must also ask: who decides what the system will do tomorrow? Who decides when it updates? Who decides what data it sees? Who decides how it behaves at the margins? These are not technical questions. They are governance questions. And governance questions cannot be delegated to the system, the provider, or the market. They must be answered by the entity that bears the consequences of the system’s decisions.
This question — “Who controls this system?” — is the hinge on which the entire TEE Method turns. It is the question that transforms technical evaluation into sovereignty governance. It is the question that the provider does not want you to ask, because the answer is almost always: not you. The provider controls the updates. The provider controls the data pathways. The provider controls the model weights. The provider controls the deprecation timeline. The provider controls the terms of service. The provider controls the support lifecycle. The entity that asks “Who controls this system?” and answers honestly discovers that it has adopted a governance structure it did not design, cannot modify, and cannot escape.
The TEE Method’s insistence on this question comes from a fundamental observation: control is the precursor to every other sovereignty domain. An entity that does not control its AI systems cannot achieve political sovereignty over them — it cannot make independent governance decisions because the provider makes those decisions through update policies and deprecation schedules. It cannot achieve economic sovereignty — it cannot control costs because the provider sets pricing unilaterally. It cannot achieve cultural sovereignty — it cannot align the system with its values because the provider defines the system’s behaviour. It cannot achieve intellectual sovereignty — it cannot understand the system because the provider controls access to the internals. And it cannot achieve technological sovereignty — it cannot build, adapt, or replace the system because the provider controls the architecture.
Part One: The Three Questions of Sovereignty
The TEE Method is built on three questions that every entity must answer for every technology it adopts. These questions are not optional — they are the architecture of sovereignty. They cannot be delegated to the technology provider, because the technology provider’s interests are not the entity’s interests. They cannot be deferred to a future governance review, because the decisions that create dependency are made at adoption, not at review. And they cannot be answered once — they must be answered continuously, for the entire lifecycle of every technology dependency.
Question 1: Who owns this system?
Ownership is not about legal title. It is about the capacity to decide the system’s future — its development roadmap, its deployment scope, its integration boundaries, its deprecation timeline. If you cannot decide these things, you do not own the system in any meaningful sense. You are a tenant, not a principal. The TEE Method distinguishes between licence ownership — the right to use a system under the provider’s terms — and governance ownership — the right to determine the system’s evolution. Most entities that believe they own their AI systems actually only hold licence ownership. The provider retains governance ownership: the right to update, deprecate, reprice, restrict, or redirect the system without the entity’s consent.
True ownership in the TEE Method sense requires: the right to access and modify source code (for software systems); the right to access and retrain model weights (for AI systems); the right to deploy on infrastructure of the entity’s choosing; the right to integrate with systems of the entity’s choosing; the right to export all data in open, documented formats; and the right to continue operating the system indefinitely without the provider’s ongoing cooperation. Any system that lacks these rights is not owned — it is rented. And rent can be increased, terms can be changed, and tenancies can be terminated. The entity that enters a technology relationship without securing governance ownership has not bought a system — it has entered a tenancy that the landlord can terminate, reprice, or repurpose at will.
Question 2: Who controls this system?
Control is about operational authority. Who decides when the system updates? Who decides what data it processes? Who decides how it behaves at the margins? Control without ownership is fragile; ownership without control is meaningless. The TEE Method requires both. Control manifests in three dimensions: update control — the entity decides when and whether to apply updates, and can test updates in a staging environment before production deployment; data control — the entity decides what data enters the system, what data leaves the system, and where data resides at rest; behavioural control — the entity can configure the system’s decision boundaries, override its outputs, and define its operating constraints.
The loss of control is rarely sudden. It occurs through a sequence of small concessions: the entity accepts automatic updates for “security”; the entity accepts cloud-only deployment for “scalability”; the entity accepts the provider’s data residency options for “compliance”; the entity accepts the provider’s model versioning for “innovation.” Each concession is framed as a benefit. The cumulative effect is the transfer of operational authority from the entity to the provider. The entity that began as the principal becomes the user. The system that began as a tool becomes the governor. The critical insight of the TEE Method is that control is not a static state — it is a continuous discipline. The entity must continuously exercise control through its Test and Evaluate infrastructure, or it will lose control by default to the provider’s automated update mechanisms, opaque data pipelines, and unilateral behavioural changes.
Question 3: Who governs this system?
Governance is about accountability. When the system produces an outcome that harms someone — a misdiagnosis, a biased decision, a security breach — who is accountable? Not in the abstract sense of liability, but in the operational sense of the person who can order the system changed, paused, or shut down. The TEE Method requires explicit governance assignment: a named accountable executive for every AI system; a documented decision-rights matrix for deployment, audit, and shutdown; an independent audit capacity that is not vendor-dependent; and a withdrawal protocol that the governance authority can trigger.
Governance is the discipline that makes Test, Evaluate, and Exit meaningful. Without governance, Test produces data that no one acts on. Without governance, Evaluate produces judgments that no one implements. Without governance, Exit produces protocols that no one triggers. The TEE Method requires that every AI system has a governance charter — a documented assignment of decision rights, accountability, and escalation procedures that is signed by the entity’s governance authority and reviewed quarterly. The governance charter is the mechanism that prevents the drift from principal to user. It makes explicit what is often implicit: who has the authority to say “stop” to an AI system.
Part Two: The Test-Evaluate-Exit Cycle
The TEE Method operationalises these three questions through a continuous cycle that prevents governance from becoming a one-time event. Governance is not a checklist completed at procurement. It is a living discipline that must be sustained for the entire lifecycle of every technology dependency. The cycle is not linear — it is recursive. Test feeds Evaluate, Evaluate informs Exit, Exit creates the leverage that makes Test and Evaluate honest. An entity that Tests but cannot Exit is an entity that produces data for the provider’s benefit. An entity that Evaluates but cannot Exit is an entity that produces judgments it cannot act on. An entity that Exits but has not Tested or Evaluated is an entity that flees without knowing where it is going.
Test: Continuous Measurement Infrastructure
Test is not a pre-deployment checkbox. It is an ongoing measurement infrastructure. Every system must be tested continuously — for technical performance, for alignment with declared objectives, for sovereignty impact, for emerging risks. The Test domain requires entities to establish specific, measurable, auditable criteria for every technology they depend on. These criteria must be defined before adoption, not after. They must be independently verifiable, not vendor-reported. And they must be continuously monitored, not periodically sampled.
The Test domain operates across the seven-layer stack. At Layer 1, the entity tests for hardware provenance, jurisdiction, and failover capacity. At Layer 2, the entity tests for network routing, latency, and interception resistance. At Layer 3, the entity tests for OS integrity, patch currency, and telemetry leakage. At Layer 4, the entity tests for API stability, version compatibility, and deprecation risk. At Layer 5, the entity tests for model drift, bias emergence, capability regression, and adversarial robustness. At Layer 6, the entity tests for data residency, jurisdictional exposure, and access control enforcement. At Layer 7, the entity tests for knowledge concentration, skill atrophy, and vendor dependency. A test infrastructure that covers only Layer 5 is not a TEE Method test infrastructure — it is a technical evaluation that ignores the sovereignty dimensions where dependency actually lives.
Evaluate: Structured Judgment Capacity
Evaluate is the interpretation layer. Raw test data is not governance. Evaluation requires structured criteria that are transparent, consistent, and independent of the technology provider’s claims. It requires the entity to build the judgment capacity to look at test results and ask: what does this mean for our sovereignty? What does this mean for our strategic autonomy? The Evaluate domain requires three capabilities: independent assessment — the ability to evaluate technology performance and risk without relying on vendor-provided assessments; sovereignty impact analysis — every technology adoption decision must include a sovereignty impact assessment across all five domains; continuous reassessment — technology landscapes change rapidly, and the entity must have mechanisms to detect and evaluate those changes.
The critical distinction in the Evaluate domain is between technical evaluation and sovereignty evaluation. Technical evaluation asks: does the system meet its specifications? Sovereignty evaluation asks: does the system’s behaviour preserve or erode the entity’s governance capacity? A system that meets all technical specifications but erodes sovereignty is a failed system in the TEE Method framework. The provider’s dashboards, certifications, and audit reports are technical evaluations. The entity must produce its own sovereignty evaluations. The entity that outsources its evaluation to the provider has not built an Evaluate domain — it has accepted the provider’s self-assessment as governance.
Exit: The Discipline of Withdrawal
Exit is the discipline that makes the cycle sustainable. Every dependency must have a withdrawal protocol — a documented, tested, funded plan for transitioning away. This is not pessimism. It is the structural requirement that makes the other two domains honest. If you cannot exit, your Test and Evaluate are theatre. The provider knows this. The market knows this. Only the entity that has designed its own exit has genuine negotiating power. The Exit domain requires: data export and migration — a verified mechanism for extracting all data in open, portable formats, tested regularly; alternative deployment — for critical systems, identified and piloted alternative solutions; transition timeline — a realistic timeline for complete transition with phased migration; knowledge transfer — a plan for developing internal expertise to operate the alternative; contingency funding — transition funding identified and reserved for critical dependencies.
The Exit domain is the most counterintuitive and the most essential. Organisations plan for success — they do not plan for divorce. But in technology governance, the withdrawal protocol is the prenuptial agreement that makes the marriage equitable. The entity that has a tested withdrawal protocol negotiates from strength: it can reject unfavourable terms, it can demand transparency, it can require governance rights, because it knows it can leave. The entity without a withdrawal protocol negotiates from desperation: it must accept whatever terms the provider offers, because it cannot afford to leave. The TEE Method makes Exit not an act of pessimism but a discipline of sovereignty.
The power inherent in drafting cannot be overstated. Those who write the rules embed their worldview into the infrastructure of governance. Those who merely adopt rules inherit someone else’s assumptions about the future.
— SOVEREIGN: Who Owns the Future? Chapter 18: Multilateral Alignment
The Control Assessment Framework
The following framework enables entities to assess their control position for every AI system they depend on. Control is not binary — it exists on a spectrum. The goal is not perfect control but an honest assessment that reveals where control has been ceded and whether that cession was deliberate or incidental. The framework should be completed by the entity’s governance authority for each critical system, and the results should drive the negotiation and investment priorities for the coming year.
| Control Dimension | Full Control (5) | Partial Control (3) | No Control (1) |
|---|---|---|---|
| Update Authority | Entity decides timing, scope, and rollback | Entity can delay but not reject updates | Provider pushes updates unilaterally |
| Data Sovereignty | Entity controls residency, access, deletion | Entity controls some but not all data flows | Provider controls all data pathways |
| Behavioural Configuration | Entity defines decision boundaries and overrides | Entity configures within provider-defined limits | Provider defines all behavioural parameters |
| Model Access | Full weight access, retraining, reproduction | Fine-tuning via provider infrastructure only | API-only access, no model visibility |
| Deprecation Rights | Entity controls lifecycle, provider cannot deprecate | Provider must give extended notice | Provider can deprecate unilaterally |
| Governance Accountability | Named entity executive with shutdown authority | Shared governance committee with provider | Provider governs, entity accepts |
The Sovereignty Test Matrix
| Sovereignty Domain | Score (1-5) | Assessment Criteria | Evidence Required |
|---|---|---|---|
| Political Sovereignty | ___ / 5 | Can the entity make independent governance decisions? | Documented decision rights, veto authority, policy independence |
| Economic Sovereignty | ___ / 5 | Does the entity control economic terms? | Contractual pricing control, competitive alternatives, cost predictability |
| Cultural Sovereignty | ___ / 5 | Does the system respect cultural context? | Localisation, value alignment, community acceptance |
| Intellectual Sovereignty | ___ / 5 | Does the entity understand the system? | Internal audit capacity, independent evaluation, knowledge distribution |
| Technological Sovereignty | ___ / 5 | Can the entity build/adapt/replace? | Open formats, portability, alternative deployment capability |
Red Flag Checklist: Control Erosion Indicators
If three or more of the following indicators apply, the entity has lost operational control of the system and must initiate an urgent control recovery assessment.
- Update Surprise: The system updates without entity notification or consent, changing behaviour in production.
- Data Drift: Data flows to jurisdictions, systems, or parties not approved by the entity’s governance authority.
- Behavioural Lock: The entity cannot override, configure, or constrain a system output that affects a core function.
- Model Opacity: The entity cannot access, audit, or reproduce the model that drives a critical decision.
- Deprecation Threat: The provider has signalled or executed deprecation of a capability the entity depends on.
- Governance Vacuum: No named entity executive can order the system paused, modified, or shut down.
- Audit Denial: The entity’s independent auditors are denied access to system internals, logs, or model weights.
- Exit Blockage: The entity cannot extract data, workloads, or configurations in open formats within a defined timeline.
If three or more indicators apply, the entity has lost control and must treat the system as a governance emergency.
Phased Control Recovery Framework
| Phase | Timeframe | Key Actions | Deliverable |
|---|---|---|---|
| Phase 1: Control Mapping | Weeks 1-2 | Complete Control Assessment Framework for all critical systems; identify all dimensions where control has been ceded; document provider dependencies for each ceded dimension | Control Dependency Map with scored assessment |
| Phase 2: Negotiation Leverage | Months 1-2 | Use Exit domain preparation as negotiation leverage; demand contractual control rights; establish independent audit rights; negotiate data sovereignty provisions | Renegotiated contracts with explicit control rights |
| Phase 3: Alternative Development | Months 3-9 | Build or acquire alternative capabilities for each ceded control dimension; test withdrawal protocols; develop internal expertise for previously outsourced control functions | Operational alternatives with verified control |
| Phase 4: Control Institutionalisation | Months 10-18 | Embed control assessment into all procurement; establish continuous control monitoring; build internal control capabilities as core organisational competency | Self-sustaining control governance infrastructure |
This question — “Who controls this system?” — is the hinge on which the entire TEE Method turns. It is the question that transforms technical evaluation into sovereignty governance. It is the question that the provider does not want you to ask, because the answer is almost always: not you. The provider controls the updates. The provider controls the data pathways. The provider controls the model weights. The provider controls the deprecation timeline. The provider controls the terms of service. The provider controls the support lifecycle. The entity that asks “Who controls this system?” and answers honestly discovers that it has adopted a governance structure it did not design, cannot modify, and cannot escape.
The TEE Method’s insistence on this question comes from a fundamental observation: control is the precursor to every other sovereignty domain. An entity that does not control its AI systems cannot achieve political sovereignty over them — it cannot make independent governance decisions because the provider makes those decisions through update policies and deprecation schedules. It cannot achieve economic sovereignty — it cannot control costs because the provider sets pricing unilaterally. It cannot achieve cultural sovereignty — it cannot align the system with its values because the provider defines the system’s behaviour. It cannot achieve intellectual sovereignty — it cannot understand the system because the provider controls access to the internals. And it cannot achieve technological sovereignty — it cannot build, adapt, or replace the system because the provider controls the architecture.
The progression from Question 1 (Who owns this system?) to Question 2 (Who controls this system?) to Question 3 (Who governs this system?) is not academic. It is the operational sequence of sovereignty loss. First, the entity surrenders ownership by accepting licence-only terms. Then, the entity surrenders control by accepting provider-managed updates, data flows, and behavioural parameters. Finally, the entity surrenders governance by accepting that the provider is the accountable party — or worse, that no one is accountable. The TEE Method interrupts this progression at Question 2 because control is the last point of intervention. Once governance is surrendered, the entity has no authority to reclaim ownership or control. But if the entity asserts control — by demanding update authority, data sovereignty, behavioural configurability, model access, deprecation rights, and governance accountability — it can still recover ownership and establish governance.
This is why the Control Assessment Framework focuses on six operational dimensions rather than abstract principles. Each dimension represents a concrete control point that the entity can negotiate, contract for, and technically enforce. Update authority means the entity has a staging environment, a rollback capability, and a contractual right to reject updates. Data sovereignty means the entity controls encryption keys, residency decisions, and access logs. Behavioural configuration means the entity can define decision boundaries, override outputs, and constrain operating parameters. Model access means the entity can inspect weights, audit behaviour, and reproduce the model. Deprecation rights means the entity controls the lifecycle timeline. Governance accountability means a named entity executive can order the system paused, modified, or shut down. These are not aspirations. They are contractual and technical requirements. The entity that cannot answer “yes” to these six dimensions does not control its AI systems — it uses them at the provider’s sufferance.
The red flag checklist operationalises the control assessment into an early warning system. “Update Surprise” means the system changed without the entity’s knowledge or consent — this is the most common and most dangerous indicator, because it means the provider’s automated update mechanism has operational authority over the entity’s production environment. “Data Drift” means data flowed to jurisdictions or parties the entity did not approve — this is the indicator that the entity has lost Layer 6 sovereignty. “Behavioural Lock” means the entity cannot constrain a system output affecting a core function — this is the indicator that the entity has lost behavioural control. “Model Opacity” means the entity cannot access the model driving critical decisions — this is the indicator that the entity has lost Layer 5 sovereignty. “Deprecation Threat” means the provider has signalled end-of-life for a capability the entity depends on — this is the indicator that the entity has no deprecation rights. “Governance Vacuum” means no one in the entity can order the system stopped — this is the indicator that Question 3 has no answer. “Audit Denial” means the entity’s own auditors cannot access system internals — this is the indicator that the entity has lost intellectual sovereignty. “Exit Blockage” means the entity cannot extract its data and workloads — this is the indicator that the entity has lost Exit domain capability. Each of these indicators, on its own, is a governance failure. Three or more together is a governance emergency.
The Closing Question
At what point does a tool you adopted become a system that owns you?
The answer is not a moment — it is a process. The process begins when the entity accepts the first concession: automatic updates, cloud-only deployment, API-only access, vendor-managed certification. It accelerates when the entity reorganises its workflows around the provider’s architecture. It completes when the entity discovers it cannot leave. The TEE Method exists to interrupt this process at every stage. The entity that tests before adopting, evaluates before trusting, and designs its exit before entering — that entity remains a principal. The entity that does not — becomes a user. The choice is not between technology and sovereignty. The choice is between governance by design and governance by accident.
This article draws on the TEE Method framework from SOVEREIGN: Who Owns the Future? The Control Assessment Framework, red flag checklist, and recovery framework presented here are practical tools derived from the TEE Method for entities committed to retaining operational control of their AI systems.
For the complete framework, including detailed control assessment protocols, layer-by-layer sovereignty auditing, and control recovery procedures for organisations of all sizes, see SOVEREIGN: Who Owns the Future? — available at tonishatagoe.com.