The Convenience Trap: How AI Services Create Dependency

There is a pattern in how technology enters our lives that deserves closer attention. The pattern is: the easier something is to use, the harder it is to leave.

Consider a hospital in rural Kenya. It needs diagnostic AI support for its clinicians. It does not have the technical staff to build or maintain its own AI system. It does not have servers or data centers. It does not have the budget for infrastructure investment. What it has is an internet connection and a growing caseload of patients who need better care than the current staffing levels can provide.

A platform offers a solution. The AI runs entirely in the cloud. No local servers to manage. No technical staff to hire. No infrastructure to build. The clinician opens a browser, enters the patient’s symptoms, and receives a diagnostic recommendation. The clinical benefit is immediate and real.

The hospital has just adopted Software as a Service — the most accessible and the most dependency-creating model in cloud computing.

The cloud computing industry has organized itself along a spectrum of service models, and that spectrum reveals a tradeoff that is rarely stated plainly: every step toward greater convenience trades sovereignty for ease. The more the provider manages, the less the customer controls. Convenience and sovereignty move in opposite directions.

At one end of the spectrum sits the organization that owns everything — the building, the servers, the storage, the network, the security team. Maximum sovereignty. Maximum cost. At the other end sits the SaaS customer who simply uses a finished application. Minimum sovereignty. Minimum cost. Between these poles, a gradient of intermediate options exists: colocation, managed hosting, bare-metal cloud, Infrastructure as a Service, Platform as a Service, container services, and serverless computing. Each step toward the convenience end transfers another layer of control from the customer to the provider.

For the Global South, this tradeoff has a specific and consequential implication. The vast majority of AI adoption in healthcare, education, and enterprise — particularly in nations with limited technical infrastructure — occurs at the SaaS level, because SaaS is the most accessible option. The clinical benefit is real. The educational benefit is real. The operational benefit is real.

But the hospital, the school, or the ministry that adopts SaaS AI has handed over the application, data processing, inference logic, and learning extraction to the provider. If the platform changes its pricing, its data policies, or its terms of service, the customer has no alternative infrastructure to fall back on. The school that built its curriculum around a platform’s educational AI cannot switch to a competitor without disrupting the academic year and losing the learning data its students generated. The ministry that deployed a platform’s triage system across a national health network is locked in by the training data its own clinicians generated — data that lives on the platform’s servers, improving the platform’s model for use everywhere else.

This is what I call the pathology of ease: the very accessibility of the tool creates the deepest dependency. The nation or institution that adopts SaaS AI is sovereign over its decision to adopt. It is not sovereign over anything that happens afterward. The decision to start is free. The cost of leaving is prohibitive. And the longer the relationship continues, the deeper the dependency grows, because the platform’s model becomes more valuable to the customer as it learns from the customer’s data — data the customer cannot take with them when they leave.

The pathology is real, but it is not inevitable. Between full SaaS dependency and full self-owned infrastructure, intermediate models exist that provide meaningful sovereignty at an achievable cost.

Sovereign cloud programs are emerging across multiple regions. France, the broader European Union, and several Gulf states have launched initiatives to build cloud infrastructure that combines the economics of cloud computing with the governance of national jurisdiction — local data centers, local legal authority, domestic operational control.

Dedicated facilities within existing data centers allow a customer to control physical access and operational authority over their own equipment, even when the building is owned by someone else. At the upper end of these models — single-tenant data centers, sovereign data centers — what the customer purchases is not computing power. It is physical sovereignty.

Air-gapped and high-security facilities, particularly prevalent in Switzerland, Luxembourg, and the Nordic countries, provide environments where even facility staff cannot access customer areas. In these models, the product is not infrastructure; the product is control.

These intermediate models do not solve the full infrastructure sovereignty challenge — a sovereign data center still needs to procure servers and chips from a concentrated supply chain. But they address the facility and operations layer of the dependency, and they are available now at costs and timescales dramatically lower than those of building a national semiconductor industry.

The Kenyan hospital does not need to choose between full SaaS dependency and building its own data center. Between those poles lies a range of options — sovereign cloud, regional cooperation, shared infrastructure — that provide meaningful control without requiring impossible investment. Knowing those options exist is the first step. Exercising them is the next step.

The convenience is real. The dependency it creates is also real. The question for every institution and every nation is: where on the spectrum do you choose to stand — and do you understand what you are trading when you choose ease?

This article is drawn from Digital Sovereignty in the Cognitive Age, available at blogs.inspire-aspire.net.