Lock-in is a spectrum
Some dependency is inevitable and reasonable - using any external service creates it. The question is how expensive switching would be, and whether you would even notice if you needed to.
Machine learning adds a particular wrinkle: vendors change the model behind an unchanged interface. Your system's behaviour changes without any change on your side, which is a form of dependency that traditional software does not have.
The three things to keep
- Your data. Training data, labels and outcomes in a form you can export and use elsewhere. This is the expensive asset.
- Your evaluation set. A held-out set with known answers, maintained by you, so any provider can be measured on the same basis.
- Your integration layer. Your code should call your own interface, which calls the vendor - not vendor-specific calls scattered through the application.
The evaluation set is the most under-appreciated. Without it you cannot tell whether a vendor's silent model change has degraded your results, and you cannot compare an alternative without weeks of work.
Questions to ask before committing
| Question | What a poor answer looks like |
|---|---|
| Can we export our data and in what format? | Only through support, or in a proprietary format |
| Do you notify before changing the model? | No, or only for major versions |
| Can we pin a version? | No - you always get the current one |
| What happens to our data if we leave? | Vague, or retained indefinitely |
| Is our data used to improve your service? | Yes, without an opt-out |
The third row matters most for consistency. A system whose behaviour can change without warning is difficult to operate in any process that needs to be auditable.
The abstraction layer, kept honest
Wrapping a vendor behind your own interface is standard advice and easy to do badly - an abstraction shaped entirely around one vendor's peculiarities provides no real portability.
Keep it shaped around what your business needs rather than what the vendor offers. If a capability is genuinely specific to one provider, isolate it and know that using it is a deliberate deepening of the dependency.
Measure continuously so you would notice
Run your evaluation set periodically against the live service and record the results. If a vendor changes something, you will see it in your own numbers rather than in a customer complaint.
That record is also what makes a switching decision straightforward. Comparing a new provider becomes running the same evaluation rather than starting an assessment from scratch.
If a vendor changed their model tonight, would you find out from your monitoring or from a customer?