Perspectives · Founder note
Sovereign AI is a procurement question, not a GPU question
Sovereign AI is usually discussed as a question of hardware: whose GPUs, in which country. For a public body or a regulated enterprise, the harder questions are contractual. Can you name every component, move it, replace it and prove what it did?
- Author
- M. K. Elango · Founder, elan1
- Published
- Reading time
- 3 min read
When a ministry or a state-owned bank asks for sovereign AI, the first conversation is usually about data centres. Is the hardware in India? Is the cloud provider Indian? Those questions matter, and they are the easy part. Capacity in the country is growing quickly. What remains scarce is an AI stack whose every part can be named in a contract.
Four questions procurement should ask
- Where does each component run, and where does each piece of data rest and travel?
- Which components could be replaced, and how long would it take?
- Who signs off a replacement, and how is it proven to behave the same?
- Can an auditor verify what the system did without asking the vendor?
A system that keeps data in the country but depends on a single proprietary model, vector store or gateway is resident, not sovereign. If that component's licence changes, its price triples or its vendor exits the market, you have no exit either.
Contracts that outlive components
elan1 Run is built around that problem. It puts the AI stack behind 10 versioned capability contracts, for things like model serving, retrieval and storage. Each contract has at least 2 open-source implementations, so no single vendor is load-bearing.
A component swap is proven, not promised. A test suite your auditor can run offline checks the replacement on your exact setup. The replacement then shadows real traffic, 2 named people sign it off, and the swap leaves a permanent record.
Residency is necessary, not sufficient
Data residency still matters, and elan1 offers India residency in AWS Mumbai today. For public bodies with stricter needs, elan1 Run is designed to run on infrastructure you name, including government and sovereign clouds operated by partners. But a procurement file that ends at "data in India" has answered one of the four questions.
What to put in the tender
If you are writing a tender for AI in a public body, the most useful clauses are short:
- A component register, kept current, naming every part of the stack and where it runs.
- An exit plan for each component, with a tested alternative.
- A swap procedure with named sign-off and an auditable record.
- Offline verification of the action record, without vendor involvement.
Hardware decides where AI runs. Contracts decide who it answers to. For public services, the second question is the one citizens will eventually ask.
Key takeaways
- Residency answers where data sits; sovereignty also needs the ability to name, replace and audit every component.
- elan1 Run puts the stack behind 10 versioned contracts, each with at least 2 open-source implementations.
- Tenders should ask for a component register, exit plans, a signed swap procedure and offline-verifiable records.
Product capabilities named here carry their current status (available, in pilot or designed) on each product page and in Trust and security. Figures marked “Design target” are specifications, not measurements.
About the author
M. K. Elango
Founder, elan1
M. K. Elango founded elan1 in Chennai to put AI agents to work inside regulated businesses, with a named person answerable for every action that commits them. He writes about pricing, approvals and what it takes for an auditor to trust an agent.
Meet the leadership team : M. K. Elango
