Indian banks and financial institutions are now answering to three active sources of AI-relevant regulatory expectation simultaneously. None of them use "artificial intelligence" the same way, and none maps cleanly onto the EU AI Act's high-risk classification system that most global governance tooling is built around. That mismatch creates a real practical problem: how do you build one controls framework that satisfies all three without running three separate compliance programs that quietly duplicate each other's work.
This piece maps each framework's key AI-relevant obligations to the governance controls that actually satisfy them, with the goal of answering all three regulators from a single evidence base rather than three disconnected ones.
RBI: the evidence mandate
RBI's supervisory stance on AI in regulated entities centers on three obligations that matter most for a governance team building controls.
Model governance documentation. Every AI system in production needs documented governance — purpose, risk classification, validation evidence, named accountability — kept current through material changes, not written once and filed.
Evidence trails for examination. Regulated entities need to produce, on request, evidence that AI systems have actually been tested, validated, and monitored. RBI's examiners have been consistent that evidence means verifiable records, not policy documents describing an intention to have records.
Outsourcing controls. AI systems or components procured from third parties carry the same oversight obligation as internally built systems. Vendor management needs AI-specific due diligence, including access to validation documentation and the right to audit.
The controls that actually satisfy these in practice: a complete AI asset registry with risk classification and named owners, a signed and tamper-evident evidence ledger with timestamped validation records, and a vendor risk module that captures third-party AI due diligence as evidence rather than as a checkbox.
SEBI: oversight at every decision point, not just at the trade
SEBI's attention to AI use in algorithmic advisory, market surveillance, and trading operations is built around a different problem than RBI's: accountability for AI-driven decisions in high-velocity, high-consequence contexts where human review can't happen at transaction speed.
The obligations that matter here: audit trails for AI-driven recommendations and decisions, human oversight at defined intervention points — including the ability to halt AI-driven activity — and documentation of decision logic sufficient for post-hoc review.
The control that actually matters isn't inference-time logging, which most systems already have. It's decision-level audit trails — records capturing not just the model's output, but what context it had, what data it accessed, and what downstream action it triggered. That distinction gets more important, not less, for agentic systems operating across multiple steps, where "what the model output" and "what actually happened" can diverge by several steps.
The controls that satisfy this: forensic replay (reconstructing any decision state at any point in time from the signed ledger), a three-lines-of-defense evidence base that shares one record set across operational, oversight, and audit functions instead of three separate ones, and decision-logic documentation exported in a format regulatory systems can actually ingest.
DPDP Act 2023: what AI inference means for data obligations
The Digital Personal Data Protection Act 2023 reaches further into AI than most implementation guides suggest, because the relevant obligations aren't only about data storage — they apply to the AI inference pipeline itself.
When an AI system processes personal data to generate a recommendation, a risk score, or a decision, that processing triggers DPDP consent and purpose-limitation requirements — even if the model was trained on anonymized data. If the inference pipeline receives and processes identifiable inputs at run time, the obligation attaches to that processing, regardless of how the model was trained.
For credit decisioning, fraud detection, and customer-facing AI in banking, this means purpose-limitation documentation for each inference use case, audit trails for personal data processed during inference, and a working data-principal-rights mechanism — including the customer's right to know AI was used in a decision affecting them.
The controls that satisfy this: inference-pipeline audit logging (what data, when, for what purpose), purpose-limitation policy enforcement that actually blocks inference on data categories outside a model's declared scope, and a data-rights module that can trace personal data through the inference pipeline for a subject access request.
Building one program instead of three
The genuinely good news is that the overlap between these three is real, not marketing. All three frameworks expect a complete AI inventory, evidence that systems have been validated and monitored, named accountability, and audit trails producible quickly on request. That's the foundation worth building once.
Where I've seen teams go wrong is assuming the overlap covers everything — it doesn't. Build the shared foundation (inventory, evidence ledger, accountability framework) once, then add the framework-specific layer on top: SEBI-specific decision tracing, DPDP-specific inference logging, RBI-specific outsourcing controls. A well-structured governance program makes that mapping explicit, so evidence collected for one framework satisfies the others wherever the obligations genuinely overlap — and doesn't pretend they overlap where they don't.
The failure mode to avoid is building three separate compliance programs that collect overlapping evidence in incompatible formats — which is exactly what happens when governance gets bolted on one regulation at a time, after the fact, by whichever team happened to own the relationship with that regulator. Institutions that map controls to obligations up front, and build deliberately for the overlap rather than assuming it, end up with a materially lower compliance cost as India's AI regulatory landscape keeps developing.
What to build first
- Build one AI inventory with risk classification and named owners, tagged to all three frameworks at once, rather than three separate registers.
- Stand up a signed, tamper-evident evidence ledger before your next examination cycle — this is the single control that satisfies the "evidence trail" requirement across RBI, SEBI, and DPDP simultaneously.
- For any AI system touching trading, advisory, or surveillance, build decision-level audit trails — not just inference logging — now, before an examiner distinguishes between the two for you.
- Add inference-time purpose-limitation enforcement to every model processing personal data, and verify it actually blocks out-of-scope feature access rather than just documenting intent to do so.
- Map each existing piece of evidence to all three frameworks explicitly, and only build framework-specific modules for the obligations that genuinely don't overlap.