Sovereignty & Data Residency
Can Your AI Survive a Foreign Vendor Cut-Off?
· 9 minute read
The fear buyers will not put in the minutes is simple: what if the foreign vendor is told to stop serving us on a Monday morning.
On a quiet Monday a cloud account can be frozen, an API key revoked, or an export licence reinterpreted. None of those events needs a war. They need a policy change in another capital, a sanctions list update, a terms-of-use refresh, or a vendor risk committee that does not have your minister's phone number.
Indian public institutions already treat this seriously for payments, identity and maps. They treat it casually for AI because the category still feels optional. It will not feel optional the week a citizen-facing agent is the front door of a scheme, a campus, or a grievance clock.
The fear is rarely written into the minutes. Officers worry it sounds political. It is not political. It is a single-point-of-failure analysis of the kind every CISO already knows how to run on a core switch. Run it on the model.
The cut-off paths that are already real
You do not need a hypothetical. These paths already happen to commercial customers. Public institutions are not exempt from them. They are only slower to write them down.
- Commercial: unpaid invoice, disputed overage, or a vendor exiting the India public-sector segment because the sales cycle was too long.
- Contractual: a click-through acceptable-use rule that bans government use, law-enforcement use, or a newly defined high-risk use after a model update.
- Jurisdictional: the vendor becomes unable to serve your department because of export control, a parent-company order, or a sanctions overlay.
- Operational: the only people who can restore the system sit in another time zone and another legal entity. The runbook is a Slack channel you cannot join.
- Technical: a licence server, feature flag, or token-signing service that must be reached on the public internet, even though inference was sold as on-prem.
Notice that three of the five paths do not require hostility. They require a product manager. Continuity planning that only imagines a geopolitical crisis will miss the more likely failure: a terms update on a Friday night.
A continuity test you can run this month
- Name the model, the runtime, the vector store, the identity provider and the licence or billing plane.
- For each, write the legal entity and the country that can compel that entity or shut the service.
- Assume that entity stops service with 24 hours' notice. No negotiation. No exception for government.
- Write the first 72 hours: who restores inference, who freezes writes, who tells the public, who tells the minister.
- Name the slower local model you will fall back to, and the last date you actually loaded it.
- If the answer is we would wait for the vendor, you do not have a continuity plan. You have a hope.
Do this on paper first. Then do it once on staging with outbound internet disabled and the vendor account frozen. The second test is the only one that counts. Officers who have watched a restore fail in a conference room stop treating this as theory.
What actually survives
Weights you can load without a licence server. Checkpoints you can hash. Prompts and evals in your repo. Connectors whose credentials you rotate. An SI or an internal team that has already done a failover drill. Object storage you control. A second GPU node that is not in the same administrative domain as the first.
DPIIT recognition and an Indian contracting entity help with procurement and with serving notice. They do not boot a GPU. An India region of a foreign cloud does not boot if the control plane is dark. A beautifully fine-tuned adapter does not boot if it only loads inside the vendor's registry.
What does not survive, even if it felt local
- Any feature that phones home for a licence check every few hours.
- A vector database whose only supported restore path is the vendor's SaaS console.
- Fine-tunes that cannot be exported as raw weights.
- Runbooks that assume the original vendor's engineers are on the bridge.
- Data you never copied out of the vendor's eval or logging tenant.
How to write this into the contract
Continuity that lives only in a slide will lose to price. Put it in eligibility and in the statement of work.
- A named failover model, already loaded in staging, with a measured quality drop the department accepts.
- A quarterly restore drill, minuted, with the vendor's SaaS control plane treated as unavailable.
- Escrow or quarterly export of adapters, prompts, evals and infrastructure-as-code.
- A clause that a licence-server outage or terms change that blocks government use is a material breach, with a right to keep running exported artefacts.
- A 72-hour communications plan that does not depend on the vendor's status page.
Ask the vendor to survive the Monday-morning test on paper. Then ask them to do it once on your staging rack before go-live. Anything less is a speech. Speeches do not answer 40,000 applicants.
The difference between lock-in and cut-off
Lock-in is expensive. Cut-off is dark. Institutions mix them because both feel like vendor power. They are not the same failure. Lock-in means switching costs are high: you can leave, it will hurt. Cut-off means you cannot run, even if you are willing to pay. Continuity planning that only negotiates price is planning for the wrong Monday.
You can live with some lock-in if exit artefacts exist. You cannot live with cut-off on a scholarship window, a grievance clock, or a hospital discharge desk. Write which workflows are cut-off intolerant. Those workflows cannot have a foreign licence server on the critical path. Other workflows can take more risk if the file says so.
A tabletop that is not [theatre](/blog/sovereignty-theatre-how-to-spot-it)
Invite the vendor, the SI, the CISO, the application owner and the person who writes the public note. Hand them a card: your API keys return 403, your status page is unreachable, your India sales lead is on a flight. You have 90 minutes. They must produce a running local inference path or a citizen-facing message the secretary will sign.
Time it. Record who spoke, who waited, and which artefact was missing. If the missing artefact is weights, you have a cut-off problem. If the missing artefact is a communications template, you have a process problem. Both are cheaper to find in a conference room than on day four of a scheme.
What to fund instead of another demo
A second GPU node in a second administrative domain. A hashed copy of weights in object storage you control. A quarterly restore that treats the vendor as absent. A public-status template that does not mention the vendor's brand. These are unglamorous line items. They are the difference between a programme and a dependency.
If the finance department asks why a second node is needed when the first is idle, show them the 72-hour card. Idle capacity is not waste when the alternative is a dark portal. It is insurance with a serial number.
Ninety days to a cut-off-tolerant critical path
Day 1: list workflows that cannot go dark for 72 hours. Scholarships, grievance clocks, hospital desks, treasury assistants usually belong here. Career chatbots usually do not. Honesty about which is which saves money.
Day 15: inventory every dependency on the critical path, including licence daemons and feature flags. Day 30: load a slower local model and measure the quality drop the process owner will accept. Write the drop down. Unwritten quality expectations are how fallbacks get rejected in a crisis.
Day 45: run the 90-minute tabletop with the vendor treated as unreachable. Day 60: fix whatever failed. Day 75: run it again. Day 90: put the surviving fallback and the communications template into the statement of work as go-live criteria.
If finance blocks the second GPU node, show them the list from day 1. Idle capacity on a cut-off-intolerant path is insurance. Insurance is cheaper than a press note that says the portal is down because a foreign key expired.
Objections you will hear — and what to do with them
Vendors will say cut-off is a political hypothetical. Terms updates, unpaid invoices and exited product lines are not political. They are ordinary. Design for ordinary.
Finance will reject idle GPUs. Show the 72-hour card and the list of cut-off-intolerant workflows. If they still reject, get the rejection in writing next to the residual risk. Silent rejection becomes your problem later.
SIs will say they can restore from their runbook. Their runbook that assumes their engineers are on the bridge is not your restore. Watch them do it with the vendor account frozen.
Someone will propose multi-vendor SaaS as the answer to cut-off. Two foreign keys are two cut-off paths. Multi-vendor helps lock-in. Local weights help cut-off. Do not confuse the two.
Communications will not want a public template that admits the portal can go dark. Write one anyway. You will need it on a Monday. Drafting it on that Monday is how you get a bad paragraph on a good department.
Questions this usually raises
- Is this only a defence-ministry problem?
- No. Any workflow that cannot pause for a week — scholarships, grievance clocks, hospital claims, treasury — has the same continuity duty. The legal hook may differ. The outage does not.
- Does an Indian contracting entity remove cut-off risk?
- It helps with service of process and payment. It does not boot a GPU if the model, the licence server or the control plane still lives with a foreign parent.
- What is the minimum acceptable failover?
- A second model you already run, on hardware you already control, with a restore you have rehearsed, even if it is slower and answers fewer questions. A paper plan is not a failover.