Three years ago, Lisa Tran, a procurement director at a state transportation department, signed a five-year deal for an AI-powered permit-processing platform. It was a good price and the demo was impressive. This year the vendor sent a renewal quote: a 140% price increase. Lisa pushed back. The account rep was polite and unworried. He knew what Lisa was about to discover. The agency's seven years of permit data lived inside the vendor's proprietary format. The workflows, the trained models, the integrations with the DMV, all of it was built to the vendor's system. Switching would cost an estimated $2.3 million and eighteen months of disruption. The renewal, even at 140% more, was cheaper than leaving. Lisa was not negotiating. She was paying a ransom she had signed up for three years earlier.

That trap is vendor lock-in: a situation where switching vendors becomes so expensive, slow or technically difficult that you effectively cannot, even when the vendor raises prices, cuts service, or falls behind the market. Lock-in arrives through architecture, through contract terms, and through simple absence of planning, and it is usually invisible until the day you need to leave. Prevention is far cheaper than remediation, but prevention only works before signature, while you still have leverage. This lesson is about building the exits before you walk in.

Why AI lock-in is worse than ordinary lock-in

You may already know software lock-in. AI adds new chains that traditional procurement was not designed to cut, and the first is that your data shapes their model. As the system runs it learns from your data, and that tuned, improved model often stays with the vendor. You generated the value and cannot take it with you. The model is also a moving target: even if you export every raw record, you cannot easily reproduce the trained behavior somewhere else, because the useful part is not in your data, it is in a model you do not own. Exporting inputs is not the same as exporting capability.

Two more chains tighten the trap. AI tools wire deeply into your other systems, your databases, your identity provider, your case management platform, and every integration is another root to pull up if you leave. And skills concentrate: your staff learn one vendor's interface, its quirks and its workarounds, so switching means retraining everyone and losing productivity during the gap. Government makes all of this heavier, because procurement is supposed to be competitive, and lock-in quietly removes competition by making the incumbent the only feasible answer even when better alternatives exist. That is a procurement integrity problem, not only a budget problem.

There is a second public-sector reason to care that has nothing to do with price. Vendor failure is real. A vendor can go out of business, be acquired and have your product deprioritized, or simply stop innovating while the field moves. Lock-in prevents you from pivoting when any of those happen, which means a risk entirely outside your control becomes a risk you cannot mitigate. Agencies commonly accept multi-year commitments because longer terms buy better pricing, and that trade is defensible. A long-term commitment to a failing vendor, with no exit built in, is not a trade. It is an unpriced liability sitting on your program.

The four forms of lock-in

Lock-in is not one thing, and the prevention for each form is different. Naming the four forms separately matters because agencies routinely solve one and assume they have solved the problem. An agency with impeccable open data formats and no trained staff is still locked in. An agency with a beautiful exit clause and a system nobody internally understands is still locked in. Work the table below against a system you already run, and be honest about which rows describe you today.

Financial lock-in is the form that decides the outcome, because it is where the other three are cashed out. Lisa's proprietary format was a technical problem, her five-year term was a contractual problem, and her staff's dependence on one interface was an operational problem, but what actually kept her in the seat was a switching estimate of $2.3 million against a renewal she could just about absorb. Prevention therefore aims at driving that switching number down before it matters, which you can only do while the vendor still wants your signature.

Technical prevention: build for portability

The goal is that your data and your work can leave with you. That starts with architecture. Prefer a modular design that separates vendor-specific components from core functionality, so you can swap a vendor for one module rather than replacing everything. Use industry-standard interfaces rather than vendor-proprietary APIs, because a standard interface is one another supplier can implement. Store data in standard formats such as CSV or JSON rather than a format only the vendor's software can read. Where it fits, use container-based deployment such as Docker or Kubernetes, which gives you a vendor-agnostic way to run the same workload somewhere else.

Data portability is the next layer, and it is worth being precise about what it does and does not deliver. Take periodic exports of your data in standard formats, and verify each time that the export actually completes and opens. Document your data schema, because a file whose fields nobody can explain is not portable in any useful sense. Periodically test migrating a sample of data into an alternative system and confirm it works there. And do not let the vendor apply transformations you cannot reverse, since irreversible enrichment quietly converts your data into their data. You should be able to export everything, including inputs, outputs and configurations, at any time rather than only at the bitter end.

