What Most People Get Wrong About Technology Dependency

• Strategic Alignment: Does the system advance the entity’s defined objectives, or does it subtly reshape those objectives to fit the system’s capabilities? Has the entity’s strategy been rewritten to accommodate the system’s limitations?
• Sovereignty Impact: Does deployment strengthen or weaken the entity’s position across the five domains of the Sovereignty Test Matrix™? Is the trajectory toward sovereignty or toward deeper dependency?
• Geopolitical Exposure: Does the system create vulnerabilities to foreign jurisdiction, sanctions regimes, or diplomatic pressure? Can the provider be compelled by its home government to act against the entity’s interests?
• Economic Value Capture: What percentage of the value generated by the system accrues to the entity versus the provider? Is the entity capturing data value, talent value, or market intelligence value? Or is the entity subsidising the provider’s global model improvement?
• Adaptive Capacity: Can the entity modify, extend, or replace the system without provider permission? Does the entity own the integration layer, the data pipeline, and the evaluation framework? Can the entity switch providers without rewriting its operational architecture?

The EVALUATE phase produces a Strategic Alignment Rating: FAVOURABLE (28–35), ACCEPTABLE (21–27), CONCERNING (14–20), or UNFAVOURABLE (7–13). Systems rated CONCERNING require structural modifications within six months. Systems rated UNFAVOURABLE require exit initiation within twelve months.

Phase 3: EVOLVE — The Adaptive Governance

Evolution is the development of the entity’s capacity to shape its own technological trajectory, rather than merely responding to trajectories set by external providers. It requires three structural commitments that must be sustained across political cycles, budget cycles, and leadership transitions.

• Building Capability: Progressive investment in domestic AI research, development, and deployment capacity — starting with applications, extending to models, ultimately to infrastructure. The entity that builds understands what it buys. The entity that only buys understands only what it is sold.
• Governance Discipline: Institutionalising the TEST and EVALUATE phases as mandatory, recurring processes with defined authority, resources, and accountability. Governance that depends on individual champions fails when champions depart. Governance that depends on institutional structures endures.
• Strategic Diversification: Multi-provider strategies that prevent any single provider from becoming irreplaceable. Open-format requirements that ensure data and workflows can be migrated. Regular exit testing that verifies withdrawal capability. Contractual protections that limit the provider’s ability to increase switching costs.

The mathematics are unambiguous. Governance is cheaper than dependency. Prevention is cheaper than remediation. Sovereignty is cheaper than subjection.

Action Plan: From Diagnosis to Sovereignty

Week 1–2: Commission the Sovereignty Inventory

Assign a cross-functional team (technology, governance, legal, operations, finance) to conduct a comprehensive inventory of every AI system in use or under consideration. For each system, document: provider, jurisdiction, data flows, integration depth, contractual terms, criticality rating, and current sovereignty score across all five domains. The inventory alone is a revelation — senior officials are visibly surprised by the number of unknown dependencies.

Week 3–4: Apply the Sovereignty Test Matrix™

Score each critical system across the five domains. Identify systems scoring below 15/25 — these require immediate governance intervention. Identify systems scoring below 10/25 — these require exit planning. Document the specific domain weaknesses for each system. A system may score well on Infrastructure but critically on Data Sovereignty. The domain-level granularity tells you where to act.

Week 5–8: Negotiate Structural Modifications

For systems scoring 10–14, engage providers with specific, non-negotiable requirements: data localisation for sensitive workloads, open-format export capabilities, contractual exit provisions with defined timelines, knowledge transfer commitments, and independent audit rights. Providers unwilling to negotiate reveal their true position. Providers willing to negotiate demonstrate that sovereignty-respecting terms are commercially viable — they just aren’t the default.

Week 9–12: Initiate Building Programme

Identify the highest-priority system for domestic replacement or supplementation. Commission a feasibility study for internal development or partnership with a sovereign-aligned provider. Begin workforce development: recruit or train AI auditors, policy technologists, and builders. Establish the governance authority with mandate, budget, and accountability. The first building project need not be ambitious — a single application, fine-tuned on local data, deployed on domestic infrastructure, governed by domestic policy — proves the model and builds the capability.

Month 4–6: Institutionalise the TEE Cycle

Implement quarterly TEST cycles for all critical systems. Implement annual EVALUATE reviews with board/ministerial oversight. Establish EVOLVE milestones: first domestic application deployed, first model fine-tuned on local data, first infrastructure component brought under sovereign control. Publish an annual AI sovereignty progress report. Transparency creates accountability. Accountability sustains discipline.

Month 7–12: Demonstrate Exit Capability

Conduct a live exit test for at least one critical system. Migrate a non-critical workload to a domestic or multi-cloud alternative. Document the timeline, cost, and operational impact. Use the results to calibrate the entity’s Sovereignty Radius™ — the maximum acceptable dependency depth for each domain. An entity that has never tested exit cannot claim to govern its dependencies. It merely hopes they will not need to be exited.

The Question Revisited

What does genuine technology dependency look like when it moves beyond vendor lock-in into strategic vulnerability — and how do you test for it before the cost of exit becomes prohibitive?

