The AI Exit Problem: I Went Looking for a New Kind of Lock-In. The Evidence Had Other Plans.

An investigation into AI providers, sovereign models, technology dependencies, and a question that turned out to be considerably less straightforward than advertised.

It started with a fairly innocent question.

What happens when an enterprise decides to leave its AI provider?

Given how enthusiastically organisations are weaving AI into everything from customer service to cybersecurity, I suspected we were building ourselves a rather interesting exit problem.

Models. Agents. Embeddings. Fine-tuning. Proprietary workflows. Specialised infrastructure.

A whole ecosystem of dependencies, apparently held together by APIs, optimism, and a surprisingly generous allocation of GPU budgets.

Surely leaving all that behind would be materially different from switching any other enterprise technology?

I thought so.

Then an inconvenient question appeared.

How is this different from replacing ServiceNow, migrating an ERP, or moving workloads between cloud providers?

We've been doing those things for decades.

We know the drill. Data migration. Integration mapping. Contractual complications. Testing. Cutover. Business continuity.

And, occasionally, discovering that the one person who understood the legacy system retired in 2019.

So was AI introducing a genuinely new kind of technology lock-in?

Or were we looking at a familiar problem wearing a considerably more expensive jacket?

I decided to investigate.

The evidence, unfortunately, refused to cooperate with my hypothesis.

And that's where things got interesting.

Plot twist #1: Sometimes, leaving an AI model is remarkably easy.

When Anthropic released Claude 3.5 Sonnet in June 2024, Sourcegraph made it available through Cody approximately an hour after release.

An hour.

Some enterprises need longer than that to agree on the agenda for a change advisory board meeting.

Of course, making a model available is not the same as completing an enterprise-wide migration. Production validation, deployment arrangements, and customer-specific dependencies still matter.

But it demonstrated something important.

When an application is designed appropriately, replacing the underlying AI model doesn't necessarily require rebuilding the surrounding system.

GitHub Copilot went further.

Its engineers developed model interfaces, extensive evaluation systems, and production testing mechanisms to support different foundation models.

In November 2025, GitHub also described evaluating nearly 30 candidate models for its specialised Next Edit Suggestions feature without finding one sufficiently good to replace the incumbent.

Think about that.

Thirty contenders. No promotion.

The lesson wasn't simply that GitHub could switch models.

It was that GitHub had developed the ability to determine whether switching was worthwhile.

And sometimes, the smartest migration is the one you don't undertake.

Plot twist #2: Owning the model doesn't mean you've escaped.

Next came the sovereignty question.

What if an enterprise doesn't want another AI provider?

What if it develops its own specialised language model, fine-tunes it using proprietary data, and deploys it on infrastructure under its control?

Surely that solves the dependency problem.

Well, not quite.

Fin, the customer-service AI company, offers a fascinating example.

It gradually moved from commercially supplied foundation models toward increasingly specialised internal AI capabilities, eventually developing its Apex answering models.

But this wasn't a weekend experiment involving an open-weight model and an enthusiastic GPU.

It required proprietary datasets, evaluation systems, reward models, specialised engineering, and substantial post-training capabilities.

And even then, Fin continued using externally developed foundation models, cloud infrastructure, and commercial AI services for parts of its product.

There is nothing inherently wrong with that.

In fact, it may be an entirely sensible architecture.

But it exposes an important distinction.

Owning a model is not the same as owning the entire capability required to operate it.

You might own the weights, rent the GPUs, depend on someone else's software framework, and require specialist engineers to keep the whole arrangement functioning.

Congratulations. You've changed the landlord.

Possibly for very good reasons.

But you're still paying rent somewhere.

Then conventional IT entered the conversation.

And this is where my original hypothesis started looking rather uncomfortable.

Because we found that conventional technology migrations already demonstrated many of the problems I initially thought made AI special.

In 2018, TSB Bank migrated to a new technology platform.

According to the UK's Financial Conduct Authority, the data migration succeeded.

The banking services, however, experienced serious disruption.

The subsequent regulatory penalties and customer consequences were substantial.

No generative AI was involved.

The data moved. The business outcomes didn't survive the transition as intended.

So much for the argument that traditional IT migrations are about preserving systems while AI migrations introduce the challenge of preserving outcomes.

