Skip to main content

Executive Resources · for leaders & councils

How to Avoid AI Vendor Lock-In

AI vendor lock-in happens when your data, workflows, or staff skills become so embedded in a single platform that switching becomes prohibitively expensive. The risk is higher with AI tools than with most software because the dependency is not just technical - it is in model behaviour, proprietary data formats, and pricing structures that vendors can change unilaterally. This page explains how to identify lock-in clauses before you sign, what contractual terms to push for, and how to build switching capacity into your AI programme from day one.

What AI vendor lock-in actually means

Lock-in in traditional software is primarily technical: data lives in a proprietary format and migration is painful. AI vendor lock-in carries additional layers. Your team learns to rely on a specific model's behaviour - its tone, its accuracy profile, its edge-case handling - and switching to a different model means retesting every workflow. Your prompts are tuned to a specific system. Your integrations point to a specific API. Your compliance documentation names a specific vendor's data processing terms.

On top of this, AI pricing models are still immature. Annual price increases of 30 to 50 per cent are not unusual in the current market. If you are locked in when the increase arrives, the leverage to negotiate or walk is gone. The cheapest moment to protect yourself is before you sign the first contract.

How to identify lock-in clauses before signing

Lock-in is rarely labelled as such. It appears in standard terms under innocuous headings. The following clause types are the ones most likely to create dependency.

  • Data portability restrictions: the contract does not commit the vendor to exporting your data in a standard, machine-readable format within a defined timeframe.
  • Model training rights: broad language allowing the vendor to use your inputs or outputs to train their models, making your data part of their product.
  • Minimum commitment and auto-renewal: annual contracts that auto-renew with a notice window shorter than your procurement cycle, trapping you for another year.
  • Uncapped price escalation: no limit on annual price increases, allowing the vendor to raise fees once you are dependent on the tool.
  • Exit fees and transition costs: charges for data export, API access termination, or migration assistance that only become visible at exit.
  • Proprietary format storage: your data is held in a format only the vendor's tools can read, making migration technically complex regardless of legal entitlement.
  • Intellectual property assignment: clauses assigning ownership of outputs, fine-tuned models, or prompt libraries to the vendor.

Contractual protections to negotiate before signing

Most of these protections are negotiable on a first contract if you raise them before signing. Once the tool is embedded in your workflows, leverage disappears entirely.

  • Data portability clause: the vendor must export all your data, in a standard open format, within 30 days of a written request. No fee for the first export.
  • Explicit exclusion of training rights: your inputs, outputs, and any fine-tuned model weights are not used for the vendor's general model training without written consent.
  • Price cap: annual increases capped at a defined percentage, typically RPI plus 3 per cent, indexed from the contract start date.
  • Exit clause: either party can terminate with 30 to 60 days' written notice, with no financial penalty beyond the notice period.
  • Transition assistance: the vendor provides a defined level of migration support at no additional cost during the exit period.
  • Sub-processor disclosure: you receive written notice of any new sub-processor with personal data access at least 30 days in advance.
  • No-audit-right removal: if standard terms exclude your right to audit data handling, reinstate it.

Architectural steps that reduce lock-in risk

Contractual protections reduce legal lock-in. Architectural decisions reduce operational lock-in - the practical difficulty of switching even when you are legally entitled to.

  • Use an AI gateway or abstraction layer so your application code calls a common interface, not the vendor's API directly. Switching vendors then requires changing one configuration, not rewriting integrations.
  • Store prompts and model configurations in version control as plain text, not inside the vendor's platform. Prompts are intellectual property and should be portable.
  • Define your use cases in terms of inputs, outputs, and quality criteria - not in terms of the specific model that delivers them. This forces you to evaluate alternatives objectively.
  • Run periodic evaluations of alternative vendors against your actual production use cases, so switching cost is understood before it becomes urgent.
  • Maintain your data in your own storage layer wherever feasible, with the vendor accessing it rather than holding it.

During a renewal: restoring leverage

If you are already inside a contract and approaching renewal, leverage is limited but not zero. Vendors who are losing customers to competitors will negotiate. Vendors who have a reliable renewal are less motivated.

The steps that restore negotiating position at renewal are: obtain at least one alternative quote before the renewal window opens, document the cost and time required to switch so you can state it accurately, identify the two or three contractual terms most important to change, and raise those terms in writing at least 90 days before the auto-renewal date.

If the vendor will not address price escalation or data portability at renewal, that is information. A vendor who holds firm on exploitative terms when asked directly is a vendor worth replacing during the next contract period.

Evaluating lock-in risk as part of the initial selection

Lock-in risk should appear as an explicit criterion in your vendor evaluation scorecard, weighted alongside capability, security and price. The questions to score at selection are: Does the vendor publish a data export specification? What format does exported data arrive in? How long does a full export take? What is the termination notice period? Is there a price escalation clause and what does it permit?

A vendor who cannot answer these questions during procurement is unlikely to become easier to deal with once you are dependent on them.

Take the next step

Want help applying this to your organisation? Use the resource below or book a 30 minute strategy call with Simon — no pitch, just practical advice.

Frequently asked questions

AI vendor lock-in is when your data, workflows, staff skills, or integrations become so dependent on a single AI platform that switching becomes prohibitively expensive or disruptive - even if you are legally entitled to leave. It differs from traditional software lock-in because the dependency includes model behaviour, proprietary prompt formats, and pricing structures the vendor controls unilaterally.

The main lock-in clause types are: data portability restrictions (no commitment to export in standard formats), model training rights (vendor can use your data to improve their product), uncapped price escalation, auto-renewal with a short notice window, exit fees, proprietary data storage formats, and IP assignment clauses that transfer ownership of outputs or fine-tuned models to the vendor. None of these are typically labelled as lock-in provisions - they appear as standard boilerplate.

Raise exit terms before you sign, not at renewal. The specific terms worth pushing on are: a 30-day data export commitment in a standard open format at no cost, a termination clause with 30 to 60 days' notice and no financial penalty, a cap on annual price increases, and a written exclusion of training rights over your data. Most vendors will negotiate these on a first contract if they want the business. At renewal, leverage depends on whether you have alternative quotes and have documented the switching cost.

Yes, but the cost rises sharply the longer you wait. The practical barriers at switch are: re-engineering integrations from the vendor's API to a new one, rewriting and retesting prompts for a different model's behaviour, migrating data from a proprietary format, retraining staff, and the lost productivity during transition. These costs are real even when the contract gives you a clean legal exit. The time to reduce them is at the start of the engagement, through abstraction layers, version-controlled prompts, and data portability commitments.

An AI gateway is an abstraction layer that sits between your application and the AI vendor's API. Your code calls the gateway with a standard request; the gateway routes it to the current vendor. When you change vendor, only the gateway configuration changes - your application code and prompts remain the same. This reduces the operational switching cost significantly, though it does not address data portability or contractual terms.

Find Out Where AI Can Save or Generate Money in Your Organisation

Book a free 30-minute call with Simon. Bring a real problem - staff time, governance worry, vendor proposal, failing pilot - and leave with a concrete first step you can take next week.

Call