Short answer: AI risk management for banks in India now means controlling three risks at once: automated decisions, shared technology providers and opaque models. RBI expects banks to explain material AI decisions and stay accountable for vendor models. So explainability logs and vendor concentration tracking must go live on day one of any AI deployment.
When a bank moves AI from pilot to live operations, it takes on three new risks at once. Decisions become automated. The technology increasingly comes from a small set of shared providers. And the models themselves are harder to explain than the rules they replace.
RBI has named this directly. In September 2026, Deputy Governor Rohit Jain singled out speed, concentration and opacity as the concerns that rise as technology embeds deeper in finance. A month earlier, Governor Sanjay Malhotra set out five immediate AI priorities for banks. This guide turns those expectations into the controls that must ship with every deployment.
What are the three risks banks inherit when AI goes live?
The three risks are automated decisions that act faster than people can intervene, shared providers that spread one failure across many banks, and opaque models that cannot justify their outputs.
Each risk fails in a different way, and each needs a different control:
| Risk | How it fails in live operations | Who answers for it | Control that must ship with the deployment |
|---|---|---|---|
| Automated decisions | Errors repeat at machine speed before anyone notices, for example thousands of wrong reminders, declines or limits in an hour | The bank, not the model | Impact tiering, kill switch, human override, real-time monitoring |
| Shared technology providers | One cloud, model or vendor flaw hits many institutions at once | The bank, even when the vendor built it | Vendor concentration register, fourth-party map, tested exit plan |
| Opaque models | The bank cannot explain why a customer was declined or flagged | The bank, to the customer and RBI | Decision logs, reason codes, explanation at three levels |
The three risks compound. An opaque model, supplied by a common provider, making automated decisions, is the scenario regulators worry about most: an error that is fast, widespread and hard to diagnose.
What does RBI expect from banks deploying AI in 2026?
RBI expects banks to inventory every AI system, govern it through a board-approved policy, explain material decisions, stress-test models and keep humans able to override them.
Speaking at FIBAC 2026 on 11 August 2026, Governor Malhotra listed five immediate priorities for banks:
- A complete AI inventory, including AI embedded inside vendor products.
- Board-approved AI governance that assigns accountability for outcomes, not just procurement.
- Explanation of AI-driven decisions that materially affect customers, especially in lending and fraud.
- Red-teaming and stress-testing before deployment and periodically after it.
- Meaningful human oversight wherever an AI error could cause material customer harm or threaten stability.
He also warned that if a few models or vendors underpin decisions across banks, a flaw in that shared layer becomes a systemic problem. He asked that outsourcing contracts carry AI-specific terms: audit rights, a right to explanation and a credible exit plan.
At Global Fintech Fest on 9 September 2026, Deputy Governor Jain put it this way: an institution “may outsource the computation, but it cannot outsource the consequence.” He added that oversight should scale with impact. A tool that summarises documents needs less scrutiny than one that approves credit or executes transactions.
These speeches sit on top of formal instruments: the FREE-AI Framework (August 2025), the draft Guidance on Regulatory Principles for Model Risk Management (June 2026), and RBI’s IT outsourcing rules, which have required banks to manage concentration risk since October 2023. Internationally, the Financial Stability Board’s November 2024 report named third-party concentration and limited model explainability among the main AI vulnerabilities for financial stability.
What does explainability mean for a bank’s AI decisions?
Explainability means the bank can show, for any material AI decision, what data was used, which factors drove the outcome and who could have intervened, in terms each audience understands.
One explanation does not serve everyone. A working design produces three layers from the same decision record:
| Audience | What they need | What the system must produce |
|---|---|---|
| Customer | Why they were declined, charged or contacted, and how to contest it | Plain-language reasons in their language; grievance route |
| Credit officer / operations | Which factors drove the outcome and whether to override | Top reason codes, confidence, policy rules triggered, override button |
| Auditor / RBI | Whether the model works as designed and was governed | Full decision log: input data, model version, rules applied, human actions, timestamps |
Three design rules make this work in practice:
- Log at decision time, not on request. Reconstructing a decision months later from a changed model is unreliable. Store the model version and inputs with every outcome.
- Separate the model from the policy. Keep credit policy in a business rules engine and use AI scores as one input. Rules are explainable by design; the model only has to explain its score.
- Make overrides visible. Every human override needs a reason code. Override rates by model are an early warning that a model is drifting.
For credit, this is why many lenders keep final decisions with rules and people. Trustt looked at this problem in why AI credit decisions in India stall at sign-off.
How should banks track AI vendor concentration risk?
Track it with a concentration register: map every AI use case to its model, vendor, cloud and data source, then measure how much decision volume each provider carries and how fast you could replace it.
Concentration hides one layer down. Two vendors may look independent but run on the same foundation model or cloud region. The register must capture these fourth parties too.
A minimal AI Vendor Concentration Register looks like this (illustrative):
| AI use case | Vendor | Underlying model | Cloud / hosting | Share of AI decisions | Time to substitute | Exit plan tested? |
|---|---|---|---|---|---|---|
| Service deflection | Vendor A | Foundation model X | Cloud 1, Mumbai | 45% | 8 weeks | No |
| Collections reminders | Vendor B | Foundation model X | Cloud 1, Mumbai | 30% | 12 weeks | No |
| Fraud alerts | In-house | Proprietary | On-premise | 15% | Not applicable | Yes |
| Document summarisation | Vendor C | Foundation model Y | Cloud 2 | 10% | 2 weeks | Yes |
Read at the vendor level, no provider carries more than 45%. Read at the model and cloud level, 75% of AI decisions depend on one foundation model in one cloud region, and neither exit plan has been tested. This is exactly the kind of exposure the register is meant to catch.
To turn the register into a single number, many risk teams use a Herfindahl-style index: square each provider’s share of decision volume and add them up. In the example, model-level concentration is 0.75² + 0.15² + 0.10² comes to about 0.60, against 0.33 if the three were evenly split. Set an internal threshold, report the index to the board each quarter and require a tested exit plan above it.
What must ship on day one of a live AI deployment?
Eight controls need to go live with the model on day one: inventory entry, impact tier, decision logging, reason codes, human override, monitoring, register entry and a tested exit path.
The Day-One AI Control Pack
- Inventory entry. The use case, owner, model, vendor and data sources are recorded before go-live.
- Impact tier. The use case is tiered by customer and financial impact (see below), which sets every other control’s strength.
- Decision logging. Inputs, model version, output and rules applied are stored for every decision.
- Reason codes. Material decisions carry machine-readable and plain-language reasons.
- Human override and kill switch. Named staff can override single decisions and halt the system entirely.
- Live monitoring. Error, drift, override and complaint rates are tracked with alert thresholds.
- Concentration register entry. Vendor, underlying model, cloud and decision share are recorded and rolled into the board index.
- Tested exit path. A fallback (rules, another model or human process) has been run at least once.
How should banks tier AI controls by impact?
Tier each AI use case by the harm a wrong output can cause, and scale validation, explainability and human oversight to that tier.
| Tier | Example use cases | Explainability required | Human role | Validation |
|---|---|---|---|---|
| Tier 1: internal, low impact | Document summarisation, policy Q&A for staff | Source citation | Staff review output before use | Pre-launch testing |
| Tier 2: customer-facing, reversible | Service queries, payment reminders, lead qualification | Conversation log, scripted responses | Escalation to human on request | Pre-launch and periodic testing |
| Tier 3: material, hard to reverse | Credit decisions, limit changes, fraud blocks, transactions | Reason codes for every decision; customer-ready explanation | Human approval or real-time override | Independent validation and red-teaming |
This matches the direction of RBI’s draft model-risk guidance, which proposes risk-based tiering of models. Most banks will find that their early wins sit in Tiers 1 and 2, as our ROI map for AI agents in banking shows.
Definitions
- AI risk management: the governance, controls and monitoring a bank applies to AI systems across their lifecycle.
- Explainability: the ability to show what data and factors drove an AI output, in terms the affected party can understand.
- Vendor concentration risk: exposure created when many AI decisions depend on the same vendor, model, cloud or data source.
- Fourth-party risk: risk from the providers your vendors depend on, such as a foundation model or cloud host.
- Kill switch: a control that halts an AI system immediately when it produces harmful or anomalous outputs.
How Trustt approaches this
Trustt is a B2B BFSI technology platform that provides digital lending, distribution, identity and AI infrastructure to banks, NBFCs and insurers in India. Trustt is a technology service provider; it does not lend.
TrusttAI agents are built to sit inside the controls described above. Each agent action is logged for review, and customer-facing agents run on the same rails as the Trustt Digital Lending Platform and the Trustt Digital Identity Suite, so their actions trace back to systems of record. For credit, Trustt’s design keeps policy in the business rules engine, where every decision carries the rules that produced it. As a third-party provider, Trustt supports the documentation, audit access and exit planning that RBI expects banks to secure from vendors.
Frequently asked questions
What is AI risk management in banking?
AI risk management in banking is the set of governance, controls and monitoring a bank applies to AI systems across their lifecycle. It covers inventorying AI use cases, tiering them by impact, validating models, explaining material decisions, keeping humans able to override outputs, tracking vendor dependence and testing exit plans. In India, RBI expects board-level accountability for these controls.
Why is explainability important for AI in banks?
Explainability lets a bank show customers, auditors and RBI why an AI system reached a decision. Without it, a bank cannot justify a loan decline, detect bias or prove a model works as designed. RBI’s Governor has said customers and regulators are entitled to know why AI declined credit, making explainability a practical requirement for lending and fraud use cases.
What is vendor concentration risk in AI?
Vendor concentration risk arises when many AI decisions, within one bank or across many, depend on the same vendor, foundation model, cloud provider or data source. A single flaw or outage in that shared layer can then disrupt many processes or institutions at once. RBI and the Financial Stability Board both identify this as a growing systemic concern.
Can a bank transfer AI risk to its technology vendor?
No. RBI’s position is that responsibility stays with the regulated entity even when a third party builds or runs the model. Banks should secure audit rights, documentation access, a right to explanation, incident notification terms and a credible exit plan in vendor contracts, and validate vendor models instead of relying on the vendor’s assurance.
What should be in a bank’s AI inventory?
A bank’s AI inventory should list every AI use case, including AI embedded inside vendor products. For each, record the business owner, purpose, impact tier, model and version, vendor, underlying foundation model, cloud or hosting location, data sources, validation status, monitoring metrics and exit plan. The inventory is the starting point for both governance and concentration tracking.
How should banks tier AI use cases?
Banks should tier AI use cases by the harm a wrong output can cause. Internal tools such as document summarisation need light controls. Customer-facing but reversible uses, such as reminders, need logging and escalation. Material, hard-to-reverse uses, such as credit decisions or fraud blocks, need reason codes, independent validation, red-teaming and human approval or override.
What did RBI say about AI risks in 2026?
In August 2026, RBI Governor Sanjay Malhotra set out five priorities: a complete AI inventory, board-approved governance, explainable material decisions, red-teaming and human oversight. In September 2026, Deputy Governor Rohit Jain highlighted speed, concentration and opacity as key risks, and stressed that institutions cannot outsource accountability for outcomes to technology providers.
Conclusion
For banks putting AI into live operations, the hard part now is control. The banks that scale AI safely will be those that ship explainability, human override and vendor concentration tracking with the model on day one, and can show RBI the evidence. Start with the Day-One AI Control Pack and the concentration register. For the lending side of the stack, see our loan origination system buyer’s guide.
Talk to Trustt about deploying AI agents with day-one controls
Sources
- Common tech dependencies could amplify financial system risks: RBI DG, Business Standard, 9 September 2026
- Winning in the AI Era: The New Playbook for Indian Banks (Governor’s address at FIBAC 2026), RBI speech, 11 August 2026
- RBI press release: Report of the FREE-AI Committee, RBI, 13 August 2025
- Draft Guidance on Regulatory Principles for Model Risk Management, RBI, 24 June 2026
- Financial stability implications of artificial intelligence: executive summary, BIS FSI, summarising the FSB report of November 2024
- The Financial Stability Implications of Artificial Intelligence, Financial Stability Board, 14 November 2024
