AI Governance Training for Banking: Who Needs to Know What, and How Do You Prove It to an Examiner
Generic AI awareness training does not satisfy an RBI examination. Examiners ask for role-specific competency evidence: that model owners can classify a change correctly, that validators can walk through LLM-specific testing without notes, that committee members can read a residual risk heat map and explain what it means for the next sanction, and that India proxy-variable fairness testing is a practiced skill, not a slide in a deck.
Zytra Research Team — October 2026 — 8 min read
Most banks treat AI governance training as a bolt-on to their existing model risk training: update the MRM curriculum to mention AI, add a module on generative AI risks, hand it to the model risk function, move on. That approach covers maybe a third of the actual training obligation.
The gap is structural, not a matter of degree. Traditional MRM training was built for validators and model owners working with statistical models — regression, scorecards, PD/LGD models. It was never built to cover prompt injection and behavioral consistency testing for LLMs, India proxy-variable fairness testing methodology, AI change classification and its governance consequences, agentic AI authorization scope, or board-level AI risk literacy. You cannot retrofit five sentences onto an existing module and call it coverage.
RBI's FREE-AI framework expects governance controls to be demonstrably effective, and examiners read "demonstrably effective" as "the people running the control can prove it under questioning." For Critical- and High-tier AI systems, training records that show role-specific AI governance competency — not just attendance — are now a standard part of the governance evidence package examiners ask for.
What the bank must do: stop treating AI training as an MRM-curriculum add-on. Build a separate, role-indexed curriculum with its own evidence trail, because that is what gets checked.
Role-Based AI Governance Training Requirements for Indian Banks
Model owners / developers — Annual + on-hire Risk classification methodology, model card documentation, change management classification, fairness testing concepts, India proxy variable categories, DPDP Act data governance obligations, escalation triggers. The sharpest gap we see in practice: owners can describe a "material change" in the abstract but cannot classify a specific prompt-template edit or a fine-tuning run against the bank's own change taxonomy when asked to do it live.
Model validators / Model Risk function — Annual + on every LLM deployment SR 11-7 gap-mapping for AI-specific risks (SR 11-7 was never written for generative models, so validators need an explicit crosswalk, not an assumption of coverage), RBI's draft eMRM guidance on model documentation and validation (issued 24 June 2026, comments closed 24 July 2026 — it requires board-approved MRM frameworks, full model inventories, risk tiering, independent validation, continuous monitoring, and human-in-the-loop/kill-switch mechanisms for AI-based models), LLM-specific validation methodology, proxy-variable testing using disparate impact ratio (also called adverse impact ratio) analysis, full-vs-targeted re-validation scope, evidence pack structure, agentic AI validation concepts.
This is the role where training gaps show up fastest in an exam. An examiner who asks a validator to run disparate impact ratio testing on a live loan-approval model, right there in the room, is not being unreasonable — eMRM draft expects independent validation competency, not a validator who can cite the concept but has never computed it. We have watched this exact scenario stall an exam for a full day.
Risk managers / AI governance committee — Annual + on regulatory change AI risk appetite setting, residual risk scoring and heat map literacy, fluency in RBI's actual FREE-AI Sutras and pillars — particularly Accountability, Understandable by Design, and Safety-Resilience-Sustainability, the three committee members cite most often in examination follow-ups — regulatory crosswalk across RBI, SEBI, IRDAI, DPDP, and the EU AI Act where applicable, incident escalation triggers with defined timelines, committee approval scope, and India examination preparation grounded in the real Sutras and pillars rather than an invented pillar list.
Committee members are the group most likely to get caught citing a framework they half-remember. Get the Sutras and pillars right, in the bank's own language, before an examiner tests it.
Board members / senior leadership — Annual briefing AI risk heat map literacy, board reporting structure, AI risk appetite governance, regulatory obligations at board level, incident governance, India penalty exposure — specifically, up to ₹250 crore per instance under the DPDP Act for a failure to implement reasonable security safeguards that results in a personal data breach, separate from the ₹200 crore cap for failing to notify a breach and the ₹50 crore cap that applies to most other contraventions, plus RBI supervisory action risk on top.
A board AI-risk briefing that works does not open with a framework slide. It opens with: here are the three AI systems rated High or Critical, here is the residual risk after controls, here is what changed since last quarter, and here is the one escalation that needs a board decision today. Directors who sit through a 40-slide taxonomy deck retain none of it; directors who get three live risk-tier examples remember all three for the next cycle.
CISO / InfoSec function — Annual + on every new LLM deployment The OWASP LLM Top 10 — prompt injection, training data poisoning, model denial-of-service, and the rest of the current list, understanding that OWASP revises this list and the bank's training needs to track the current revision rather than a frozen snapshot — KV cache governance, agentic AI security controls (authorization-scope, tool-execution, and session-isolation boundaries), red-teaming methodology benchmarked against Zytra's own FinProof categories for BFSI (a Zytra-built benchmark, not an industry-wide standard — useful as a structured internal baseline, not a claim of external certification), and AI incident response differences from a conventional security incident runbook.
Front-line staff using AI tools — On deployment + annual refresher Tool limitations, override documentation, escalation triggers, data quality responsibilities, customer disclosure obligations, and DPDP Act obligations specific to customer data handled through AI tools.
Training Frequency, Required Evidence, and Where Records Fall Apart
| Training Type | Who | Frequency | Evidence Required |
|---|---|---|---|
| Role-based AI governance curriculum | Model owners, validators, risk managers, CISO, board, front-line staff | Annual, plus trigger-based (on-hire, on-deployment, on regulatory change) | Attendance + competency assessment results, not attendance alone |
| LLM-specific technical training | Model validators, CISO function | Annual + on every LLM deployment | Test scenarios completed, scored validation walkthroughs |
| India proxy-variable fairness training | Model owners, validators, risk managers | Annual + on new model class | Documented test methodology applied to at least one live model example |
| Change classification training | Model owners | Annual + on-hire | Classification exercises scored against the bank's own taxonomy |
| Board AI risk briefing | Board, senior leadership | Annual | Briefing minutes + board questions logged |
| Incident escalation drills | Risk managers, CISO, front-line staff | Annual | Drill completion + time-to-escalation metrics |
| Regulatory crosswalk refresh | Risk managers, AI governance committee | On regulatory change | Updated crosswalk document + sign-off |
What the bank must do: stop recording "completed" as the evidence unit. Record what was tested and what score it produced — that is the only format examiners accept as proof of competency rather than proof of attendance.
Common AI Governance Training Gaps and How to Close Them
| Gap | Required Fix |
|---|---|
| MRM training mentions AI in passing instead of covering it as a distinct curriculum | Stand up a separate AI governance training track with its own syllabus, owner, and records |
| Validators trained on traditional model risk but never tested on LLM-specific methodology | Add scored LLM validation scenarios — prompt injection testing, hallucination classification, RAG pipeline review — to the annual validator cycle |
| Proxy-variable fairness testing taught as a concept, never practiced on a real model | Require every annual cycle to include a hands-on test run using disparate impact ratio analysis against at least one in-production model |
| Board briefings framed as generic "AI risk awareness" with no bank-specific numbers | Replace generic slides with the bank's own risk-tier inventory, residual risk scores, and the quarter's actual escalations |
LLM-Specific Training: What Validators and CISO Teams Actually Need to Test
Training content for LLM-specific risk needs to cover behavioral consistency testing methodology (does the model give materially different answers to the same question asked twice, or asked with minor rephrasing), prompt injection and jailbreak risk, hallucination classification split into factual, behavioral, and instruction-following categories (BFSI examiners increasingly ask which category a given incident falls into, because the remediation differs by category), RAG pipeline assessment (what the retrieval layer can leak that the model itself would otherwise refuse to say), and KV cache governance (what gets cached, for how long, and who can access cached state across sessions).
None of this is testable through a multiple-choice quiz. It has to be a scored exercise against a real or sandboxed deployment, with the output kept as the evidence record.
India Proxy-Variable Fairness Training: Caste, Religion, Language, and Disability Proxies
This is the training content most banks skip entirely, and it is the one examiners probe hardest. Caste proxies run through surname patterns, pincode-to-community crosswalks, and historically redlined branch catchment areas. Religion proxies run through name patterns and, in some portfolios, specific merchant category codes tied to religious institutions. Language-community proxies run through preferred-language fields and regional dialect markers in call-center transcripts. Disability proxies run through transaction-channel patterns (assisted-channel usage, accessibility-tool flags) that correlate with disability status even when disability itself is never collected as a field.
The concrete test that separates a bank that can defend its fairness program from one that cannot: can the validator run a correlation test between loan approval outcomes and a pincode-based caste crosswalk, on an actual portfolio, and produce a number — not a statement that "we test for this."
What Examiners Actually Ask, and Why Completion Records Don't Answer It
Four questions that reliably expose a training gap in the room: walk me through how you classified this specific model change and why; show me the disparate impact ratio for this loan product's protected-class proxy and how you computed it; what's your kill-switch trigger for this agentic workflow and who has authority to pull it; and what did the board actually decide the last time this risk category breached appetite.
Training records that show only "completed: yes" answer none of these. Records that show the scored exercise, the methodology applied, and the specific model or scenario it was tested against answer all four — and that gap, far more than the content of the training itself, is what separates a clean exam from a remediation order.
Action Checklist: Building an Examination-Ready AI Training Program
- Split AI governance training out of the general MRM curriculum into its own role-indexed track, with the seven role categories above as the backbone, each carrying distinct content and frequency.
- Replace every "concept-only" fairness or validation module with a scored, hands-on exercise against a real or sandboxed model — disparate impact ratio testing and pincode-based proxy crosswalks are the minimum bar for India fairness training.
- Rewrite the risk-manager and committee curriculum around RBI's actual FREE-AI Sutras and pillars (not an invented five-pillar list), and refresh the regulatory crosswalk every time RBI, SEBI, IRDAI, or DPDP guidance changes — the eMRM draft alone (June–July 2026 comment cycle) changes what "validation competency" means for every bank it covers.
- Fix the board penalty-exposure briefing to state the DPDP Act's actual tiered caps (₹250 crore for a security-safeguards failure causing a breach, ₹200 crore for non-notification, ₹50 crore for most other contraventions) instead of a flat per-incident number.
- Change what counts as a training record: capture the scored exercise, the model or scenario it was run against, and the result — not attendance — so the evidence pack answers an examiner's live question instead of restating a syllabus.
Related: AI governance program and policy
Turn training completion records into governance competency evidence
Zytra tracks governance actions by role — approvals, fairness testing, escalations, change classifications — and generates the competency evidence that satisfies RBI examination questions. Training records say who completed a course; governance action records say who actually governed.