The expensive lock-in in enterprise AI is not the model but the untagged usage history, the prompt estate tuned to one vendor, and the evaluation suite that was never written. Vendor neutrality is an architecture property, and the right partner is one that helps you keep it.
Every vendor-selection deck I have reviewed has a slide about lock-in, and the slide is about the model: which lab, which contract, which exit clause. I have built and led a practice inside a frontier-lab partnership, so it would be convenient for me to say pick one and commit. I am going to say something closer to the opposite, because the clients I have seen do best, inside that partnership and outside it, are the ones who could leave. The lock-in that hurts enterprises is almost never the model. Models are swappable in weeks if you built for it. What is not swappable is a year or more of untagged usage history, a prompt estate tuned by hand to one model’s habits, and the evaluation suite that was never written because the demo worked. Those are the switching costs. Nobody puts them in the business case.
Build, buy, or partner sounds like a spectrum of ownership. It is really three different things being purchased, and the labels mislead.
Buy usually means buying a demo with a logo on it. What you actually acquire is the vendor’s roadmap, their data terms, and their definition of done. The model inside is often the same frontier model you could call directly. You are paying for the wrapper, and for the right to be surprised by its limits later.
Build usually means building a model nobody needed. I have watched teams spend the better part of a year on fine-tuning and training infrastructure to produce something that, in my judgment, a frontier model with good retrieval and a clean eval suite would have matched in a fraction of the time. Ownership feels like control. But the ownership that matters is not ownership of weights. It is ownership of the measurement and the switch.
Partner is the door most organizations walk through whether they name it or not, because a vendor relationship becomes a partnership the moment your roadmap depends on theirs.
If the model is swappable, where does the switching cost hide? In four places, none of which appears on a price sheet.
Billing-unit assumptions in the business case. The forecast was built in one vendor’s tokens, at one vendor’s prices, and the ramp was fitted to that. Change vendors and the case has to be rebuilt from scratch, which in practice means it is not rebuilt, and finance loses the thread.
Prompts hand-tuned to one model’s quirks. Every production system I have looked inside accumulates a prompt estate: system prompts, few-shot examples, formatting rules, the odd sentence someone added at two in the morning because the model kept doing the wrong thing. Most of it is tuned to one model’s habits, scattered across repositories, and nobody knows which parts are load-bearing.
Telemetry that does not record model version. The trace captures latency, tokens, and the workflow step, if you are lucky. It does not record which model and version produced the output, so when you want to compare a candidate against the incumbent there is no baseline. The history exists but cannot be read.
Evaluations that do not exist. Without a fixed evaluation suite representing the system’s real work, a vendor change is not an engineering decision. It is a leap of faith, and enterprises rarely take leaps of faith with production systems. The demo worked, so the eval was never written, so the model can never be changed. A missing test suite is the strongest lock-in I have seen.
The four share one thing. None of them needed a vendor to impose it. Each was an omission by the buyer, made early, when it was cheap to avoid.
The right response is not to build a model. It is to build the thin layer that makes the model a replaceable part. In engagements I have led, that layer has four pieces.
A gateway. Every model call passes through it, so routing, rate limits, cost attribution, and logging happen in one place rather than in every application. It is the same reason enterprises put an API gateway in front of their services a decade ago.
A model registry. It names which model and version serves which workflow, so a change is a configuration edit with an audit trail rather than a hunt through code.
Prompt versioning. Prompts are treated as source: reviewed, tagged, and tied to the eval run that approved them. The prompt estate stops being folklore and becomes an asset you can inventory.
An eval harness that runs against any provider. The same fixed suite, with a ground-truth oracle per workflow, pointed at whichever model you like. The question “would the other model do as well” gets an answer in hours or days instead of a quarter.
This layer is the paved road. Teams that use it get neutrality by default. Teams that go around it get the demo, and the lock-in.
The layer not worth building, for almost every enterprise, is your own foundation model. The economics of training at the frontier favor the labs, and the control you think you are buying is available far more cheaply through the harness above. Build the measurement. Rent the capability.
The right partner helps you keep neutrality rather than quietly eroding it. The terms I look for are generic, and I would ask for them from any vendor, including the one I work with.
Data terms per data class. Which data may reach the model under which retention and training terms, decided once per data class rather than renegotiated per project. If the answer needs a lawyer every time, the paved road has a toll booth.
Deprecation notice and version pinning. A written window before a model version retires, and the ability to pin in the meantime, so the vendor’s release calendar does not become your incident calendar.
Usage telemetry you own. Per-call records with model version, consumption, and your own metadata, exportable in a form you can join to your unit-of-work data. The vendor’s dashboard is not your telemetry.
A roadmap conversation that goes both ways. You learn what is coming in time to plan for it. They learn what your workloads actually need. A partnership where information flows in one direction is a subscription with a nicer name.
The forecast belongs before vendor selection, not after it. In the two-numbers piece I argued that the billing unit in a business case should be deliberately abstract, because a model that hard-codes tokens has quietly chosen a vendor before the vendor selection. Price per unit of work, with runs per unit and consumption per run as separate terms, and a switch becomes one changed parameter and a re-run of the eval suite. Keep the band lopsided. The right tail of agentic consumption does not care who the vendor is.
When the arrangement works, the division is clean. The partner supplies capability and roadmap: the models, the improvements, the early notice of what is changing. You keep the measurement and the switch: the gateway, the registry, the eval suite, the telemetry, the forecast in abstract units.
That division is what makes candor possible from inside a vendor relationship. A partner who knows you can leave has to earn the renewal on capability. A partner who knows you cannot does not. The clients who get the most honest roadmap conversations, and the strongest position at renewal, are, in my experience, the ones whose architecture made leaving plausible.
So the decision rule is short. Build the harness. Buy the model. Partner for the roadmap.
The rule is cleaner than the practice. The harness makes models interchangeable in plumbing, not in behavior. Prompts will still need re-tuning on a switch, and the eval suite tells you how much, which is the point of having it. Some workloads genuinely favor one model. A neutral architecture does not make that preference go away. It makes it measurable instead of assumed.
The discipline also costs something up front, usually weeks of platform work and more when the eval suite has to be built from nothing, which is exactly the work the demo was allowed to skip. For anything built to run past a year, I have not yet seen it fail to pay back, and I hold that as an observation from a limited set of engagements rather than a law.
The vendors that hold enterprises longest are not the ones that lock them in. They are the ones whose clients could leave, and stay anyway.
Related: The unit economics problem in enterprise AI and What enterprise grade actually means for AI applications.