The answer is not comfortable. Genuine dependency looks like the Singapore financial firm that cannot migrate without rebuilding its entire risk infrastructure. It looks like the East African health ministry that displaced its radiologists for a system that misses a quarter of local TB cases. It looks like the South American agriculture ministry that sidelined traditional knowledge keepers for a platform optimised for global staple crops. It looks like the thirty African nations whose cloud provider knows their dependency better than their own ministers do.

The test is the TEE Method™. The timeline is now. The cost of waiting is measured not in procurement budgets but in sovereignty itself. Every quarter that passes without TEST, EVALUATE, and EVOLVE is a quarter in which the asymmetry deepens, the switching costs compound, and the provider’s position strengthens. The entity that waits for the perfect moment to begin Governor discovers that the perfect moment was the moment it first deployed an AI system without testing its sovereignty implications.

The window for governance is not closed. But it narrows with every deployment, every integration, every quarterly renewal accepted without interrogation. The TEE Method™ exists to widen that window — to give leaders the framework, the tools, and the discipline to govern before they are governed.

This article draws on the TEE Method™ framework from SOVEREIGN: Who Owns the Future?

The sovereign entity does not ask for permission to govern its technology. It governs. The question is not whether the provider will allow sovereignty — the question is whether the entity will demand it. The TEE Method™ provides the framework. The entity provides the will. The future belongs to those who test before they trust, evaluate before they adopt, and evolve before they are forced to.

Consider the alternative: an entity that never tests, never evaluates, never evolves. An entity that adopts every system the market offers, integrates every capability the provider promises, and discovers — too late — that the architecture it inhabits was designed by others, for others, and that its own interests were never part of the design specification. This is not a hypothetical. It is the observable trajectory of every institution that has mistaken procurement for governance, access for capability, and convenience for sovereignty.

• Data Governance: Where does data physically reside? Who accesses it? Under what legal jurisdictions? Is it used for model training? Can it be exported in open formats? What happens to data upon contract termination? Is there a data deletion guarantee with verification?
• Dependency Mapping: What happens if this system becomes unavailable tomorrow? What is the restoration timeline? At what cost? What institutional capabilities have atrophied? Which downstream systems would fail? What is the cascade effect?
• Provider Interrogation: What are the provider’s incentive structures? How does the provider monetise the entity’s data and usage patterns? What are the provider’s contractual obligations versus commercial incentives? Who are the provider’s other clients — and do any represent conflicts of interest?
• Cultural Impact: Does the system embed assumptions that conflict with local practices? Does it standardise decision-making in ways that erode institutional diversity? Does it privilege one language or communication framework? Does it change how the entity’s people think, decide, and relate to their work?
• Workforce Impact: Which roles does the system displace? Which roles does it create? Is there a funded transition plan? Are the displaced workers the entity’s citizens? What skills are being lost — and can they be recovered?

The TEST phase produces a Sovereignty Test Matrix™ score for each system. Systems scoring below 15/25 are flagged for mandatory EVALUATE review. Systems scoring below 10/25 trigger immediate exit planning.

Phase 2: EVALUATE — The Strategic Alignment

Evaluation interrogates alignment — not whether the system works, but whether it serves the entity’s strategic interests. A system that performs well is not necessarily a system that serves well. This distinction is the central insight of the TEE Method™.

• Strategic Alignment: Does the system advance the entity’s defined objectives, or does it subtly reshape those objectives to fit the system’s capabilities? Has the entity’s strategy been rewritten to accommodate the system’s limitations?
• Sovereignty Impact: Does deployment strengthen or weaken the entity’s position across the five domains of the Sovereignty Test Matrix™? Is the trajectory toward sovereignty or toward deeper dependency?
• Geopolitical Exposure: Does the system create vulnerabilities to foreign jurisdiction, sanctions regimes, or diplomatic pressure? Can the provider be compelled by its home government to act against the entity’s interests?
• Economic Value Capture: What percentage of the value generated by the system accrues to the entity versus the provider? Is the entity capturing data value, talent value, or market intelligence value? Or is the entity subsidising the provider’s global model improvement?
• Adaptive Capacity: Can the entity modify, extend, or replace the system without provider permission? Does the entity own the integration layer, the data pipeline, and the evaluation framework? Can the entity switch providers without rewriting its operational architecture?

The EVALUATE phase produces a Strategic Alignment Rating: FAVOURABLE (28–35), ACCEPTABLE (21–27), CONCERNING (14–20), or UNFAVOURABLE (7–13). Systems rated CONCERNING require structural modifications within six months. Systems rated UNFAVOURABLE require exit initiation within twelve months.

Phase 3: EVOLVE — The Adaptive Governance

Evolution is the development of the entity’s capacity to shape its own technological trajectory, rather than merely responding to trajectories set by external providers. It requires three structural commitments that must be sustained across political cycles, budget cycles, and leadership transitions.

• Building Capability: Progressive investment in domestic AI research, development, and deployment capacity — starting with applications, extending to models, ultimately to infrastructure. The entity that builds understands what it buys. The entity that only buys understands only what it is sold.
• Governance Discipline: Institutionalising the TEST and EVALUATE phases as mandatory, recurring processes with defined authority, resources, and accountability. Governance that depends on individual champions fails when champions depart. Governance that depends on institutional structures endures.
• Strategic Diversification: Multi-provider strategies that prevent any single provider from becoming irreplaceable. Open-format requirements that ensure data and workflows can be migrated. Regular exit testing that verifies withdrawal capability. Contractual protections that limit the provider’s ability to increase switching costs.

