The Economics of Sovereign AI: When Local Is Cheaper, When It Is Not

Most sovereignty discussions eventually arrive at money: what does it cost to keep AI workloads on Indian infrastructure, and who pays the difference? The honest opening is that there is no single answer — the arithmetic splits by workload, and a provider that quotes one number for everything is doing marketing, not economics.

This post is deliberately qualitative. Figures live where they stay current — the published rate card and the dated comparison — and any number printed here would drift. What survives drift is the structure: which costs sovereignty changes, which it does not, and how to read the difference.

Three buckets. First, the jurisdiction premium: running in-country, on in-country infrastructure, can carry different rates than the global default — sometimes higher, sometimes lower, and the sign depends on the provider’s stack rather than the country’s. Second, the routing economics: when a workload can be served by a small open model in-country instead of a frontier model, the savings from right-sizing routinely dwarf the sovereignty line item — that is the argument behind Adaptive routing. Third, the training economics: dedicated GPUs billed per second are the same arithmetic anywhere; what changes with an Indian operator is procurement and tax posture, not the physics.

The costs sovereignty does not change: token counts, context lengths, and the price of prompt engineering mistakes — which is usually where the real money lives.

When the workload belongs to a model class that is already cheap. Bulk summarisation, classification, extraction — the bread-and-butter volumes — run best on small open models, which cost a fraction of frontier rates and can be served in-country without a premium. A sovereign stack that right-sizes these workloads beats a global default that routes everything to the most expensive model, sometimes by a wide margin.

When training replaces renting at scale. A fine-tuned model owned by the organisation serves at the cost of its own GPUs, not at a per-token rent that scales with every call. Past a workload size the organisation actually has, the owned model’s bill stops tracking usage in the way a rented one cannot.

And when the alternative carries hidden exits. Provider lock-in prices itself at migration time — the year the contract renews. A stack with an exit built in is cheaper on the day it matters, even if it never looks cheaper on a per-token table.

On frontier-scale capability, in the near term. If the workload genuinely needs the very largest closed models, the in-country catalog may not carry them, and the open model that comes closest can cost more to serve at the same quality — a capability limit rather than a geography one, and worth pricing into the plan up front rather than meeting it at renewal.

On under-utilised infrastructure. In-country dedicated serving and on-premise deployments are commitments; a workload that spikes twice a year at low baseline volume will pay for idle capacity on any architecture, and the sovereign version of that bill is no smaller.

And on unplanned migrations. Moving an established stack — integrations, keys, dashboards, retrained instincts — costs real engineering weeks wherever the stack lands. Sovereignty is a reason to make the move; it is not a discount on the move.

The published rate card is the only numbers that matter for comparison — and it must be dated, because undated prices are stories. Check the comparison page for the same discipline: the Vidman AI-vs-rivals page prints competitor figures as dated snapshots, verified against their sources, and says which date.

Beyond that, price the workload, not the token. The blended rate at your actual input-output split — the calculator does exactly this — beats any headline number, and the difference between the two is where procurement mistakes are made.

When the workload is not yours to own. A side project, a prototype, a monthly spike — renting the frontier at per-token rates is the cheapest honest choice, and dressing it in sovereignty is paying a premium for a story.

When the savings claim is the pitch. Any vendor whose sovereignty argument leads with a percentage is selling geography as discount; the numbers that hold are on the rate card, and the rate card does not need adjectives.

And when the organisation cannot pass the test of its own numbers. If nobody can name the actual monthly token spend, the input-output split, or the top three workloads by volume, then no infrastructure decision — sovereign or otherwise — is being made with arithmetic. Do the homework first; the economics of sovereignty reward exactly the people who did.

Five moves, in order. One: name the workloads and their volumes — without this, every vendor claim is unfalsifiable. Two: right-size first — route the cheap work to the cheap models, wherever they are served. Three: separate the sovereignty line item from the routing savings; a vendor that blends them is hiding one inside the other. Four: read only dated, sourced numbers, and price the workload, not the token. Five: compute the exit — what migration costs, and whether the stack has one built in.

Run those five and the economics answer itself: where sovereign is cheaper, where it costs more, and which of the two your workloads actually are. The companion pieces — the definition and the checklist — apply the same standard to this platform, gaps included.