The dependency you cannot see is the real lock-in

Vendor choice creates the illusion of control, but resilience depends on what happens when a model, provider or platform can no longer be used. As intelligent systems become more deeply embedded in operations, the real test is whether the business can change direction without disrupting what now depends on them.

An organisation can believe it has built a flexible AI architecture right up until a model is withdrawn, a supplier changes its terms, or a critical workload must move. What looked modular on an architecture diagram can prove much harder to untangle in production, where applications have inherited assumptions from models, data sits inside proprietary pipelines, and governance has been designed around decisions made months or years earlier.

This is the more interesting idea behind IBM Institute for Business Value’s The calculus of AI sovereignty. The report, based on research with 1,000 senior executives across 16 geographies and 17 industries, argues that sovereignty is less about owning the technology stack than retaining the ability to change direction when circumstances demand it. Only nine per cent of executives describe their understanding of their dependencies across vendors, models and infrastructure as excellent.

That lack of visibility is becoming more consequential as intelligent systems move deeper into operational processes. The problem is not dependence itself. Enterprises have always relied on external technology providers. The risk emerges when that dependence becomes so deeply embedded that the business discovers it has lost the practical ability to change supplier, model or infrastructure without redesigning the system around it.

Flexibility can be an illusion

Multi-vendor estates should, in theory, reduce concentration risk. If one provider becomes expensive or unsuitable, another offers an alternative. IBM’s research suggests the reality is less deliberate. Organisations frequently arrive at complex supplier landscapes through local purchasing decisions, regulatory requirements and inherited technology rather than through a conscious attempt to create resilience.

The distinction is important because having several suppliers is not the same as being able to substitute them. Different business units may use different models while still relying on proprietary integration layers or data structures that make moving between them difficult. Complexity can create the appearance of choice while quietly reducing the organisation’s ability to exercise it.

Conor Mlacak, CIO at Staples Canada, describes the commercial consequence succinctly: “Once you’re locked in, you lose leverage.” His point reaches beyond price negotiations. A supplier has far greater influence when leaving requires months of engineering work than when the customer can move a workload or replace a model without materially disrupting operations.

Among executives who had switched or attempted to switch AI vendors during the past two years, three quarters described the process as difficult. Data portability, technical coupling, compliance requirements and model revalidation turned what might appear to be a straightforward supplier change into a much broader programme of technical and operational work.

The risk becomes greater because the underlying technology is not static. IBM’s respondents report unexpected price increases, service restrictions, model deprecations and changes to privacy or data-handling terms during the previous two years. Conventional enterprise software certainly changes, but organisations are accustomed to formal upgrade cycles and relatively predictable product roadmaps. Model behaviour and service conditions can move much faster.

An architecture designed around the assumption that today’s model, API or commercial relationship will remain broadly stable can therefore become brittle surprisingly quickly.

The model is rarely the only dependency

Replacing a model sounds deceptively simple when models are discussed as interchangeable components. The practical dependency usually extends much further. Applications may have been tuned around a particular model’s behaviour, security controls built around its interface and evaluation processes designed to establish that its outputs are safe enough for a specific use.

IBM found that more than half of the executives surveyed believe replacing a core model would require substantial decoupling or a complete system rebuild. Regulated businesses face an additional burden because switching may also require renewed validation, audit and compliance work before the replacement can be trusted in production.

Dalton Gouws, Group IT Director and Board Member at VWG UK Ltd, has taken a deliberately different approach to different layers of the technology estate. “We accept long-term strategic relationships at the application layer,” he says. “But, at the model layer, we deliberately preserve optionality.”

Dependence on a mature enterprise application may be entirely rational when the switching cost is understood, and the supplier relationship remains stable. The calculation changes when a model sits inside rapidly evolving workflows, where deteriorating performance, new commercial terms or a stronger alternative may require the organisation to move quickly. In those situations, preserving the ability to substitute one component for another becomes part of the architecture rather than a future procurement concern.

Sri Lanka Telecom offers an example of how architecture can preserve that freedom. Repeated changes by hyperscalers were forcing its teams to rework solutions, so the company introduced a gateway layer that separates applications from the models underneath them. Anil Pradeep Kumara, Head of AI and Data, says the approach allows models and providers to be switched with less disruption to the applications that depend on them.

The significance lies less in the technology than in the design principle. Optionality must be engineered before it is needed. An organisation that waits until a provider becomes unavailable or commercially unattractive to discover how tightly coupled its systems have become has already surrendered much of its negotiating and operational freedom.

Lock-in becomes a continuity problem

Dependency begins as an architectural concern but eventually reaches the operating business. A customer service process, fraud engine or supply chain workflow does not care why an underlying model has stopped working; it simply experiences the resulting interruption.

IBM found that a large majority of executives believe a seven-day outage at their primary AI provider would have a severe or critical impact on operations. Respondents also reported repeated AI-related disruptions during the previous two years, with vendor service problems and deprecations ranked as the most common cause.

Those findings move the sovereignty debate away from abstract concerns about technology independence. Once systems influence everyday operational decisions, the ability to move workloads or substitute a component starts to resemble conventional business continuity planning.

More than half of respondents estimate that moving core AI systems and applications to another vendor would take at least six months, while relocating the training and operational data behind them would take an average of 145 days. Those timescales expose how quickly a theoretical ability to switch can collapse under the weight of real infrastructure, data and validation requirements.

Sergio Sánchez Gallego, CTIO at Telefónica España, captures the requirement without arguing for technological independence. “Our architecture must be flexible enough to evolve, allowing us to swap components or adopt new technologies without starting from scratch.”

That ability to change without starting again is arguably a better test of sovereignty than where a workload happens to run. Data residency remains important, particularly in regulated industries, but location alone does not guarantee control if the organisation cannot practically move the data or replace the systems surrounding it.

Control should follow consequence

Trying to remove every external dependency would be both expensive and unnecessary. IBM instead argues for selective sovereignty, applying different levels of control according to the importance of the system and the consequences if it fails.

Mission-critical and differentiating systems justify greater investment in portability because disruption could affect revenue, risk or operations. Alternative models can be validated in advance, data exit routes tested and failover arrangements exercised before they are required. Less critical systems can rely more heavily on managed providers, while commodity services such as transcription or routine automation may warrant very little investment in independence at all.

The principle is less about sovereignty than proportionality. A business should spend most heavily on optionality where losing it would have the greatest commercial or operational consequence, rather than attempting to create an expensive escape route from every technology it buys.

IBM recommends measuring time and cost to switch for critical systems, which exposes an important difference between contractual freedom and practical freedom. A contract may permit an organisation to leave a provider tomorrow, but that right offers limited protection if extracting the data, rebuilding integrations and revalidating the replacement will take half a year.

Boards and technology leaders can therefore ask a more useful question than whether they are locked into a particular supplier. They can ask what would happen if that supplier had to be replaced next month. Which applications would continue to operate, which models could move and which dependencies would suddenly become visible?

The strongest architecture is unlikely to be the one with the greatest number of providers or the least external technology. It is the one in which the organisation understands where dependency has been accepted deliberately and where freedom to change has been preserved.

Lock-in becomes dangerous when it remains invisible until the business needs an alternative. By then, the theoretical presence of another vendor or model is irrelevant. What counts is whether the organisation can use it.