The mathematics are unambiguous. Governance is cheaper than dependency. Prevention is cheaper than remediation. Sovereignty is cheaper than subjection.

Action Plan: From Diagnosis to Sovereignty

Week 1–2: Commission the Sovereignty Inventory

Assign a cross-functional team (technology, governance, legal, operations, finance) to conduct a comprehensive inventory of every AI system in use or under consideration. For each system, document: provider, jurisdiction, data flows, integration depth, contractual terms, criticality rating, and current sovereignty score across all five domains. The inventory alone is a revelation — senior officials are visibly surprised by the number of unknown dependencies.

Week 3–4: Apply the Sovereignty Test Matrix™

Score each critical system across the five domains. Identify systems scoring below 15/25 — these require immediate governance intervention. Identify systems scoring below 10/25 — these require exit planning. Document the specific domain weaknesses for each system. A system may score well on Infrastructure but critically on Data Sovereignty. The domain-level granularity tells you where to act.

Week 5–8: Negotiate Structural Modifications

For systems scoring 10–14, engage providers with specific, non-negotiable requirements: data localisation for sensitive workloads, open-format export capabilities, contractual exit provisions with defined timelines, knowledge transfer commitments, and independent audit rights. Providers unwilling to negotiate reveal their true position. Providers willing to negotiate demonstrate that sovereignty-respecting terms are commercially viable — they just aren’t the default.

Week 9–12: Initiate Building Programme

Identify the highest-priority system for domestic replacement or supplementation. Commission a feasibility study for internal development or partnership with a sovereign-aligned provider. Begin workforce development: recruit or train AI auditors, policy technologists, and builders. Establish the governance authority with mandate, budget, and accountability. The first building project need not be ambitious — a single application, fine-tuned on local data, deployed on domestic infrastructure, governed by domestic policy — proves the model and builds the capability.

Month 4–6: Institutionalise the TEE Cycle

Implement quarterly TEST cycles for all critical systems. Implement annual EVALUATE reviews with board/ministerial oversight. Establish EVOLVE milestones: first domestic application deployed, first model fine-tuned on local data, first infrastructure component brought under sovereign control. Publish an annual AI sovereignty progress report. Transparency creates accountability. Accountability sustains discipline.

Month 7–12: Demonstrate Exit Capability

Conduct a live exit test for at least one critical system. Migrate a non-critical workload to a domestic or multi-cloud alternative. Document the timeline, cost, and operational impact. Use the results to calibrate the entity’s Sovereignty Radius™ — the maximum acceptable dependency depth for each domain. An entity that has never tested exit cannot claim to govern its dependencies. It merely hopes they will not need to be exited.

The Question Revisited

What does genuine technology dependency look like when it moves beyond vendor lock-in into strategic vulnerability — and how do you test for it before the cost of exit becomes prohibitive?

The answer is not comfortable. Genuine dependency looks like the Singapore financial firm that cannot migrate without rebuilding its entire risk infrastructure. It looks like the East African health ministry that displaced its radiologists for a system that misses a quarter of local TB cases. It looks like the South American agriculture ministry that sidelined traditional knowledge keepers for a platform optimised for global staple crops. It looks like the thirty African nations whose cloud provider knows their dependency better than their own ministers do.

The test is the TEE Method™. The timeline is now. The cost of waiting is measured not in procurement budgets but in sovereignty itself. Every quarter that passes without TEST, EVALUATE, and EVOLVE is a quarter in which the asymmetry deepens, the switching costs compound, and the provider’s position strengthens. The entity that waits for the perfect moment to begin Governor discovers that the perfect moment was the moment it first deployed an AI system without testing its sovereignty implications.

The window for governance is not closed. But it narrows with every deployment, every integration, every quarterly renewal accepted without interrogation. The TEE Method™ exists to widen that window — to give leaders the framework, the tools, and the discipline to govern before they are governed.

This article draws on the TEE Method™ framework from SOVEREIGN: Who Owns the Future?

The sovereign entity does not ask for permission to govern its technology. It governs. The question is not whether the provider will allow sovereignty — the question is whether the entity will demand it. The TEE Method™ provides the framework. The entity provides the will. The future belongs to those who test before they trust, evaluate before they adopt, and evolve before they are forced to.

Consider the alternative: an entity that never tests, never evaluates, never evolves. An entity that adopts every system the market offers, integrates every capability the provider promises, and discovers — too late — that the architecture it inhabits was designed by others, for others, and that its own interests were never part of the design specification. This is not a hypothetical. It is the observable trajectory of every institution that has mistaken procurement for governance, access for capability, and convenience for sovereignty.

• No AI system in the portfolio has been subjected to a sovereignty assessment in the past twelve months
• At least one critical system (health, finance, security, tax, customs, education) runs on a single provider with no tested alternative
• Contracts for critical AI systems lack data localisation, portability, or exit provisions
• The entity has no domestic AI auditing capability and relies on provider self-assessment
• AI workforce roles (builders, auditors, policy technologists, ethics leads) are unfilled or outsourced
• No withdrawal protocol exists for any deployed AI system
• Provider pricing changes in the past twenty-four months have been accepted without negotiation
• Geopolitical risk assessment for AI providers has never been conducted
• Institutional knowledge of pre-AI operational processes has been lost or not documented
• Board or ministerial oversight of AI governance occurs annually or less frequently
• The entity cannot answer “what happens if this system becomes unavailable tomorrow?” for its three most critical AI systems

