RBI AI Circular 2024: A Compliance Checklist for Indian Banks

RBI's supervisory conversations with regulated entities on AI have been getting specific — not principles-only language, but concrete expectations around governance frameworks, audit trails, AI inventories, outsourcing controls, customer protections, and incident reporting. Whatever the precise document trail, the six obligation areas below are the ones showing up in real RBI examination conversations, and each is treated as an examination requirement, not an aspiration.

This checklist works through each obligation, what an examiner will actually ask for, and the gap most banks are currently carrying. It isn't legal advice on any specific circular — it's a practical map of what examination-readiness requires operationally.

Who this applies to. Every RBI-regulated entity that develops, procures, or deploys AI — banks (public and private), NBFCs, housing finance companies, payment aggregators, and anything else RBI regulates. If an AI system makes or influences a decision affecting a customer, this applies.

Obligation 1: board-approved AI governance framework

Regulated entities need a board-approved AI governance policy covering the full lifecycle — development, validation, deployment, ongoing monitoring. This isn't a document you write once and file. The board has to approve it, own it, and receive regular reporting on its status.

What an examiner will ask for: the board resolution approving the framework, with a date; the current framework document, with a last-review date; evidence the board or a board committee actually receives AI risk reporting; named ownership — who runs AI governance, and who do they report to.

Common gap. Most banks have a technology risk policy with one paragraph on AI. That's not AI-specific governance, and the examiner knows it isn't, because the failure modes are different — a credit model failing from distribution shift isn't an IT incident, and an IT risk framework was never built to catch it.

Obligation 2: audit trail

Complete, timestamped records of AI model decisions and governance actions — beyond ordinary application logging. An audit trail in the sense an examiner means it has to be tamper-evident, has to capture decision context (not just the output), and has to be producible in a format an examiner can actually review on the spot.

What an examiner will ask for: a sample audit trail for a specific decision — a credit decline, a fraud alert — showing model version, input features, output, and timestamp; evidence the trail can't be altered after the fact; the governance audit trail (who approved which model, when, on what evidence); a retention policy with retrievability on request.

Common gap. Application logs capture events. They don't capture who approved the model, what validation evidence was reviewed, or what conditions attached to the approval. These live in different systems at most banks, and nobody's connected them. "Show me the governance record for this credit model's last deployment" is the question that, in my experience, most reliably triggers a multi-day manual document hunt.

Obligation 3: AI inventory

Every AI system in production registered and risk-classified — broader than a model validation register, which usually only covers statistical models the model risk function has formally validated. The scope here is wider: rule-based systems with learned components, GenAI, autonomous agents, and AI embedded inside vendor-provided systems all count.

What an examiner will ask for: a complete register of every AI system in production, including third-party and vendor-provided AI; a risk classification per system (typically Critical/High/Medium/Low); business function, data used, customer impact, and owner for each; date of last validation or review.

Common gap. Banks generally know about the models their model risk function has validated. They don't have visibility into AI embedded inside vendor software — loan origination platforms, CRM systems, fraud tools — AI deployed by business units without formal IT involvement, or agents a product team spun up last quarter. The obligation covers all of it. Finding the AI you don't know you have is usually the first gap to close, before any governance process can run against a complete list.

Obligation 4: outsourcing and third-party controls

When AI is sourced from or operated by a third party, the regulated entity keeps the governance responsibility. This extends existing outsourcing risk management to AI-specific risks: drift, data lineage, third-party model security, and the ability to audit third-party AI decisions.

What an examiner will ask for: a list of third-party AI providers and what they provide; contractual provisions for documentation, audit rights, incident notification, and data residency; evidence of ongoing performance monitoring post-deployment; an exit plan if a provider terminates.

Common gap. Banks generally have outsourcing frameworks built for services — call centres, IT operations — not for AI embedded in software. A vendor whose loan origination system includes a credit-scoring component is providing AI, full stop, and most contracts signed before this became a live expectation have no AI-specific documentation, audit-rights, or validation-access provisions at all.

Obligation 5: customer protection

AI that reaches customers — directly, or through outputs that inform customer-facing decisions — needs specific controls: preventing harmful or incorrect outputs from reaching customers, disclosing AI involvement in decisions, and giving customers a path to human review.

What an examiner will ask for: controls blocking harmful, incorrect, or discriminatory outputs; testing evidence — how the guardrail is tested, how often, against what adversarial inputs; customer disclosure where AI is used in decisions; a defined human-review process on customer request.

Common gap. Runtime guardrails are the technology gap most commonly found here. Banks running GenAI for chatbots, document extraction, or advisory tools often lean on the underlying LLM's built-in safety settings — which are tuned for generic abuse, not BFSI-specific attack categories like prompt injection, financial-advice violations, or regulatory-metric gaming.

On false positives. A guardrail with a high false-positive rate creates a different compliance problem: it blocks legitimate banking queries as if they were harmful, producing an operational outage of its own. In Zytra's own FinProof benchmark, Meta's PromptGuard recorded a 96.9% false-positive rate on BFSI banking queries, against 0.5% for Aval on the same test set. Whatever guardrail you're running, an examiner asking about customer protection controls is implicitly asking about both sides of that trade-off — blocking real attacks and not blocking real customers.

Obligation 6: incident reporting

Material AI failures have to be reportable, with supporting documentation: a definition of what counts as a material AI incident, a classification and escalation process, and documentation sufficient to support a regulatory notification — timeline, root cause, impact, containment.

What an examiner will ask for: a board-approved definition of a material AI incident; a 12-month incident log with classification and resolution status; any incidents actually reported to RBI, with the notification and supporting documentation; a root-cause analysis process for AI failures specifically.

Common gap. Most incident frameworks cover IT and operational incidents. An AI-specific incident — a model producing systematically wrong outputs for a subset of customers, an agent exceeding its authorization scope, a GenAI system generating something that reads as financial advice — doesn't map cleanly onto IT incident categories, and most banks haven't built a separate classification path for it.

The checklist, in one table

What readiness actually looks like

An institution that can walk an examiner through all six obligations without a manual document search has gotten there by building three things together: a discovery and inventory system covering shadow and vendor AI, a governance workflow that produces audit-trail evidence as a by-product of normal activity rather than a pre-inspection scramble, and runtime controls tested against BFSI-specific adversarial inputs with FPR measured and documented.

Every bank I've seen go through an RBI technology examination on AI in the last couple of years tells the same story: the hard question was never "do you have a governance framework" — they do. It was "show me the evidence." That gap, between having a policy and being able to produce proof the policy is actually operating, is the one that actually costs institutions time and credibility in the room.

If "show me the audit trail for this credit model's last deployment" triggers a multi-day document search in your institution, you are not examination-ready, regardless of what the governance policy on file says.

What to do before your next examination

1. Run a dry-run audit-trail request on one live credit or fraud model today, and time how long it takes to produce — that number is your real readiness metric.
2. Build or complete your AI inventory including vendor-embedded and shadow AI before the model risk register is mistaken for the whole picture.
3. Review every AI vendor contract for documentation, audit-rights, and incident-notification provisions, and flag the ones signed before AI governance was a live expectation.
4. Measure your customer-facing guardrail's false-positive rate on your own banking traffic, not a generic benchmark, and document it.
5. Write a board-approved definition of a material AI incident this quarter if one doesn't already exist — it's the single most commonly missing document in this list.