RBI's definition of "model" is any system that takes inputs, applies some processing logic, and produces an output used for business decisions. RBI's own illustration makes the point sharply: a spreadsheet-based loan pricing calculator is just a tool, until it takes borrower type, tenor, and credit score as inputs, runs them through a rate grid, and spits out a lending rate. At that point, it's a model, and it falls under this framework.

The accountability language is equally direct. An RE is responsible for model outcomes regardless of whether the model was built in-house, bought from a vendor, or some mix of both. There is no version of "the vendor built it, so the vendor owns the risk" that survives this guidance. In fact the RBI expects the RE to have insights into the vendor model and its risks before introducing the same in their systems

Four roles now have to exist for every model: an Owner, a Developer, a Validator, and an Approver. The Validator has to sit independent of development and use. For smaller REs running lean teams, that independence requirement brings along a structural cost.

RBI has proposed the three lines of defence model for monitoring of Models. The Board signs off on the Model Risk Management Framework and sets the RE's appetite for model risk. The Risk Management Committee of the Board reviews validation reports for anything tiered "high" risk, keeps standing oversight over third-party and AI models specifically, and reviews breach reports. Underneath sits a three-lines-of-defence structure that will look familiar to anyone who has built an operational risk function before: model owners as the first line, an independent validation function as the second, internal audit as the third.

Risk tiering decides almost everything that follows from validation intensity, who signs off, to how closely a model gets monitored. RBI clearly states that just because a model is easy to understand doesn't automatically earn a lighter risk tier. Simplicity and materiality are separate questions. A model that's simple to explain but drives a large share of lending decisions continues to stay in the high tier.

Vendor-supplied models get no free pass. RBI requires REs to independently validate third-party models regardless of any certification the vendor already provided. A vendor's assurance is not enough. Contracts have to secure audit rights and give REs access to enough technical documentation to actually run that validation, which is a real constraint on vendors who prefer to keep their models opaque. Interestingly, Banks will now have much more insight into vendor models and that might pose to be an actual business risk for these vendors.

Then there's the retention requirement worth naming plainly: decommissioned models stay in the inventory for 10 years from the date they're retired. This is a major records-management project in its own right. Additionally, validation reports have to reach the Risk Management Committee within three months of completion, so the clock starts running early.

.

Key Criteria defined by the RBI when employing AI/ML Models:

1. EXPLAINABILITY
The more a model's output drives a material decision or touches a customer directly, the more the RE has to be able to explain how the model got there. Where full explainability genuinely isn't possible, RBI doesn't ban the model outright — it asks for compensating controls instead: tighter validation, usage limits, more frequent monitoring.

2. BIAS
RBI asks REs to identify discriminatory-output risk and run a fairness assessment, with recalibration or redesign as the remedy. It's worth being specific about how bias actually gets into a credit model, because the mechanism matters more than the label. One path: patterns get baked into historical data from a period when certain groups were underserved, and the model keeps penalising them long after the underlying discrimination has eased. A second path: the model rewards whatever behaviour was common among the majority of past successful applicants, even when that behaviour has no causal link to actual creditworthiness — moving house often, say, or not owning a particular brand of smartphone. Neither path involves an explicit rule that discriminates against anyone. Both still produce that result.

3.Generative AI
Specifically: control boundaries against hallucination, mandatory disclosure that a customer is talking to an AI system, and the right to escalate to a human on request.

4.TESTING
RBI wants stress tests under adversarial and edge-case conditions, out-of-sample checks to catch overfitting, and ongoing monitoring for data drift. Not a one-time sign-off before launch. A standing obligation.

5.HUMAN OVERSIGHT
RBI names the expected kill-switch arrangements and human-in-the-loop mechanisms, and then goes a step further than most model risk frameworks do. RBI specifically names automation bias and decision fatigue , the tendency of a human reviewer to over-trust a model's output or grow too tired from reviewing volume to catch the case that actually matters. That's aimed at the reviewer, not the machine, and this is a more mature regulatory instinct than just a framework.

The EU solved the same problem differently. Its AI Act classifies credit scoring and creditworthiness systems as "high-risk" by category, and that classification triggers a specific, mandatory compliance checklist rather than a set of principles to interpret on your own.
For example Article 9 requires REs to identify risks to fundamental rights and build measures that actually reduce them, not simply document that the risk exists.
Article 10 sets requirements on the training data itself, aimed at the same historical and majority-bias problems described above, forcing an examination of what the data represents before a model is built at all rather than after it starts producing skewed outcomes.
Article 14 goes furthest: it requires that high-risk systems be designed, from the first line of code, so a human can meaningfully oversee them.
Enforcement runs through sector-specific supervisors the banking regulator for credit institutions, and a separate AI-focused body for standalone credit scoring agencies and other nonbank entities.

RBI's draft asks for the same outcomes like fairness, explainability, human oversight but stops well short of telling REs how to test for any of them. No numeric bias threshold. No mandated testing methodology. No training-data standard written into the text itself. That's consistent with how RBI regulates more broadly: principles over prescription, judgment over checklists. RBI leaves the door open for more specific AI requirements later, which suggests the regulator knows this too. Until those arrive, the job of deciding what a rigorous fairness test looks like belongs to the RE, not the regulator. That's either a vote of confidence in Indian financial institutions or an admission that RBI isn't ready to write the specification yet. Probably some of both.

A few things are worth starting immediately, whether you run a bank's model risk function or you're building a lending product that will eventually answer to this guidance.

AI has emerged to be an essential technology for all REs. While RBI has handed REs a checklist of outcomes it has not defined any rulebook. While the framework, the tiering structure, the validation function has all been defined, AI ethics and AI policy that will direct these structures is something that the REs have to evolve on their own.