Dependency is not a binary state. It is a spectrum — and the entity that does not know where it sits on that spectrum has already ceded the power to define its own position.

Part Four: The TEE Method™ Framework — Test, Evaluate, Evolve

The TEE Method™ provides a structured mechanism for converting dependency awareness into governance action. It operates in three phases, each with distinct objectives, tools, and accountability structures. The method is not a compliance checklist — it is a governance discipline that must be institutionalised, resourced, and sustained.

Phase 1: TEST — The Operational Interrogation

Testing interrogates the system before and during deployment. It asks five question clusters that the commercial procurement process never asks, because the commercial procurement process is designed to validate the vendor’s claims, not to interrogate the sovereign implications.

• Data Governance: Where does data physically reside? Who accesses it? Under what legal jurisdictions? Is it used for model training? Can it be exported in open formats? What happens to data upon contract termination? Is there a data deletion guarantee with verification?
• Dependency Mapping: What happens if this system becomes unavailable tomorrow? What is the restoration timeline? At what cost? What institutional capabilities have atrophied? Which downstream systems would fail? What is the cascade effect?
• Provider Interrogation: What are the provider’s incentive structures? How does the provider monetise the entity’s data and usage patterns? What are the provider’s contractual obligations versus commercial incentives? Who are the provider’s other clients — and do any represent conflicts of interest?
• Cultural Impact: Does the system embed assumptions that conflict with local practices? Does it standardise decision-making in ways that erode institutional diversity? Does it privilege one language or communication framework? Does it change how the entity’s people think, decide, and relate to their work?
• Workforce Impact: Which roles does the system displace? Which roles does it create? Is there a funded transition plan? Are the displaced workers the entity’s citizens? What skills are being lost — and can they be recovered?

The TEST phase produces a Sovereignty Test Matrix™ score for each system. Systems scoring below 15/25 are flagged for mandatory EVALUATE review. Systems scoring below 10/25 trigger immediate exit planning.

Phase 2: EVALUATE — The Strategic Alignment

Evaluation interrogates alignment — not whether the system works, but whether it serves the entity’s strategic interests. A system that performs well is not necessarily a system that serves well. This distinction is the central insight of the TEE Method™.

• Strategic Alignment: Does the system advance the entity’s defined objectives, or does it subtly reshape those objectives to fit the system’s capabilities? Has the entity’s strategy been rewritten to accommodate the system’s limitations?
• Sovereignty Impact: Does deployment strengthen or weaken the entity’s position across the five domains of the Sovereignty Test Matrix™? Is the trajectory toward sovereignty or toward deeper dependency?
• Geopolitical Exposure: Does the system create vulnerabilities to foreign jurisdiction, sanctions regimes, or diplomatic pressure? Can the provider be compelled by its home government to act against the entity’s interests?
• Economic Value Capture: What percentage of the value generated by the system accrues to the entity versus the provider? Is the entity capturing data value, talent value, or market intelligence value? Or is the entity subsidising the provider’s global model improvement?
• Adaptive Capacity: Can the entity modify, extend, or replace the system without provider permission? Does the entity own the integration layer, the data pipeline, and the evaluation framework? Can the entity switch providers without rewriting its operational architecture?

The EVALUATE phase produces a Strategic Alignment Rating: FAVOURABLE (28–35), ACCEPTABLE (21–27), CONCERNING (14–20), or UNFAVOURABLE (7–13). Systems rated CONCERNING require structural modifications within six months. Systems rated UNFAVOURABLE require exit initiation within twelve months.

Phase 3: EVOLVE — The Adaptive Governance

Evolution is the development of the entity’s capacity to shape its own technological trajectory, rather than merely responding to trajectories set by external providers. It requires three structural commitments that must be sustained across political cycles, budget cycles, and leadership transitions.

• Building Capability: Progressive investment in domestic AI research, development, and deployment capacity — starting with applications, extending to models, ultimately to infrastructure. The entity that builds understands what it buys. The entity that only buys understands only what it is sold.
• Governance Discipline: Institutionalising the TEST and EVALUATE phases as mandatory, recurring processes with defined authority, resources, and accountability. Governance that depends on individual champions fails when champions depart. Governance that depends on institutional structures endures.
• Strategic Diversification: Multi-provider strategies that prevent any single provider from becoming irreplaceable. Open-format requirements that ensure data and workflows can be migrated. Regular exit testing that verifies withdrawal capability. Contractual protections that limit the provider’s ability to increase switching costs.

The mathematics are unambiguous. Governance is cheaper than dependency. Prevention is cheaper than remediation. Sovereignty is cheaper than subjection.

Action Plan: From Diagnosis to Sovereignty

Week 1–2: Commission the Sovereignty Inventory

