In August 2025, a committee constituted by the Reserve Bank of India — chaired by Prof. Pushpak Bhattacharyya of IIT Bombay — submitted its report on responsible AI adoption in India's financial sector. The report is known by the name FREE-AI.
What's genuinely useful about this report, regardless of exactly how its 26 recommendations are grouped, is that it's specific. It isn't a page of principles with the implementation left to each bank's imagination — it sets out operational expectations an RBI inspection team is increasingly likely to test against. The structure below follows the four-theme grouping commonly used in secondary commentary (fairness, reliability, explainability, ethics-adjacent governance); treat the exact recommendation numbering (F-1, R-3, etc.) as a working reference to confirm against the primary report before it goes into an examiner-facing document.
What this adds to RBI's existing AI expectations. RBI's broader supervisory themes on AI — governance framework, audit trail, inventory, outsourcing, customer protection, incident reporting — describe the architecture a bank's AI governance has to have. The FREE-AI report is the layer underneath that: what "responsible AI" actually means in operational terms, across fairness, reliability, explainability, and governance. Banks need both, mapped to specific controls, not treated as separate compliance exercises.
Fairness-related recommendations
This group requires regulated entities to detect, measure, and remediate bias in AI systems affecting customer outcomes — credit decisions, insurance pricing, customer-service routing. The themes cover training-data quality, ongoing bias monitoring, and the governance process for acting on detected bias.
| Theme | What it requires | Evidence an examiner will expect |
|---|---|---|
| Data representativeness | Training data documented for demographic representativeness; gaps identified and addressed | Data lineage documentation; bias test results at training time |
| Pre-deployment bias testing | Fairness metrics (demographic parity, equalized odds) tested before production deployment | Pre-deployment bias test report with threshold justification |
| Ongoing monitoring | Continuous bias-metric monitoring in production, with alerting on threshold breach | Monitoring dashboard; bias metric time series; alert log |
| Disparate impact assessment | Regular assessment of AI-driven decisions for disparate impact on protected groups | Disparate impact analysis with statistical significance; remediation record |
| Feedback mechanism | Customer channel for reporting suspected AI discrimination | Feedback log; investigation records; outcome tracking |
| Third-party bias coverage | Fairness requirements extended to vendor-provided AI | Vendor bias attestations; third-party fairness test results |
| Human review for adverse decisions | High-stakes decisions (credit denial, account closure) subject to human review on request | Human review process documentation; review log with outcomes |
| Board reporting | Fairness metrics and bias incidents reported to the board or risk committee on a regular cadence | Board or committee reports; minutes showing fairness review |
Reliability-related recommendations
This group covers performance consistency, robustness to distribution shift and adversarial inputs, and failure handling. In a BFSI GenAI context specifically, it extends to hallucination rates, consistency across similar prompts, and degradation under adversarial pressure.
| Theme | What it requires | Evidence an examiner will expect |
|---|---|---|
| Performance benchmarks | Defined thresholds per AI system; continuous monitoring and alerting on degradation | Threshold documentation; monitoring dashboard; alert log |
| Distribution shift detection | Monitoring for input shifts that degrade model performance; a recalibration process | Distribution monitoring setup; shift detection log; recalibration records |
| Adversarial robustness | Testing against prompt injection, jailbreaks, and boundary-probing, with a documented methodology | Adversarial test results; red-team reports; benchmark scores |
| Fallback and graceful degradation | Defined fallback behavior when performance drops below threshold; human handoff protocols | Fallback design documentation; incident log showing fallback activation |
| Reproducibility | Outputs reproducible for investigation purposes; model versioning and inference-log retention | Model registry with version history; ability to reproduce a specific output |
| Hallucination controls (GenAI) | Factual-accuracy monitoring, grounding controls, a process for catching and correcting hallucinated outputs | Hallucination rate measurement; grounding test results; correction process |
| Third-party reliability standards | Reliability requirements written into vendor contracts; ongoing monitoring of vendor AI | Vendor SLA for AI performance; monitoring evidence |
Explainability-related recommendations
This is the hardest group to satisfy technically, and the one that matters most in BFSI, because adverse decisions have to be explainable to both customers and regulators. The report distinguishes model-level explainability (internal governance) from decision-level explainability (customer-facing), and expects both. In practice, this is the group where I've seen banks get caught out hardest at inspection — a fairness dashboard looks fine on a slide, but "explain this specific credit denial to the customer in plain language, right now" is a different and much less forgiving test.
| Theme | What it requires | Evidence an examiner will expect |
|---|---|---|
| Model documentation | Full documentation of architecture, training data, performance, and known limitations | Model card or equivalent, version-controlled and auditable |
| Feature attribution | Ability to identify the primary factors driving a customer-affecting decision | SHAP/LIME outputs or equivalent; feature importance documentation |
| Customer-facing explanation | Plain-language explanation of decision factors for adverse decisions, on request | Explanation generation process; sample explanations; customer interface documentation |
| Regulator-facing explanation | Technical explanation of decision methodology, including for complex models | Model explanation documentation; inspection-ready explanation format |
| Complexity management | For black-box models: compensating explainability controls, documented and tested | Compensating control documentation; evidence explanations are accurate |
| GenAI explainability | Traceable grounding — what source informed an output — with citation where applicable | RAG grounding logs; source attribution evidence; output tracing capability |
Ethics- and governance-related recommendations
This group covers the governance scaffolding for responsible AI — board oversight, ethics review, conflicts of interest, a process for staff or customer ethical concerns. These are, in my experience, the requirements most likely to come up with an examiner who has read broadly about AI governance and wants to see whether the institution has actually built the muscle, not just the policy document.
| Theme | What it requires | Evidence an examiner will expect |
|---|---|---|
| AI ethics policy | Board-approved policy covering prohibited uses, human dignity, privacy, customer protection | Board resolution; current policy document; last review date |
| Ethics review process | Pre-deployment ethics review for high-risk AI, documented and recorded | Ethics review framework; records for deployed high-risk systems |
| Conflicts of interest | Controls preventing AI from optimizing for metrics that conflict with customer interests | Objective documentation; evidence customer interests were protected |
| Whistleblower channel | Staff channel for raising AI ethics concerns, with investigation and escalation | Channel documentation; investigation log; escalation records |
| Public disclosure | Disclosure of AI use in significant customer-facing decisions | Disclosure policy; customer communication examples |
The coverage gap is real, whatever the exact pillar count turns out to be
No global AI governance platform tracks RBI publications closely enough to have built a working control mapping for this report — Arthur AI, Credo AI, Holistic AI, and Lakera are built against EU AI Act and NIST AI RMF, not RBI's committee output. Indian-native compliance tools that do track RBI circulars tend to focus on regulatory monitoring, not AI model governance specifically. The practical result for most Indian banks: this is still a DIY mapping exercise — translate the recommendations into existing controls, find the gaps, assign owners, build an evidence trail — without much vendor tooling built specifically for it.
A realistic timeline for that exercise is three to six months: discovery, gap analysis, control assignment, testing, evidence collection. Institutions that start now will have something defensible in front of an examiner; the ones that don't will be answering "we're working on it" when asked.
What to do this quarter
- Pull the committee's primary report and verify the exact recommendation structure against it — don't build your control mapping off a secondary summary, including this one.
- Assign a named owner to each theme above (fairness, reliability, explainability, ethics-adjacent governance), not one owner for "AI compliance" generally.
- Run a pre-deployment bias test on every credit, pricing, or underwriting model currently in production if you haven't already — this is the most commonly skipped control in the fairness group.
- Build a customer-facing explanation capability for adverse decisions now; it's the control most banks have only in ad hoc, post-complaint form.
- Set a board reporting cadence for fairness metrics and AI ethics concerns before your next board cycle, not after an examiner asks for the minutes that don't exist.
More India AI compliance guides
Compliance checklist for Indian banks
Six obligation categories, what evidence an examiner will ask for, and common gaps.
Read →RBI, SEBI & DPDP: mapping India's AI rules
Framework-level overview of all three India AI regulatory requirements and how they interact.
Read →Zytra India BFSI coverage
Clause-level mapping for RBI, SEBI, and DPDP with evidence outputs for each obligation.
Explore →FREE-AI ready before your next RBI inspection?
Zytra's India compliance team will walk through your current FREE-AI coverage, identify gaps, and map the fastest path to examination-readiness across all 26 recommendations.