AI vendor lock-in risk — the security review angle

A procurement view of lock-in asks: what would it cost, in time and money, to migrate off this vendor. That is a real and useful question, and it belongs in a business case. It is a different question from the one a security review needs answered, which is: if this vendor fails a control requirement, has an incident, or refuses a contractual term we later decide we need — can we actually act on that, or has the switching cost made “require the control or don't proceed” an empty threat by the time we need to make it.

Those two questions correlate but do not collapse into each other. A system can be cheap to migrate in engineering-hours terms and still be functionally locked in from a security standpoint, if the thing making it hard to leave is not infrastructure cost but an asset that cannot be reconstructed on a different vendor's terms — a fine-tuned model, an indexed corpus, a body of agent logic tuned to one provider's specific behaviour. The procurement conversation tends to price the infrastructure migration and miss the asset that actually can't move.

Every AI vendor security review implicitly relies on a piece of leverage it rarely states out loud: the organisation can require a control, or decline to proceed, because at initial procurement the organisation has options. “We'll require encryption at rest, a defined data-retention boundary, and a model-change notification clause, or we won't sign” is a credible position when three other vendors can plausibly do the job.

That leverage does not survive deep integration. Once a system has been in production for a year, has a fine-tune trained on a year of the organisation's own data, has an application layer whose prompts and agent logic were shaped around this specific model's quirks, and has users who depend on it daily, “we'll require X or we won't proceed” is no longer a credible sentence. The organisation is not choosing whether to accept the vendor's terms anymore; it is choosing between accepting the vendor's terms and an outage its own business cannot absorb. A vendor security team that understands this distinction prices it into how firmly they will hold a negotiating position two years into the relationship.

The leverage a security review assumes it has — the ability to say “require it or we walk” — is a property of how portable the system is at the moment the sentence is spoken. Lock-in doesn't remove the sentence. It removes the credibility behind it.

The asymmetry is worth stating plainly, because it explains why this erosion is easy to miss from inside the organisation experiencing it. The vendor knows exactly how embedded the relationship has become — it can see usage volume, integration depth, and how much of the customer's operating process now assumes the product will keep working the way it does today. The customer's security team, by contrast, frequently does not have a standing view of its own switching cost, because no one is tasked with tracking it as it changes. The result is a negotiation where one side has an accurate, continuously updated picture of the leverage balance and the other is negotiating from a year-old assumption.

This is why lock-in belongs in a security review at all, rather than being left entirely to procurement: the review's ongoing ability to require controls, respond to an incident with real consequences, or decline a renewal is not a constant. It decays as the system embeds, and it decays fastest for AI systems specifically, because the assets that make an AI system valuable — the tuned data, the tuned logic — are frequently the least portable parts of the whole stack.

A fine-tuned model checkpoint hosted by a vendor is, in the ordinary case, not something the organisation can simply download and run elsewhere — it exists inside the vendor's hosting environment, trained against that vendor's base model and fine-tuning pipeline, and the weights themselves are frequently not exportable under the commercial terms even where they are technically extractable. The organisation's own data went in; what comes back out is a capability that only exists inside this vendor's walls.

RAG-indexed data creates a related but distinct version of the same problem: the retrieval index is frequently built with a vendor-specific embedding model, chunking strategy, and metadata schema. Moving to a different vendor does not just mean re-pointing an API call — it means re-embedding the entire corpus with a different embedding model, because embeddings from one model are not compatible with a vector index or similarity search tuned for another. For a large or continuously growing corpus, that is a non-trivial re-indexing project, not a configuration change, and the review question is whether anyone has actually scoped what that project would take.

A system whose prompts, few-shot examples, and agent instructions have been iteratively tuned against one specific model's behaviour is what we would call prompt-locked: the system works, but its correctness depends on quirks of the specific model it was tuned against — how that model interprets ambiguous instructions, its particular tendency toward or away from verbosity, how it handles a given prompt structure's edge cases. Swap the underlying model, even for a nominally more capable one from a different provider, and the system's behaviour can degrade in ways that are hard to predict and expensive to re-tune away.

This is a genuinely new lock-in vector relative to conventional SaaS — there is no equivalent in a system built on a deterministic API, where the same input reliably produces the same output regardless of which server handles the request. A prompt-locked AI system is, functionally, locked to a specific model's behavioural fingerprint, not merely to a specific vendor's infrastructure.

Agentic systems built on a vendor's proprietary orchestration format — tool-definition schemas, multi-step planning constructs, memory or state-management primitives specific to that vendor's framework — carry a lock-in vector distinct from either the model or the data. The orchestration logic itself, not just the model it calls, becomes an asset that exists in a format only one vendor's runtime understands.

This matters because orchestration logic tends to accumulate the most organisational investment of any layer in an agentic system — it encodes the actual business process the agent executes, built up over many iterations. A vendor whose orchestration format cannot be exported to a portable representation (even an imperfect one, even one requiring translation work) has made that accumulated investment inseparable from the vendor relationship, in a way that a stateless API call to a model never was.

The fourth vector is the training data itself, once it has been used to fine-tune a vendor-hosted model. Even when the organisation retains a copy of the original training set, the fine-tuned artefact that resulted from it — the actual behavioural improvement the organisation paid for, in compute time and iteration effort — exists only inside the vendor's hosting environment. Re-running the same fine-tuning job against a different vendor's base model does not reliably reproduce the same result, because the base model, the fine-tuning pipeline, and the hyperparameters all differ.

This means the organisation's own historical investment in improving the system becomes vendor-specific capital, not portable capital — a meaningfully different situation from a conventional SaaS product where the organisation's configuration and data can, in principle, be exported and reapplied elsewhere even if doing so is tedious.

The practical review question is not “how hard would it be to migrate” asked in the abstract — it is a specific, time-boxed scenario: what would a 90-day exit from this vendor actually require, technically, starting today. The 90-day framing matters because it forces the answer to be concrete rather than aspirational — most vendors and most internal teams can describe migration as theoretically possible over an unbounded timeframe; far fewer can describe what a bounded, realistic exit looks like.

The review should get a specific answer to each of the four vectors above: can the RAG index and its underlying documents be re-embedded elsewhere without starting the corpus from scratch; is there a record of how the system performs against at least one alternative model, even if that record shows meaningful degradation; can the orchestration logic be exported to any portable representation, even a lossy one requiring engineering work to reconstitute; and does the organisation have a usable copy of its fine-tuning data independent of the vendor's hosted artefact.

None of these need to have a fully satisfying answer at initial review — a system can proceed with a documented, moderate degree of lock-in as an accepted residual risk, the same way any other control gap can. What the review cannot do is treat “we'll figure out portability later, if we ever need to leave” as an acceptable answer, because “later” is precisely when the organisation will have the least leverage to demand it.

For a new AI vendor system, or for an existing one approaching a renewal decision, the review is complete on the lock-in dimension when it can answer these with a specific, evidenced answer rather than an assumption:

• What would a 90-day exit from this vendor actually require, technically, starting today?
• Is the corpus behind any RAG feature re-embeddable elsewhere without a full rebuild, and has anyone scoped that work?
• Has the system's prompt and agent logic ever been validated against a second model, and what did that show?
• Can the agent orchestration logic be exported to a portable representation, even one requiring translation effort?
• Does the organisation hold a usable, independent copy of any data used to fine-tune a vendor-hosted model?
• Has “low switching cost” been verified as a control at this review, rather than assumed as a future nice-to-have?

The leverage window for requiring answers to these questions is at initial procurement, before the system is embedded — not two years later, when the organisation is asking the vendor for a concession it no longer has the standing to demand.