TL;DR

  • RBI has proposed, but not yet finalized, draft guidance requiring human override, suspension, and kill-switch mechanisms for AI/ML models across all 11 categories of regulated entities, from Base-layer NBFCs to All-India FIs.
  • The comment window closed July 24, 2026. No effective date has been set as of this writing.
  • The draft’s core demand: named, qualified people must be able to pause, override, or deactivate a model in real time, and they must have the expertise to actually challenge model output rather than rubber-stamp it.
  • This closes the loop on the series. Stress testing, covered in the previous post, proves a model behaves under pressure. Human-in-the-loop governance proves someone can stop it if it doesn’t.
  • Maker-checker approval and immutable audit trails are the two control types that operationalize human-in-command. Neither requires a new department or a new workflow layer.

A collections model starts flagging borrowers it shouldn’t. A fraud model’s false-positive rate creeps up over a weekend and nobody notices until Monday. The model risk officer’s first question in a room like this is never “do we have a model inventory.” Every regulated entity has one of those by now. The real question is: who has the authority, right now, to pause this model, and can they prove it if a regulator asks.

Most institutions answer the first half confidently. Fewer can answer the second. A model inventory tells you what’s running. It does not tell you who can stop it, how fast, or whether that person actually understood the model well enough to make the call. That gap, between having a model and having a governed human relationship to it, is exactly what regulators have started naming directly.

Your Model Inventory Isn’t the Same as Your Kill Switch

RBI’s Department of Regulation proposed draft guidance around June 2026 that speaks directly to this gap. It would require human-in-the-loop AI banking compliance software and processes capable of overriding, suspending, or deactivating a model in real time, not just logging that a model exists.

It is important to be precise about status here: this is draft guidance. The comment period closed on July 24, 2026, and as of this writing, no effective date has been set. Institutions should treat it as a strong directional signal, not a compliance deadline with a fixed calendar.

What makes the draft consequential is its breadth. It is not aimed only at large, sophisticated banks running upper-layer NBFC operations. As proposed, it would apply across all 11 categories of RBI-regulated entities: commercial banks, small finance banks, payments banks, local area banks, regional rural banks, urban and rural co-operative banks, NBFCs across all four layers (Base, Middle, Upper, and Top), All-India Financial Institutions (EXIM Bank, NABARD, NaBFID, NHB, SIDBI), asset reconstruction companies, and credit information companies.

A Base-layer NBFC running a single collections scoring model would fall under the same expectation as a Top-layer NBFC running dozens of models across credit, fraud, and deposits. Scale doesn’t exempt an institution from needing a human who can act.

What Human-in-Command Actually Means in the Draft Text

Without citing a specific chapter or clause, since none has been confirmed publicly, the substance of the proposal centers on a few concrete obligations.

Human oversight has to extend to automated and model-driven decisions, not just to the initial approval of a model before deployment. The people exercising that oversight need the power to override a decision, pause a model, or switch it off entirely. And the draft is explicit that this oversight has to come from qualified staff who can genuinely challenge model output. A committee member who nods along at a monthly review does not meet that bar.

The draft describes override, suspension, or deactivation mechanisms, including kill-switch arrangements, for immediate intervention when a model malfunctions. It names three acceptable modes of oversight: human-in-the-loop, human-on-the-loop, or equivalent oversight mechanisms. That range matters. It means the requirement isn’t universal manual review of every single decision. It’s a spectrum, and an institution gets to choose where on that spectrum a given model class sits, provided the choice is documented and defensible.

All of this sits under a Board-approved Model Risk Management Framework, which can be delegated to a Risk Management Committee of the Board. The authority to pull a model out of production has to trace back to a board-level decision about how that authority is structured, not to an informal understanding among the data science team.

The Expertise Test Is the Part Most Institutions Will Fail First

Here’s the harder problem hiding inside the draft’s language. An override button means nothing if the person holding it doesn’t understand the model well enough to know when pressing it is the right call.

An override button nobody has been trained to use is not a control. It’s a compliance artifact. Regulators reviewing this framework will ask not just who has override authority but what that person would need to see in the model’s behavior to actually exercise it. If the honest answer is “they’d need someone from the data science team to explain what’s happening first,” the human-in-the-loop requirement isn’t met, regardless of what the org chart says.

This is where the series’ previous post becomes directly relevant: Stress Testing AI Models: What RBI Expects Before You Deploy. A model that hasn’t been stress-tested gives its human overseer nothing concrete to challenge output against. The overseer needs a documented baseline of how the model behaves under adverse conditions to recognize when current behavior has drifted outside it. Stress testing and human oversight aren’t two separate compliance line items. One produces the reference point the other needs to function.

Kill Switches Are a Workflow Requirement, Not a New Committee

The instinct many institutions will have is to stand up a new oversight function: a committee, a review board, a dedicated model risk desk. That instinct usually adds cost without adding the thing the draft actually asks for, which is demonstrable control.

Maker-checker approval, already standard in most regulated lending and collections workflows, is functionally a human-in-the-loop control. A named approver reviews a model-driven recommendation and authorizes it before it takes effect. What’s typically missing isn’t the human step. It’s the proof that the step happened, who performed it, and what they saw at the time.

That’s where an immutable audit trail earns its place. iTuring’s Model Governance module logs every maker-checker approval, every override, and every model version change in a record that can’t be edited after the fact and can be pulled on demand during an examination. The mechanism doesn’t require inventing a new department. It requires instrumenting the approval workflow that likely already exists so that override authority is logged, timestamped, and exportable.

No performance statistic is attached to this section, because none genuinely fits a governance and oversight requirement like this one. What matters here is the mechanism, not a metric.

What to Build Before the Rule Is Final, Not After

Draft guidance from RBI has a track record of becoming final with modest changes rather than disappearing. That’s a reasonable expectation for institutions to plan around, not a certainty, but waiting for a confirmed effective date before building override capability risks a retrofit under deadline pressure, which is a worse position than building early and adjusting to final clause language later.

A practical starting checklist, ahead of any final rule:

  • Name accountable individuals per model class now, not a generic “risk committee.” A specific person with the expertise to challenge that model’s output.
  • Wire override logging into the maker-checker flows that already exist, rather than building a parallel process.
  • Confirm the audit trail behind those approvals is immutable and exportable in a format an examiner can review directly.
  • Document the chain from model-level override authority up to Board-approved MRMF sign-off, including any delegation to a Risk Management Committee of the Board.

None of this requires waiting for RBI to finalize a date. All of it is buildable on infrastructure most regulated lenders already have in some form.

Four-step human-in-the-loop model shutdown process: anomaly detection, override authority review, model pause or deactivation, and recording the action in an immutable audit log.

If your override authority isn’t named, logged, and provable today, the time to fix that is before an examiner asks, not after. Request a Working Session with iTuring’s Model Governance team to see how maker-checker approval and immutable audit trails map onto your existing model inventory.