The Lock-In That Changed
The vendor lock-in conversation in enterprise technology has a well-established vocabulary. Proprietary data formats that require vendor-specific tools to access. Migration costs that make switching economically irrational even when the current vendor is not meeting expectations. Switching costs embedded in integrations, trained workflows, and accumulated data that create exit friction. These risks are real and the mitigation strategies are understood: open standards, portable data formats, modular architecture, contractual exit rights.
The lock-in risks that have become most significant in 2026 are different in character, and the standard procurement playbook for avoiding them is insufficient.
Regulatory lock-in is the risk that a vendor relationship creates compliance dependencies that are harder to exit than technical ones. The AI system that is embedded in a high-risk use case under the EU AI Act cannot be replaced without a new conformity assessment. The critical ICT third-party provider under DORA cannot be replaced without a risk assessment and, potentially, supervisory notification. The regulated service that has built its compliance architecture around a specific vendor’s audit capability cannot switch vendors without rebuilding that compliance architecture. These regulatory dependencies did not exist three years ago, and the contracts being signed today frequently do not account for them.
AI vendor dependency introduces lock-in dimensions that have no precedent in conventional software procurement. The model that the enterprise has fine-tuned on proprietary data is a dependency on the infrastructure required to run that model. The AI inference API that enterprise applications have been built around creates a usage dependency that changes character when the vendor changes pricing, changes capability, or discontinues specific model versions. The training data investment that produces a competitive AI capability is a dependency on the vendor’s data processing infrastructure that is expensive to move. Each of these creates a vendor relationship that is harder to exit than the contract suggests.
The Regulatory Lock-In Mitigation Framework
Mitigating regulatory lock-in requires incorporating regulatory dependency analysis into the vendor selection and contract negotiation process, which most procurement functions are not currently equipped to do.
The regulatory dependency analysis for a new vendor relationship should address two questions. First, what regulatory compliance obligations does this vendor relationship create or affect? The DORA critical third-party provider assessment, the NIS2 supply chain risk assessment, the EU AI Act conformity assessment for AI systems that involve the vendor’s products. Each of these regulatory obligations creates a dependency on the vendor that must be accounted for in the exit cost calculation.
Second, what contractual protections mitigate the exit cost of this regulatory dependency? The audit rights that allow the enterprise to gather the evidence required for a conformity assessment with a replacement vendor. The data portability provisions that allow the enterprise to extract its AI training data, its compliance evidence archive, and its configuration data in a vendor-neutral format. The notice period provisions that allow adequate time for regulatory transition when the vendor relationship ends. The contract that addresses these provisions before signature is significantly easier to exit than the one that does not.
The procurement function that incorporates regulatory dependency analysis into its vendor evaluation process needs legal input with specific regulatory expertise, not just standard contract negotiation capability. The regulatory technology lawyer who understands the specific obligations created by a vendor relationship under the applicable regulatory framework is a procurement resource, not just a compliance resource.
The AI Vendor Contract Framework
The AI vendor contract requires provisions that standard software procurement contracts do not include, because the AI vendor relationship creates dependencies that software licence relationships do not.
Model continuity provisions address the risk of the vendor changing, deprecating, or discontinuing specific model versions that enterprise applications depend on. The provision should require minimum notice periods before model discontinuation, the provision of migration support to successor models, and where available, the right to deploy the specific model version in the enterprise’s own infrastructure if the vendor discontinues it as a hosted service. Not all AI vendors will accept these provisions, but requesting them is informative: the vendor’s response to model continuity provisions reveals how they think about the long-term enterprise relationship.
Training data and fine-tuning provisions address the intellectual property and portability questions that arise when the enterprise has used its own data to fine-tune a vendor’s model. The provision should specify ownership of the fine-tuned model weights, the enterprise’s right to export the fine-tuned weights for deployment on alternative infrastructure, and the confidentiality and security obligations that govern the enterprise’s training data while it is within the vendor’s infrastructure.
API stability provisions address the risk of the vendor changing API behaviour, pricing, or access terms in ways that affect enterprise applications that have been built around the API. The provision should require minimum notice periods before API changes, the availability of the previous API version for a defined period after a new version is released, and price change notice periods that allow adequate time for budgeting and sourcing alternatives.
Performance and quality provisions for AI systems are more complex than for conventional software because AI system performance can degrade over time (model drift), varies by input type, and has quality dimensions that conventional system performance metrics do not capture. The contract should specify measurable performance benchmarks, the obligation to maintain performance within defined parameters, and the remediation obligations if performance falls below those parameters.
The Portfolio Approach to Lock-In Management
The vendor portfolio approach to lock-in management is the structural mitigation that complements the contractual approach. A single-vendor position in any significant technology domain creates concentration risk that no contractual provision can fully mitigate. The portfolio approach maintains relationships with at least two credible vendors in each significant technology domain, with workloads distributed between them in proportions that maintain genuine commercial leverage.
The portfolio approach has a cost: the operational overhead of managing multiple vendor relationships and the engineering overhead of maintaining compatibility with multiple vendor implementations. This cost is real and must be weighed against the risk it mitigates.
The assessment that determines whether the portfolio approach is cost-justified should be made at the strategic domain level, not at the individual vendor relationship level. For technology domains where vendor concentration creates existential operational risk if the vendor relationship is disrupted, the portfolio approach is worth its overhead. For technology domains where vendor concentration creates inconvenience rather than existential risk, the single-vendor model with appropriate contractual protections may be sufficient.
The Contract Review Process That Should Precede Every Significant Signature
The contract provisions that protect against the new lock-in risks are not standard in vendor templates. The vendor’s standard contract template is written to protect the vendor’s interests, not the enterprise’s. Negotiating the provisions described above requires that the enterprise arrives at the negotiation with a clear position on which provisions it requires and the analytical basis for that position.
The contract review process that supports this negotiation should include: a regulatory dependency analysis by the appropriate legal specialist, an AI vendor dependency assessment by the technology team, and a portfolio concentration assessment that evaluates the proposed relationship against the existing vendor portfolio.
This process takes time and resources. The alternative is signing contracts that create dependencies that the enterprise discovers only when they become difficult or expensive to exit. The VMware-Broadcom experience is instructive: the enterprises that had invested in contractual flexibility had more options when the pricing model changed than those that had not.
The lock-in cost that is avoided by better contracting is the highest-return use of legal and procurement capacity in the technology organisation.