Vendor Lock-In in AI: Where It Hides and How to Limit It

Lock-in in AI is subtler than a contract

Classic vendor lock-in is a painful migration and a data export. AI vendor lock-in is that plus a few things specific to how these systems are built — assets that live in the vendor's tooling, models you can't take with you, and data shapes tied to one provider. It's worth mapping before you sign, because the switching cost compounds quietly.

Where it hides

• Prompts and flows in a vendor console. Your prompt engineering, your conversation design, your relevance rules — authored in the vendor's UI, with their own history, editable only through them. If you leave, you rebuild it.
• A fine-tuned model you can't export. You paid to fine-tune on your data; the weights stay with the vendor. Switching means re-fine-tuning somewhere else from scratch.
• Conversation and decision logs. The record of what the system did — training data, audit trail, analytics — in the vendor's store, sometimes not fully exportable.
• Embeddings tied to one model. A vector index built with one provider's embedding model can't be queried by another's. Switching embedding providers means re-embedding the whole corpus.
• The eval set built in their tooling. Your test cases and their expected outputs, trapped in a format that doesn't come out.
• A proprietary API shape. Integration code written against a vendor-specific request and response format that no one else matches.

How to limit it

• Keep prompts and flows in your repo, in version control, as the source of truth. If a vendor console is used, treat it as a mirror.
• Own your data. Contractual export of conversation logs, decision records, and analytics in a usable format — checked, not assumed.
• Prefer portable formats. An exported model format that runs across runtimes, rather than a single-vendor runtime — on our shelf-monitoring engagement a portable model format is what kept the option open to change edge hardware without a rebuild.
• Abstract the provider. A thin internal interface for "call the model" and "get embeddings," so swapping providers is one adapter, not a rewrite.
• Budget the re-embed. Know up front that changing embedding models means re-indexing the catalogue — it's a one-off job, but plan for it.

The re-embed is the concrete one

Of all the lock-in points, embeddings are the one people hit unexpectedly. A vector index built with one provider's embedding model returns nonsense if you query it with another's — the vector spaces don't line up. Switching embedding providers means re-embedding the entire corpus and rebuilding the index: a one-off batch job, real but bounded. Budget it as a known cost of switching rather than a reason you can't. On our portfolio projects the embedding call sits behind a thin internal interface, so changing provider is one adapter plus that re-embed, not a rewrite.

The fine-tuned model is the one you can't fix later

If you've fine-tuned on a vendor's platform and the weights don't come out, there is no mitigation after the fact — leaving means re-fine-tuning from your dataset somewhere else. The only real defence is deciding up front: keep the training dataset and the eval set in your own storage, and prefer a provider whose fine-tuning output you can export.

Where this stops being right

• A commodity capability you'd never switch — the lock-in cost is theoretical, and the abstraction layer is overhead.
• An early-stage product moving fast — some lock-in is an acceptable trade for speed, as long as you know where it is.
• A vendor with a genuinely unique capability — there's no alternative to be locked in from; the question is just data portability.

FAQ

What's the worst AI lock-in? A fine-tuned model you can't export and prompts that only exist in a vendor console. Both mean rebuilding your core work to leave.

How do I limit embedding lock-in? Abstract the embedding call behind an internal interface, and accept that switching models means a one-time re-embed of the corpus — plan for it rather than being surprised.

Is some lock-in acceptable? Yes — for speed, early on, or for a capability only one vendor has. The point is to know where it is and what leaving would cost, not to avoid it entirely.

ISTRALLEN builds AI features with prompts in your repo, portable model formats, and a provider abstraction so switching is an adapter, not a rewrite — see what we do.