Permanent Assurance or Permanent Risk: The AI Compliance Framework Indian Banks Must Build Now

The Regulatory Landscape: EU AI Act, RBI Circular, and NIST AI RMF

Indian banks and NBFCs that process data touching EU residents are subject to two distinct AI regulatory regimes simultaneously. RBI's draft AI governance circular — released for industry comment and expected to be finalised — establishes expectations around model risk management, explainability, fairness, and board-level accountability. The EU AI Act, which entered into force in August 2024 and whose high-risk AI provisions apply from August 2026, imposes a conformity assessment regime, mandatory technical documentation, post-market monitoring, and human oversight requirements for AI systems in credit scoring, insurance risk assessment, and employment — all categories directly relevant to Indian BFSI operations with EU data exposure.

These two regimes are not identical, but they are not irreconcilable. Both require documented risk classification of AI systems, ongoing monitoring of model behaviour in production, and a named accountability structure. The EU AI Act formalises this through its Annex III high-risk classification list and Article 9 risk management system requirements. RBI's framework uses the language of model risk management familiar to Indian banks from their SR 11-7-equivalent internal policies. The structural overlap is real, and a well-designed AI compliance framework for banks covering the EU AI Act and RBI can satisfy both without running parallel documentation silos.

The bridge between these two regimes is NIST AI RMF 1.0, published in January 2023. Its four core functions — Govern, Map, Measure, Manage — map cleanly onto both regulators' expectations. Govern covers board and senior management accountability, which RBI mandates and which the EU AI Act enforces through its authorised representative and conformity assessment obligations. Map covers system-level risk classification. Measure covers ongoing evaluation — bias testing, performance monitoring, drift detection. Manage covers the response and remediation cycle. Treating NIST AI RMF as the operating architecture, with EU AI Act and RBI requirements mapped as jurisdiction-specific controls, reduces duplication and gives the compliance function a single audit-ready evidence structure.

Compliance Gap Diagnostic: Where Indian Banks Actually Stand

Most Tier-1 and Tier-2 Indian banks enter this dual-regulator environment with three structural gaps. First, model inventories are incomplete or inconsistently maintained: AI systems procured through vendor relationships, embedded in core banking platforms, or built by business units outside the model risk team often sit outside the formal model register. Under both RBI's draft circular and EU AI Act Article 51, every high-risk AI system must be registered and documented before deployment. An incomplete inventory is not a paperwork problem — it is an unmanaged liability.

Second, explainability evidence is frequently produced at launch and not refreshed. Credit decisioning models are the highest-risk category under EU AI Act Annex III and attract equivalent scrutiny under RBI's fairness expectations. Producing a SHAP summary at model validation time and filing it does not constitute ongoing explainability assurance. If the model's feature importance distribution shifts post-deployment — which it will, as economic conditions change — the original explainability documentation is no longer accurate. The gap between what was documented and what the model is currently doing is a conformity gap.

Third, vendor AI governance is largely absent. Many Indian banks consume AI-enabled services through third parties — credit bureau integrations, fraud detection platforms, conversational AI for customer service — without contractual assurance obligations. The EU AI Act's Article 28 establishes that where a deployer has significant control over an AI system's purpose or use, obligations can shift upstream to the bank itself. RBI's outsourcing guidelines place ultimate accountability with the regulated entity regardless of sourcing. Neither framework allows compliance responsibility to be contracted away. Banks need vendor assurance clauses that require technical documentation, audit access, incident notification timelines, and evidence of ongoing conformity testing.

Continuous Assurance vs. One-Time Audit: Why the Distinction Is Existential

The most consequential misunderstanding in Indian BFSI AI compliance is treating conformity as a state to be achieved and certified, rather than a condition to be maintained and demonstrated continuously. This error is understandable: Indian banks have long operated on audit cycles — internal audit, RBI inspection, statutory audit — where a point-in-time assessment produces a finding that is then remediated. That model does not transfer to AI systems.

The EU AI Act's Article 9 requires that the risk management system for high-risk AI be a continuous iterative process, updated throughout the system's lifecycle. Article 72 mandates post-market monitoring. These are not aspirational standards — they are conformity conditions. A bank that conducts a thorough pre-deployment validation and then relies on periodic internal audit to verify ongoing compliance will fail a conformity assessment because the assessment asks for evidence of continuous monitoring, not a historical audit report.

A permanent AI assurance function is the only defensible response. This does not mean a large team. It means embedding evaluation checkpoints in the model lifecycle at defined intervals — not just at launch. It means automated monitoring pipelines that generate evidence artefacts, not just operational dashboards. It means a documented escalation path when drift or performance degradation is detected, with records of what decision was made and by whom. A pre-launch checklist satisfies a checkbox. It does not satisfy a regulator who can ask, on any given day, what your model did yesterday and why.

The RBI circular's expected requirement for board-level reporting on AI risk reinforces this. If the board is to receive meaningful AI risk reports, the underlying assurance function must be generating continuous evidence. Boards cannot attest to AI risk on the basis of a six-month-old validation report.

Building the Framework: From Gap to Governed Lifecycle

The practical path from current state to governed AI lifecycle has four stages. First, complete and classify the model inventory — every AI system, including vendor-supplied ones, mapped against the EU AI Act Annex III high-risk list and RBI's risk tiers. Second, establish baseline technical documentation for each high-risk system: intended purpose, training data provenance, performance metrics, explainability methodology, and human oversight procedures. Third, instrument production monitoring so that every high-risk model generates continuous evidence of performance, fairness, and drift — not alerts sent to an inbox, but structured artefacts stored in an audit-ready repository. Fourth, define the governance layer: who reviews evidence, at what frequency, what thresholds trigger escalation, and how decisions are recorded.

This is not a technology problem primarily — it is a process and accountability problem that technology enables. The banks that will satisfy both RBI and EU AI Act are not necessarily the ones with the most sophisticated ML infrastructure. They are the ones that have made AI assurance a permanent organisational function with clear ownership, defined cadences, and evidence that survives regulatory scrutiny on any given day — not just the day before an inspection.

The spoke articles linked below address the five technical disciplines that underpin this framework: model risk management, bias and fairness testing, operational resilience under DORA, audit trail architecture, and vendor AI governance. Each is a separable problem. Together, they define what a complete AI compliance framework for banks navigating the EU AI Act and RBI actually looks like in practice.