AI Vendor Lock-In: What Businesses Should Consider Before Building

What does vendor lock-in actually mean here?

Lock-in is not a moral failing or a trap laid for you. It is simply the cost of changing your mind: the money, the weeks and the risk involved in moving a working system to a different provider. Every dependency carries some, including the spreadsheet macro your accountant wrote a decade ago. The question worth asking before a build is not how to avoid it, but how large it is and whether you would notice in time.

AI systems make this sharper for two reasons. Providers release, reprice and retire models faster than most software changes, and much of what makes your system valuable is not the model at all. It is your documents, your rules, your prompts and the record of what good output looks like. Where those live decides how painful a change of provider will be.

Where does lock-in actually happen?

It is rarely one decision. It accumulates in six layers, and they are not equally hard to unwind.

Notice the pattern. The layers that are hardest to move are the ones where your own material is stored in someone else’s shape. A workflow you can read, a prompt you can copy and a document you still hold are all portable. A diagram inside a console and an index you cannot rebuild are not.

When is lock-in a fair trade?

Often. A managed service that gets a working enquiry desk running in three weeks may be worth far more than the theoretical freedom of a system you would have to staff and maintain. A workflow that handles forty items a month does not deserve an abstraction layer. Speed, reliability and the team you actually have are legitimate reasons to accept a dependency.

The judgement is a trade between what you gain and what leaving would cost. Take the dependency freely where the switching cost is low. Take it deliberately, with an exit written down, where the value is high and the switching cost is high. Be careful where the switching cost is high and the value is ordinary, which is where most regret sits.

The NIST AI Risk Management Framework makes a related point about third parties: technologies acquired from them may be complex or opaque, and their risk tolerances may not match yours. It asks for policies covering third-party risks, and for contingency processes to handle failures or incidents in third-party data or AI systems judged to be high-risk. Both are worth having before you need them.

Which portability measures are worth the effort?

A few habits keep most of your options open, and none of them requires building your own platform.

• Keep the source material. Hold the original documents and records, not only the derived index or the vendor’s processed copy.
• Own the evaluation set. Real cases with expected outcomes are what let you compare a new provider honestly in a day.
• Keep prompts and workflow definitions in your own repository, versioned, even when they are pasted into a console to run.
• Route model calls through one internal interface, so changing provider is a change in one place rather than forty.
• Export logs on a schedule, in a format you can read without the vendor’s viewer.
• Write down the configuration: models, settings, thresholds and integrations, so nobody has to reverse-engineer it later.

Portability is national policy as well as good sense. Among its recommendations for increasing adoption, the India AI Governance Guidelines ask for greater data availability, sharing and usability supported by data portability standards and data governance frameworks. The same instinct works inside a single business.

What belongs in the contract before you sign?

Exit terms are cheapest to agree while you are still deciding. Once the system is live and the renewal is three weeks away, your position is weaker.

• Your data returned on request, in a documented format, within a stated period.
• Deletion after exit, including logs, backups and derived copies such as embeddings.
• Who owns prompts, configurations and anything trained or tuned on your data.
• Notice periods, renewal terms and how price changes are communicated.
• Sub-processors and processing locations, with notice before either changes.
• Support, availability and what happens if a model you depend on is retired.

Some of this is not optional. Where a vendor processes personal data on your behalf, India’s framework requires a valid contract and holds you responsible for the processing anyway, which our guide to India’s data protection framework covers in detail.

What should you ask a vendor before committing?

1. What exactly do we get back if we leave, in what format, and how long does it take?
2. Can we run the same workflow against a different model, and what breaks if we do?
3. Are our prompts and workflow definitions exportable as files we can keep?
4. Where is our data processed and stored, and how would a change of region be handled?
5. Is our data used to train or improve your models, and can that be switched off?
6. How much notice do we get before a model, feature or price changes?
7. What happens to our workflows if the model we rely on is retired?

The answers matter less than the manner of them. A vendor who answers precisely, in writing, is showing you how the relationship will run. Vagueness at this stage rarely improves after signature. The same questions are useful when you are still weighing build, buy or integrate.

What does a sensible position look like?

That is the whole idea. Accept the dependencies that buy you speed, keep the four portable things in your own hands, and know the size of the door. NIST’s framework asks for third-party risks and benefits to be monitored regularly, with pre-trained models watched as part of ordinary maintenance, which in a small company is one line in an annual review rather than a programme.

When a workflow becomes central enough that switching cost is a board-level question, that is usually the point to consider building a product around it. Our Custom AI Platforms work is designed with that separation in mind, with portability and handover agreed as part of the scope rather than discovered at renewal.