Every AI cost overrun gets treated as a procurement problem. Most of them are the first visible sign of a dependency nobody chose.
In my last edition I argued that AI’s cost structure is set at design time, not at renewal. This one is about what happens when you reach the renewal anyway.
Every board eventually asks two questions about AI. The first is what it costs. That one gets asked every quarter, and it gets answered.
The second arrives later — usually from a director who has lived through a vendor exit before. If we had to leave, what would it take?
Most technology leaders hear that as a cost question. Inference bills climbing, egress charges, a renewal uplift nobody budgeted for. It all reads like procurement: negotiate harder, tighten FinOps, put a second vendor in the next RFP.
It is not a cost problem. It is the invoice for a dependency nobody decided to take on.
Egress was never the problem. It was the receipt.
Cloud taught us the pattern. Egress fees were never the problem. They were the moment the problem became visible: data had accumulated somewhere, gravity had formed around it, and leaving now carried a price nobody had modelled when the decision to arrive was made.
The mechanism matters more than the fee. A decade of cloud economics trained organisations to evaluate every decision in unit-cost terms. Cost per instance, per gigabyte, per request. It is a powerful discipline. It is also a language with a gap in it.
Sovereignty has no unit. Optionality has no unit. So when someone asks whether the organisation can still leave, the question gets translated into the only language available, a comparison of this year’s run cost against a one-time migration cost. Framed that way, the answer is always to stay.
Not because staying is right. Because the question was never asked in a form that could return any other answer.
The model moves. The context stays.
AI is repeating the pattern, one layer higher, and faster.
The model is the visible part, and the most portable. Swapping one foundation model for another is increasingly an engineering task, not a strategic one. What does not swap is everything an organisation builds around it: the embeddings generated against one model’s representation of meaning, the fine-tunes, the retrieval logic tuned to one vendor’s quirks, the evaluation history that tells you whether the system is getting better or worse, the agent scaffolding wired into one platform’s tools and permissions.
Call it the context layer. It is where the actual institutional knowledge of an AI deployment lives. And almost nobody is governing it as a position or pricing it as a risk.
The model is what you rent. The context is what you build — and it is the part that refuses to leave.
This was the conversation I kept having at Dell Technologies Forum stops across the region this season: different industries, different regulators, the same quiet question in the corridor afterwards. Nobody was asking which model to use any more. They were asking why the thing they had built felt so hard to move.
The discovery rarely comes from a strategy review. It comes sideways. A vendor conversation reprices something that was assumed to be fixed. Or an internal team tries to move a working use case to a different platform and finds that the model moves in a week while the context stays behind.
Either way, the organisation learns its exit cost the same way it learned its egress cost: after the fact.
One dependency. Three owners. Nobody holds the sum.
The same dependency looks different depending on where you stand, and each altitude hides it in a different way.
At the workload, it hides inside architecture. A retrieval pipeline, an embedding store, an evaluation harness. Each choice is reasonable on its own. Together they set into something that only runs well in one place. Engineers usually see this first, and rarely have the vocabulary to escalate it as anything other than technical debt.
At the organisation, it hides inside capability. Teams learn one platform’s way of doing things. Processes, approvals and skills form around it. The dependency is no longer just in the stack; it is in how people work. That is the version that makes a migration feel like a reorganisation, because it is one.
At the sovereign altitude, it hides inside assumptions about jurisdiction. Where the context layer physically sits, whose law governs it, and who can compel access to it. Across APJC this is no longer abstract. Data residency rules, sovereign AI programmes and regulator expectations are moving faster than most enterprise AI architectures were designed to absorb — which is why sovereignty has to be answered per workload, not once for the estate.
The trap is that each altitude is owned by someone different. Engineering sees the first, the operating model owns the second, risk and legal own the third.
Nobody owns the sum — and the sum is the exit cost.
This is not an argument for leaving.
I sit at an infrastructure company, so let me be precise about what I am not saying.
This is not a case for repatriation, and it is not a case against any platform. Depending on a vendor is often the right call. Speed matters, and a deep platform commitment can be worth every dollar of the exit cost it creates.
The failure is not dependency. The failure is dependency that was never chosen. A leader who decides to stay on a public cloud AI platform, knowing what leaving would cost and accepting it, holds a position. A leader who stays because the question was never asked in a form that allowed any other answer holds a liability.
One is a strategy. The other is drift with a renewal date.
Staying is a decision. Or it is a default.
AI will happily optimise your cost to stay. It will tune the prompts, compress the tokens, route the cheaper model. What it cannot do is tell you whether staying is still a decision, or has quietly become a default.
That judgment does not automate. It belongs to whoever answers the board’s second question.
So the question I would put to any leadership team running AI in production is not what this costs to run. It is this: if the board asked tomorrow what it would take to leave, who could answer — and how long would it take them to find out?
Cost is what you pay to stay. Dependency is what you would pay to leave. Only one of them arrives on an invoice — which is exactly why the other one is yours to own.