AI Vendor Lock-In Is a CIO Problem, Not Procurement's

Picture the sequence. A bank's procurement team runs a competitive process, negotiates a decent rate on a frontier model, and signs a twelve-month commitment. Six months in, a rival provider ships something materially better at a lower unit price, and a product team asks to move. Engineering comes back with the verdict: this is not a switch, it is a re-platform, because the model's quirks are threaded through prompts, output parsers, evaluation harnesses, and a dozen integration points. The contract was portable; the system was not. This is the form of AI vendor lock-in that actually costs money, and it is almost never visible in the document procurement signed.

The lock-in that matters does not live in the commercial terms. It lives in the code, in the many small couplings between your product and one provider's way of doing things. Procurement can win every point on the rate card and still hand you a dependency that takes two quarters to unwind.

So here is the position. Which model you buy is a reversible, tactical choice that will look wrong within a year whatever you pick. Whether your architecture treats the model as a replaceable component is a strategic choice that determines how expensive being wrong turns out to be. The first is a procurement conversation. The second is a concentration-risk posture, and in a regulated institution it belongs to the CIO and the board, not to the desk that negotiates the rate card.

Why the model is the wrong thing to commit to

The uncomfortable fact underneath every foundation-model decision is that you are committing to a moving target with a planning horizon shorter than your procurement cycle. Capability and price reset on a cadence measured in months. No CIO can credibly forecast which provider leads in eighteen months, and any strategy that depends on that forecast being right is fragile by construction. The rational response to unforecastable change is not to pick harder. It is to design so that picking wrong is cheap.

That reframing matters because it moves the decision out of the domain of prediction, where you will lose, and into the domain of architecture, where you have control. You cannot make the market stop moving. You can decide whether a better model landing next quarter is a fortnight's integration or a re-platform. That property is set long before the better model exists, by choices your teams make now about where a provider's specifics are allowed to leak into your systems.

Why AI vendor lock-in is now a supervisory concern, not just a commercial one

For regulated financial services this stopped being a purely commercial question the moment operational-resilience expectations hardened around third parties. The EU's Digital Operational Resilience Act, live since the start of 2025, requires institutions to understand critical ICT third-party dependencies, maintain credible exit strategies, and avoid concentration they cannot unwind. UK operational-resilience rules point the same way. A hard, undocumented dependency on a single model provider for a critical customer-facing process is precisely the kind of concentration a supervisor will ask you to evidence you can exit.

Read that against the earlier scenario and the stakes change. The inability to move providers is no longer only a negotiating weakness that lets a vendor raise your price. It is a resilience gap you may have to explain, and an exit plan you may be unable to demonstrate. When a board asks what happens if this provider fails, doubles its price, or is itself told to withdraw a capability, the honest answer for most institutions today is that they do not know, because nobody built for the answer. That is a governance finding waiting to happen.

The boundary pays for itself long before any migration

There is an argument that portability is insurance you pay for and never claim. In practice, owning the boundary between your systems and the model earns its keep continuously, because it turns model selection from a standard you adopt into a decision you make per unit of work.

I saw this most directly in a system I built outside financial services, a content-generation pipeline that assembled media from many components. Every model and media capability sat behind a single internal interface, and a router chose which backend served a given job. That choice was a pure function of the quality tier requested, which backends were actually usable on the machine at that moment, and an optional budget ceiling that ruled out anything too expensive, and it always fell back to an option that could not fail. I designed and built that router as real, working, unit-testable code, not a diagram, and the shape transfers exactly. In a bank, a document-classification step, a customer-facing summary, and an internal analyst aid have different accuracy needs and very different risk exposure, and behind a proper boundary you can route each to the model that fits it and change your mind next quarter. Without one, you are stuck paying frontier prices for clerical work, or accepting clerical quality on the flows that carry regulatory weight.

The named engineering idea here is old and unglamorous: an anti-corruption layer, a translation boundary that keeps a volatile external dependency from dictating the shape of your internal domain. It is exactly the pattern that lets an incumbent provider and its challenger coexist behind one interface. The discipline I hold to is to specify the capability you depend on, not the vendor that currently supplies it, so the vendor can change without your design having to move. That is the same model-interoperability pattern we use to make provider exit testable rather than theoretical, and it is a core concern of platform engineering.

The failure mode nobody puts in the business case

The boundary introduces its own risk, and it is the one that bites in production. The same seam that lets you swap a provider deliberately also lets a stale configuration swap one accidentally, with no error raised. In that same pipeline I watched a leftover setting silently downgrade output; everything ran, nothing failed, and the result was quietly worse than intended. Transferred into a regulated flow, that is not an inconvenience. It is an unrecorded change to the thing that produced a customer outcome.

The router in that system handled this in a way worth copying: alongside every output it recorded which backend it had chosen and the alternatives it had weighed, so the decision was an inspectable fact rather than an assumption. That single habit is what connects the abstraction to your model-risk obligations. Banks operating under the PRA's model-risk management principles already need a defensible inventory of the models in use and evidence of which one did what. An architecture that can silently substitute models without recording the substitution is incompatible with that duty. Build the swap and the record together, or you have built a faster way to lose the audit trail.

The steelman, and why it only half holds

The strongest counter-argument is that this is premature engineering. The market, it runs, is consolidating around a small number of serious providers; abstraction layers are notorious for reducing every model to its blandest common denominator and stripping out the very capabilities you are paying for; and an institution racing to ship value should commit to one good provider, exploit everything it offers, and not gold-plate a portability story it will never use. There is real truth here. A premature abstraction is a tax, and for a genuinely experimental product bet, where the differentiator is one provider's distinctive capability, wrapping that capability away is self-defeating. Feel the lock-in first, and pay for portability when the switching cost becomes real rather than hypothetical.

Where the argument fails is in the regulated core, and that is exactly where most CIO attention should sit. On a supervised, customer-facing process, exit capability and auditability are not gold-plating; they are conditions of operating. The consolidation claim also cuts the other way, because the fewer the serious providers, the sharper the concentration risk, and the more a supervisor cares whether you can move. As for the blandest-common-denominator worry, the answer is to scope the abstraction rather than abandon it. You wrap the capability you depend on across providers, and you leave a deliberate, documented exception for the one place a specific model's edge is genuinely your advantage. That is a design judgement, not a reason to hard-wire yourself to a vendor everywhere by default.

What to do differently on Monday

Treat model selection as a reversible architecture decision with a named owner, and stop letting it be settled implicitly by whichever team integrated first. For any model-backed capability on a regulated process, require that it sits behind an internal boundary, and make which model and which version produced a given output a logged attribute wired into your model inventory rather than bolted on later. Set an explicit portability bar and test it the way you test an operational-recovery plan: if a provider became unacceptable tomorrow, on commercial, resilience, or supervisory grounds, how many weeks to move, and who signs that estimate off. Fold the answer into your DORA exit planning and your AI governance controls rather than treating them as separate exercises.

Then resist the opposite error. Do not abstract the one capability where a particular model is your genuine edge; document that dependency as a deliberate, eyes-open exception with an owner and a review date, so it sits on the record and is not an accident. Optionality everywhere is its own waste. The craft is knowing which couplings you are choosing to keep.

Architecture, not procurement, determines lock-in

The model you are proud of today will look ordinary within a year, and the provider you trust will, at some point, disappoint you on price, capability, or resilience. None of that has to be an emergency. Decide now that your institution's dependence on any single model is a matter of architecture and concentration risk that the CIO owns, and the next model release becomes an opportunity you can take rather than a migration you dread. Lock-in is not something a contract prevents. It is something an architecture permits.