Model portability is the layer most agencies never reach. Document the model architecture, the training procedure and the hyperparameters in enough detail to reproduce it. Require standard model formats such as ONNX or SavedModel rather than a proprietary container that only runs on the vendor's engine. Require that the model be interpretable without the vendor's own tooling, so you can explain a decision after the relationship ends. Keep documented model testing procedures and run them regularly, because a model you cannot test is a model you cannot responsibly move. Finally, keep infrastructure independence in view: containerized deployment, a viable on-premises option, documented fallback procedures if vendor infrastructure is unavailable, and no single point of failure that only the vendor can repair.

Contractual prevention: write the exit into the deal

Technical portability means nothing if the contract does not guarantee it. These clauses are your insurance policy. Federal acquisition rules, the FAR and DFARS that govern how agencies buy, give you room to require them, and state and local acquisition rules generally have equivalents. Negotiate them in before signature, because afterward you have no leverage at all. The table below carries the six protections agencies most often wish they had bought; the requirement families that follow it come from a fuller contract framework and overlap deliberately, because different contracting shops organize the same protections differently.

On data ownership and rights, the terms to secure are that the government owns all government-provided data and the vendor holds only usage rights for the contracted service; that on termination the vendor returns or deletes government data within 30 days; that the government may copy and back up its own data at any time; and that the vendor may not use government data for any other purpose. On model ownership, distinguish two cases. For a vendor's own proprietary model, seek a perpetual license to use it for the contracted purpose. For a custom model trained on government data, seek ownership, or at minimum an unlimited license, and prohibit the vendor from using your data to improve products it sells to others.

Exit and transition terms are where the deal is actually won or lost. Seek the right to terminate without cause after year one on 30 to 90 days' notice, a transition period on termination during which the vendor maintains the system at no additional cost, and an obligation to provide the documentation and training the agency needs to operate the system independently. Require explicitly that the vendor does not charge for data extraction or model handoff, because a vendor who agrees to hand your data back and then prices the export as a project has given you nothing. Note that the transition assistance clause in the table and the no-cost maintenance period described here are two different asks; decide which you need and price both.

Two smaller terms carry more weight than their length suggests. Require the vendor to identify all subcontractors and give the agency the ability to require a different one where necessary, and require the vendor to license any subcontractor intellectual property in a way that survives a change of subcontractor. Without that second term, a vendor's own supply chain becomes a source of lock-in you cannot see, let alone negotiate. The wider vendor-risk picture behind those clauses, including flow-down obligations and subcontractor auditing, is worked through in Third-Party AI Risk Management.

Now the caution that makes the rest of this section usable. A signed exit clause is a legal right, not a working migration. It tells you what a court would eventually make the vendor do; it does not tell you whether the export runs, whether the file is intelligible, whether your staff can operate the replacement, or how many months the transition consumes. Rights and capability are different things, and the only honest test of a data-portability clause is whether someone has actually exercised it and used the result. Until then, treat the clause as a necessary condition you have satisfied and an open question you have not answered.

Operational prevention: build the capability to leave

Operational lock-in is the quietest of the four forms, because nothing about it appears in the contract or the architecture diagram. Documentation is the first defense. Maintain complete system documentation covering architecture, data flows, decision logic and model details, kept current by the government as well as the vendor, and detailed enough that a qualified engineer who has never seen the system could operate and troubleshoot it. Review it annually against the system as it now exists, since documentation decays silently and the discovery that it is three versions out of date always happens at the worst possible moment.

Staff training is the second. Train government staff on operation, troubleshooting and maintenance to the point where they could run basic functions without vendor support, cross-train enough people that no single person is critical, and continue training as the system evolves. The third is visibility: the government should have direct access to logs, metrics and performance data, the ability to diagnose problems without calling the vendor, alerting that reaches your people first, and retained historical data for analysis. If your only window into the system is a dashboard the vendor renders for you, you cannot evaluate the vendor's performance independently of the vendor's account of it.

The fourth is knowledge preservation, which is the practice of getting institutional knowledge out of individual heads and vendor heads and into artifacts. Write runbooks for common operations such as updates, performance tuning and incident response. Then run the exercise that most agencies avoid: can you operate this system without the vendor, and for how long? Do it as a scheduled drill with a written result, not as a hypothetical in a meeting. The answer is the real measure of your operational independence, and unlike a contract clause, it cannot be negotiated into existence.

Strategic prevention: do not put all your weight on one vendor

