Lock-in is rarely written into the contract
Procurement reviews the contract. The contract is usually fine — most model providers have unremarkable commercial terms and no exit penalty. The lock-in arrives later and from a different direction: an engineer, reasonably, imports the provider's SDK and calls it directly from the code that does the work.
Eighteen months on, that import statement appears in ninety files. The provider changes pricing, retires the model version you built against, or compliance asks a question the terms do not answer — and what should be a vendor conversation is now a rewrite with a business case attached.
The seven questions to answer before you sign
We hand this list to clients before any AI vendor commitment. It takes an afternoon and has saved several of them a year:
- 1. Which classes of our data may leave our boundary? Classify into public, internal, confidential and regulated first. Everything else follows from this and it is a business decision, not a technical one.
- 2. Does this tier train on our submissions? Free tiers of the major providers generally use submitted content to improve their products; paid tiers contractually do not. Read the tier you are actually on, not the marketing page.
- 3. What is the model retirement policy? Providers deprecate model versions. If your prompts are tuned to a version with a twelve-month life, you have a recurring project, not a purchase.
- 4. Where is inference physically performed? Data residency questions arrive from enterprise customers and regulators, usually after you have shipped.
- 5. What happens to our data at rest, and for how long? Retention windows for prompts and outputs vary widely between providers and tiers.
- 6. Can we run an equivalent workload elsewhere tomorrow? If the honest answer is no, you have architectural lock-in whatever the contract says.
- 7. Who owns the consumption budget? Usage-based pricing has no natural ceiling. Without a named owner reviewing spend monthly, finance discovers the number at quarter end.
Questions one and six are the load-bearing ones. The other five are important; those two determine whether the rest are recoverable.
What the failure data actually shows
MIT's NANDA initiative published the most-cited enterprise AI study of the cycle in 2025 — The GenAI Divide: State of AI in Business 2025 — built on 300 public deployments and 150+ executive interviews. Its headline finding was that roughly 95% of enterprise GenAI pilots delivered no measurable P&L impact, and that the divide was organisational rather than technological.
Gartner's projection points the same way from a different angle: it expects over 40% of agentic AI projects to be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. Read together, the anatomy is consistent — single-vendor SDKs wired into production code, no privacy boundary, no baselines, and no named owner for spend.
| 95% | Enterprise GenAI pilots with no measurable P&L impact (MIT NANDA, 2025) |
|---|---|
| >40% | Agentic AI projects Gartner expects to be cancelled by end-2027 |
| ~1 week | Typical cost of building the abstraction that prevents most of this |
What the routing layer actually is
It is less exotic than it sounds. A thin interface your application calls — 'summarise this', 'classify that' — behind which a router decides which provider and model serves the request, based on the data's classification, the quality the task needs, and cost.
Two consequences follow immediately. The privacy question stops being a debate and becomes routing policy: regulated classes pin to a model inside your boundary, everything else goes to whichever frontier model is best value this quarter. And the vendor question stops being architecture: when the market reshuffles — and it reshuffles roughly quarterly — you change a config value.
We build this way on our own products, which is the only reason we are confident recommending it. Our site chatbot is provider-agnostic; moving it between Gemini, Anthropic and an OpenAI-compatible endpoint is an environment variable, not a project.
The sequencing mistake almost everyone makes
The instinct is to prove value first and worry about architecture later. It is a reasonable instinct and it is why so many pilots become stranded assets. The pilot works, leadership funds production, and the team discovers that the thing they built cannot be moved, cannot pass a compliance review, and has no cost ceiling.
The alternative costs about a week: build the abstraction and the data classification before the first workflow, then run the pilot behind it. The pilot is no slower. The difference is that if it succeeds you can ship it, and if it fails you have lost a pilot rather than a quarter.
A decision rule you can steal
If you take one operating rule from this, take this one:
- Classify data before choosing a model — the classification decides the architecture
- Never let application code import a provider SDK directly; call your own interface
- Confirm the training terms of the tier you are actually on, in writing
- Baseline the workflow numerically before the pilot, or you cannot prove anything afterwards
- Name one person accountable for consumption spend, with a monthly review in the calendar
- Re-evaluate the model market quarterly; treat a provider swap as routine maintenance
Where we would tell you not to hire us
If you are running one internal workflow with non-sensitive data and no compliance surface, the routing layer is over-engineering. Call the provider directly, keep the code in one file, and revisit when a second workflow appears.
The abstraction earns its week when you have more than one workflow, any regulated data, or an enterprise customer who will eventually send a security questionnaire. Below that threshold we would tell you to spend the week on the product instead.