AI Vendor Lock-In Starts in Your Integration Layer

Rebuilding an integration layer you already paid for once lands in Tier 3 of our cost of API integration guide — indicatively ₹14L – ₹24L for several systems plus your own API behind one internal service, with scoped auth, rate limiting and reconciliation that hold up under load. AI vendor lock-in is the mechanism that makes a company pay for that layer twice. It attaches where the model, the pipeline feeding it, the workflow wrapped around it and the audit trail underneath all arrived from one supplier on one contract, with no seam left to cut.

Model vendors now sell implementation alongside the tokens. Consulting arms, acquired integration shops, applied engineers seconded into your team. For a workload at the edge of your business, that is a reasonable purchase. For the workload your customers actually pay for, the purchase needs a second price attached to it: the cost of leaving. That number is almost never in the proposal.

Why model vendors want the implementation work too

Selling model access is close to a commodity business. Nothing about it stays proprietary for long, and a buyer can point the same code at a different endpoint. Selling the system around the model is a far better business, because a system is expensive to build and nobody rips one out casually.

Pilots also stall at the plumbing. A demo against a model API is straightforward. Getting it into production means connecting internal data, resolving identity and permissions, defining what the software does when the provider returns an error mid-transaction, and satisfying whoever signs off on retention. Model quality does not touch any of that work. It is also where AI budgets stop converting into deployed software, and a vendor watching its own pilot-to-production rate has an obvious fix: sell the plumbing too.

A services arm that builds inside your workflows also sees your workflows. It learns which tasks are painful and which processes are worth productizing next, and that intelligence flows back to the vendor’s roadmap. You are paying for the implementation and writing the requirements document for whatever gets built after it.

What AI vendor lock-in actually attaches to

The model looks like the obvious place for lock-in to live. It is the most portable component in the system. Prompts and endpoints are cheap to move, and even a fine-tune has a rough equivalent somewhere else. When a model vendor spends serious money standing up a consulting arm, the moat has moved a floor above the model — that post follows the argument through the news as it broke.

The sticking happens in components that get built once and inspected never.

The retrieval and data pipeline. Chunking rules, embedding model, index, refresh cadence. Change the embedding model and the whole index gets rebuilt, which is a batch job when the pipeline is yours and a procurement conversation when it is a managed feature of somebody’s platform.

The evaluation set. Test cases get written wherever the tooling makes it easiest, and in a bundled deployment that is the vendor’s console. Once they live there, you cannot demonstrate that a replacement is better rather than differently wrong. Migration becomes a matter of opinion, and opinion loses to inertia.

Orchestration is business logic written in a vendor’s DSL: tool definitions, retry policy, human-review thresholds, escalation paths. Nobody writes down why the human-review threshold sits where it does, so porting it means re-litigating a decision settled once in a meeting.

Whoever holds your audit trail holds your compliance posture. Access logs, PII handling, retention windows and audit exports are the least glamorous part of the build and the hardest to move, because a regulated buyer will not re-derive its logging history to change suppliers.

Owning those four layers at the start costs a few architectural arguments. Reclaiming them two years in is a rebuild, and the integration layer is the ₹14L – ₹24L part of it. The retrieval pipeline and the governance work sit outside that figure.

Should you buy implementation from your model vendor?

Sometimes, yes. Their engineers know the failure modes of their own model better than anyone you can hire, and for a first deployment that knowledge is worth real money. Near-term delivery risk drops.

The test we apply is narrow: does this feature appear on your pricing page? If a customer is paying for the output, own the code that produces it. If the workload is internal — summarizing meeting notes, triaging an inbox — buy the bundle and spend the saved effort somewhere that compounds.

A workload that starts internal and becomes the product is the one that hurts. Fraud review that grows into a customer-facing risk score. A support assistant that gets promoted to the primary support channel. Those get architected as throwaway pilots and then quietly moved into the revenue path, and the move never arrives with a budget line for re-owning the plumbing. Settle the ownership question at pilot time, when it costs a design conversation instead of a rebuild.