The deepest protection is architectural and organizational. Separate your data layer from the AI layer: keep the authoritative data in a system you control and let AI tools read from it, so that swapping the AI tool never means rescuing your data. Where it is feasible, use more than one provider for related needs, which keeps each one honest and proves to both of you that switching is possible. For critical systems, negotiate with two vendors in parallel rather than picking a favorite and then negotiating. Use a modular approach so different components come from different suppliers and pieces can be swapped without a full replacement.

Re-competition is the discipline that keeps all of this real. Re-compete a system periodically rather than rolling renewals indefinitely; a two to three year cycle is a common target and the point is less the exact interval than the fact that an interval exists and is scheduled. Pilot before you commit, and use the pilot to test exit rather than only entry: attempt a real export of real data during the pilot and record how long it took and what was missing. Keep institutional knowledge in-house by documenting your own workflows and business rules, so that when the vendor changes, the description of how your agency works does not change with it.

If you do have to move: staged migration

Sometimes prevention arrives too late and you have to migrate anyway. Doing it in stages keeps a rollback available at every point, which is what makes the decision to leave survivable for the executive who has to approve it. In the first phase, run parallel operation for roughly 30 to 60 days: the new vendor's system runs alongside the current one, it makes recommendations that a human reviews, and you depend on nothing it produces while you evaluate quality, integration and operational readiness. Nothing is at stake yet, which is precisely why this phase gets cut short under schedule pressure and precisely why it should not be.

The second phase is gradual cutover, again in the range of 30 to 60 days. Shift decisions to the new vendor in steps, first 10 percent, then 25 percent, then 50 percent, monitoring both systems in parallel and comparing outputs at each step, keeping the ability to roll back throughout. The third phase moves all decisions to the new vendor and keeps the old system available for about 30 days as a rollback option while historical data is archived. The fourth phase decommissions: the old system is shut down, historical data is retained for audit and compliance purposes, and the exit procedures written into the original contract are formally completed and documented.

Sum those phases and the migration runs somewhere between roughly three and five months of active work before decommissioning, which is why a six-month migration window is a realistic planning assumption rather than an optimistic one. Two things reliably break the plan. The first is discovering during phase one that the export you assumed was available is not, which is an argument for testing the export years earlier. The second is starting a migration without the rollback capability intact, which converts a staged move into a single irreversible cutover performed under time pressure. Neither failure is a technology problem.

A usable artifact: the lock-in risk scorecard

Score any AI procurement before you sign. Rate each of the ten checks below as 0 where the condition fails, 1 where it is partially met, and 2 where it is fully met, for a maximum of 20. A total under 14 means you are building a trap, and you should either fix the gaps in negotiation or walk away. Score it with the contracting officer and the program owner in the same room, because the disagreements about what counts as partial are where the real risk conversation happens.

• We own all our input and derived data, in writing.
• Data exports in open, documented formats are available on demand.
• A standard, documented API exists and is named in our contract.
• We can export models, business rules and configurations.
• Transition assistance is guaranteed at known rates.
• Renewal price increases are capped.
• No clause holds our data or transition hostage to disputed fees.
• Our authoritative data lives in a system we control.
• We tested a real data export during a pilot.
• Our workflows are documented independently of the vendor.

Lisa's original deal would have scored about 5 of 20. After her renewal fight she rebuilt the agency's approach: data now lives in a system the state controls, every new AI contract carries the export and cap clauses, and pilots include a mandatory export test. The next vendor that tried a steep renewal hike found the agency could credibly walk, and the increase came down to single digits within a week. Note what actually changed there. The clauses helped, but the thing the vendor responded to was an agency that had demonstrated, to itself first, that leaving was operationally possible.

Anti-Patterns

