How do we avoid getting locked into an AI vendor?
Lock-in is rarely about the contract. It is about where your mapping logic and joined history live. If both sit inside one vendor's product, leaving means rebuilding years of work regardless of what the agreement says. Keep credentials in your accounts, keep joined data in a store you can query, and keep the model layer swappable. Accept switching cost where it buys real value; refuse it where it buys nothing.
Distinguish switching cost from being held hostage
Every useful system creates some switching cost. Your team learns it, workflows form around it, historical reports assume it. That is normal and often worth paying for. Lock-in becomes a problem when the cost of leaving is disproportionate to the value delivered, and when it was designed in rather than incurred honestly.
The practical question is not "can we leave" but "what exactly would we lose." Write that list down before signing, not during the argument.
A useful exercise: ask what you would need from a vendor on the day you told them you were leaving, and whether their agreement obliges them to provide it. Most companies find the answer is nothing beyond raw exports of each source system, which is a very different thing from the joined history they have been paying to maintain.
The three places lock-in actually lives
- The identity graph. The accumulated knowledge that this phone number, this click and this customer record are one person. Expensive to rebuild and invisible until you try.
- Business rules. Rubric definitions, alert thresholds, source classifications. If they are configuration you can export, they move. If they are the vendor's internal code, they do not.
- History. Scored calls, tagged leads and derived metrics that exist nowhere upstream. Losing these breaks your ability to compare year over year, which quietly kills the argument for the next project.
Design choices that keep options open
Keep the model layer behind an interface so a change of AI provider is a configuration change rather than a rewrite — that is the point of treating model integration as its own layer. Keep raw source data landing in your own store before any vendor transforms it. Prefer vendors whose connectors use documented public APIs over ones relying on private arrangements you cannot replicate.
None of this requires building everything yourself. It requires that the durable assets exist outside any single product boundary.
Where accepting lock-in is the right call
Your operational system is a reasonable place to be deeply committed. Migrating a field service platform is genuinely painful, and that pain buys you a coherent operational spine. Fighting it by keeping everything vendor-neutral usually produces a worse business, not a freer one.
The rule of thumb: be deeply committed to at most one system of record, and deliberately loose everywhere else. Then make sure the layer that connects them is one you can carry with you.
Topics: vendor lock-in · portability · risk · architecture
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.