The AI Lock-In Question: What Happens When the Model You Built On Changes

The most important part of the tool your clinic depends on is something nobody in your building made, and something your vendor did not make either. It is a model a third party owns, and they can change it without asking either of you.

The kind of change that never throws an error

Ordinary vendor risk is loud. A price goes up, a service goes down, a system is retired, and you get an email or a phone call from a very apologetic account manager. You complain, you plan, you move on.

A model change is quieter. The same consultation, run against a new model version, can come back shorter, more hedged, structured differently, or emphasising a different part of the encounter, and nothing objects. No error, no failed request, no red line anywhere. The note is still a valid note, it is just not quite the note your clinicians learned to trust at a glance. Whatever depended on the old shape, a clinician’s four-second check, a billing code pulled from a phrase, a discharge instruction a patient reads at home, can quietly start being wrong. The first person to notice is usually a colleague reading back through a chart.

Before the fix, the honest question: how exposed is what your clinic already runs?

The real test: could you swap providers by lunch?

That is the whole diagnostic, translated for a practice: not could you eventually move with enough time and budget, but could you take your test cases and your data to a different vendor this quarter and know within a week whether the new one is as good. For anything built for you, the same test applies one level down: if prompts live in one place, a thin layer sits between the tool and the model provider, and a handful of evals confirm a new model still gives good answers, the answer is yes. If the honest answer is no, you have learned something no migration quote would have told you: exactly where the coupling actually lives.

What actually protects you

Two things do almost all of the protecting, and neither is exotic.

A thin integration layer, for anything built for you. One place that owns the prompt, the call to the model, and the shape of what comes back. Everything else talks to that layer, never to the provider directly. It is the same discipline behind adding an intelligence layer instead of a migration: a thin seam is cheap to build and cheap to change, a deeply wired integration is neither. If you are buying rather than building, this is a question to put to the vendor, and the quality of the answer tells you a great deal.

A handful of evals. Not a full test suite, a short, fixed set of real examples with answers you already know are right, that you re-run whenever a model version changes. Evals are the only thing standing between a silent behaviour change and a clinician finding it first, months later, in somebody’s chart. Without them you find out about a regression from a colleague, and by then you cannot say how long it went on.

What holds when the model changes

What your clinic runs

• A thin adapter seam yours
• Evals on real answers yours
• Prompts in one place yours
• The rented model rented
• The vendor API rented

What the vendor can change What stays yours

Neither of these is a call to hedge against everything. Most of what a clinic runs will never need this, and preparing for a move you will never make is its own kind of waste. This is specifically for the one or two AI touchpoints where a quiet change in behaviour reaches a patient or a chart, which is where the cost of being wrong stops being commercial.

The honest part: you cannot eliminate this

None of this makes the dependency go away, and it should not pretend to. You are still renting the model, the same way every business running on cloud infrastructure is exposed to that provider’s outages and price changes. If you are chasing a defensible advantage, it was never going to be the model itself. Rented ground does not become yours because you built something good on top of it.

The realistic goal is not zero exposure, it is a cheap exit. The difference between a vendor change costing you an afternoon and costing you a quarter is almost entirely the two things above, and both are cheap to build now and expensive to retrofit after the model has already changed on you.

You cannot stop the ground from moving. You can make sure it does not take the building down with it.

What to do Monday

Do not audit everything. Pick the single AI tool your practice would miss most if it broke, which is usually whichever one your clinicians have stopped writing notes without, and do two things this week: write five real cases with answers you know are correct that you can re-run in under a minute, and ask the vendor in writing what happens when the underlying model version changes and whether you get told. That is most of the protection, for a fraction of the effort a full migration would cost.

---

Want to know exactly how coupled your clinic is to one AI vendor? Book a free consult and we will map your biggest AI touchpoint together and show you what a real eval set, and a contract you could actually leave on, would look like. See more on Second Opinion.