On 13 August 2025 the Reserve Bank of India published the report of its committee on a Framework for Responsible and Ethical Enablement of Artificial Intelligence, and the FREE-AI framework it set out remains the closest thing India has to an RBI AI framework for banks and NBFCs. The committee, chaired by Professor Pushpak Bhattacharyya of IIT Bombay, set out seven principles it calls sutras and 26 recommendations under six pillars, thirteen to enable innovation and thirteen to mitigate risk. Regulated entities are named as an owner in thirteen of them.
More than a year later it is still a committee report, not a direction. What has changed is that its entity-level recommendations now have a route into supervisory expectation. The RBI’s Annual Report of 29 May 2026 said that draft directions on model risk management, covering AI and incorporating the committee’s recommendations, were nearly complete. On 24 June the RBI published a draft Guidance on Regulatory Principles for Model Risk Management that asks for a board-approved framework, an inventory of every model, independent validation of vendor models, disclosure to customers, a route to a human and kill-switch arrangements. Comments closed on 24 July.
This is the practical explainer for the team inside a bank or NBFC that has to implement it: the seven sutras, all 26 recommendations by pillar and owner, what the RBI has done since, and a build list with one use case walked through. In August I mapped FREE-AI against the NCSC’s agent guidance and the EU AI Act. The argument is that the regulated-entity half of FREE-AI is an engineering specification written in regulatory prose. An institution that builds the inventory, the tiering and the evidence trail now will meet the final guidance with a configuration change rather than a programme. I built conversational AI for banks at Active.Ai from 2016 to 2019, architecting the Triniti platform, so the worked example is a customer-service assistant.
What the RBI FREE-AI framework is, and what it is not
The committee was announced in the RBI’s policy statement of 6 December 2024 and constituted on 26 December. Its members included Debjani Ghosh of NITI Aayog, Balaraman Ravindran of IIT Madras, Abhishek Singh of MeitY, Rahul Matthan of Trilegal, Anjani Rathor of HDFC Bank and Sree Hari Nagaralu of Microsoft India.
Two RBI surveys framed its work. The Department of Supervision surveyed 612 entities between February and May 2025, close to 90% of the sector’s assets, and found only 127, or 20.80%, using or developing AI. Customer support was the commonest of 583 applications at 15.60%, followed by credit underwriting at 13.70%. Only a third of respondents reported any board-level framework for AI oversight, and only a quarter had formal processes for mitigating AI incidents or failures. In the FinTech Department’s survey of 76 entities, 85% asked for a regulatory framework.
The report answers with recommendations, not rules. Its verbs are “should” and “may”; its addressees include the government, regulators, self-regulatory organisations and industry bodies as well as regulated entities; and each recommendation carries an owner and a timeframe, short or medium term, which the report does not define.
The RBI’s own reading is in its Annual Report for 2025-26. The FinTech Department said it was assessing the report to help formulate “more specific guidance”, and set two goals for 2026-27: to initiate steps towards an AI Innovation Sandbox, and to establish a principle-based framework for the use of AI in finance under Utkarsh 2029, the RBI’s strategy to 2029. Supervisors studied AI adoption in 2025-26 and plan a review of AI cyber risk. The principles are settled; the rules are coming, starting with the model risk draft.
The seven FREE-AI sutras, read as design constraints
The sutras are the principles every recommendation serves. Read by an engineer, each is a constraint on a system rather than a statement of values.
1. Trust is the Foundation. The report calls trust non-negotiable. In practice that means evidence: behaviour the institution can show, not assert.
2. People First. AI should augment human decision-making and defer to human judgement, final authority rests with people who can override it, and citizens should know when they are dealing with AI. That is an override path and a disclosure, both built in.
3. Innovation over Restraint. Responsible innovation with a purpose is to be encouraged over caution. It licenses proportionality: low-risk uses take a lighter path.
4. Fairness and Equity. Outcomes should be fair and non-discriminatory, which needs segment-level evaluation before launch and segment-level monitoring after it.
5. Accountability. Accountability rests with the entity deploying the AI, whoever built the model. Every system needs a named owner, and a vendor contract does not move the liability.
6. Understandable by Design. Explainability is a design feature, and outcomes should be understood by the deployer. Capture reasons when the decision is made; they cannot be reconstructed later.
7. Safety, Resilience and Sustainability. Systems should be secure, resilient to physical, infrastructural and cyber risk, able to detect anomalies, and energy efficient. That is red teaming, fallbacks, a kill switch and a model no larger than the task needs.
Regulated entities are named as an owner in 13 of FREE-AI’s 26 recommendations
Six pillars, 26 FREE-AI recommendations, and who has to act
The six pillars split the recommendations into two halves of thirteen. Infrastructure (1 to 5), Policy (6 to 9) and Capacity (10 to 13) enable innovation; Governance (14 to 17), Protection (18 to 22) and Assurance (23 to 26) mitigate risk. The useful cut is by owner. The first half is addressed almost entirely to the RBI, the government, other regulators and industry bodies, and names regulated entities only in recommendation 10. The second names them in every recommendation from 14 to 25. Table 1 lists all 26 with the artefact each implies.
Infrastructure. A financial-sector data infrastructure built as digital public infrastructure, possibly linked to the AI Kosh datasets platform (1); an AI Innovation Sandbox offering compute and data, without the regulatory relaxations of the existing sandbox (2); incentives and funding for smaller entities, with the report suggesting a ₹5,000 crore corpus plus ₹1,000 crore a year for five years (3); indigenous financial-sector models as a public good (4); and a framework for integrating AI with digital public infrastructure (5).
Policy. Regulators should build a sector AI policy framework anchored in the sutras, and the RBI may issue consolidated AI guidance as a single point of reference (6). They should lower compliance expectations, within basic safeguards, for AI that widens inclusion (7). Recommendation 8 deserves a second reading. It proposes a graded liability framework in which entities stay liable for customer losses, but supervisors take a tolerant stance on first-time or one-off aberrations where an entity has followed safety mechanisms such as incident reporting, audits and red teaming. Repeated breaches, gross negligence or failure to remediate forfeit it. The controls in the second half are the price of that tolerance. Recommendation 9 asks for a standing AI committee under the RBI and a sector spoke of the national AI Safety Institute.
Capacity. Entities should build AI competence in the board and the C-suite and train the staff who use AI, with a suggested glide path of two to three years for AI governance expertise (10). The RBI should train its regulators and supervisors (11), industry bodies such as the IBA should share practices and pitfalls (12), and regulators and industry should reward responsible innovation (13). The AI compliance toolkit (26) sits under Assurance but belongs here: an industry body builds it, to complement internal validation rather than replace it.
That leaves recommendations 14 to 25, four of them shared with regulators or supervisors. They are the build list.
What has happened since August 2025
The draft model risk guidance. Issued on 24 June 2026, it applies to eleven categories of regulated entity, banks and NBFCs of every layer among them, and to every model they use, built or bought, with a model defined widely enough to include decision rules and a loan-pricing spreadsheet. It asks for a board-approved model risk management framework, with the board’s risk committee approving high-risk deployments. The inventory must name owners, developers, validators and approvers, tier, intended use, dependencies and findings; nothing unlisted may run, and retired models stay listed for at least ten years. Tiering weighs materiality, complexity and, for AI, reliance and autonomy, and the factors may not offset one another. Every model, a vendor’s included, needs independent validation by the entity “notwithstanding” any certification the provider offers.
Its AI section, where FREE-AI becomes specific, names seven risk dimensions, from explainability and hallucination to bias, output variability and data risk, and asks for red teaming or equivalent challenge. Customer-facing and generative models need controls against prompt injection, limits on session and context persistence, disclosure that the user is dealing with AI, and an option to switch to a human. Oversight must include override, suspension or deactivation, kill switches among them, and attention to automation bias. Vendor contracts must give documentation sufficient to validate, audit rights and an exit. The draft says further AI requirements may follow. I can find no final text published by 1 October.
The cybersecurity Directions. On 31 July 2026 the RBI issued entity-wise cybersecurity and technology risk Directions, in force immediately. The commercial bank version has no AI-specific clause, but it requires new or emerging technology to be adopted within risk appetite and evaluated for security threats before it reaches critical systems, and cyber incidents to be reported on the RBI’s DAKSH platform within six hours of detection. An AI failure that is also a cyber incident runs on that clock.
The speeches. At FIBAC on 11 August Governor Sanjay Malhotra asked banks for a complete inventory of AI systems, including those inside vendor products, board-approved AI governance policies, the capacity to explain decisions that materially affect a customer, red teaming before and after deployment, and human oversight wherever an error could cause material harm. He said “the model decided” can never be an acceptable answer to a customer, an auditor or the RBI. On 19 August Deputy Governor Shirish Chandra Murmu added that loan rejections should be explained clearly to the customer.
What has not happened. I can find no RBI instrument, up to 1 October, issuing the consolidated guidance of recommendation 6, the incident reporting framework of 22, the sector repository of 23 or the disclosure framework of 25, and the AI sandbox is on the 2026-27 agenda as first steps. The regulator-owned items are pending; the entity-owned items are being written into supervisory expectation. Nobody should wait for the first before building the second.
The FREE-AI build list for banks and NBFCs
The twelve entity-facing recommendations, plus capacity building, reduce to ten things a platform team ships.
1. A board-approved AI policy. Recommendation 14 lists governance structure, accountability, risk appetite, operational safeguards, auditability, consumer protection, disclosures, the model lifecycle and liability, with the risk management committee owning AI risk. Annexure V gives an eight-part outline with an annual review. The test is whether every obligation points at an artefact the platform produces. Write it as a layer on the model risk framework the draft requires, not a parallel document, so the two cannot drift.
2. An AI inventory. Recommendation 23 asks for models, use cases, target groups, dependencies, risk category and grievances, updated at least half-yearly; the draft adds owners, validators and findings, and a rule that nothing unlisted runs. The only inventory that stays true is one the platform generates: every model call passes a gateway that refuses unregistered callers, every agent runs as a registered principal, as I argued in July, and egress logs reveal the AI inside vendor products.
3. Risk classification. The report’s tiers are concrete: internal summarisation is low risk; chatbots and fraud detection used for preliminary assistance are medium; credit underwriting, and autonomous systems that handle customer interactions, make financial decisions or move funds, are high. Store the tier as a field that drives approval authority, red-team frequency, audit depth and oversight mode, and recompute it whenever a system gains a tool, a data class or autonomy. Recommendation 15’s data controls belong here, because tier and data class together decide where a call may run, and the report wants sensitive data kept in institution-controlled environments when external models are used.
4. AI in product approval. Recommendation 17 puts every AI-enabled product through product approval, with evaluations for fairness, bias, understandability, customer protection, cybersecurity and compliance, random sampling of outputs, back-testing and expert review, run by a team independent of the developers. That is an evaluation bench with a release gate owned outside the build team.
5. Validation, monitoring and fallback. Recommendation 16 asks for validation, drift and bias detection and defined fallbacks, with human oversight of medium- and high-risk uses. Recommendation 21 extends business continuity to silent degradation: a model should be able to declare itself unavailable and trigger a backup, and people should check a sample of decisions, the report’s example being 1%. Build the sample queue, drift monitors and fallback route as platform services, and pin vendor model versions.
6. Incident reporting. The sector framework of recommendation 22 does not exist yet; the entity half does not need it. The report defines an AI incident broadly, as development, use or malfunction that leads to harm, offers an indicative form in Annexure VI, and says that reporting what was observed, where and how it went wrong and what was done should suffice. Keep a register with severity tiers and a clock, and send anything that is also a cyber incident to DAKSH within six hours. Under recommendation 8, the register is also the evidence that earns tolerance.
7. Disclosure and grievance. Recommendation 18 says customers must be told when they are dealing with AI, be able to reach a human whenever they want, and never be misled about AI use; voice AI should run on verified 1601-series numbers and online channels should be clearly labelled. Make disclosure and handoff channel components, not prompt text, and tag every complaint with the system that caused it, so the inventory’s grievance field and the annual-report disclosure of recommendation 25 fill themselves.
8. AI-specific security and red teaming. Recommendation 19 names adversarial attacks, data poisoning, model manipulation and deepfakes, wants assessment to continue after deployment, and says systems should be capable of instant termination. Recommendation 20 sets red teaming at least semi-annually for medium- and high-risk systems, before deployment for low-risk ones, and after major updates. A kill switch becomes a control only once it has been drilled.
9. Audit. Recommendation 24 asks for risk-based audit of data, models and outputs, independent third parties for high-risk uses, a framework review at least every two years, and checks that processes can be stopped, paused or unwound. If items 1 to 8 write their evidence to one store keyed by inventory identifier, an audit becomes a query.
10. Capacity. Recommendation 10 asks for AI competence from the board down. Record who may override what and train those people first, because the draft wants oversight staff with the expertise and authority to challenge and escalate.
A worked example: a customer-service assistant at a bank
Take a generative AI assistant in a commercial bank’s app and website. It answers product questions from the knowledge base, shows a logged-in customer recent transactions, raises service requests such as a card block or a dispute, and hands off to the contact centre. Customer support was the commonest AI application in the RBI’s survey.
Tier. In the report’s examples a chatbot giving preliminary assistance is medium risk, but an assistant that acts on an account moves towards the high-risk description of autonomous systems that handle customer interactions or move funds, and under the draft low complexity cannot offset autonomy. The design decision is to keep anything that moves money out of the assistant’s tools, make the card block an action the customer confirms, and make the dispute a case opened for a person. The reasoning goes into the inventory.
Inventory and data. The entry lists the model provider and pinned version, the retrieval index, the core-banking and card APIs, the cloud region, the target group, the tier, the owner and the validator, with grievances counted from launch. Account data is fetched inside the bank’s boundary, and the prompt carries masked identifiers (recommendation 15).
Approval and validation. The independent evaluation team runs the release gate: answers checked for grounding in the knowledge base, refusals checked for anything resembling financial advice, quality compared across the bank’s languages, and quoted fees checked against the product master (recommendations 16 and 17). After launch a weekly sample of conversations goes to human reviewers, with the report’s 1% as a floor.
Disclosure and handoff. The first message says the customer is talking to an AI assistant, a visible control reaches a person at any point with the conversation attached, the voice version runs on the bank’s 1601-series number, and complaints are tagged with the assistant’s identifier (recommendation 18).
Security and red teaming. Before launch and at least twice a year the red team tries prompt injection through pasted text and documents, tries to extract another customer’s data, and tests the report’s own example, a model leaking account numbers when queried in unintended ways (recommendations 19 and 20). Sessions keep no memory beyond the conversation, as the draft’s limits on context persistence suggest.
Fallback and incidents. If the drift monitor or the human sample crosses its threshold, the assistant declares itself unavailable and the app reverts to menus and the contact-centre queue (recommendation 21). A wrong fee quoted to customers is an AI incident needing remediation and, where money was lost, compensation, which the report puts on the entity. Showing one customer another’s transactions is also a cyber incident on the six-hour clock (recommendation 22).
Audit, disclosure and people. Internal audit covers the assistant at the depth its tier sets and confirms that the kill switch, fallback and override work (recommendation 24). The annual report says where the bank uses AI and how many AI-related complaints it resolved (recommendation 25), and the supervisors who receive handoffs are trained to log assistant errors (recommendation 10).
Having built assistants for banks, I would put most of the effort into the handoff, the fallback and the record of what the assistant said, because those are what a customer and a supervisor see when the model is wrong.
Recommendations
- Build the inventory first, from the platform. Keep one schema with the report’s fields and the draft’s, populated by the gateway and agent registry, covering AI inside vendor products and attested every six months.
- Tier every entry and let the tier drive controls. Use the report’s low, medium and high examples, add reliance and autonomy as the draft does, and recompute on any new tool, data class or degree of autonomy.
- Write the board AI policy as a layer on the model risk framework, on the Annexure V outline, owned by the risk management committee and reviewed annually.
- Ship disclosure, human handoff and grievance tagging on every customer-facing system now. They are cheap, and the report, the draft and both August speeches ask for them.
- Open an AI incident register and clock before the RBI designs one. Route cyber incidents to DAKSH within six hours. The tolerance in recommendation 8 goes to entities that can show their reports.
- Put AI into product approval with an independent evaluation team and a release gate, and validate vendor models yourself, under contracts that give documentation, audit rights and an exit.
- Red-team on the report’s schedule and drill the kill switch and the fallback, with every finding filed where audit can read it.
- Make audit and the annual-report disclosure queries over one evidence store, and train the board and the people in the loop, recording who may override what.
