Vendor lock-in in AI infrastructure: what to watch for
Not every closed choice in AI infrastructure is lock-in, and it's worth being precise about the difference before reaching for the word. Lock-in is when switching costs you far more than the value you got from the convenience, because the vendor has made leaving deliberately expensive. A reasonable tradeoff is when you picked a closed tool because it was genuinely the best fit, and switching later would just be normal migration work, not punitive. Both exist in AI infrastructure. Here's how to tell them apart before you commit, not after.
Proprietary fine-tuning formats
Some platforms let you fine-tune a model but store the result in a format that only runs on that platform, sometimes not even as downloadable weights, just an API endpoint you can query. If you've invested real time and data curation into a fine-tune and it only exists as a hosted endpoint, you don't own the artifact, you own access to it, and that access is exactly what the vendor controls. Before committing meaningful effort to a fine-tuning workflow, check whether the resulting weights are yours to export in an open, runnable format. If the answer is no, weigh that against how replaceable the fine-tune is; a lightweight adapter you could redo in an afternoon on a different platform is a much smaller lock-in risk than months of curated training data locked behind one vendor's tuning API.
Closed model weights
Building a product around a closed-weight model like GPT-4 or Claude means your product's core capability lives behind an API you don't control, priced how the vendor decides, deprecated on the vendor's schedule. That's not automatically a mistake, closed models are frequently the best available option for a given task, but it is a dependency worth naming honestly rather than treating as a permanent, risk-free foundation. Open-weight models don't remove this risk entirely, since you still depend on whoever trained and released them continuing to maintain that lineage, but they do mean you hold a copy of the actual weights, and a copy you hold keeps running even if the org that trained it stops. See our open-weight vs closed-weight models post for the deeper tradeoff between the two.
Non-standard APIs
The OpenAI-compatible chat completions API has become a de facto standard that most serving frameworks and inference providers now support, vLLM, Ollama, and most managed platforms included. Building your integration layer against that shape rather than a vendor's bespoke SDK is a small amount of extra discipline upfront that pays off directly the day you want to swap providers or self-host the same workload: the application code barely changes, only the endpoint does. A platform that requires its own non-standard request and response format is adding a switching cost that provides you no benefit, which is one of the clearer lock-in signals to watch for.
Data export difficulty
Before you're deep into a platform, check what leaving actually looks like: can you export your logs, your fine-tuning data, your usage history, and your configuration in a usable format, or does the vendor's dashboard only let you view it? A platform that makes export trivial is signaling confidence that you'll stay because the product is good, not because leaving is a project. One that makes export hard, or buries it behind a support ticket, is telling you something about how it expects to retain customers, and it's worth taking that signal seriously before you've accumulated a year of data there.
Where open-weight and OpenAI-compatible choices actually help
Running an open-weight model behind an OpenAI-compatible API, on infrastructure you rent or own, reduces several of these risks at once: the weights are yours to keep regardless of what the model's original publisher does next, and the API shape means your application layer isn't rewritten if you move providers. That's a real reduction in lock-in risk, not a complete elimination of it. You still depend on the hardware provider you're renting from, on continued community or vendor support for the specific model you chose, and on your own team's ability to operate the serving stack. Being honest about which risks moved and which didn't is more useful than treating "open-weight" as a synonym for "no lock-in."
The tradeoff that's not lock-in
It's worth saying plainly: choosing a closed API because it's currently the best tool for the job is not lock-in by itself. Lock-in is specifically about switching costs disproportionate to the value received, not about using a proprietary product at all. A team that picks GPT-4 for a task it's genuinely best at, with clear eyes about the dependency, has made a reasonable engineering tradeoff. The mistake to avoid isn't using closed tools, it's not knowing what leaving would cost until you're forced to find out.