AI vendor lock-in is the risk that a business can't leave, downgrade, or even function without one AI provider — and in June 2026 it stopped being a slide in a consultant's deck and became a live event, when a US export-control order took a frontier model offline overnight for every company that had quietly built around it. That's the visible half of the lock-in problem. The quieter half — AI consultant lock-in, and the one I actually see wreck Dutch mkb projects — is depending on the person who built the system, not the platform it runs on.
What the Claude Fable 5 shutdown actually taught
On 9 June 2026, Anthropic released Claude Fable 5 and Claude Mythos 5, its most capable models yet. Three days later, the US Commerce Department ordered the company to suspend global access under export-control rules, after reports of a jailbreak with alleged national-security implications. Because Anthropic had no way to verify a user's nationality in real time, the only compliant option was to pull both models offline everywhere, for everyone, within hours. They stayed down for 18 days. When Commerce lifted the order at the end of June, Fable 5 came back — at roughly double the price of Anthropic's own Opus 4.8, instantly the most expensive model the company sold.
Nothing about that sequence was unique to Anthropic; the same could happen to any frontier lab under the same regulatory pressure, and the point of raising it here isn't to single one out. It's that every business whose support bot, code-review pipeline or client-facing agent was hard-wired to one specific model had, for two weeks, no fallback and no vote in what came next. The surveys back up how common that exposure already was before the incident: 81% of US enterprise executives say they're at least somewhat concerned about depending on a single AI vendor, 47% say losing their primary vendor would disrupt a key business function, and only 6% believe they could actually switch without real operational damage. Model-level lock-in, in other words, is now something boards openly worry about. Good — that's the half of the problem people are finally naming.
The lock-in nobody names: depending on the person, not the platform
Here's the half I watch clients walk into far more often, and it has nothing to do with which model sits behind the API. A business can do everything right on the model question — pick an open standard, avoid a single vendor's proprietary agent stack — and still be completely unable to touch its own AI system, because the prompts, the exception logic, the orchestration and the "why does it do that" knowledge live in one person's head: the consultant who built it.
I ask every founder I meet a version of the same question the research for this piece kept surfacing: what happens after implementation — who actually manages this in month fourteen? Almost nobody has an answer, because almost nobody asks it before signing. It's not on the checklist next to price and timeline, which is exactly why it's the more dangerous lock-in. Model lock-in shows up in a Commerce Department letter or a repriced invoice, loud and unmistakable. Consultant lock-in shows up quietly, as a support ticket that takes three weeks instead of three hours, because the one person who understood the system is on holiday, working for someone else, or has simply raised the retainer and knows you can't easily say no.
Why this is a business-model choice I have to fight, not an accident
I don't think most consultants set out to build a trap. The trap builds itself. The fastest, most impressive way to ship an AI system is to wire it straight into one vendor's framework, bake the client's exception rules into prompts only you've seen, and skip the architecture document because the client is thrilled with the demo and nobody asked for it. It ships in weeks. It looks brilliant in the meeting. And it creates a system that only its author can safely touch — which happens to be the version of "success" that maximises my own future retainer.
I feel that pull on every project, and I'd be lying if I said otherwise. A system nobody but me understands is worth more to my business, every single month, than one your own team can run without me. Being honest about that incentive is the only way I know to build against it deliberately, instead of drifting into it by accident the way I think most consultancies do. It also explains why the industry rarely talks about this openly: naming the incentive is bad for the incentive.
What I actually build differently
A few concrete habits, none of them exotic, all of them things I could be checked on.
- Every project ends with a written architecture document in plain Dutch or English, not a diagram only I can read, plus a working session where someone on the client's own team — not necessarily technical — operates and adjusts the system with me watching, not the reverse.
- Code and data live in the client's own repository and cloud tenant from day one, never mine, so there's nothing to "hand over" because nothing was ever mine to hold.
- Where the choice exists, I build on open standards rather than a single vendor's proprietary agent stack. This got materially cheaper to do properly in 2026: Stacklok's industry survey found 41% of software organisations are now in limited or broad production with MCP servers, and over 10,000 public MCP servers exist to connect a system to the tools it needs without hard-coding one vendor's format into the plumbing. Model-agnostic design used to mean extra engineering hours; a lot of that tax has quietly disappeared this year, which is precisely why there's less excuse for skipping it than there was two years ago.
- I default to fixed-scope projects over open-ended retainers, on purpose, because a retainer is the one commercial structure that rewards me financially for the system staying dependent on me. A fixed scope forces the incentive back onto doing the handover properly the first time.
- And every contract states, before the first invoice is sent, what happens if the client wants to leave: what they receive, in what format, and how long a transition takes. Negotiating that during a breakup is the worst possible time to negotiate it, and I've seen enough breakups negotiated badly to know that in advance beats in anger every time.
None of this is really about enterprise budgets, either, even though most of the vendor-lock-in research is written for CIOs with a governance team behind them. A 100-person enterprise running 37% of its AI workloads on five or more models, per this year's CIO survey, still has someone whose job is to review that exposure on a schedule. A 20-person Dutch or Flemish mkb almost never does. There's no quarterly vendor-dependency review, no in-house AI team to notice a support ticket taking three weeks instead of three hours, no governance layer sitting between the founder and the consultant's invoice. That's precisely why the questions in this piece matter more for a smaller business than a larger one, not less — you have fewer people positioned to catch the problem after the fact, which makes catching it before you sign the only reliable option you actually have.
Each habit above is really shorthand for the same underlying check, worth spelling out once: does leaving cost you a negotiation, or does it cost you a rebuild? A negotiation is annoying but survivable — you argue about price, timelines, maybe a kill fee, and life goes on. A rebuild means starting the project over with someone else, at full cost, because nothing from the first engagement is usable without its original author. A large enterprise with a governance team can usually absorb that cost once and move on. A twenty-person installation firm or accountancy practice cannot — it doesn't have a second budget lying around for the same project. Which is exactly why the underlying question, negotiation or rebuild, matters more at that size than at enterprise scale, and costs nothing extra to ask before you sign.
Even Europe's flagship sovereignty project didn't fully escape this
It's worth admitting how hard this actually is to get right, even with the best intentions and a serious budget — because the clearest recent example isn't a small AI-bureau, it's the European Commission itself. In April 2026, the Commission awarded its first-ever sovereign cloud framework — worth up to 180 million euros over six years — to four providers, explicitly to reduce Europe's dependency on non-European infrastructure. Three of the winners, Post Telecom with OVHcloud and CleverCloud, StackIT, and Scaleway, build on their own technology and reached the framework's top independence tier, SEAL-3. The fourth, Proximus — the Belgian telecom group — won its slot through S3NS, a joint venture whose cloud layer runs on Google's technology beneath a European legal wrapper, and landed one tier lower, at SEAL-2.
CISPE, the body representing 38 European cloud companies, called the decision "sovereignty washing," warning that dressing a foreign hyperscaler's technology in local governance doesn't remove the underlying dependency, it just makes it harder to see. The Commission's own defence — that a non-European technology stack under sufficiently strict governance can still clear its sovereignty bar — is a reasonable institutional argument. It's also, almost word for word, the same argument every AI vendor makes about its own proprietary lock-in: trust the wrapper, don't worry about what's underneath. If the European Commission can spend 180 million euros and years of deliberate planning and still land one tier below full independence, a Dutch or Flemish mkb signing a chatbot contract on a Tuesday afternoon has essentially no chance of catching the equivalent problem on its own. That's not a reason to give up on the question. It's the reason to ask it before you sign, not after.
A short checklist before you sign with any AI consultant
Five questions, asked once, before the first invoice, to any AI consultant you're considering.
- Who owns the code and data when this project ends — in writing, not in spirit?
- Could a different developer read this system and make a small change without calling you first?
- If pricing or access to the underlying model changes, what does it cost in time and euros to move?
- Is any part of this married to one vendor's proprietary format that a standard tool couldn't replace?
- What does the contract say happens, step by step, if you want to leave?
If any of those five doesn't have a clean answer before you sign, you're not being paranoid by asking twice. You're doing the one piece of due diligence that neither the demo nor the price quote will ever do for you — and for a business without an in-house AI team to catch the problem later, it may be the only chance you get to catch it at all.
I'll be honest about the tension one more time: making myself replaceable is not what most consultancy business models reward, and there are months I feel that pull as sharply as any founder does. But I'd rather write it down here, in public, than have a client find out the hard way — from a Commerce Department letter, a repriced invoice, or a support ticket that quietly takes three weeks — that the dependency was designed in from the start, and nobody ever asked.