Assign a cross-functional team (technology, governance, legal, operations, finance) to conduct a comprehensive inventory of every AI system in use or under consideration. For each system, document: provider, jurisdiction, data flows, integration depth, contractual terms, criticality rating, and current sovereignty score across all five domains. The inventory alone is a revelation — senior officials are visibly surprised by the number of unknown dependencies.

Week 3–4: Apply the Sovereignty Test Matrix™

Score each critical system across the five domains. Identify systems scoring below 15/25 — these require immediate governance intervention. Identify systems scoring below 10/25 — these require exit planning. Document the specific domain weaknesses for each system. A system may score well on Infrastructure but critically on Data Sovereignty. The domain-level granularity tells you where to act.

Week 5–8: Negotiate Structural Modifications

For systems scoring 10–14, engage providers with specific, non-negotiable requirements: data localisation for sensitive workloads, open-format export capabilities, contractual exit provisions with defined timelines, knowledge transfer commitments, and independent audit rights. Providers unwilling to negotiate reveal their true position. Providers willing to negotiate demonstrate that sovereignty-respecting terms are commercially viable — they just aren’t the default.

Week 9–12: Initiate Building Programme

Identify the highest-priority system for domestic replacement or supplementation. Commission a feasibility study for internal development or partnership with a sovereign-aligned provider. Begin workforce development: recruit or train AI auditors, policy technologists, and builders. Establish the governance authority with mandate, budget, and accountability. The first building project need not be ambitious — a single application, fine-tuned on local data, deployed on domestic infrastructure, governed by domestic policy — proves the model and builds the capability.

Month 4–6: Institutionalise the TEE Cycle

Implement quarterly TEST cycles for all critical systems. Implement annual EVALUATE reviews with board/ministerial oversight. Establish EVOLVE milestones: first domestic application deployed, first model fine-tuned on local data, first infrastructure component brought under sovereign control. Publish an annual AI sovereignty progress report. Transparency creates accountability. Accountability sustains discipline.

Month 7–12: Demonstrate Exit Capability

Conduct a live exit test for at least one critical system. Migrate a non-critical workload to a domestic or multi-cloud alternative. Document the timeline, cost, and operational impact. Use the results to calibrate the entity’s Sovereignty Radius™ — the maximum acceptable dependency depth for each domain. An entity that has never tested exit cannot claim to govern its dependencies. It merely hopes they will not need to be exited.

The Question Revisited

What does genuine technology dependency look like when it moves beyond vendor lock-in into strategic vulnerability — and how do you test for it before the cost of exit becomes prohibitive?

The answer is not comfortable. Genuine dependency looks like the Singapore financial firm that cannot migrate without rebuilding its entire risk infrastructure. It looks like the East African health ministry that displaced its radiologists for a system that misses a quarter of local TB cases. It looks like the South American agriculture ministry that sidelined traditional knowledge keepers for a platform optimised for global staple crops. It looks like the thirty African nations whose cloud provider knows their dependency better than their own ministers do.

The test is the TEE Method™. The timeline is now. The cost of waiting is measured not in procurement budgets but in sovereignty itself. Every quarter that passes without TEST, EVALUATE, and EVOLVE is a quarter in which the asymmetry deepens, the switching costs compound, and the provider’s position strengthens. The entity that waits for the perfect moment to begin Governor discovers that the perfect moment was the moment it first deployed an AI system without testing its sovereignty implications.

The window for governance is not closed. But it narrows with every deployment, every integration, every quarterly renewal accepted without interrogation. The TEE Method™ exists to widen that window — to give leaders the framework, the tools, and the discipline to govern before they are governed.

This article draws on the TEE Method™ framework from SOVEREIGN: Who Owns the Future?

The sovereign entity does not ask for permission to govern its technology. It governs. The question is not whether the provider will allow sovereignty — the question is whether the entity will demand it. The TEE Method™ provides the framework. The entity provides the will. The future belongs to those who test before they trust, evaluate before they adopt, and evolve before they are forced to.

Consider the alternative: an entity that never tests, never evaluates, never evolves. An entity that adopts every system the market offers, integrates every capability the provider promises, and discovers — too late — that the architecture it inhabits was designed by others, for others, and that its own interests were never part of the design specification. This is not a hypothetical. It is the observable trajectory of every institution that has mistaken procurement for governance, access for capability, and convenience for sovereignty.

THE SCENARIO

A mid-sized financial services firm in Singapore has built its entire fraud detection pipeline on a single US-based AI platform. The platform delivers 94% detection accuracy, integrates seamlessly with existing infrastructure, and costs a fraction of building in-house. Three years in, the firm discovers that the platform’s API structure has created implicit dependencies in every downstream system — credit scoring, customer onboarding, regulatory reporting, and risk modelling all route through the same inference endpoints. When the platform announces a 40% price increase and deprecates the model version the firm relies on, the firm faces a choice: accept the new terms and rebuild its integration layer, or attempt a migration that would take eighteen months and cost $4.2 million. The firm’s board discovers it has no credible alternative, no internal capability to build one, and no contractual leverage. The platform knows this.

