Practical guides
How to avoid AI vendor lock-in
Lock-in is rarely created by the model you chose. It is created by the things you did not keep: the evaluation sets, the context, and the ability to run the same request somewhere else.
Vendor lock-in in AI is usually discussed as a model choice, which makes it sound like a decision made once at the beginning. It is not. Swapping one model for another is often a configuration change. The expensive dependencies form elsewhere, quietly, over about eighteen months.
They form in the places where your system stopped being portable: in prompts tuned to one provider's behaviour, in data that now only exists inside a vendor's index, in evaluation criteria nobody wrote down, and in a workflow that has come to assume one product's shape.
Avoiding this is not about refusing to depend on anyone. It is about keeping five specific assets on your side of the line.
Five things to keep
If you can run your evaluation set against a different provider on a Wednesday afternoon, you are not locked in. Everything else is architecture detail.
Where the architecture decides it
A few structural choices carry most of the outcome, and all of them are cheaper to make at the start than to retrofit.
An interface you own
Your application should call your own abstraction, not a provider SDK scattered through the codebase. One thin layer, one place to change.
Open protocols at the seams
Where tools and data sources connect, prefer open standards such as the Model Context Protocol over bespoke integrations that only one platform speaks.
Portable serving as an option
Keeping an open-weights path viable through stacks like vLLM changes your negotiating position even if you never use it.
Observability outside the vendor
Traces and metrics through OpenTelemetry into your own store. Monitoring that lives in a provider's console leaves when you do.
This is the same argument as vendor-neutral AI architecture, and it is why we take the position we do on owning the systems that encode your judgement.
The contract terms worth arguing about
Procurement usually negotiates price and availability. The terms that determine portability are elsewhere in the document.
Export on demand, in bulk
The right to extract your data, logs, and configuration in a documented machine-readable format, at any time, without a professional services engagement.
Model deprecation notice
How much warning you get before a model you depend on is retired or changed. This is a real operational risk and the notice period is negotiable.
Price change mechanics
Caps and notice periods on unit price at renewal. Consumption pricing is competitive at pilot volume and less so once you are operationally dependent.
Training and retention terms
Whether your data trains their models, how long it is retained, and where. Relevant to the EU AI Act and to your own governance posture under the NIST framework.
Ask for all four at the point where you still have alternatives. None of them is unusual, and the willingness to grant them is itself information about the supplier.
The overcorrection to avoid
It is possible to spend more avoiding lock-in than lock-in would ever cost. Building a full abstraction over every provider capability, refusing any managed service, or running your own infrastructure for a workflow of modest volume are all ways of paying an insurance premium larger than the claim.
The proportionate test is the cost of switching, not the fact of dependency. If replacing a provider would take a fortnight, you have enough portability. If it would take two quarters and a rebuild, you do not, and the fix is almost always one of the five assets rather than a re-platforming.
Depend on suppliers. Keep the evidence of what good looks like, the context that makes the system work, and one exercised path out. That combination costs very little and it is what turns a supplier relationship back into a choice. The layer-by-layer version of the same decision is in build versus buy for enterprise AI.
Could you switch provider in a fortnight.
If the answer is no, the fix is usually one of the five assets rather than a rebuild. We can tell you which one in an afternoon.