In June 2026 the Reserve Bank of India put out its Draft Guidance on Regulatory Principles for Model Risk Management — and, for the first time, wrote artificial intelligence squarely into the rulebook for banks and NBFCs. Its message to every regulated entity is direct: you may use AI, but you must be able to explain it, oversee it, audit it, and switch it off. For institutions still deciding how to adopt generative AI, the draft quietly answers a bigger question — not whether to use AI, but on whose terms.
A note before we begin: this is an architecture discussion, not legal or regulatory advice. The guidance is a draft (issued June 2026; stakeholder comments closed 24 July 2026), and the final obligations may change. Work through what applies to you with your risk and compliance teams.
What the RBI draft actually asks for
The draft would require every regulated entity — commercial banks, small finance and payments banks, co-operative and regional rural banks, NBFCs and more — to run its models, AI included, inside a governed framework. The provisions that matter most for anyone deploying generative AI:
- A kill switch. Every AI system must be capable of being overridden, suspended or deactivated through “kill-switch arrangements” — and models must be decommissioned in a controlled way.
- A board-approved Model Risk Management Framework. Covering governance, model tiering, inventory, documentation, validation, approvals, monitoring, change management, business continuity and decommissioning — with the board and its Risk Management Committee accountable for high-risk models.
- Human oversight. Documented human oversight of AI-driven decisions, so a person — not a model alone — carries the consequential call.
- Explainability, not black boxes. Models must be explainable, with control boundaries to contain the risks of generative AI, hallucinations included.
- Customer disclosure. Entities should disclose when AI is being used in interactions with customers.
- Third-party accountability. Risk management extends to third-party and vendor AI — the regulated entity stays accountable no matter whose model is doing the work.
Turning this into a review? We mapped all six principles into a free, tickable RBI AI readiness checklist you can take into your next model-risk meeting.
The draft doesn’t ask whether your AI is clever. It asks whether you can prove what it did, and stop it if you must.
Why the default cloud-AI setup fights these principles
Read the requirements together and a pattern appears: each one is easy to satisfy when you control the system, and hard when you don’t. The common way institutions have adopted generative AI — a subscription to a public cloud AI service — sits on the wrong side of that line:
- You can’t truly switch off a service you don’t run; you can cancel a contract, not pull a lever inside your own boundary.
- A frontier model behind an API is close to a black box — hard to explain to a validator, harder to bound.
- The audit trail of who accessed what, and what left the building, lives on the provider’s systems, not yours.
- And every prompt handed to an outside service is a third-party processing event you must now account for — the very surface the draft tells you to manage down.
None of this makes public AI unusable. It means that for the regulated core — credit files, KYC, board papers, customer data — the architecture has to change if the paperwork is going to add up.
How a private, governed deployment supports each principle
A privately deployed platform doesn’t rewrite the regulation; it puts the controls the regulation asks for on your side of the boundary. Mapping ZenithAI’s architecture to the draft’s principles:
- Kill switch & decommissioning — ZenithAI runs inside your own infrastructure, and its outward-reaching modules are individually switchable. The deployment is yours to suspend, restrict or shut down; you don’t raise a ticket with a vendor to stop it.
- Human oversight — consequential actions (sending an email, placing a call) require an explicit, contemporaneous human confirmation. The assistant proposes; a person decides. See security & governance.
- Explainability, not a black box — answers cite the exact source page they came from, and figures are computed in a hardened sandbox and badged “✓ Computed”, not guessed. A validator sees the basis for an output, not just the output. More in our enterprise deployment guide.
- Audit trail & monitoring — a fail-closed privileged-access audit ledger and egress logging with redaction give you a reviewable record of who accessed what and what crossed the boundary.
- Third-party accountability — the core platform runs open-weight models on your hardware, with no proprietary model vendor in the loop for the core reasoning. That shrinks the third-party surface the draft asks you to govern in the first place.
- Customer disclosure & data control — because organisational data and the models reasoning over it stay inside your environment, what is used and disclosed remains your decision to document, not a provider’s.
Be precise about what this means. ZenithAI’s architecture supports the principles the draft describes — it shrinks the surface your model-risk framework has to cover and puts the evidence under your control. It is not a compliance product, and no platform makes a bank “RBI compliant” by itself: your board-approved framework, model inventory, validation, tiering and disclosures still do that work. This is the same posture we take on the DPDP Act — architecture that supports obligations, not a certificate that discharges them.
A checklist for your next model-risk review
Whether you build, buy or subscribe, the draft turns a handful of questions into board-level ones. Take these into your next review of any AI system:
- Can we suspend or switch off this AI from inside our own environment — today, without a third party?
- Can we explain a given output to a validator — the source, the computation, the reasoning?
- Is there a human decision before any consequential action the AI proposes?
- Can we produce an audit trail of access and data movement ourselves, on demand?
- How much of this depends on a third party we’d have to hold accountable — and can we reduce it?
Where the answers depend on a provider’s assurances, note them as residual risk; where they depend on your own infrastructure, note them as evidence. That one exercise usually makes the architectural conversation with your board very short.
Want the full version? We turned this into a free, printable RBI AI readiness checklist: seven sections, tickable, no form in the way. Get the checklist →
Where to take it
The institutions that adopt AI well under this regime won’t be the ones that move fastest — they’ll be the ones that can answer for it. If you’re weighing how to bring generative AI to a bank or NBFC on the regulator’s terms, request a demonstration and bring your risk and IT teams. See also how ZenithAI is built for banking and other regulated sectors, and why the same controls make the case for sovereign AI at the institutional level.