• Building on proprietary features because they are convenient. Vendor-specific capabilities genuinely make development faster, so architectural discipline loses to delivery pressure and the system gradually becomes dependent on features no alternative supplier offers. Switching then requires a complete redesign, and you are locked in despite wanting out. Evaluate the architectural consequence of every vendor-specific choice at the time you make it, and prefer standards-based approaches even when they are slightly more complex.
• Trading term length for price without buying exit rights. Longer commitments get better pricing, so the incentive runs toward multi-year deals with termination penalties. Then the vendor underperforms and you are trapped in a contract you cannot leave. Accept a higher unit cost in exchange for stronger termination rights; flexibility is a purchased good, and this is what it costs.
• Leaving ownership to the boilerplate. Contracts are long and ownership clauses hide in standard terms, so nobody reads them closely until the day you want to move and discover the vendor owns the models trained on your data. Document ownership of data, derived data, and both proprietary and custom models explicitly, in language a non-lawyer can read, and confirm it separately from the rest of the terms.
• Deferring documentation because it is expensive. Documentation is costly and never urgent, so it slips, and the system ends up understood only by vendor staff. When you try to replace the vendor you find you cannot operate what you own, and you renegotiate from a position of weakness. Make comprehensive, current documentation a contractual deliverable with an annual review, not a best-effort commitment.
• Skipping training and calling the vendor instead. Development gets the attention and training is deferred, so staff never learn to run the system. When migration becomes necessary the internal capability does not exist and the migration price rises accordingly. Cross-train several people, build genuine internal operations capability, and exercise it on a schedule.
• Treating an exit clause as an exit. A data-portability requirement, an open-format commitment or a termination right feels like the problem is solved, and the file gets closed. None of those tell you whether the export runs, whether the output is usable, or whether your staff can operate a replacement. Exercise the right during the pilot and again periodically, and treat an untested clause as an open risk rather than a completed control.
• Reading one successful test migration as proof you can switch. A sample export that loads cleanly into an alternative system is real evidence and it is narrow evidence. It says nothing about volume, about the integrations, about the trained model you cannot reproduce, or about the months of parallel running. Record what the test actually covered, name what it did not, and keep the untested parts on the risk register instead of retiring them.

Practice Prompts

• Map the lock-in risk on a live acquisition. For an AI system you are acquiring, list the technical exposures (proprietary APIs, data formats, tight coupling), the contractual exposures (term length, ownership ambiguity, missing exit clause) and the operational exposures (documentation, staff training, monitoring capability). For each, state probability, impact and a specific mitigation you could put into the solicitation this month.
• Design for portability. Draw your intended architecture and mark each component as vendor-independent or vendor-specific. Then name the standard interfaces and formats at each boundary, and write down how you would test portability at that boundary. The components you cannot classify are the ones to look at hardest.
• Write the migration plan before you need it. Develop a six-month plan to move from your current vendor to an alternative, covering the parallel operation phase, the gradual cutover procedure, the rollback capability at each step, and final decommissioning. Identify the single step in that plan you are least confident about.
• Draft the vendor's migration obligations. Write the contract section covering required documentation, data migration support, model handoff procedures, timeline and costs, and any restrictions on the vendor during transition. Then ask what happens under each clause if the relationship has ended badly, which is the only situation in which it will ever be used.
• Test your independence. Build a checklist assessing whether your team could operate the system without the vendor: documentation completeness and currency, staff training and cross-training, monitoring and diagnostic capability, troubleshooting capability, and operations runbooks. Then run it as a drill with the vendor unavailable for a day and write down what actually happened.

Reflection

• For an AI system you are acquiring or already run, what are your greatest lock-in risks, and which of the four forms do they fall into?
• How would you mitigate each one, and which mitigations are still available to you at this point in the relationship?
• Which contract terms matter most in your context, and which of them are already in your current agreement?
• How would you build the staff capability to operate without this vendor, and who would own that work?
• How would you test your migration ability this quarter, and what would you do if the test failed?

Glossary

• Lock-in. A situation where switching vendors becomes prohibitively expensive or technically impossible.
• Portability. The extent to which a system, its data and its models work with alternative vendors or infrastructure.
• Migration. The process of transitioning from one vendor to another.
• Transition support. Vendor assistance in moving to an alternative system, including documentation, data extraction and handoff.
• Proprietary format. A data or model format specific to one vendor and difficult to migrate away from.
• Flow-down. Contract language requiring a vendor to impose its obligations to you on its own subcontractors, including obligations that preserve your ability to transition.
• Re-competition. Putting an existing system back out for competitive award on a scheduled cycle rather than renewing indefinitely.

Related Lessons

• Third-Party AI Risk Management covers the wider vendor risk picture, including subcontractor flow-down and continuous monitoring.
• AI Contract Negotiation covers how to get clauses like these actually accepted at the table.
• AI Vendor Evaluation Methodology covers scoring vendors before selection, including portability as a criterion.
• Managing AI Vendor Performance covers holding a vendor to committed service levels during the relationship.
• Working with AI Vendors and Contractors covers the working relationship that determines how a transition actually goes.
• Multi-Cloud, Multi-Model Strategy covers the architectural side of avoiding single-provider dependence.
• AI Interoperability Across Agencies covers the standards work that makes portability possible beyond one system.
• Moving from Pilot to Production covers using the pilot phase to test more than functionality.