A national health ministry in East Africa deploys a diagnostic AI system from a European provider to address a critical shortage of radiologists. The system processes chest X-rays for tuberculosis screening across two hundred clinics. Eighteen months later, the ministry learns that the training data excludes the genetic polymorphisms prevalent in the local population, resulting in a 23% false-negative rate for a specific TB strain. The provider acknowledges the gap but indicates that retraining would require “commercial justification” — a minimum of five hundred thousand labelled images from the local population, which the ministry must provide at its own expense. The ministry has already displaced its remaining radiologists to administrative roles. It cannot revert to manual screening. It cannot afford the retraining data. The diagnostic capability it depends on is structurally misaligned with the population it serves.

A ministry of agriculture in South America adopts an AI-powered crop yield prediction platform from a major cloud provider. The system integrates satellite imagery, weather data, and historical yields to guide planting decisions for millions of smallholder farmers. Two growing seasons in, the ministry discovers that the model’s accuracy degrades significantly for indigenous crop varieties and traditional farming practices — the very systems the ministry’s food sovereignty policy is designed to protect. The provider’s response: the model is “optimised for global staple crops.” The ministry has already restructured its extension services around the platform’s recommendations. Traditional knowledge keepers have been sidelined. The platform has become the de facto agricultural policy authority, accountable to no one in the country it serves.

The Question

What does genuine technology dependency look like when it moves beyond vendor lock-in into strategic vulnerability — and how do you test for it before the cost of exit becomes prohibitive?

Part One: The Problem Is Not Lock-In. It Is Asymmetry.

Most organisations understand vendor lock-in. They recognise proprietary formats, contractual exit barriers, and the switching costs that accumulate when a system becomes deeply embedded. What they miss is the structural asymmetry that makes lock-in inevitable — the information advantage that providers hold over every entity that depends on them.

The multinational technology company that deploys a cloud platform across thirty African nations knows, in real time, how each of those nations uses the technology. It knows which government ministries are most dependent. It knows which processes would collapse without the platform. It knows how deeply integrated the platform is in each institution. It knows the switching costs for each client. It knows who is exploring alternatives and who is not. It knows the pattern of usage that signals dependency, and it knows the pattern that signals flight risk.

The client knows none of this. The client sees a dashboard. The provider sees a dependency map.

This asymmetry is not accidental. It is the commercial logic of the AI platform model. The provider’s business model requires deepening dependency over time — more data, more integration, more workloads, more institutional processes restructured around the platform’s capabilities. Every quarter, the provider’s position strengthens. Every quarter, the client’s negotiating position weakens.

The asymmetry extends beyond usage data. The provider controls the model architecture, the training data composition, the evaluation benchmarks, the deprecation schedule, the pricing structure, the API evolution, and the support tier allocation. The client controls none of these. The client receives what the provider chooses to deliver, on terms the provider chooses to offer, at a price the provider chooses to set.

When the provider is a foreign entity operating under a foreign legal jurisdiction, the asymmetry becomes geopolitical. The provider’s home government may compel data access, service modification, or service termination. The client’s government may have no reciprocal leverage. This is not theoretical. The CLOUD Act, FISA Section 702, and analogous legislation in other major AI-producing nations establish legal frameworks for extraterritorial data access that apply to every entity using those providers’ services — regardless of where the entity operates.

The entity that shapes how leaders think — what frameworks they use, what questions they ask, what information they consider, what options they generate, what trade-offs they weigh — has more power than the entity that controls any physical infrastructure.

Part Two: How Dependency Manifests — The Five-Domain Diagnostic

The TEE Method™ identifies five domains in which technology dependency becomes strategic vulnerability. Each domain represents a distinct vector of exposure. An entity may be sovereign in one domain while critically dependent in another. The Sovereignty Test Matrix™ assesses each domain on a 1–5 scale, where 1 indicates critical dependency and 5 indicates full sovereign control.

Domain	Score (1–5)	What It Assesses
Data Sovereignty	___	Control over data location, access, portability, and value capture. Can the entity move its data? Does the provider use entity data for model training? Are cross-border data flows governed by the entity or the provider? Is data processed in jurisdictions the entity has approved?
Infrastructure Sovereignty	___	Control over the physical and logical infrastructure running AI systems. Does the entity own or govern the compute, storage, and network layers? Are critical workloads running on foreign infrastructure without contingency? Can the entity sustain operations if foreign infrastructure becomes unavailable?
Workforce Sovereignty	___	Domestic capability to build, govern, audit, and evolve AI systems. Does the entity have AI auditors, policy technologists, builders, labour transition strategists, ethics governance leads, and sovereign data stewards? Or is talent predominantly foreign-trained and foreign-retained? Can the entity replace departed talent domestically?
Intellectual Sovereignty	___	Capacity to understand how AI systems work at a level sufficient to govern them. Can the entity independently evaluate model outputs, assess bias, interrogate architectural decisions, and challenge vendor claims without relying on the vendor’s own explanations? Does the entity possess the technical literacy to govern what it procures?
Governance Sovereignty	___	Institutional frameworks for AI decision-making: procurement authority, testing mandates, evaluation protocols, evolution mechanisms, and withdrawal triggers. Does the entity govern its AI relationships, or does it merely administer them? Are sovereignty assessments mandatory for all AI procurement?

Scoring Guide: 1 = Critical dependency (no meaningful control, provider dictates terms) · 2 = Significant dependency (limited control, exit costly or slow) · 3 = Moderate dependency (some control, exit feasible with planning) · 4 = Minor dependency (substantial control, exit straightforward) · 5 = No dependency (full sovereign control, credible alternatives maintained)

