An RBI AI examination is not a single-topic audit. It's a cross-cutting assessment of how a bank governs its AI — from how complete the inventory actually is, through the quality of validation and fairness testing, to whether board oversight is substantive or ceremonial. Most banks prepare for AI examination the way they prepare for an IT audit — systems checks, documentation review, policy recitation. That's the wrong model. Examiners bring specific questions about specific systems, ask for adverse-action notice samples, and ask about the last monitoring alert that was actually investigated. The gap between "documentation-ready" and "evidence-ready" is where most findings come from, and it's a wider gap than most model risk teams assume until they're asked to close it on a six-week clock.
Seven governance domains examiners probe
1. Fairness — bias testing and discriminatory outcome prevention. Examiners check whether the bank has identified which groups are protected under Indian law and RBI guidance, and whether AI systems have actually been tested for discriminatory outcomes against them — reviewing test design, not just results: how proxy variables were chosen, what threshold defined disparate impact, and what happened when one was found. Evidence to have ready: bias testing reports for critical and high-risk credit and customer-facing AI; documented rationale for proxy variable selection (especially India-specific ones — pincode as socioeconomic/caste proxy, UPI counterparty as religious-community proxy); disparate-impact results against a documented threshold; remediation records; ongoing monitoring configuration.
2. Reliability — production performance and drift monitoring. Examiners test whether AI systems keep performing within validated parameters in production and whether the bank can actually detect when they don't — looking for the gap between validation accuracy and production accuracy as a number in the record, not a reassuring statement in a slide. Evidence to have ready: monitoring dashboards per critical system; threshold documentation (what triggers an alert, who receives it); the last three performance review cycles for high-risk AI; validation-vs-production accuracy comparison within the last 12 months.
3. Explainability — customer-facing explanations and adverse-action quality. This is the domain where examiners most often ask for actual samples, not documentation of capability. A notice reading "your application was declined due to model output" without specific, actionable factors won't satisfy the Fair Practices Code's explanation standard, and examiners will directly compare the technical explanation (SHAP values, feature importances) against what actually appears in the customer letter. Evidence to have ready: de-identified adverse-action samples from the last 90 days; documentation of how technical outputs get translated into customer language; regional-language availability; any complaints about explanation quality and how they were resolved.
4. Ethics-adjacent governance — board oversight and substantive AI ethics review. Examiners test whether oversight is real: does the board get meaningful AI risk reporting, does an enforced ethics policy exist, were ethics questions considered through the AI lifecycle? They can tell the difference between a bank where this is a policy document and one where it's an operational process that generates records. Evidence to have ready: the last quarterly board AI risk report; a policy with real version history; board/committee approval records for high-risk deployments; any use case rejected or modified on ethics grounds.
5. Accountability — governance structure and named ownership. Examiners verify every AI system has a named business owner accountable for its decisions, not just a technical owner, and they review whether the governance committee has the right membership and authority, and whether its records show real deliberation rather than rubber-stamped summaries. Evidence to have ready: the inventory showing named owners; the committee charter; 12 months of meeting records showing attendance and actual decisions; a RACI matrix for AI governance roles.
6. Integrity — data quality and adversarial robustness. Examiners assess whether training and production data quality is monitored, whether drift is detected, and whether AI systems resist adversarial manipulation — for LLMs and customer-facing AI specifically, whether prompt injection and adversarial input testing has actually happened, not just been planned. Evidence to have ready: data quality monitoring records; drift detection configuration; adversarial testing results; vendor AI data integrity assessment.
7. Security — AI-specific cybersecurity and threat management. Examiners check whether AI systems sit inside the bank's cybersecurity framework with AI-specific mitigations — model poisoning, prompt injection, inference attacks, open-source supply chain risk — rather than being covered only by generic IT controls, and whether AI security incidents have a response process distinct from general IT incident response. Evidence to have ready: an AI threat model; AI-specific controls mapped into the cybersecurity framework; a distinct AI incident response procedure; penetration testing records for the AI systems themselves, not just the infrastructure underneath them.
A practitioner note worth having in your back pocket before the examiner arrives: when they ask about "the last alert that was investigated," they are not asking you to describe your monitoring system. They want the actual ticket, the actual timestamp, and the actual name of the person who closed it. Teams that answer in the abstract lose credibility in the room fast.
Common examination findings and their root causes
| Finding | Severity | Root cause | Remediation |
|---|---|---|---|
| AI inventory incomplete — examiners find shadow AI not in the registry | High | Deployment process doesn't require registration; business units adopt vendor AI tools without formal approval | Require registration before production deployment; run a quarterly shadow AI discovery scan |
| Fairness testing omits India proxy variables | High | Bank adopted an international fairness framework without India adaptation | Add pincode/UPI/device/accessibility proxy tests; document the design rationale |
| Adverse-action notices lack customer-comprehensible factors | High | Technical SHAP output used directly in notices without a plain-language layer | Build a translation layer; require customer-experience sign-off before deployment |
| Vendor AI sits outside the MRM framework | High | MRM process built for internally developed models only; vendor AI assumed covered by the vendor's own governance | Extend MRM to vendor AI: independent review of vendor validation reports, the bank's own fairness testing for customer-facing vendor AI |
| Monitoring exists but has no action thresholds | Medium | Dashboards built without defined escalation criteria | Define performance and fairness thresholds per critical system; document the escalation path |
| Agentic AI deployed without separate risk classification | Medium | Treated as standard model risk; autonomous action scope and authorization limits never separately documented | Add agentic AI risk classification to the MRM framework; require separate committee approval for autonomous action scope |
India-specific examination areas with no international equivalent
India proxy-variable fairness examination is the fastest way to generate an immediate finding. Examiners specifically look for testing against pincode as a socioeconomic/caste proxy, UPI counterparty/geographic patterns as a religion proxy, device type/application language as a linguistic-minority proxy, and accessibility interaction patterns as a disability proxy. No international framework specifies these — a bank that has only run US/EU demographic fairness tests will have an immediate gap.
Financial inclusion obligations get checked against actual PMJDY numbers, not policy intent. Banks with a government inclusion mandate need specific analysis of PMJDY account-holder approval rates in credit AI, and evidence that AI-assisted KYC serves rural/BC customers as accurately as urban ones.
Vernacular explanation availability is checked directly, not assumed. For banks with significant non-English customer bases, an adverse-action explanation available only in English for a customer who banks in Tamil or Bengali is a real finding on explainability grounds, not a technicality.
BC-network AI governance gets examined as the bank's own responsibility. Examiners look for BC-specific AI governance procedures, including how the bank ensures BC-assisted decisions get the same oversight as direct-channel decisions.
How to actually get examination-ready
- Build the seven-domain evidence pack (fairness, reliability, explainability, ethics governance, accountability, integrity, security) as a living record, not a pre-examination scramble.
- Pull a real sample of adverse-action notices today and check whether they'd survive an examiner's side-by-side comparison against the underlying SHAP output.
- Run the India proxy-variable fairness tests now, even without a codified checklist to point to — this is the single fastest path to a finding if skipped.
- Confirm every committee's meeting records actually show deliberation, not just approval of pre-written summaries.
- Pressure-test your own team: ask them to produce "the last alert that was investigated" for your most critical AI system, right now, and see how long it takes.
Zytra generates examination-ready evidence packs across all seven governance domains — hash-chained audit records, fairness testing with India proxy variable methodology, adverse-action quality records, and committee approval chains — exportable as PDF or OSCAL. Request a demo to see evidence generated continuously rather than assembled under time pressure.
Related: AI governance and regulatory compliance
Generate examination-ready AI governance evidence continuously
Zytra produces hash-chained audit trail records, fairness testing documentation, committee approval chains, and FREE-AI pillar evidence packs — ready for RBI examination without last-minute assembly. Banks using Zytra respond to examiner requests with evidence retrieval, not evidence creation.