Early AI adopters stumble across the horror of vendor lock-in. Here we go again?

Many market watchers are flagging AI vendor lock-in as a risk. When it comes to technology adoption, vendor lock-in is something of an occupational hazard. All tech professionals are aware of it, and yet here we are again, with early adopter executives wondering how they became so dependent on a single supplier. 

From the supply-side, of course, having loyal/dependent customers comes with first mover market advantage. AI orchestration platform provider Zapier recently commissioned a survey based on 542 US C-level executives and decision-makers at organizations that currently pay for one or more AI-related vendors. Only respondents with active paid AI vendor contracts were included to ensure findings reflect real operational and financial commitments. The results are in.

AI vendor lock-in is layered

The research itself does not specify what type of AI is being discussed, so it is probably fair to surmise that it is predominantly reflecting adoption of Gen AI machine learning models. Generative AI has many layers of vendor-dependence to unpick. For example, machine learning models require infrastructure scale that typically locks organization into contracts with hyperscalers or with specialised AI infrastructure providers.

AI vendors themselves all offer their own proprietary APIs to enable interoperability between systems, but switching providers means using a different API and the consequent re=coding of the AI system. Then there is industry-specific or domain-specific synthetic data to train AI models which traps AI workflows in proprietary walled gardens. 

Many data storage systems necessary for AI, also use proprietary formats that keep customers in their environment. And then each AI vendor will have its own vendor tools to assist with building, training, testing and monitoring systems which are proprietary and provide additional pain in migrating to another vendor.

And this is all before getting into the weeds of contractual obligations around pricing and renewal.

Migration from one AI vendor to another is hard

As the report makes clear:

The question isn't whether AI is useful. It's what happens when the AI you depend on disappears, spikes its prices, or gets acquired by a private equity firm that's going to strip it for parts?

When asked what would happen if their AI vendor’s services ended suddenly, nearly half of survey respondents said the impact would be serious with at least one key business function not being able to continue working correctly.

However, if this scenario occurred, enterprise leaders expressed strong confidence in their ability to migrate to a new AI vendor, with nearly nine in 10 saying they could do it within four weeks. Many believe it would move even faster—41% estimate 2-5 business days, and 13% say they could complete the switch in a single day.

When probed on their experience migrating between AI platforms, experience did not bear such optimism out. Two-thirds have already attempted to migrate between AI platforms. Among those, only 42% report a smooth transition. The remaining 58% say the process either failed outright or required significantly more effort than expected. 

According to the report:

The problem is that when AI is already woven into internal processes, connected to other systems, and tuned to specific workflows, it has dependencies, edge cases, and little adaptations that nobody documented because they were ‘temporary.’

 In other words all the characteristics of  the classic software migration challenge that makes changing supplier much harder than simply changing a billing plan.

The main problems cited included problems communicating with new and existing vendors; difficulties understanding the current vendor contract and problems finding a suitable replacement.  This shapes how leaders view vendor lock-in. In the survey, 81% say they're at least a little concerned about their organization's dependency on specific AI vendors, and nearly a third say they're very concerned.

As the report observes:

A simple procurement decision morphs into a cross-functional expedition involving security reviews, data mapping, integration rebuilds, and re-training.

Managing AI vendors is a new job function 

Survey respondents were clear about what they did want: transparency. One in three leaders said clearer pricing, features, and contract terms would make the biggest difference. Another 26% want easier data transfers, and 24% want more flexible pricing.

Interestingly, nearly half now have internal teams dedicated specifically to evaluating and managing AI vendors. This team’s job is to figure out which AI tools to use, how to use them, and how to avoid vendor lock-in.

Organizations are deliberately using multiple AI vendors simultaneously to spread risk across providers. Another 42% maintain contingency plans in case of pricing changes, contract updates, or service outages. More than a third incorporate open-source alternatives or design around data portability and standard APIs. A similar share uses third-party integration or orchestration tools to coordinate workflows across systems. Some go even further, building proprietary AI tools (31%) or negotiating shorter, more flexible contracts (29%) to maintain leverage.

My take

Clearly the vested reason for Zapier highlighting the AI vendor lock-in issue is because it offers a business process automation platform to create integrations (or Zaps) between public apps to move data, automate repetitive tasks and incorporate AI into workflows and systems. It is one tool available to put in the technology arsenal enterprises need to tackle the issue of AI vendor lock-in. 

Another asset in that arsenal I would suggest would be a neutral managed service provider, system integrator or consultancy to help internal teams navigate the AI vendor wild west. 

Oh, and while we are thinking about this issue, I do not give much credence to the argument that AI itself will resolve the issue by making it so quick and easy to rewrite code that lock-in no longer matters. Why? See my discussion with Rajesh Padmakumaran.