Model Lock-In
Model lock-in is the AI-era form of vendor lock-in. It forms when a build hard-wires one vendor's model into the workflow, so switching later means rebuilding. The dependence is deeper than classic software lock-in because more than data is stranded: prompts are tuned to one model's behavior, embeddings live in one provider's vector space, and agent workflows are calibrated to one model's behavior. None of that transfers. For a CFO, the exposure is an off-balance-sheet switching liability equal to the cost of rebuilding those prompts, embeddings, and calibrations on another vendor's model, and it grows with every tuned prompt and every embedded document even though no line on the balance sheet records it. The vendor's token pricing becomes your unit economics, the vendor's deprecation schedule becomes your maintenance calendar, and every model update the vendor ships changes how your system behaves without your involvement. Our position, stated as a design rule: AI does not replace deterministic software and machine learning. Layered on top of systems you own, it improves their performance. Using AI to substitute foundational business systems leads to excessive token usage while costing reliability and accuracy, as the models are more likely to hallucinate where no reliable data layer exists.
How it actually works
The lock-in forms in the build, not the contract. A pilot gets wired directly to one provider's API because that is the fastest path to a demo. Prompts accumulate adjustments that compensate for that specific model's behavior. Documents get embedded in the provider's vector space, which no other provider can read. By the time the pilot becomes a workflow, the model is a load-bearing component that was never evaluated as one. In our AI consulting work we see the recognizable pattern: the token bill scales with usage whether or not results follow, and the pilot demonstrates that the tool works without establishing that it changed a number the business tracks.
The costs arrive on the vendor's schedule. Token prices change without your input, and we are starting to see token costs increase across the industry. Models get deprecated, which forces re-validation of every prompt and workflow tuned to the old one. Model updates change output behavior between one day and the next, which is a reliability problem for any process that depends on consistent answers. As we wrote in our vendors analysis, the people telling you to use more tokens are the ones selling the tokens; the incentive structure behind agentification is the same one behind every usage-billed platform.
The alternative is layering. Deterministic software handles everything a rule, a lookup, or a threshold can decide, because deterministic systems produce the same answer every time at near-zero marginal cost. Machine learning you own handles the pattern recognition. The language model sits at the edges, with minimized context per call, doing only the work that genuinely requires reasoning over language. A system built this way can switch model vendors by changing one integration layer, because the model was never the system. Our own team replaced several subscriptions with on-demand APIs this way, completing the same work at a fraction of the cost, and paused rather than expanded LLM usage when token costs began to rise.
In practice
The cost of substituting AI for working systems is now measured: MIT's NANDA initiative published findings in 2025 that 95% of generative AI pilots delivered zero measurable impact on the P&L, despite $30 to $40 billion in enterprise investment. The pilots that fail this way share the pattern described above: the model was asked to replace deterministic software and measurement discipline rather than extend them, and the spend accrued to the vendor whether or not a business number moved.
Where we come in
We build the deterministic and machine-learning layer first, evaluate the expected impact on profit before anything gets built, and add model calls only where reasoning over language is genuinely required, with minimized context per call. Everything is scoped up front and the systems are portable: you are never locked to a single model, platform, or vendor.
Start a Revenue Health Pre-Assessment →See it in action
Related terms
- Vendor lock-in
- The classic form: switching costs engineered into a platform through proprietary formats, contracts, or integration depth. Model lock-in adds a layer the classic form lacks: the locked component changes behavior on the vendor's schedule.
- Token costs
- Usage-based pricing for model calls. The variable cost that scales with adoption, set by the vendor, and revisable at any time. A workflow's token consumption is a direct measure of its lock-in exposure.
- Model deprecation
- The vendor retiring a model version. Every prompt, evaluation, and workflow tuned to the deprecated model must be re-validated against its replacement, on the vendor's timeline.
- Agentification
- Rebuilding processes as chains of model calls. Each added call multiplies token consumption and deepens the dependence on one model's behavior. The industry pattern of maximizing calls benefits the party selling the tokens.
- Abstraction layer
- An integration boundary that lets the model behind a workflow be swapped without rebuilding the workflow. The design choice that determines whether switching is a configuration change or a rebuild.
- Portability
- The property that a system's data, features, and logic survive a vendor change. Deterministic code and owned models are portable; prompts and embeddings tuned to one vendor generally are not.