Why a test, and why now
Indian enterprises spent the last three years buying AI: subscriptions, copilots, pilots. That was the right first step. The next step is putting AI inside the processes that carry money, identity and risk: KYC, claims, grievances, maintenance, mission operations. That is where the question changes from “does it work?” to “can we prove what it did?”
The regulators have already moved. The DPDP Rules phase in through May 2027, the RBI's FREE-AI framework asks banks for AI policies, inventories and audits, and MeitY's governance guidelines put accountability with the deployer. None of them asks whether your AI is clever. All of them ask whether you can show your work.
The six questions below are how I think about it. They are deliberately vendor-neutral. Use them on us, on anyone else, and on your own teams.
The six questions
For each: the answer that means you are still consuming, the answer that means you are building, and the evidence to ask for.
1 · Where does the data run?
Consuming: “In a region near you, per the contract.” Building: region, cloud and keys you can inspect, with every outbound hop declared and logged. Ask for: the network egress list, the key custody arrangement, and where prompts, logs and embeddings are stored.
2 · Which model made that decision?
Consuming: “The AI.” Building: the exact model, version and configuration on record for any decision, with its lineage, evaluation history and an approver. Ask for: the record behind one real decision from last week.
3 · What did the model actually see?
Consuming: the raw customer record. Building: the masked form, provably, with sensitive fields tokenised or redacted before any model, tool or embedding service read them. Ask for: the stored input of one real call.
4 · What stops the agent doing harm?
Consuming: a prompt that asks the model to behave. Building: a policy outside the model that blocks what must never happen, however the request is phrased. Ask for: one thing the system must never do, and show it being blocked.
5 · Who approved the consequential step?
Consuming: “The system.” Building: a named person, with the time, the context they saw and the policy that required them. Ask for: the approver of one real high-impact action.
6 · What will you show the regulator?
Consuming: a screenshot and a slide. Building: a signed record an outsider can verify without trusting the vendor or your IT team. Ask for: an export an auditor could check on their own.
How to run it in an hour
Pick one workflow a regulator already cares about. Not a sandbox. A real one: a grievance queue, a KYC exception, a maintenance work order, an operations log.
Put four people in the room: the process owner, the engineer who built it, someone from risk or compliance, and the vendor. Ask the six questions about one specific decision the system made last week, not about the system in general.
Score each answer as a record or an assurance. A record is something someone can open and check. An assurance is a sentence. Six records means you are building. Any assurance marks exactly where the work is.
What the answers usually look like
Still consuming
A vendor's word about where the data runs. A model version that lives in an engineer's memory. Raw customer records reaching the model. A system prompt as the safety plan. “The system” as the approver. A screenshot for the regulator.
None of this means the team did anything wrong. It means the system was built for a pilot and is being asked to carry a core process.
Building
Region, cloud and keys you can inspect. Version, lineage, evaluation and approver on record. The masked form, provably. A policy outside the model. A named person with a signed record. A receipt an outsider can verify.
Systems that answer all six were designed that way. It is very hard to add these properties after the fact.
Red flags to listen for
“It's hosted in India” as the whole answer to question one. Residency is necessary, not sufficient: who holds the keys, who can push an update, and where the logs go matter as much.
“We have guardrails” without being able to show one blocking something. A guardrail that lives inside the prompt is a request, not a control.
“Human in the loop” when the human is a reviewer of a sample, not the approver of the action. Ask who approved this specific step.
“We can export logs” when the logs are editable by the same team that runs the system. A record that the operator can change is not evidence.
How we answer it
We built AgentAnywhere so that all six are answered by construction: models registered with owners and lineage in Model Hub, sensitive data masked at the perimeter by Veil, policy enforced outside the model at the gateway, a named human on consequential steps, and a signed Trust Receipt for every call, running in your cloud or air-gapped with Swaraj. That is one way to pass the test. The test itself does not depend on whose product you use.
If you want a second pair of eyes, book a one-hour sovereignty review. Bring one workflow; we will run the six questions on it with you and leave you the scorecard.
Frequently asked questions
What is the sovereignty test for AI?
Six questions that show whether an organisation controls its AI or rents it: where does the data run, which model made the decision, what did the model actually see, what stops the agent doing harm, who approved the consequential step, and what will you show the regulator. Each must be answered from a record, not from a vendor's assurance.
What questions should I ask an AI vendor before deployment?
Ask for records, not promises: the network egress list and key custody; the model and version behind one real decision; the stored input for one real call, to see whether sensitive data was masked; a demonstration of a policy blocking a forbidden action; the named approver of one high-impact step; and an audit export an outsider can verify.
Is hosting AI in India enough for sovereignty?
No. Residency is necessary but not sufficient. Sovereignty also requires control of the keys, of updates to the model and software, of where logs, prompts and embeddings are stored, and a verifiable record of what the system did.
How long does it take to run the sovereignty test?
About an hour for one workflow, with the process owner, the engineer who built it, someone from risk or compliance, and the vendor in the room, asking the six questions about one specific decision the system made recently.
Written by
Siddhartha Chandurkar
Founder, ShepHertz Technologies
Siddhartha Chandurkar writes for AgentAnywhere, the sovereign AI platform built by ShepHertz Technologies, which has put AI into production since 2012.
