RBI guidelines and AI: outsourcing, localisation and audit

There is no standalone RBI AI guideline as of this writing. What exists is a set of directions that already bind banks, NBFCs and payment firms, and every AI system you deploy lands inside them: the directions on outsourcing of IT services, the requirement that payment system data be stored in India, the IT governance and information security directions, and the fair practices and grievance expectations that apply to any automated decision. The practical question is not "what does RBI say about AI" but "which of these does my AI system trigger, and what evidence will I need".

This article maps the four areas most AI projects in Indian financial services touch, explains what each one means for architecture and vendor choice, and describes how we build so that the compliance conversation is short. It is a builder's reading of the regulatory landscape, not legal advice; your compliance team and counsel own the interpretation.

Why RBI AI guidelines matter to a build decision

Most AI projects in a bank stall at the outsourcing review, not at the technology. A hosted model API is a third-party service processing customer data; that is an outsourcing arrangement in the regulator's frame, with due diligence, contractual, audit-access and exit expectations attached. Teams that discover this at sign-off lose months. Teams that design for it from day one, usually by keeping the model and data inside their own environment, find the review becomes an infrastructure and vendor question they already know how to answer. The fintech industry page describes how we approach regulated builds.

The four areas and what they mean for AI

Outsourcing: who is processing the data

The outsourcing directions ask a simple question: is a third party performing an activity, on your data, that you would otherwise perform yourself? If a model provider's endpoint reads a customer's statement to classify transactions, the answer is yes. That means the provider goes through due diligence, the contract must give you and the regulator audit access, you need an exit plan, and the arrangement is reported in your outsourcing register. None of this is impossible with a large provider, but it is slow and it constrains model choice.

The alternative is to run open-weight models inside your own cloud account or data centre. The cloud provider remains an outsourced party, but that arrangement typically already exists and has been reviewed. The model becomes software you run, not a service you buy. This is the main reason our BFSI work defaults to private deployment, as set out in private AI for banks.

Localisation: where the data sits and where it travels

Data localisation for payment data is strict: the full end-to-end transaction record must be stored in India. Inference is processing, and processing outside India on payment data creates a question you do not want to answer. For AI systems the safe pattern is to keep model inference, embedding generation, the vector index and all logs in an Indian region or on-prem. Do not assume a global provider's "India region" covers every component; check where logs, backups and support tooling actually live.

Non-payment customer data is governed by broader expectations under the IT directions and by the DPDP Act. We treat all customer data the same way for simplicity: it stays inside the perimeter. The DPDP obligations are covered in DPDP Act 2023 and AI.

Audit: the record you will be asked to produce

An auditor or an RBI inspection team will ask what the system did, on which data, under whose authority, and whether it changed. The evidence needed is a single log that ties each request to an authenticated identity, the model version, the retrieved sources, the output and any downstream action. Change management evidence is a record of every prompt and model change with the evaluation results that justified it. Business continuity evidence is a plan for what happens when the GPU host or model server fails.

Build these from the start. Retrofitting an audit trail onto a system that was built as a demo is the single most expensive mistake we see. The structure we use is described in AI audit trails: what regulators will ask to see.

Accountability for automated decisions

Where an AI system influences a credit, pricing, collections or complaint outcome, the regulator's expectation is that the entity remains accountable: the decision must be explainable to the customer, non-discriminatory, reviewable by a person, and recorded. In practice we design AI in these flows as decision support with a human decision-maker, or as automation within narrow, board-approved policy limits with a human override. A model that recommends and a person who decides is a defensible pattern; a model that decides with no record is not.

Explainability in practice

Explainability does not mean publishing model weights. It means the customer-facing reason for an outcome is derived from documented factors, the internal record shows which inputs and rules drove it, and a reviewer can reproduce it. For LLM-based systems this is why we insist on grounded outputs with citations and structured reasons, not free text.

A worked example

An NBFC wanted to automate the first pass of KYC document review. Before design, the compliance team listed the directions in play: outsourcing (if a hosted vision API was used), localisation (identity documents and account data), IT governance (change control and logs) and fair practices (a rejected applicant must get a reason and a human review). The architecture followed: an open-weight vision model on GPU instances inside the NBFC's own Indian cloud region, extraction into a review queue, every extraction logged against the reviewer and the model version, and a rule that no application could be rejected without a human decision recorded. The outsourcing register gained no new entry because the cloud provider was already on it. The audit team received one report per period, reconciled to the case system. The KYC document intelligence case study describes the work.

Team and timeline

Regulatory mapping happens inside a Sprint Zero discovery sprint, $3,250 / ₹2,00,000 over ten working days, credited to the build. Your compliance officer, information security lead and the business owner join two workshops; we produce the use-case shortlist, the control map against each direction, the architecture and a fixed price. The build itself is usually delivered as private and self-hosted agentic AI from $31,500 / ₹20.8L plus infrastructure, over eight to sixteen weeks depending on integrations, with a shadow period before anything acts on a customer record. Care Plans cover model change management and evaluation reruns after go-live; see the pricing page for the tiers.

Before you start: a checklist

• List which RBI directions the use case triggers and name the internal owner for each
• Decide whether the model will be hosted (outsourced) or self-hosted (your infrastructure)
• Confirm the region for inference, embeddings, index, logs and backups
• Check the cloud provider is already in your outsourcing register
• Define which decisions the system may take alone and which need a human
• Design the audit log before the first prompt is written
• Agree the customer-facing reason format for any automated outcome
• Plan the change-management record for prompt and model updates

Questions clients ask

• Is a hosted model API always an outsourcing arrangement? If it processes customer data, treat it as one and involve the outsourcing team; if it only drafts public content on non-customer data, the risk is lower but still document it.
• Does self-hosting remove all third-party risk? No. The cloud provider, GPU host and support vendor remain third parties; the model itself stops being a service.
• Can we use AI for credit decisions? As decision support with a human decision and a recorded reason, yes. Fully automated rejection without review is hard to defend.
• What does the inspection team actually look at? Policies, the outsourcing register, logs tied to identity, change records with evaluation evidence, and the continuity plan.
• Do these expectations apply to fintech partners of banks? Banks push their obligations down to partners contractually, so a fintech serving a bank should build to the same standard.

Related reading

The primary sources are the RBI's directions on outsourcing of IT services and IT governance on the regulator's own site. Related posts: self-hosted LLMs for BFSI, AI governance for mid-size companies and the fintech industry page.

Map the directions first, build the log before the prompt, and keep a person on every decision the regulator would ask about.