Total Score ___ / 25

A score of 20–25 indicates a sovereign posture — the entity governs its AI relationships from a position of strength. A score of 15–19 indicates managed dependency — the entity has awareness and some control but remains vulnerable to provider decisions. A score of 10–14 indicates critical dependency — the entity’s strategic autonomy is constrained by provider choices. A score below 10 indicates governance capture — the entity has effectively surrendered sovereign control over critical AI systems.

Part Three: The Red Flag Checklist

If three or more of the following apply, the entity is in a critical dependency position requiring immediate structural intervention:

• No AI system in the portfolio has been subjected to a sovereignty assessment in the past twelve months
• At least one critical system (health, finance, security, tax, customs, education) runs on a single provider with no tested alternative
• Contracts for critical AI systems lack data localisation, portability, or exit provisions
• The entity has no domestic AI auditing capability and relies on provider self-assessment
• AI workforce roles (builders, auditors, policy technologists, ethics leads) are unfilled or outsourced
• No withdrawal protocol exists for any deployed AI system
• Provider pricing changes in the past twenty-four months have been accepted without negotiation
• Geopolitical risk assessment for AI providers has never been conducted
• Institutional knowledge of pre-AI operational processes has been lost or not documented
• Board or ministerial oversight of AI governance occurs annually or less frequently
• The entity cannot answer “what happens if this system becomes unavailable tomorrow?” for its three most critical AI systems

Dependency is not a binary state. It is a spectrum — and the entity that does not know where it sits on that spectrum has already ceded the power to define its own position.

Part Four: The TEE Method™ Framework — Test, Evaluate, Evolve

The TEE Method™ provides a structured mechanism for converting dependency awareness into governance action. It operates in three phases, each with distinct objectives, tools, and accountability structures. The method is not a compliance checklist — it is a governance discipline that must be institutionalised, resourced, and sustained.

Phase 1: TEST — The Operational Interrogation

Testing interrogates the system before and during deployment. It asks five question clusters that the commercial procurement process never asks, because the commercial procurement process is designed to validate the vendor’s claims, not to interrogate the sovereign implications.

• Data Governance: Where does data physically reside? Who accesses it? Under what legal jurisdictions? Is it used for model training? Can it be exported in open formats? What happens to data upon contract termination? Is there a data deletion guarantee with verification?
• Dependency Mapping: What happens if this system becomes unavailable tomorrow? What is the restoration timeline? At what cost? What institutional capabilities have atrophied? Which downstream systems would fail? What is the cascade effect?
• Provider Interrogation: What are the provider’s incentive structures? How does the provider monetise the entity’s data and usage patterns? What are the provider’s contractual obligations versus commercial incentives? Who are the provider’s other clients — and do any represent conflicts of interest?
• Cultural Impact: Does the system embed assumptions that conflict with local practices? Does it standardise decision-making in ways that erode institutional diversity? Does it privilege one language or communication framework? Does it change how the entity’s people think, decide, and relate to their work?
• Workforce Impact: Which roles does the system displace? Which roles does it create? Is there a funded transition plan? Are the displaced workers the entity’s citizens? What skills are being lost — and can they be recovered?

The TEST phase produces a Sovereignty Test Matrix™ score for each system. Systems scoring below 15/25 are flagged for mandatory EVALUATE review. Systems scoring below 10/25 trigger immediate exit planning.

Phase 2: EVALUATE — The Strategic Alignment

Evaluation interrogates alignment — not whether the system works, but whether it serves the entity’s strategic interests. A system that performs well is not necessarily a system that serves well. This distinction is the central insight of the TEE Method™.

• Strategic Alignment: Does the system advance the entity’s defined objectives, or does it subtly reshape those objectives to fit the system’s capabilities? Has the entity’s strategy been rewritten to accommodate the system’s limitations?
• Sovereignty Impact: Does deployment strengthen or weaken the entity’s position across the five domains of the Sovereignty Test Matrix™? Is the trajectory toward sovereignty or toward deeper dependency?
• Geopolitical Exposure: Does the system create vulnerabilities to foreign jurisdiction, sanctions regimes, or diplomatic pressure? Can the provider be compelled by its home government to act against the entity’s interests?
• Economic Value Capture: What percentage of the value generated by the system accrues to the entity versus the provider? Is the entity capturing data value, talent value, or market intelligence value? Or is the entity subsidising the provider’s global model improvement?
• Adaptive Capacity: Can the entity modify, extend, or replace the system without provider permission? Does the entity own the integration layer, the data pipeline, and the evaluation framework? Can the entity switch providers without rewriting its operational architecture?

The EVALUATE phase produces a Strategic Alignment Rating: FAVOURABLE (28–35), ACCEPTABLE (21–27), CONCERNING (14–20), or UNFAVOURABLE (7–13). Systems rated CONCERNING require structural modifications within six months. Systems rated UNFAVOURABLE require exit initiation within twelve months.

Phase 3: EVOLVE — The Adaptive Governance

Evolution is the development of the entity’s capacity to shape its own technological trajectory, rather than merely responding to trajectories set by external providers. It requires three structural commitments that must be sustained across political cycles, budget cycles, and leadership transitions.

