Some lock-in is fine. Some isn’t.
Every vendor relationship has some lock-in. You learn the vendor’s product, you build integrations, your team gets comfortable. That’s the cost of doing business with any external party and it’s a fair trade for the value the vendor provides. Reasonable lock-in is fine.
Structural lock-in is different. Structural lock-in is when the vendor’s contract or product architecture is shaped to make leaving expensive in ways that exceed the actual cost of the relationship. Structural lock-in transfers optionality from you to the vendor, permanently, regardless of how the relationship goes.
Six patterns of structural lock-in show up repeatedly in AI vendor contracts in 2026. Each is refuseable. Each costs you meaningfully if you sign without addressing it.
1. Workflow definitions trapped in the vendor’s format
The vendor’s product lets you build workflows in a proprietary visual editor. The workflows are stored in the vendor’s database. There is no export. There is no documented format. If you leave, you rebuild your workflows from scratch on the next platform.
This pattern is common in “no-code AI workflow” platforms. The lock-in surface is the workflows themselves — often weeks of building and tuning per workflow.
Refuse via: export of workflow definitions in human-readable form (YAML, JSON, markdown). If the vendor cannot export, that’s a flag. Some vendors will commit to “machine-readable export” without committing to documentation; require both.
2. Fine-tuned models you can’t take with you
You provide training data. The vendor fine-tunes a model on your data. The fine-tune is hosted only on the vendor’s platform. If you leave, the fine-tune stays with the vendor — including the value of your training data.
Refuse via: ownership of the fine-tuned model weights, with the right to host elsewhere. Some vendors will resist this aggressively because their business model depends on you not having the weights. That resistance is the answer about whether to sign.
In practice, fine-tuning has become less central than it was in 2023-2024, so this matters less for many workloads. Where it does matter, the lock-in is meaningful.
3. Embeddings trapped in proprietary vector stores
You ingest documents. The vendor produces embeddings using their proprietary embedding model. The embeddings are stored in their vector database. If you leave, the embeddings have no value because they were produced by a model you can no longer use.
Refuse via: use a standard embedding model (OpenAI’s, Cohere’s, or an open-source one) and store embeddings in a format you can take with you. Refuse vendors who insist on proprietary embedding models for “performance” reasons unless they can demonstrate the performance delta is large.
4. Identity and access management coupled to the vendor
Your users authenticate through the vendor’s auth system. Permissions, roles, and access control are managed within the vendor’s product. If you leave, you rebuild the access control surface from scratch.
Refuse via: SSO integration with your existing IdP (Okta, Azure AD, etc.). Permissions managed through your IdP, with the vendor reading group memberships. Avoid vendors who require their own IAM as the source of truth.
5. Volume tier discounts contingent on exclusivity
The vendor offers a substantial volume discount, but the discount terms include an exclusivity clause: “to maintain volume pricing, customer agrees not to use comparable services from named competitors.”
This is a one-way transfer of optionality dressed as a discount. The discount is real money; the optionality you give up is also real. The optionality is usually worth more than the discount, especially in a fast-moving market.
Refuse via: decline exclusivity terms entirely, even at the cost of the discount. If the discount is truly large, negotiate the exclusivity to a narrow definition (specific feature, specific market segment) with a sunset clause.
6. Outputs that license back to the vendor
Buried in some contracts: a clause granting the vendor a perpetual, royalty-free license to outputs generated by the platform — including outputs you consider your IP.
This was rare in traditional SaaS and is increasingly common in AI vendor contracts, often justified as “needed for product improvement.” It is a substantial IP transfer that most customers don’t notice.
Refuse via: strike the license clause or limit it sharply. Vendors who want a license to your outputs can have one only for narrowly defined purposes (debugging your account, training models with your explicit consent per artifact). General-purpose perpetual licenses are not acceptable.
Lock-in patterns that are fine
In contrast, here are lock-in patterns we don’t refuse:
Team learning curve. Your team learns the vendor’s product. That’s reasonable. The cost of switching is the cost of relearning, which is bounded.
Integration work. You built integrations into the vendor’s API. Moving requires re-doing the integrations. This is unavoidable for any meaningful product relationship.
Configuration that didn’t exist before. The vendor’s product helped you configure things you wouldn’t otherwise have. You don’t have a right to take the vendor’s product capabilities with you.
Performance tuning. Specific configurations or prompt structures that work well on this vendor’s platform are vendor-specific. Reasonable.
The line is roughly: lock-in is acceptable when it’s a cost of the value you got. Lock-in is unacceptable when the contract is structured to amplify that cost beyond the underlying value.
The negotiation conversation
The hard part of refusing lock-in is the negotiation conversation. Two practical notes:
Lead with specifics. Don’t say “we’re concerned about lock-in.” Say “we need the workflow export clause modified to require human-readable format.” Specific asks are negotiable. Generic concerns get deflected.
Be willing to walk. The vendors who refuse to negotiate lock-in are the ones whose business model depends on it. They are the ones you most want to walk away from. The willingness to walk is what makes the negotiation possible.
In practice, mature vendors will negotiate. Immature ones won’t. The negotiation itself is a screening signal about which kind of vendor you’re talking to.
What this saves you
Across a typical $300k/year AI vendor relationship, refusing these six patterns at signing usually:
- Preserves $100–250k of optionality value over 24 months (the expected cost of needing to migrate without the protections).
- Reduces lock-in-related risk to manageable levels.
- Makes contract renewal a real negotiation rather than a forced renewal.
- Signals to other vendors that you negotiate seriously, improving subsequent deals.
The legal cost of negotiating these terms at signing is in the low five figures. The cost of not negotiating them and discovering the constraints later is substantially higher.
The mindset shift
The deeper shift is psychological. SaaS-era procurement treated vendor lock-in as a cost of doing business. AI-era procurement should treat it as a deliberate decision, made with awareness of the trade-offs.
The vendors know this market is moving fast. They are writing contracts that capture as much customer optionality as customers will give them. The companies that get this right are the ones who treat vendor relationships as portfolios — some lock-in is acceptable for the value, but the portfolio level of lock-in is monitored and managed.
The take
Some lock-in is fine. Six patterns are structural and refuseable. Refuse them at signing. The negotiation cost is small. The optionality preserved is large. AI vendors who can’t negotiate on these terms are telling you something important about how they expect the relationship to go.
Vendor management is part of Fractional CAIO engagements. If you have an AI procurement in flight and want a contract review, schedule a call.
