What vendor lock-in means
Vendor lock-in means: switching to another provider has become so expensive, effortful, or risky that it's practically off the table – you're tied in. That's not inherently bad, but it should be a conscious decision, not one you slide into by accident.
Where lock-in arises with AI
With AI, dependence arises in several places: prompts optimized precisely for one particular model; a model fine-tuned for one provider (see "When is fine-tuning actually worth it?"); proprietary interfaces and data formats that aren't easy to take with you; and integrations built deep into workflows. The more of these that come together, the higher the switching barrier.
How to bound lock-in
Four approaches help: route the model through a swappable abstraction layer instead of wiring it in hard (then the provider can be swapped); keep your own data exportable and under your control (e.g. RAG on your own data, see "What is RAG (Retrieval-Augmented Generation)?"); don't over-tune prompts to a single model; and assess switchability before you start, not only when it's urgent.
Lock-in isn't always bad
A certain amount of dependence is often a fair price for convenience and performance – a turnkey proprietary service saves effort (see "Open source vs. proprietary AI models: what's the difference?"). The point isn't to avoid every dependence, but to enter it consciously and know how expensive an exit would be.
Why this matters for you as a decision-maker
Before you commit to a provider, it's worth asking: how much effort would switching be in a year? Is our data portable? That's not paranoia, but a conscious weighing of convenience today against freedom of action tomorrow (related to "Build vs. buy vs. API: what's the right call?").