The Short Answer
A government gains AI capability without dependency by making three things non-negotiable before signing: the data stays on infrastructure the government controls, the underlying model can be swapped without rebuilding the system, and the source code is owned outright rather than licensed per user.
Karnataka's "Government First" position ā sovereign government data resides on servers within the state ā is the first of those three, applied at the moment it is cheapest to apply: as a precondition of entry rather than a clause to revisit later.
The other two matter just as much. A model you cannot replace and code you cannot read will constrain a government as firmly as an offshore data center.
Sovereignty is an architecture, not a hosting address ā the durable version is the one where you own all the code and the data, run any model, and deploy on infrastructure you control.
What did Karnataka actually demand from Anthropic?
On August 6, 2026, Karnataka Chief Minister D K Shivakumar met a delegation from Anthropic ā including Michael Sellitto, Chris Ciauri, Irina Ghose, Amlan Mohanty, and Samarth Masson ā to discuss a long-term partnership spanning governance, higher education, healthcare, research, and the state's startup ecosystem.
The reported use cases were unusually concrete for an exploratory meeting: detecting and reducing fraud in government systems, and hardening examination processes so question papers set by government agencies stay leak-proof.
But the operative detail was a restatement of existing policy.
Karnataka reiterated its "Government First" stance ā sovereign government data must reside on servers within the state ā and framed citizen data protection, privacy, and data sovereignty as the foundation for any deployment across government services.
Karnataka is India's ninth most populous state, projected at roughly 69 million people for 2026. A governance-wide AI deployment there is not a pilot.
It is population-scale public infrastructure, which is precisely why the sequencing of the data condition matters more than the size of the contract.
Why does data residency alone not make an AI deployment sovereign?
Data residency answers one question ā where do the bytes sit at rest ā and leaves three others open. A government can satisfy residency completely and still be unable to act independently.
Consider what residency does not cover. The model itself may be reachable only through an API the government does not operate. The application logic may be a binary the government's security team cannot read. The contract may reprice annually on a per-user basis.
None of that is fixed by keeping a disk inside a state border.
The pattern is familiar enough to name. A vendor demonstrates real capability. An agreement is signed with soft data-governance language. Data migrates to vendor infrastructure. Integrations accumulate.
By the time anyone prices an exit, the switching cost is structural rather than technical ā and the vendor sets the terms on pricing, model changes, and access.
Karnataka intervened at step one. That is the only step where intervention is cheap: preconditions cost nothing to state and everything to retrofit.
| What you control | Residency only | Full ownership |
|---|---|---|
| Where data sits at rest | ā In-jurisdiction | ā In-jurisdiction |
| Choice of underlying model | ā Vendor's catalog | ā Any model, swappable |
| Source code your team can audit | ā Opaque | ā Full source |
| Cost driver | ā Headcount | ā Actual usage or flat license |
| What survives the vendor leaving | The data | The whole system |
How much does government AI cost per seat versus usage-based?
Per-seat licensing is not one pricing option among several for a government. At public-sector headcounts it is the wrong shape, because the bill tracks the size of the payroll rather than the amount of work the AI actually does.
The arithmetic is unforgiving. Commercial per-seat AI runs roughly $30ā60 per user per month ā Microsoft Copilot at about $30, ChatGPT Enterprise around $60, Glean near $40. Multiply by a government workforce and the annual figure arrives before a single query has been asked.
| Government users | Per-seat @ $30/mo | Per-seat @ $60/mo | Usage-based @ ~$3/user/mo actual |
|---|---|---|---|
| 5,000 | $1.8M/yr | $3.6M/yr | $180K/yr |
| 50,000 | $18M/yr | $36M/yr | $1.8M/yr |
| 500,000 | $180M/yr | $360M/yr | $18M/yr |
The usage column assumes what deployment data consistently shows: most licensed users are light users. A per-seat contract charges the same for the clerk who runs four queries a month as for the analyst who runs four hundred.
Priced by consumption, that distribution is the point rather than the loss.
Self-hosting changes the shape again. Running open-weight models on infrastructure the government already owns converts a recurring per-user fee into a fixed cost ā the GPUs and the license ā that does not move when headcount does.
What architecture lets a government swap AI vendors without rebuilding?
Three properties, and a government can verify all three during procurement rather than discovering them during an exit.
Model-agnostic execution. The system treats the model as a configured dependency, not a hard-wired one.
Commercial models ā Claude, GPT, Gemini ā and open-weight models such as Llama, Qwen, DeepSeek, or Mistral run through the same interface, so replacing one is a configuration change rather than a migration.
Full source code ownership. The government holds the code under a perpetual license. Security teams read it, audit it, and modify it.
The practical test is blunt: if the vendor vanished tomorrow, the system keeps running because the government already has everything required to run it.
Deploy-anywhere packaging. The same stack installs into a government cloud, a private VPC, an on-premise data center, or a fully air-gapped enclave. Classification level becomes a deployment decision instead of a reason to run a separate procurement.
Karnataka's own stated use cases show why this is not academic. Fraud detection reaches into financial systems of record; examination security touches material whose leakage is a public scandal.
Neither is a workload a government wants mediated by infrastructure it cannot inspect.
Which questions should a government ask before signing an AI agreement?
Call it the Karnataka test. Five questions, each with a verifiable answer, all askable before money moves ā which is the only time the answers are cheap to change.
- If this vendor disappeared tomorrow, what still runs? If the answer is "nothing," the agreement is a dependency regardless of where the data sits.
- Can we change the underlying model without rebuilding integrations? A configuration change is sovereignty. A migration project is lock-in with better marketing.
- Can our own security team read the source code? Not a summary, not a whitepaper, not a certification ā the code.
- Does the bill scale with headcount, or with what we actually use? At 500,000 users the difference between the two is measured in hundreds of millions of dollars a year.
- Who holds the keys to data at rest, and who can revoke them? Residency without key custody is a location, not a control.
A vendor that answers all five cleanly is selling capability. A vendor that deflects on three is selling a relationship, and the exit price is being set right now, before anyone has thought to ask for it.
Is Karnataka's approach an outlier or a pattern?
It is a pattern, and the capital committed to it is no longer symbolic.
In July 2026, HCLTech signed an MoU with the Government of Odisha to build an AI data center inside a proposed Sovereign AI Park, in partnership with Sarvam AI ā an investment expected to exceed ā¹15,000 crore, with a planned capital outlay of roughly ā¹14,257 crore including state assistance.
HCLTech had taken a 10.5% stake in Sarvam AI for $150 million, and its Bhubaneswar technology center is slated to open by 2028 with an estimated 5,000 employees.
The stated purpose is the same one Karnataka is expressing in procurement terms: secure, scalable, indigenous digital infrastructure for government bodies, enterprises, research institutions, and startups.
Read together, the two are the same policy at different layers. Odisha is building sovereign capacity at the infrastructure layer. Karnataka is enforcing sovereignty at the contract layer. A government needs both, and only one of them can be bought quickly.
How does ibl.ai deploy sovereign AI for government agencies?
The ibl.ai platform is built for the answer Karnataka is reaching for: you own all the code and the data. Agencies receive the full source code under a perpetual license and run the platform on their own infrastructure ā government cloud, private VPC, on-premise, or fully air-gapped.
The platform is model-agnostic by construction. Commercial models and open-weight models run through the same interface, so an agency can move from a hosted frontier model to a locally-hosted one without rebuilding what sits on top.
Licensing is not per-seat, so cost tracks usage rather than payroll.
Security controls align to NIST 800-53, with PIV/CAC authentication, role-based access control, and complete audit trails suitable for oversight and public-records obligations.
Pre-built AI agents for government cover citizen services, compliance, procurement, and workforce training.
One more thing regulated and defense buyers tend to ask about directly: ibl.ai is family-owned and operated from New York, NY. Not VC-controlled, not foreign-owned ā a U.S.-headquartered partner whose incentives do not reset with the next funding round.
Further reading: the government AI deployment gap, AI cost math for government agencies, and sovereign AI alternatives to ChatGPT Gov and Claude Gov.