The durable advantage in banking AI lies in governed data and portable workflow architecture. Selecting a foundation-model supplier matters, but it is not an adequate sovereignty strategy. A bank must control where sensitive information travels, who can inspect it, how model outputs enter decisions and how the institution changes suppliers without rebuilding its operating model.
This report merges two historical banking-AI briefs. Supplier, employer and personal names have been removed. Unsupported aggregate budgets and universal break-even ranges have been removed from the current edition; the institutional control analysis is retained. The original call is preserved: banks that maintain model choice and own their governed data layer are better placed across different outcomes in the model market.
The India policy update
MeitY’s parliamentary reply of 25 March 2026 records a ₹10,372 crore IndiaAI Mission outlay, more than 38,000 GPUs onboarded to the common compute facility, and 190 approved projects. These are dated programme observations, not evidence of October utilisation or measured productivity. An earlier announcement of 20,000 additional GPUs was an expansion commitment; this article does not silently count it as delivered capacity.
For a bank or public institution, access to subsidised compute can lower entry costs but does not settle control over data, models or consequential actions. The September 24 RBI address on resilient banking places technology, cyber security and AI within banking trust. The practical interpretation here is that procurement must join capability with accountability: a named owner, explicit permissions, independent tests and the ability to stop or replace the service.
The DPDP Rules 2025 use phased commencement. A notification date alone does not make every clause immediately effective. This article does not turn the rules into a blanket claim that all AI processing must occur on domestic servers; the applicable obligation depends on the actual data, activity and effective provision.
Sovereignty has several boundaries
Sovereignty boundaries overlap without being interchangeable
| Aspect | Retained observation |
|---|---|
| Data residency | Data residency asks where information is stored and processed. |
| Operational control | Operational control asks who can administer the system, inspect logs or access encryption keys. |
| Legal control | Legal control asks which jurisdictions can compel action from the supplier. |
| Model control | Model control asks whether the buyer can inspect, adapt, host or replace the model. |
These boundaries overlap but do not coincide.
A model hosted inside a country’s borders can still depend on remote support, a foreign control plane or an external service needed during an incident. Conversely, a tightly governed hosted service can be appropriate for a low-sensitivity workload without requiring the institution to own model weights. The architecture should follow the information and decision risk rather than a single marketing label.
The historical materials therefore described sovereignty as a workload-level decision. An internal policy search tool, a developer assistant and a customer-facing credit decision do not have identical requirements. A bank should not use the most restrictive deployment for every task, but it also should not allow a low-risk pilot to establish the default for consequential decisions.
Figure 01 · Qualitative comparison
Four boundaries of sovereign AI
| Boundary | Question | Evidence to request |
|---|---|---|
| Data residency | Where is data stored and processed? | Documented locations and subprocessors |
| Operational control | Who can administer systems and keys? | Access policies and audit evidence |
| Legal control | Which jurisdictions can compel the supplier? | Contract and legal assessment |
| Model control | Can the institution inspect, adapt or replace it? | Licences, export and portability tests |
Five layers need explicit ownership
Ownership across five layers keeps information and action controlled
| Layer | What the institution must control | Failure if ownership is unclear |
|---|---|---|
| Data | Entitlements, provenance, retention and permitted use | Restricted information enters an unauthorised workflow |
| Retrieval | Corpus selection, freshness and access filtering | A correct-looking answer cites the wrong policy or customer |
| Model | Evaluation, version choice and substitution | A provider update changes behaviour without approval |
| Orchestration | Routing, tool permissions and action limits | A text generator acquires unintended authority |
| Monitoring | Outcome evidence, incidents and rollback | Failures persist without an accountable owner |
The data layer is especially important. Curated internal material contains the institution’s policies, decisions and operating knowledge. Its value depends on quality and rights, not simply volume. If a bank cannot distinguish approved policy from a superseded draft, a more capable model may reproduce the ambiguity more fluently.
Data preparation should include document ownership, effective dates, access restrictions and a process for correction. These are recurring operating responsibilities. They cannot be completed once during a pilot and then left unchanged while the institution’s products and obligations evolve.
Retrieval is useful, but it does not remove model risk
Retrieval-augmented generation supplies relevant material to a model before it answers. It can improve specificity and provide evidence. It does not guarantee that the retrieved material is correct, that the model has interpreted it properly or that the user is authorised to see every fragment.
Access filtering should happen before retrieval results reach the model. A final display filter is insufficient if restricted text has already entered a prompt or log. Search relevance also needs to be evaluated against task success: finding a document containing similar words is different from locating the governing rule.
Evaluation should include obsolete policies, contradictory documents, missing information and misleading instructions embedded in retrieved content. The system should be able to say that the evidence is insufficient. A forced answer can be more damaging than a failed retrieval because it creates unwarranted confidence.
For consequential workflows, retain the evidence used, the model version, the prompt or instruction version and the human decision. The purpose is to reconstruct why an outcome occurred. A transcript alone may not preserve the exact documents or tool responses that shaped the answer.
Open models and hosted models have different economics
Hosted models offer a low fixed-cost entry point and access to external development. Self-hosting can improve control and potentially lower unit cost at sustained scale, but it adds infrastructure, engineering, evaluation and operating responsibilities. The economic comparison must include those responsibilities.
The old one-to-two-billion-token threshold is withdrawn as a current procurement rule. Model quality, accelerator type, batching, latency, redundancy and staffing must be specified before a comparable break-even calculation is possible.
Let be monthly token volume, the effective hosted cost per token, the fixed monthly self-hosting cost and the variable self-hosting cost per token. A simplified break-even volume is
provided . This calculation omits quality differences and the cost of failed tasks. If a cheaper model requires more retries or human correction, token cost can fall while completed-work cost rises.
The useful unit is therefore cost per accepted outcome. Include retrieval, inference, tool execution, monitoring, human review and rework. For a coding assistant, measure accepted changes and downstream defects. For document processing, measure correctly completed cases. For research support, measure whether the output is accurate and usable, rather than counting generated words.
Figure 02 · Conceptual framework
From governed data to accountable action
How the parts connect
- Authorised datafilter firstGoverned retrieval
- Governed retrievalevidenceModel proposal
- Model proposalproposalValidation and approval
- Validation and approvalauthorisedControlled execution
- Validation and approvalexceptionAudit and exception
- Controlled executionrecord outcomeAudit and exception
Diversification should be engineered
A bank can sign contracts with several suppliers and still be dependent on one. Prompts, output schemas, embedding formats, tool interfaces and evaluation methods can create switching costs. Portability requires deliberate separation between the business workflow and supplier-specific adapters.
The orchestration layer should route tasks according to sensitivity, quality, latency and cost. It should also support a controlled fallback. A fallback model may have different capabilities, so switching should not silently expand the set of actions it can perform. Some workflows should degrade to human review when the preferred model is unavailable.
Avoid unnecessary abstraction. If every feature is restricted to the lowest common denominator across all providers, portability can destroy useful capability. The better approach is a stable core interface with explicit extensions and documented dependence. This makes the cost of substitution visible rather than pretending it is zero.
The historical outlook expected several model families to coexist: frontier reasoning services, private-deployment specialists, open-weight models and narrow task models. The argument was about an adaptable portfolio of capabilities, not a prediction that every bank should use every category.
Governance is part of the production architecture
A model should not receive authority merely because it can produce a plausible tool call. Separate recommendation, validation, approval and execution. Typed interfaces, parameter checks, transaction limits and entitlements should enforce the permitted action independently of the model’s prose.
For example, an assistant may draft a client-service response using approved information. Sending the message, changing an account setting or initiating a payment are separate actions with separate permissions. The system should record who approved an action and what evidence supported it.
Model evaluation should be repeated when the model, retrieval corpus, prompt, tool schema or policy changes. A successful initial evaluation does not establish that a later configuration is safe or effective. Release management needs rollback and a comparison set that captures meaningful business failure modes.
Security testing should include prompt injection, data leakage, excessive tool permissions and attempts to induce unsupported conclusions. Controls should be tested as a chain. A strong model safety layer cannot compensate for an unrestricted database credential supplied to an agent.
Public capability is wider than a compute purchase
The historical briefs’ 55–70% compute allocation and 8–15% banking technology-budget estimates lacked a consistent accounting boundary. They are excluded from this current edition. Public procurement should instead disclose the full lifecycle budget: data preparation, inference and storage, network/energy, integration, security testing, human review, support and exit.
India’s industrial-policy objective can be tested through capability additionality. Does public support make a useful task affordable for an eligible buyer who could not otherwise execute it? Does the programme create portable data and evaluation assets? Can a small institution switch suppliers without losing its records or service continuity? These outcomes are more informative than counting a GPU twice across a vendor announcement and a public pool.
A procurement scorecard should distinguish allocated hardware, actually accessible capacity, consumed accelerator-hours and accepted service outcomes. Subsidy per accelerator-hour and subsidy per correct completed task are different measures. Publishing both would reveal whether cheap compute is reaching productive uses or simply lowering the cost of poorly specified experiments.
Figure 03 · Conceptual framework
Supplier choice has to survive an exit test
How the parts connect
- Institutional workflowstable contractSupplier adapter
- Supplier adapterrouteCurrent model
- Supplier adaptersubstituteAlternative model
- Current modelbaselineExit rehearsal
- Alternative modelcandidateExit rehearsal
- Exit rehearsaldocument resultsProcurement evidence
A staged implementation decision
Begin with a bounded task whose result can be checked. Establish a baseline using the existing workflow, including error rates, elapsed time and human effort. Select data that can be used lawfully and operationally. Define the failure conditions that require escalation.
Pilot with real variation rather than only ideal examples. Include missing data, ambiguous requests, outdated policies and high-load periods. Compare the AI workflow with the baseline using accepted outcomes, not merely speed. Record who performs the extra checking that makes a pilot appear successful.
Production approval should require a named owner, operating support, evidence retention, a release process and an exit path. Expansion should follow demonstrated performance in the next workload or jurisdiction. A successful internal drafting tool does not automatically validate an autonomous customer-facing agent.
Review the portfolio periodically. A previously expensive model may become economical; a private model may become inadequate; a new policy may change permitted data flows. The architecture should allow these changes without forcing a complete redesign.
Procurement evidence should survive the pilot team
Require a record of the evaluated model, data permissions, task population, failure cases and accepted outcome measures. A later operating team should be able to understand why the system was approved without relying on the memory of its original sponsor. Include support responsibilities and the procedure for changing providers. This evidence is especially useful when an enthusiastic pilot expands into several business units: the original permission and quality boundary should remain visible as scope changes.
What remains defensible as the market changes
Ownership of evaluation datasets also matters: a supplier change should not erase the institution’s ability to compare accepted outcomes consistently.
The historical forecasts about individual suppliers have been converted into anonymous scenarios rather than disguised as current winners. A regional model specialist could achieve durable scale, remain a useful regulated-workload niche or consolidate into a larger platform. A closed-model leader could retain superior capability while losing pricing power. Open models could reduce inference cost while increasing the buyer’s operating burden.
Across those scenarios, governed data, reproducible evaluation and controlled orchestration retain value. They let the institution benefit from model progress without surrendering the ability to change direction. That is the substantive meaning of sovereignty in the banking working environment: the bank can explain, govern and replace the components through which information becomes action.
Source record and update scope
MeitY / PIB — IndiaAI ₹10,372 crore; >38,000 GPUs; 190 approved projects, dated programme figures. Observation/publication: 2026-03-25. Verified primary source; observed date stated.
Reserve Bank of India — Banking trust framing verified; article procurement interpretation is analysis. Observation/publication: 2026-09-24. Verified primary source; observed date stated.
MeitY — Rules have phased commencement, not wholesale immediate operation. Observation/publication: 2025-11-13. Verified primary source; observed date stated.
