Why AI Lock-In Is Bigger Than the Model
Most AI products arrive as a bundle: one company’s interface, one company’s route for your data, one company’s AI models. Keeping those three separable is what protects you when the market shifts.
AI is not a product trend you adopt once and move on from. It is a foundational layer of capability, like the internet, and it keeps improving in ways that reshape how work gets done. When something changes that quickly, the important strategic question is not which tool you start with. It is how easily you can change your mind later.
Most AI products still arrive as a bundle: one company’s interface, one company’s route for your data, one company’s models and, before long, one company’s way of working. The bundle is genuinely convenient, which is exactly why it succeeds. It is also how lock-in happens, quietly, without a decision anyone remembers making.
The risk worth worrying about is not that you picked the wrong flagship model this quarter. It is that your workflows, your team’s defaults and your rules about sensitive data all end up inside a bundle you cannot take apart when the market moves. And it will move.
That is why “use more than one provider” is only part of the answer. A single-vendor bundle locks in three things at once: the interface your work takes place in, the route your data takes, and the AI models you get used to. Those three sit on top of one another, and they are easiest to understand from the top down.
Convenience is the whole appeal
A bundle feels like progress because it removes decisions. One subscription, one history, one place to ask for help, and nothing to compare. For one person, that can be enough for a long time. For a team, it can become the standard without a deliberate choice, simply because it was already there when the work started.
This is not a new pattern. In the early consumer internet, services such as AOL packaged the connection, the mailbox and the content into a single product that was far easier to use than the open web. The package won users through convenience. The open web proved more durable because its parts were separable: you could change your provider, your browser or your mailbox without giving up the others. The organisations that treated the package as though it were the internet had to unpick that assumption later, and it cost more then than it would have at the start.
Today’s AI products often look like that package. The workspace, the data path and the models are sold as one thing, and after a few months of daily use it becomes genuinely hard to see them as three separate choices. That is what makes lock-in here different from the version most people prepare for. It is rarely an engineering rewrite, and rarely even a contract negotiation. It is the slow process of a bundle becoming the way you think about the work.
The place your work lives
The first lock is the one you look at all day, which is probably why it is the easiest to overlook. It does not feel like infrastructure at all.
Work accumulates in the chat window: drafts, decisions, the half-finished reasoning behind a conclusion, the small process someone invented and never wrote down. It is natural to treat that window as the workflow. It is not the workflow. It is one way of reaching the models underneath, sitting on top of a data path you probably did not specify.
The other ways are already here or taking shape. Internal tools call models directly. Ordinary software calls them as part of a normal feature. Agents will take actions across other systems on someone’s behalf. If your assistant is effectively the whole arrangement, each of those additions starts from scratch: new habits, new rules about what is allowed, new places where sensitive context can end up. If the chat window is only one of several ways into the same arrangement, the work and the rules survive the change.
This is why using several chatbots is a weak version of adaptability. It gives you more places to type, and no more portability than you had before.
The route your data takes
One layer down is the lock that tends to surface at the worst possible moment, usually when someone asks a direct question about a customer’s data.
A bundle does not only give you somewhere to work. It also settles, quietly, where your prompts and documents go once you press send, which means taking on an operator, a jurisdiction and a default nobody in your organisation wrote. The marketing may promise that data stays in a particular region, which is worth having, but where the hardware sits is a different question from which laws reach it and who can be compelled to hand something over. The operator matters as much as the map.
For everyday use, inheriting that arrangement is often fine. For customer records, internal documents, or anything you would not paste into a public form, it is a decision about risk, whether or not it felt like one at the time. Being able to change your mind later has to include being able to say that a particular kind of data goes to a particular kind of environment, and that some of it does not leave at all.
None of this means every workload belongs in the most restricted environment available. It means the environment should follow the data rather than the bundle. Where inference actually runs is covered separately. The narrower point here is that a data path baked into the product you live in is not a choice you still have when you finally need it.
The AI models you get used to
At the bottom sits the part most people mean when they say vendor lock-in, and it is the one they tend to underestimate. Described technically it sounds like a weekend of work: swap one SDK for another, or cancel one subscription and start another. The expensive version is harder to see, because it lives in habits rather than in code.
It is also not really one model. A large provider gives you a family of them: a fast one, a cheap one, a careful reasoning one, one tuned for code, and a new flagship every few months. Moving between them feels like keeping your options open, and inside the bundle it is the only kind of choice on offer. Every one of those options still shares the same interface, the same data path and the same operator. Choosing between siblings is not the same as being able to leave.
Over months of daily use you calibrate to one provider’s models. You learn which phrasing gets a useful answer, how much context to provide, where it tends to go wrong, and which tasks demand close review. You keep your notes in its history. You come to rely on a handful of features that are genuinely good and have no easy equivalent elsewhere. None of this is a mistake, and none of it is the vendor behaving badly. It is what happens with any tool you use every day. The catch is that the capability underneath is still improving quickly, so the tool your habits are built around may not stay the best fit for the work you actually do.
At team level, those habits harden into defaults. A few people settle on one assistant, the shared prompts and the “this is how we do it here” collect around it, and new colleagues inherit the arrangement as culture rather than as a decision they could question. By the time anyone asks whether a model from somewhere else would suit a particular job better, the cost of finding out is no longer a subscription. It is the friction of changing how a group of people works.
It would be easier if you could wait for the market to settle and commit afterwards. There is little sign of that happening. The frontier keeps moving between a handful of labs, and open-weight models keep improving underneath them, which makes credible alternatives more available rather than less, including the option to run a model in an environment you choose yourself. That does not make anything simpler. It does mean the sensible planning assumption is more models and more trade-offs over time, rather than a winner who ends the argument.
Keeping the ability to change your mind
The useful response to all this is not to collect more tools. It is to be deliberate about which parts of your setup are meant to hold still, and which parts are expected to change.
The parts that should hold still are the ones you would not want to rebuild: how the work actually gets done, the standards you hold output to, the rules about what may be sent where, and your ability to reconstruct how a decision was reached. The parts that will keep changing are the places people work, from a chat window today to internal tools, ordinary software and agents, as well as the models running underneath them. Keeping those two groups apart is the whole idea. That ability to change your mind later is what optionality really means: a property of how things are arranged, not a count of subscriptions.
Trust has to be built into that arrangement rather than announced alongside it, and in practice it comes down to a few unglamorous questions. Which model produced this, and when? What did it read in order to answer, and roughly what did it cost? Which rules applied, and who changed them last? A team that can answer those questions can compare tools honestly, explain a decision months after the fact, and notice when something has quietly changed underneath them.
It also means matching the tool to the job rather than reshaping the job to fit the tool. Different work wants different trade-offs: careful reasoning, code, plain extraction, price, speed, or a stricter route for the data. That choice is only real if the surrounding rules do not have to be rewritten every time you make it.
For one person, this can start small. Do not let a single chat history become the only record of your work, and be explicit with yourself about what is allowed to leave your environment. For a team, it has to be deliberate. The test is not whether people can name three models. It is whether you could change the interface, the data path or the models without renegotiating how you decide what is allowed.
The takeaway
This market is not consolidating into one stack. It is becoming more competitive, more varied and more embedded in ordinary work.
The way to take the upside without inheriting someone else’s constraints is to keep the changeable parts changeable. The interface, the route your data takes and the models are three decisions rather than one, and they age at different speeds. Using more than one provider is a reasonable start. Treating those three as separable is the deeper commitment.
That is a judgement leaders need to make, in much the same way they once had to understand the internet before they could see what it would become. The convenient bundle is not the whole of AI, any more than the walled garden was the whole of the internet.
This article is part of a foundational series on AI literacy and adoption. You might also want to read AI Is Here to Stay, Token Economics: The Unit of AI Compute, and Where Does Your AI Actually Run?.