How to keep the model layer swappable

One internal interface for every model call. Provider SDKs live behind a single adapter module and appear nowhere else in the application. Swapping providers then means writing a second adapter and flipping a config value, rather than editing every call site in the codebase.

Prompts, tool schemas, retrieval settings and evaluation sets sit in your repository under version control, reviewed like code. When a prompt changes, the diff is in your git history and the eval run either passes or does not.

Retrieval reads from your own store. The vector index is derived data, rebuildable from a source of truth you control, so re-embedding is a batch job you schedule. If you are weighing fine-tuning against retrieval, portability belongs in that decision — our RAG vs. fine-tuning breakdown covers where each choice binds you.

Traces and evaluation results land in your own observability sink as well as the provider’s dashboard. You want the record of how quality moved when the time comes to argue for a replacement.

That is the architecture behind our AI-integrated software work: the intelligence sits inside the product, and you leave with the prompts and the evaluation sets, including the test cases the system was measured against. An adapter module and a prompts directory are cheap while a build is young, and a project of their own once provider calls are scattered through the application.

What to negotiate before you sign

Ask for exit terms in the same conversation as pricing, while the vendor still wants the deal.

Export rights on everything derived from your data: fine-tune artifacts or a documented path to reproduce them, evaluation sets in a portable format, prompt and configuration history, the retrieval index configuration. Source code ownership for anything custom-built, with the repository in your organization from the first commit rather than transferred at the end.

“Logs on request” is not a clause. A usable log-export term names granularity, retention, format, and who pays. Granularity means one record per model call, carrying the prompt, the retrieved context, the model version, the tool calls made and the output; a daily aggregate of token counts is a billing report and answers nothing an auditor asks. Retention means how far back the export reaches and whether it survives the contract ending, because a regulator’s question can arrive after you have stopped paying the vendor. Format means newline-delimited JSON or CSV against a schema written into an appendix, delivered to storage you control, so you can ingest your own history without standing up a project for it. Then the commercial half: who bears the cost of the export, how long the vendor has to produce it, and whether you can pull it on a schedule yourself instead of raising a ticket. A term promising audit logs “in a mutually agreed format” agrees to nothing, and the agreeing then happens on your way out, when the vendor has stopped being helpful.

Look also for the clause that quietly prevents parallel evaluation. Exclusivity language, minimum-commitment structures that make a second provider unaffordable, and auto-renewals tied to committed spend all do the same work: they remove your ability to test an alternative before the renewal date arrives. Pick the date you intend to re-evaluate, and confirm the contract lets you do it.

When a single-vendor bundle is the right call

A team without platform engineers, running one bounded internal workflow. Build a provider-routing layer for that and you have added a config system nobody needed and a second code path that never gets exercised. Premature portability engineering is a real cost, paid immediately, against a migration that may never happen.

The prompts and the eval set still belong in your own repository, and keeping them there is cheaper than any abstraction. Inside a fully managed deployment, those two assets decide whether leaving is a migration or a rewrite. Choosing between a platform’s built-in AI and something built for you is the adjacent decision — the custom AI vs. SaaS AI comparison sets out that trade.

What we would refuse to build

We would not put a provider’s SDK into application code. It goes behind one adapter, always, including on a project with a single model call. That is the cheapest version of this decision and it never gets cheaper later.

We would not build a system whose evaluation lives in someone else’s console. If the test suite cannot run locally and show you the numbers moving, there is nothing to hand over at the end.

We would not build a multi-provider router before there is a second real use case for it. Routers are for teams with traffic to route.

And we would not take on a build where the vendor’s managed service owns the audit log while your name is on the compliance certificate. If a regulator asks how a decision was made, the answer cannot depend on a support ticket to a third party. That requirement goes into the scope in writing — audit records in systems you control, exportable in a format your compliance reviewer accepts — and where a vendor will not commit to it, we would rather lose the work than build around it.