Closing

Preventing vendor lock-in requires thinking about exit before committing. Design for portability, contract for flexibility, and build the internal capability to operate without the supplier. Each of the three layers covers a gap the other two leave open, and any one on its own leaves a door a vendor can eventually close. The scorecard is a way of forcing that assessment into a number before signature, when it can still change the deal, rather than after, when it can only change your mood.

The result is not an adversarial relationship. It is a healthier one. Vendors behave differently when both sides understand that the agency is choosing them repeatedly rather than being held by them, and competitive pressure keeps a supplier responsive in ways that no service level agreement reliably achieves. Lisa's second vendor did not lower its increase because of a clause. It lowered the increase because the agency had proved to itself that leaving was possible, and the vendor could tell. Build that capability while you still have the leverage to ask for it.

Key Takeaways

• Lock-in comes in four forms. Technical, contractual, operational and financial, each with its own prevention. Solving one and assuming you are safe is the most common mistake, because the financial form is where the other three get cashed out.
• Prevention happens before signature. The day you sign is the day you have the most leverage and the least information; every day after reduces the leverage. Build the exits into the deal up front, because remediation is far more expensive than prevention.
• AI lock-in is worse than software lock-in. Your data trains a model the vendor keeps, the capability is not in your exportable data, integrations multiply the cost of leaving, and staff skills concentrate on one interface.
• Architecture decisions today determine flexibility tomorrow. Modular design, standards-based interfaces, open data formats and portable model formats cost a little more at the start and are close to impossible to retrofit.
• Shorter terms with strong exit rights beat long terms with good pricing. Accept a higher unit cost for the right to leave. Termination rights, no-cost transition support and a ban on charges for data extraction are the terms that matter most.
• Clear data and model ownership prevents future disputes. Write down who owns input data, derived data, proprietary models and custom models trained on your data, and what happens to each at contract end.
• Documentation and training create operational independence. A contract right you cannot operationally exercise is not an exit. Current documentation, cross-trained staff and independent monitoring are what make the right usable.
• An exit clause is a right, not a migration. Test it. A periodic migration test is evidence you can move data, not proof you can move the operation, so record what the test covered and keep the untested parts on the risk register.
• Vendor relationships improve when both sides know you could switch. Competitive pressure, scheduled re-competition and a credible alternative do more for service quality than escalation clauses do.

Frequently Asked Questions

Our contract is already signed and we are locked in. What can we still do? Work the operational layer, which is the only one still fully under your control. Build and maintain your own documentation, cross-train staff, negotiate independent access to logs and metrics, and start moving authoritative data into a system you control even if the AI tool still reads from the vendor. Then plan the re-competition rather than the renewal, and start the portability work far enough ahead that the export is tested before the negotiation, not during it.

The vendor says an open export is technically impossible for a trained model. Is that credible? Sometimes, and it is still your problem. Proprietary model internals genuinely may not export, which is why model portability is a separate layer from data portability. What is never credible is that your input and output data, your business rules and your configurations cannot be exported. Separate the three asks in negotiation, get the ones that are achievable in writing, and record the model as a known residual risk rather than accepting a single refusal for all three.

Does insisting on open standards mean we cannot buy the best available tool? Occasionally, and that is a real trade rather than a rhetorical one. The way to make it a decision rather than a drift is to price it: what would switching cost if this proprietary choice is made, and what is the capability worth against that number. Agencies get into trouble not by choosing a proprietary tool deliberately but by accumulating proprietary dependencies nobody ever evaluated.

How often should we actually test the export? At minimum during the pilot, before signature, because a failed export test before signature is leverage and after signature is a discovery. Then on a regular cycle thereafter, since vendors change formats, and a test that passed two years ago tells you about a system that no longer exists. Write the result down each time, including what was missing, so that the gap between the contractual right and the working capability stays visible.

Is a multi-vendor strategy realistic for a small agency? Full multi-vendor architecture usually is not, but the underlying protection is available at any size. Keep the authoritative data in a system you control, buy the AI capability as a layer that reads from it, and schedule re-competition. A small agency that can move its data has more real leverage than a large one that cannot, regardless of how many suppliers each of them uses.