The RBI Wants a Kill Switch on AI. That Instinct Is Right.

This is what "you own the risk" has always required

The Reserve Bank of India released its Draft Guidance on Regulatory Principles for Model Risk Management in June 2026, with the comment period closing on 24 July 2026. It's still a draft, the final obligations may change before it's notified, and I'll say that again lower down because it matters. But the headline requirement has already got attention for the wrong reason: a mandatory kill switch, the ability to override, suspend, deactivate or decommission an AI model whenever the institution decides it has to.

Said like that, it sounds like a safety feature bolted on because someone is worried about AI going rogue. It isn't that. It's the RBI writing AI into the same accountability logic that already governs every other system a bank runs. If you can't turn off a system you're responsible for, you were never really responsible for it, you were just hoping. The draft is the first time that logic has been written down for AI/ML specifically, in India's banking rulebook, and I think the instinct behind it is correct.

Six requirements, in plain language, not eleven pages of circular text

The draft's coverage is broad. It reaches commercial banks, small finance banks, payments banks, local area banks, regional rural banks, urban and rural co-operative banks, NBFCs across every layer, All-India Financial Institutions, Asset Reconstruction Companies, and Credit Information Companies, roughly eleven categories of RBI-regulated entity in total. If your institution touches credit, deposits, or payments in India and it's using AI or ML anywhere in that chain, this draft is written with you in mind.

Stripped of the circular-speak, it asks for six things:

• A kill switch. The demonstrated ability to override, suspend, deactivate, or fully decommission any AI model in production, on demand.
• A board-approved Model Risk Management Framework. Not a policy document written for the auditor once a year, a live framework the board has actually signed off on.
• Documented human oversight. A named, accountable human in the loop for material AI-driven decisions, not "the system decided" as an acceptable answer.
• Explainability over black-box behaviour. The institution has to be able to explain how a model reached a material decision, not just report the output.
• Customer disclosure. Customers get told, plainly, when AI is being used in a decision that affects them.
• Third-party accountability. If the AI comes from a vendor, the regulated entity stays accountable for it. A vendor's own safety certification doesn't transfer the obligation away.

Easy when you own the system. Genuinely hard when you're renting it.

Here's the part I think gets missed in most of the commentary on this draft. Every one of those six requirements is straightforward to satisfy if your institution runs the AI system on infrastructure it controls, and can become genuinely difficult if the AI is a service you call over the internet and don't operate yourself.

Take the kill switch literally. You cannot instantly and completely deactivate a model that lives on someone else's servers, behind someone else's API, on someone else's schedule. You can stop calling it, which is not the same as decommissioning it, and it does nothing about the queries and outputs that already left your perimeter on the way there and back. Explainability runs into the same wall from a different angle. A frontier model called as a hosted API is, from the bank's side of the connection, a black box by construction, you send a prompt, you get an answer, and the reasoning in between is not something you can inspect, audit, or hand to an examiner. And the audit trail itself, the record of what the model was asked, what it returned, and when, often lives on the vendor's systems, under the vendor's retention policy, in a jurisdiction the regulated entity doesn't fully control. Third-party accountability under the draft says that arrangement doesn't get the institution off the hook. It just means the institution is accountable for a system it can't fully see into.

None of this is an argument against using AI. It's an argument that the deployment model you choose determines, upfront, whether compliance with a draft like this is a documentation exercise or an architecture problem you can't retrofit your way out of.

I've heard this exact tension in the room before, just about a different technology

Chairing FICCI's Multilingual Internet and Universal Acceptance Committee, and its Task Force before that, put me in conversations with regulators and large enterprises wrestling with the same underlying question the RBI's draft is now writing into rule: when you adopt a powerful new capability, does your institution retain the ability to control, explain, and if necessary stop it, or has that control quietly moved to whoever's infrastructure you're running on. That question came up about data localisation, about cloud adoption, and now it's coming up about AI specifically, and the RBI's kill-switch clause is, to me, the clearest sign yet that regulators have stopped treating "the vendor handles that" as a satisfying answer.

My own view, shaped by those FICCI-room conversations more than by this specific draft, is that AI in regulated sectors should be something an institution can own and answer for directly, not something it subscribes to and hopes turns out to have been compliant. That's not a claim that private or on-premise deployment automatically satisfies the RBI, or any regulator. A private deployment with no board framework, no documented oversight, and no real kill-switch procedure would fail this draft just as completely as a cloud one. What ownership of the infrastructure does is remove the structural excuses, the "we can't reach the internals," the "the audit log is on their servers," the "we can't fully switch it off." It leaves the institution with the harder, more honest work of actually building the governance the draft asks for, instead of discovering it can't.

This is the reasoning behind ZenithAI's architecture, not a reaction to it

We built ZenithAI to run on private cloud or on-premises infrastructure that the customer controls, specifically so that questions like these have straightforward answers instead of vendor-dependent ones. When a bank or NBFC owns the deployment, a kill switch is an operational procedure, not a support ticket to a third party. The model's behaviour, logs, and decision trail sit on infrastructure the institution's own auditors can walk into. Human oversight and disclosure are things the institution designs into its own workflow, not something it has to request from outside.

I want to be precise about what that does and doesn't mean, because this is a founder's reflection on where policy is heading, not legal advice, and owning your AI infrastructure is not the same thing as being compliant with the RBI's draft, or any regulation. Architecture removes the excuses and makes the six requirements achievable. It doesn't replace the board framework, the documented oversight procedures, or the actual discipline of using the kill switch when it's needed. That work still has to be done, by the institution, on top of whatever it's built on. But it's a great deal easier to do that work honestly on a system you can see all the way through than on one you're calling over the internet and hoping explains itself when an examiner asks.

If your institution is one of the roughly eleven categories this draft reaches, it's worth reading what RBI's 2026 AI rules ask of your AI stack in more technical detail, and running a free RBI AI readiness checklist against whatever you've already deployed, before the draft becomes final rather than after.

Frequently asked