• Building Capability: Progressive investment in domestic AI research, development, and deployment capacity — starting with applications, extending to models, ultimately to infrastructure. The entity that builds understands what it buys. The entity that only buys understands only what it is sold.
• Governance Discipline: Institutionalising the TEST and EVALUATE phases as mandatory, recurring processes with defined authority, resources, and accountability. Governance that depends on individual champions fails when champions depart. Governance that depends on institutional structures endures.
• Strategic Diversification: Multi-provider strategies that prevent any single provider from becoming irreplaceable. Open-format requirements that ensure data and workflows can be migrated. Regular exit testing that verifies withdrawal capability. Contractual protections that limit the provider’s ability to increase switching costs.

The mathematics are unambiguous. Governance is cheaper than dependency. Prevention is cheaper than remediation. Sovereignty is cheaper than subjection.

Action Plan: From Diagnosis to Sovereignty

Week 1–2: Commission the Sovereignty Inventory

Assign a cross-functional team (technology, governance, legal, operations, finance) to conduct a comprehensive inventory of every AI system in use or under consideration. For each system, document: provider, jurisdiction, data flows, integration depth, contractual terms, criticality rating, and current sovereignty score across all five domains. The inventory alone is a revelation — senior officials are visibly surprised by the number of unknown dependencies.

Week 3–4: Apply the Sovereignty Test Matrix™

Score each critical system across the five domains. Identify systems scoring below 15/25 — these require immediate governance intervention. Identify systems scoring below 10/25 — these require exit planning. Document the specific domain weaknesses for each system. A system may score well on Infrastructure but critically on Data Sovereignty. The domain-level granularity tells you where to act.

Week 5–8: Negotiate Structural Modifications

For systems scoring 10–14, engage providers with specific, non-negotiable requirements: data localisation for sensitive workloads, open-format export capabilities, contractual exit provisions with defined timelines, knowledge transfer commitments, and independent audit rights. Providers unwilling to negotiate reveal their true position. Providers willing to negotiate demonstrate that sovereignty-respecting terms are commercially viable — they just aren’t the default.

Week 9–12: Initiate Building Programme

Identify the highest-priority system for domestic replacement or supplementation. Commission a feasibility study for internal development or partnership with a sovereign-aligned provider. Begin workforce development: recruit or train AI auditors, policy technologists, and builders. Establish the governance authority with mandate, budget, and accountability. The first building project need not be ambitious — a single application, fine-tuned on local data, deployed on domestic infrastructure, governed by domestic policy — proves the model and builds the capability.

Month 4–6: Institutionalise the TEE Cycle

Implement quarterly TEST cycles for all critical systems. Implement annual EVALUATE reviews with board/ministerial oversight. Establish EVOLVE milestones: first domestic application deployed, first model fine-tuned on local data, first infrastructure component brought under sovereign control. Publish an annual AI sovereignty progress report. Transparency creates accountability. Accountability sustains discipline.

Month 7–12: Demonstrate Exit Capability

Conduct a live exit test for at least one critical system. Migrate a non-critical workload to a domestic or multi-cloud alternative. Document the timeline, cost, and operational impact. Use the results to calibrate the entity’s Sovereignty Radius™ — the maximum acceptable dependency depth for each domain. An entity that has never tested exit cannot claim to govern its dependencies. It merely hopes they will not need to be exited.

The Question Revisited

What does genuine technology dependency look like when it moves beyond vendor lock-in into strategic vulnerability — and how do you test for it before the cost of exit becomes prohibitive?

The answer is not comfortable. Genuine dependency looks like the Singapore financial firm that cannot migrate without rebuilding its entire risk infrastructure. It looks like the East African health ministry that displaced its radiologists for a system that misses a quarter of local TB cases. It looks like the South American agriculture ministry that sidelined traditional knowledge keepers for a platform optimised for global staple crops. It looks like the thirty African nations whose cloud provider knows their dependency better than their own ministers do.

The test is the TEE Method™. The timeline is now. The cost of waiting is measured not in procurement budgets but in sovereignty itself. Every quarter that passes without TEST, EVALUATE, and EVOLVE is a quarter in which the asymmetry deepens, the switching costs compound, and the provider’s position strengthens. The entity that waits for the perfect moment to begin Governor discovers that the perfect moment was the moment it first deployed an AI system without testing its sovereignty implications.

The window for governance is not closed. But it narrows with every deployment, every integration, every quarterly renewal accepted without interrogation. The TEE Method™ exists to widen that window — to give leaders the framework, the tools, and the discipline to govern before they are governed.

This article draws on the TEE Method™ framework from SOVEREIGN: Who Owns the Future?

The sovereign entity does not ask for permission to govern its technology. It governs. The question is not whether the provider will allow sovereignty — the question is whether the entity will demand it. The TEE Method™ provides the framework. The entity provides the will. The future belongs to those who test before they trust, evaluate before they adopt, and evolve before they are forced to.

Consider the alternative: an entity that never tests, never evaluates, never evolves. An entity that adopts every system the market offers, integrates every capability the provider promises, and discovers — too late — that the architecture it inhabits was designed by others, for others, and that its own interests were never part of the design specification. This is not a hypothetical. It is the observable trajectory of every institution that has mistaken procurement for governance, access for capability, and convenience for sovereignty.