THE SCENARIO
A coalition of central banks in a developing region adopts a shared AI-driven payment infrastructure platform. The platform is built by a foreign fintech consortium and certified against international standards. It promises to harmonise transaction processing, reduce settlement costs, and satisfy the international banking community’s demands for modernised infrastructure.
Within eighteen months, the platform has become the de facto regulatory standard for the region’s financial transactions. Banks structure their compliance departments around its classifications. Regulators reference its risk categories in their guidance.
Nobody voted for this. No legislation authorised it. No procurement process evaluated it.
What happens when the infrastructure you depend on becomes the infrastructure that governs you?
Internally built systems must be tested across all five domains. Internally built systems must be evaluated across all seven layers. Internally built systems must be subject to human oversight. Internally built systems must be periodically re-assessed. Internally built systems must have withdrawal protocols — yes, even internally built systems can become institutional dependencies that need governance.
The Evaluate domain builds on this foundation by asking: given that we have tested this system, what does it mean? Interpreting the test results requires structured evaluation criteria that are transparent, consistent, and independent of the technology provider’s claims.
These source paragraphs from the TEE Method framework capture the central thesis of this article: technology dependency is not a technical problem to be solved with better procurement. It is a governance condition that must be diagnosed, measured, and managed through deliberate structural choices. The central bank scenario above is not hypothetical — it is a composite drawn from observable patterns across multiple regions where foreign-built payment infrastructure has become the governance layer for domestic financial systems. The technology was adopted for its efficiency. It became the governor because no one designed the governance architecture to prevent it.
Part One: The Four Forms of Technology Dependency
The TEE Method identifies four distinct forms of technology dependency, each requiring a different strategic response. Understanding which form — or combination of forms — characterises a given relationship is the prerequisite for effective governance. Most entities do not suffer from a single form of dependency; they suffer from a compound dependency profile where functional, knowledge, structural, and governance dependencies reinforce each other in ways that make extraction exponentially more difficult over time. The compounding effect is the central challenge: an entity that enters a relationship with only functional dependency will, without deliberate intervention, develop knowledge dependency, then structural dependency, and finally governance dependency — each layer making the next more probable and more expensive to reverse.
1. Functional Dependency
Functional dependency occurs when an entity cannot perform a core function without a specific technology provider. The payroll system, the customer relationship management platform, the cloud infrastructure — these become so deeply embedded in daily operations that the entity loses the capacity to imagine alternatives. The TEE Method’s first diagnostic question is simple but powerful: If this provider disappeared tomorrow, could this entity continue to operate for thirty days? If the answer is no, functional dependency exists and must be addressed. Functional dependency is the most visible form, but it is rarely the most dangerous. It is dangerous because it creates the justification for accepting the other three forms. The entity reasons: we need this function, therefore we must accept the provider’s terms. This reasoning is the gateway to compound dependency.
Functional dependency manifests differently across organisational scales. For a small enterprise, it may be a single SaaS platform that handles invoicing, customer management, and reporting. For a government agency, it may be a tax processing system that touches every citizen interaction. For a central bank, it may be the payment settlement infrastructure that underpins the entire financial system. The scale differs, but the structure is identical: a core function has been outsourced to a provider that the entity cannot replace at acceptable cost and time. The TEE Method requires entities to map every core function to its technology provider and assess the substitution time — the time required to transition to an alternative — at each layer of the stack.
2. Knowledge Dependency
Knowledge dependency is more subtle and more persistent than functional dependency. It occurs when an entity relies on external providers not just for technology, but for the understanding of that technology. The entity cannot evaluate whether the system is performing correctly because it lacks the internal expertise to make that judgment. It cannot customise the system to its needs because the knowledge required resides entirely with the vendor. The entity becomes a passenger in its own technology stack, unable to distinguish between a feature and a vulnerability, between a performance optimisation and a surveillance capability, between a genuine improvement and a strategic lock-in mechanism.
Knowledge dependency is the form that survives even after functional alternatives exist — because the entity does not know how to evaluate them. An entity may have three competing cloud providers that all offer functionally equivalent services, but if the entity’s internal teams only know how to operate on Provider A’s console, use Provider A’s APIs, and debug Provider A’s failure modes, then the entity is knowledge-dependent on Provider A. The TEE Method addresses this through its Evaluate domain, which requires entities to build the internal capacity to assess, challenge, and improve the technologies they use. This capacity cannot be outsourced — an auditor who is vendor-certified is not an independent evaluator. The entity must develop its own judgment infrastructure: the ability to read source code, to interpret model weights, to analyse network traffic, to evaluate data flows, and to make governance decisions based on its own analysis rather than the provider’s assurances.
3. Structural Dependency
Structural dependency is the deepest form. It occurs when the technology provider’s architecture, data formats, and workflows become the entity’s architecture, data formats, and workflows. The entity has not just adopted a tool — it has adopted a structure. Its business processes mirror the provider’s product roadmap. Its data is stored in the provider’s proprietary format. Its compliance frameworks are built around the provider’s certifications. The TEE Method’s Test domain explicitly examines structural dependency through layer-by-layer auditing of the technology stack. Structural dependency is the form that makes exit not just difficult but conceptually unimaginable — because the entity has reorganised itself around the provider’s architecture.
Consider an organisation that has built its entire customer onboarding workflow around a specific identity verification platform. The workflow is not just “use the platform” — it is: collect these specific data fields, in this specific order, validate against these specific rules, store in this specific format, trigger these specific downstream processes. The organisation’s CRM schema matches the platform’s data model. The organisation’s compliance documentation references the platform’s certification numbers. The organisation’s staff training teaches the platform’s interface. To switch platforms, the organisation does not just need a new platform — it needs a new data model, a new workflow, a new compliance framework, a new training programme, and new integrations for every downstream system. The cost of exit is not the cost of the new platform. It is the cost of reorganising the entity.
4. Governance Dependency
Governance dependency occurs when the rules governing the technology — its terms of service, its compliance certifications, its update policies, its deprecation schedules — are set entirely by the provider and accepted passively by the entity. The entity has surrendered its governance capacity in exchange for operational convenience. Governance dependency is the form that legitimises the other three. It is the entity saying: we do not need to govern this, because the provider governs it for us. The provider’s incentives become the entity’s governance framework. The provider’s risk tolerance becomes the entity’s risk tolerance. The provider’s strategic priorities become the entity’s strategic constraints.
Governance dependency is rarely a conscious choice. It emerges through a sequence of procurement decisions where governance terms are treated as boilerplate rather than strategic choices. The entity accepts the provider’s standard terms because “everyone uses them.” The entity accepts the provider’s update policy because “it’s more secure that way.” The entity accepts the provider’s data processing agreement because “it’s GDPR compliant.” Each acceptance is rational in isolation. The cumulative effect is the transfer of governance authority. When the provider changes its pricing model, the entity cannot negotiate — it must accept. When the provider deprecates a critical feature, the entity cannot refuse — it must adapt. When the provider is acquired by a strategic competitor, the entity cannot prevent the transfer of its data and dependencies — it must comply. The entity that accepted governance dependency has no leverage, because it surrendered its leverage at the moment of adoption.
Part Two: The Seven-Layer Stack Audit
The TEE Method requires a systematic audit across seven layers of the technology stack. This is not a theoretical exercise — it is a practical measurement infrastructure that makes dependency visible and therefore governable. Each layer represents a distinct sovereignty decision point. An entity that is sovereign at the application layer but dependent at the hardware layer has not achieved sovereignty — it has achieved a conditional operational capability that can be revoked by the hardware provider at any time. The seven layers are not independent; they are a cascade where dependency at any layer propagates upward, constraining the entity’s choices at every layer above it.
Layer 1: Hardware and Compute
Who owns the physical infrastructure? Where are the data centres located? Under what jurisdiction do they operate? What are the power, cooling, and connectivity dependencies? These questions are not abstract. A data centre in a foreign jurisdiction is subject to that jurisdiction’s data access laws, surveillance mandates, and national security directives. The entity that does not control its compute infrastructure does not control the systems that run on it. The TEE Method requires entities to map their compute dependencies to the jurisdiction level and assess the legal exposure of each dependency.
The hardware layer is where sovereignty begins or ends. An entity that runs its AI models on foreign-owned cloud infrastructure has already made a sovereignty choice — whether it recognises it or not. The cloud provider’s terms of service, the hosting jurisdiction’s legal framework, the data centre’s physical security — these are not technical details. They are the constitutional framework within which the entity’s AI systems operate. The entity that wants sovereignty must either own its hardware or have contractual and legal guarantees that are enforceable in its own jurisdiction. “Trusted cloud” certifications are not sovereignty — they are the provider’s promise to follow its own rules, which the provider can change at any time.
Layer 2: Network and Connectivity
Who controls the data pathways? Which internet exchange points does traffic traverse? What are the routing dependencies? Are there single points of failure in the network path? Network dependency is often invisible until a route is cut, a cable is severed, or a routing policy changes. The entity that cannot route its traffic through domestically controlled infrastructure is dependent on the routing decisions of foreign carriers and the foreign jurisdictions that regulate them.
The network layer is the circulatory system of the technology stack. Data that cannot move is data that cannot be governed. An entity that depends on foreign internet exchange points for its critical data flows has exposed its sovereignty to routing decisions it cannot control. The TEE Method requires entities to map their network dependencies: which carriers, which exchange points, which submarine cables, which satellite links. For each, the entity must assess: can we reroute? What is the latency penalty? What is the legal exposure of the alternative routes? The entity that has only one path to its cloud provider has not achieved network sovereignty — it has achieved a conditional connectivity that can be severed by a single routing decision.
Layer 3: Operating System and Virtualisation
Who controls the base software layer? Is it open source or proprietary? What are the update and patch dependencies? Can the entity run its own builds? An operating system that the entity cannot audit, cannot patch independently, and cannot compile from source is an operating system that the entity does not control. The virtualisation layer adds another dimension: if the hypervisor is proprietary and the entity cannot inspect its behaviour, the entity cannot know what the hypervisor sees, logs, or transmits.
The operating system layer is where software sovereignty is won or lost. A proprietary OS is a black box that the entity must trust. An open-source OS that the entity cannot build, patch, or audit is a theoretical freedom, not a practical one. The TEE Method requires entities to assess their OS dependency not by licence type but by operational capability: can we patch a zero-day vulnerability without waiting for the vendor? Can we compile a hardened kernel for our security requirements? Can we verify that the OS is not exfiltrating telemetry? The entity that answers “no” to any of these questions has OS-layer dependency that cascades into every application running on that OS.
Layer 4: Middleware and APIs
Who governs the integration layer? Are the APIs open standards or vendor-proprietary? What are the versioning and deprecation policies? Can the entity build its own adapters? Middleware dependency is the bridge between structural and governance dependency. When an entity’s workflows are built on vendor APIs, the vendor controls the entity’s business logic. When the vendor deprecates an API version, the entity’s workflows break — not because the entity’s needs changed, but because the vendor’s roadmap changed.
The middleware layer is where structural dependency becomes visible. An entity that has built its integrations on REST APIs with JSON payloads has more structural portability than an entity that has built on vendor-specific SDKs with proprietary serialisation. But even open-standard APIs can create dependency if the entity has no alternative implementation to switch to. The TEE Method requires entities to assess middleware dependency by substitution testing: can we swap the API provider without changing our application logic? If the answer is no — because we use vendor-specific extensions, because we depend on vendor-specific performance characteristics, because our error handling assumes vendor-specific failure modes — then we have middleware dependency regardless of the API standard.
Layer 5: Application and AI Models
Who controls the intelligence layer? Are the models open-weight or closed? What are the fine-tuning and customisation capabilities? What are the inference dependencies? AI model dependency is the newest and most opaque layer. A closed model is a black box that the entity cannot audit for bias, cannot verify for safety, cannot customise for its context, and cannot reproduce if the provider withdraws access. Fine-tuning capabilities that require the provider’s infrastructure are not sovereignty — they are a deeper form of dependency.
The AI model layer introduces a new dimension of dependency: the dependency on the model’s training data, architecture, and behaviour. An entity that fine-tunes a closed model on its own data has not achieved model sovereignty — it has created a derivative work that it cannot extract, cannot deploy independently, and cannot audit. The model’s behaviour is determined by its pre-training, which the entity did not control, on data the entity did not curate, with objectives the entity did not define. The TEE Method requires entities to assess AI model dependency across five dimensions: weight access (can we run the model on our infrastructure?), training data transparency (do we know what the model was trained on?), architecture visibility (can we inspect the model structure?), behavioural controllability (can we constrain the model’s outputs?), and reproducibility (can we rebuild the model from scratch if the provider withdraws?).
Layer 6: Data and Governance
Who sets the rules for data use? Where does data reside at rest and in transit? What are the jurisdictional implications? Who has access under what legal authority? Data sovereignty is not a storage question — it is a governance question. Data stored domestically but processed through foreign-controlled APIs is not sovereign data. Data subject to foreign legal process — whether through cloud provider terms of service or government surveillance mandates — is not sovereign data. The entity that cannot control the legal framework governing its data does not own its data.
The data layer is where the other six layers converge. Hardware, network, OS, middleware, and application dependencies all manifest as data dependencies: where does the data live, who can access it, under what legal authority, and for what purposes? The TEE Method requires entities to conduct a data flow sovereignty audit: for every data stream entering and leaving the entity’s systems, identify the jurisdiction at rest, the jurisdiction in transit, the legal authorities with access, the contractual parties with rights, and the technical controls in place. A data flow that crosses a jurisdiction with surveillance laws that conflict with the entity’s sovereignty requirements is a sovereignty breach — regardless of whether the data is encrypted.
Layer 7: Human and Institutional
Who has the expertise to operate, audit, and replace the system? What are the knowledge concentration risks? What are the contractual constraints on staffing and skills development? The human layer is the most overlooked and the most decisive. An entity that depends on vendor-certified engineers for system operation has not just outsourced its technology — it has outsourced its institutional capacity. Contractual clauses that restrict hiring from the vendor, that require vendor certification for system access, that prohibit reverse engineering — these are not commercial terms. They are sovereignty constraints.
The human layer is where governance capacity lives or dies. An entity can have perfect technical sovereignty — own hardware, domestic network, open-source OS, standard APIs, open-weight models, domestic data — but if no one in the entity understands how to operate, audit, or replace the stack, the entity has no practical sovereignty. The TEE Method requires entities to assess human-layer dependency through a knowledge distribution audit: for each critical system, how many internal staff can operate it independently? How many can audit it? How many can migrate it? If the answer is “one” or “zero” for any critical system, the entity has a single-point-of-failure in its governance capacity that is as dangerous as a single-point-of-failure in its technical infrastructure.
The Seven-Layer Dependency Audit
The following framework provides a systematic audit across every layer of the technology stack. Each layer must be assessed independently — dependency at any layer creates governance exposure that cascades. An entity that scores 5 at Layer 5 but 1 at Layer 1 has not achieved sovereignty. It has achieved a conditional capability that exists at the sufferance of its hardware provider. The audit must be repeated quarterly for critical systems, annually for all systems, and immediately upon any vendor acquisition, jurisdiction change, or architectural modification.
| Layer | Sovereignty Question | Assessment Criteria | Red Flag |
|---|---|---|---|
| 1. Hardware/Compute | Who owns the physical infrastructure? | Data centre locations, jurisdiction, power dependencies | Single-provider DCs in foreign jurisdiction |
| 2. Network | Who controls data pathways? | IXP traversal, routing dependencies, failover | No domestic routing alternatives |
| 3. OS/Virtualisation | Who controls the base software? | Open vs proprietary, update dependencies, build rights | Proprietary with no source access |
| 4. Middleware/API | Who governs integration layer? | Open standards vs vendor APIs, versioning policy | Vendor-locked APIs, no open adapters |
| 5. Application/AI | Who controls the intelligence? | Open-weight vs closed, fine-tuning rights | Black-box, no audit, no customisation |
| 6. Data/Governance | Who sets data rules? | Residency, jurisdiction, access authority | Foreign data access laws apply |
| 7. Human/Institutional | Who has operational expertise? | Knowledge concentration, skills development | Single-point-of-failure expertise |
The Sovereignty Test Matrix
Score each domain from 1 (critical dependency) to 5 (full sovereignty). The goal is not perfect scores — it is an honest, actionable profile that reveals where governance investment is needed most. Mixed profiles are the norm. An entity that scores 4 on Political Sovereignty but 2 on Technological Sovereignty has a specific, actionable governance gap: it can make independent decisions but cannot implement them without provider cooperation. The matrix should be completed by a cross-functional team including technology, legal, procurement, and strategy — not by IT alone.
| 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 |
Most entities will have a mixed profile — sovereign at some layers, dependent at others. The TEE Method does not require sovereignty at every layer. It requires that the entity understands its stack position, governs it deliberately, and improves it progressively.
— SOVEREIGN: Who Owns the Future?
Red Flag Checklist: Identifying Critical Dependency Risks
The following indicators identify warning signs that technology dependency has reached critical levels. If three or more apply, immediate strategic action is required. These are not theoretical risks — they are the observable patterns that precede sovereignty loss. The checklist should be run quarterly for all critical systems, and the results should be reported to the entity’s governance authority.
- Single-Provider Critical Function: A core function depends entirely on one technology provider with no viable alternative identified or tested.
- Proprietary Data Lock-In: Organisational data is stored in a proprietary format that cannot be exported without transformation, data loss, or significant cost.
- No Withdrawal Protocol: There is no documented, tested plan for transitioning away from the dependent technology, even in an emergency.
- Vendor-Dependent Expertise: The entity relies on the technology provider (or their certified partners) for all troubleshooting, customisation, and optimisation — internal staff lack the knowledge to operate independently.
- Unilateral Pricing Power: The provider has increased prices significantly in the past two years, or the entity cannot predict future pricing due to opaque licensing models.
- Governance Capture: The provider’s terms, certifications, or compliance frameworks have become the entity’s de facto standards, limiting the entity’s ability to make independent governance decisions.
- Acquisition or Consolidation Risk: The provider operates in a consolidating market, or the provider itself has been recently acquired, creating uncertainty about future product direction, pricing, and support.
- Cross-Border Jurisdictional Risk: The provider operates under a different legal jurisdiction with data access laws, surveillance capabilities, or regulatory requirements that may conflict with the entity’s sovereignty interests.
If three or more of these indicators apply, the entity is in a critical dependency position and should initiate an urgent TEE Method assessment across all five sovereignty domains.
Phased Implementation Framework
| Phase | Timeframe | Key Actions | Deliverable |
|---|---|---|---|
| Phase 1: Assessment | Weeks 1-4 | Complete Sovereignty Test Matrix for all critical dependencies; map all single-provider dependencies for core functions; conduct seven-layer stack audit; develop red flag checklist per dependency | Technology Dependency Assessment Report with scored matrix |
| Phase 2: Strategic Planning | Months 2-3 | Develop withdrawal protocols for the three highest-risk dependencies; identify and pilot alternative solutions; begin knowledge transfer programmes to reduce knowledge concentration; negotiate contractual protections including data portability, transparent pricing, and genuine exit provisions | Technology Sovereignty Strategic Plan with withdrawal protocols |
| Phase 3: Implementation | Months 4-12 | Execute multi-provider strategies for critical dependencies to prevent single-provider lock-in; implement open-format standards for all new data and workflow systems; establish continuous monitoring infrastructure for dependency indicators; conduct regular exit testing to verify withdrawal capability | Operational sovereignty with verified withdrawal capability |
| Phase 4: Institutionalisation | Months 13-18 | Embed dependency assessment into all technology procurement and adoption decisions; build internal capacity for independent technology evaluation and audit; develop sovereign alternatives for critical infrastructure where economically viable; participate in the drafting of technology governance frameworks | Self-sustaining governance infrastructure for technology sovereignty |
The Closing Question
What happens when the infrastructure you depend on becomes the infrastructure that governs you?
The transition from adoption to governance is not automatic. It requires deliberate structure, sustained commitment, and the frameworks to make sovereignty measurable rather than aspirational. The TEE Method provides the structure. The choice belongs to those who lead.
This article draws on the TEE Method framework from SOVEREIGN: Who Owns the Future? The Sovereignty Test Matrix, red flag checklist, and implementation framework presented here are practical tools derived from the TEE Method for entities committed to governing their technology dependencies deliberately.
For the complete framework, including detailed TEE Method assessment protocols, layer-by-layer auditing procedures, and sovereignty test matrices for organisations of all sizes, see SOVEREIGN: Who Owns the Future? — available at tonishatagoe.com.