Three different problems
- Provider lock-in: dependence on one model vendor's API and behaviour
- Supplier lock-in: only your developer can change or run the system
- Data lock-in: your accumulated data cannot leave in a usable form
They need different remedies and the third is the one people notice too late.
Provider lock-in is the least serious
- Keep prompts in configuration rather than in code
- Put a thin interface between your system and the provider
- Avoid provider-specific features unless the benefit is large and named
- Keep an evaluation set, so switching is a measured afternoon rather than a leap
With an evaluation set, changing model provider is a test run and a configuration change. Without one, it is a rewrite you cannot verify.
Supplier lock-in is a contract question
Code in a repository you own, credentials in your accounts, documentation sufficient for another developer, and no runtime dependency on the supplier's infrastructure.
Ask for all four at proposal stage. Reluctance now predicts a difficult conversation later.
Data lock-in is the real trap
Conversation history, corrections, evaluation cases and accumulated tuning are what make a mature system valuable. If they live in a product you cannot export from, you cannot leave.
Test the export before you commit — not the documented capability, the actual file.
What is worth accepting
Some lock-in is a reasonable price for a much better product. The point is to choose it knowingly, with an idea of what leaving would cost.
Write that number down at the start. It makes the renewal conversation an informed one.