What RBI's draft model-risk guidance asks of an AI agent

What the draft is

The draft Guidance on Regulatory Principles for Model Risk Management, 2026  (opens rbi.org.in, external site) was issued for public consultation on 24 June 2026. It is proposed to apply across regulated entities, from banks to NBFCs in every layer, and to replace the chapter on credit-risk models in the RBI's 2002 guidance note on credit risk management. It is a draft: the final text may change, and nothing in it applies until the RBI issues it.

Its definition of a model is broad. Any system that takes inputs, applies processing logic and produces outputs that materially affect decisions counts, whether or not the entity calls it a model. A spreadsheet that sets loan pricing is in scope. So is an AI agent that scores an alert or drafts a disposition.

What it asks

• A board-approved framework: a model risk management framework approved by the board and covering AI and ML models, with high-risk models approved by the board's risk management committee.
• An inventory and tiers: a living inventory of every model in use, each placed in a risk tier that sets how closely it is watched.
• Independent validation: every model validated independently of the people who built it, including models bought from a vendor, whatever certificate the vendor holds. Outsourcing a model does not outsource its risk.
• Human oversight: human-in-the-loop or on-the-loop arrangements, the ability to override or suspend a model, a kill switch, and periodic human review of AI-driven decisions. The draft names automation bias and reviewer fatigue as risks in their own right.
• Explainability where it matters: credit underwriting is treated as material, so explanations are held to a higher bar. Where a model cannot be fully explained, the draft asks for compensating controls, such as more validation, output checks, closer monitoring and limits on use.
• Records that outlast the model: documentation kept through the model's life, with records of decommissioned models proposed to be kept for 10 years or more. Vendor contracts must give access to technical documentation and audit.
• Honesty with customers: customers told when they are dealing with an AI system and what its limits are, with a route to a person on request, and controls against hallucination and prompt injection.

What changes when the model is an agent

Much of the draft reads as if written for scorecards: a model produces a number and a person or a rule acts on it. An agent closes that gap. It reads the alert, forms a view and, unless something stops it, writes the outcome back to the core system. Three parts of the draft land differently as a result.

1. 01The kill switch has to stop actions, not only outputs. Switching off a model that produces a score is simple. Stopping an agent means stopping what it is about to change in the core, at once, without leaving half-finished work behind.
2. 02Oversight has to sit before the commit. Reviewing a sample of decisions after the month closes is periodic review, not oversight. For a change that moves money or touches a customer, a person has to see the proposed action before it happens, with enough context to disagree.
3. 03The record has to name the authority. A log saying the agent changed a limit is not enough to validate the agent or answer an inspector. The record needs the input, the confidence, the rule that applied and the person who approved or refused, kept as long as the model's own records.

Designing for the validator

A few choices make an agent easier to validate under the draft:

• Put every agent in the model inventory with its own risk tier, owner and validation date, including agents built on a vendor's model.
• Route every change an agent proposes through one decision point that can allow it, send it to a named person or refuse it, and that can stop every agent in one step.
• Set confidence thresholds with your risk owner and send every case below the line to a person. Track the share that goes to people, so reviewer load shows up as a number before it shows up as fatigue.
• Keep one record per action with the agent's identity, input, confidence, rule, approver and outcome, and plan to keep it for 10 years.
• Tell customers when an agent is involved, and give them a person when they ask.

Where elan1 fits

elan1 Govern is designed to be that decision point. An agent proposes a change; Govern allows it, asks a person you name, or refuses it, before anything reaches the core system. Its emergency stop pauses every agent at once and starts the incident report. Each decision is recorded with the agent's identity, the rule and the approver, in a form a validator can check offline, and kept for as long as your policy requires.

elan1 Decide routes alerts and documents by calibrated confidence and treats credit and anti-money-laundering outcomes as recommend-only: it suggests, a person decides. elan1 Run keeps the models and the record in India, on infrastructure you name. None of this replaces your own model risk framework or independent validation; it is designed to give both something to check.