Good enterprise technology governance has always been about protecting business outcomes.

We also examined companies that brought technology capabilities in-house.

37signals, for example, reported substantial reductions in its cloud bill after moving major application workloads from AWS onto owned infrastructure.

Its economics were influenced by workload characteristics, existing infrastructure, and internal engineering capabilities.

Sound familiar?

Fin's specialised AI strategy and 37signals' cloud repatriation are different technical undertakings, but they share a familiar business question:

At what point does owning or operating more of the technology become economically preferable to buying it as a service?

That question predates AI by a considerable margin.

So, apparently, does the answer: it depends.

Enterprise IT's most enduring two-word contribution to management literature.

We followed the money. It didn't give us a dramatic answer either.

Perhaps AI exit wasn't fundamentally different technically.

But surely rapidly improving AI models change the economics of remaining with an incumbent.

There was something here worth testing.

Model prices and capabilities have changed significantly. An alternative might offer better performance, lower inference costs, or both.

If an organisation cannot switch, perhaps it loses access to those improvements.

But there's a complication.

A better benchmark score doesn't automatically translate into better business results.

A cheaper model doesn't necessarily produce cheaper successful transactions.

And a model that looks attractive today might lose its advantage when the incumbent releases an update next month.

We explored historical pricing, task-specific evaluations, reported production transitions, and transparent economic sensitivity analyses.

The conclusion was wonderfully inconvenient.

Whether switching pays depends on workload volume, actual business improvements, validation effort, transition cost, and how long the advantage lasts.

Groundbreaking?

Not exactly.

That's established technology investment economics.

The underlying principles of modularity and the value of being able to substitute better components were being studied long before anyone needed a prompt engineer.

What we couldn't establish from the public evidence was whether ordinary enterprises are losing substantial financial value specifically because they cannot replace their AI models quickly enough.

And without that evidence, claiming a distinctive AI exit penalty would have been rather adventurous.

So, did the hypothesis survive?

Not in its original form.

We found that AI models can sometimes be replaced quickly.

We found that deeply specialised AI capabilities can be more complicated to replace.

We found that developing proprietary models can reduce some dependencies while introducing others.

We found that organisations invest significantly in knowing which models to adopt—and which to reject.

What we didn't establish was that AI exits are systematically more expensive, difficult, or disruptive than comparable conventional enterprise technology migrations.

The public information simply wasn't sufficiently comparable or complete.

That doesn't prove AI exit is the same.

It means we don't yet have enough evidence to demonstrate that it is fundamentally different.

There's a distinction.

And it's one worth respecting.

Which leaves me with a question.

Perhaps we've been asking the wrong thing.

Instead of asking whether enterprises can escape their AI providers, perhaps we should ask whether they're making rational investments in their ability to do so.

For a company processing millions of AI-assisted customer interactions, continuous model evaluation and replacement might be economically valuable.

For an organisation using AI to summarise a few internal reports, building an elaborate provider-neutral architecture might be an impressive way to spend money solving a problem it doesn't actually have.

Both can be perfectly rational decisions.

The challenge is knowing which one you're making.

So, after following this question through AI architectures, specialised models, sovereignty, cloud infrastructure, migration economics, and a few uncomfortable comparisons with conventional IT, I'm left with a rather unspectacular but defensible conclusion.

AI may be changing the pace at which technology choices become attractive.

We haven't yet established that it changes the fundamental economics of leaving.

And I find that uncertainty more interesting than another confident prediction about inevitable AI lock-in.

Because the evidence isn't finished.

I'd particularly like to hear from people who've actually moved production workloads between AI providers, replaced foundation models, or brought model capabilities in-house.

What did the transition reveal?

Was the real difficulty the technology, the commercial arrangement, the validation, the economics—or something entirely different?

Equally interesting: did you evaluate switching and decide it wasn't worth the trouble?

I'm interested in documented experiences, not just another round of warnings about vendor lock-in.

We have decades of those already.

For now, the AI Exit Problem remains an open question.

And occasionally, the most useful thing research can tell us is that the question deserves better evidence before it deserves a confident answer.

Rumblings of My Mind | Enterprise Signal

Independent personal research based on publicly available sources. The analysis and interpretations reflect my own understanding and may evolve as new evidence emerges.