Can a Tier-2 Bank Build a Credible AI Governance Capability Center in 90 Days?

The Problem Behind the Board Mandate

Most Tier-2 Indian banks and mid-size insurers facing RBI's draft AI governance expectations arrive at the same internal conversation: the board has mandated AI oversight before fiscal year-end, the compliance team has drafted a policy, and the AI or technology leadership is now trying to explain why a policy document is not enough. The gap is real. AI governance capability center setup for BFSI compliance is an operational problem, not a documentation problem. Regulators are moving toward frameworks that expect demonstrable, repeatable processes — an inventory you can produce on request, evaluation evidence you can defend, and a monitoring function that does not switch off after go-live.

This article is a phased 90-day implementation guide for the governance or risk lead who has the mandate but not yet the blueprint. The structure is three 30-day sprints. Each sprint has a component checklist, a roles-and-responsibilities anchor, and a compliance callout. Nothing here requires a greenfield technology investment; the first sprint can begin with spreadsheets and existing model documentation.

Sprint 1 (Days 1–30): Inventory, Risk Classification, and Governance Spine

The first sprint has one non-negotiable output: a live, versioned model inventory. Without knowing what AI systems are in production, in pilot, or in procurement, every downstream governance decision rests on incomplete ground. The inventory should capture, at minimum: system name, business function, data inputs, output type, whether the output is human-reviewed or automated, the population affected, and the team responsible.

Component checklist for Sprint 1: complete the model inventory across all business units; establish a risk-tiering schema that classifies each system by potential harm and decision autonomy; draft a governance charter naming the AI Risk Owner, the Model Validation Lead, and the Compliance Liaison; convene the first meeting of the AI Oversight Committee; and produce a gap assessment against your existing model risk management policy.

On risk classification: regulators in multiple jurisdictions have converged on the principle that AI systems making consequential decisions about individuals — credit, insurance pricing, claims — carry higher governance obligations than systems used for internal process efficiency. Your risk-tiering schema should reflect that principle and be documented with the rationale for each tier assignment. The specific categories and thresholds you apply should be grounded in your institution's risk appetite, not copied wholesale from any single regulatory text.

Compliance anchor — Sprint 1: RBI's draft framework on AI governance, released for public comment, signals an expectation that regulated entities maintain documentation of their AI systems and the controls applied to them. This is directionally consistent with the general risk management obligations under RBI's existing model risk guidance. If your institution also operates or procures systems that touch EU counterparties, the EU AI Act's Article 9 requires a risk management system for high-risk AI — interpreted broadly as a documented, iterative process, not a one-time assessment. Maintaining a structured inventory positions you to respond to either set of expectations without rebuilding from scratch.

Roles and responsibilities — Sprint 1: The AI Risk Owner holds accountability for the governance charter and has the authority to halt a deployment. The Model Validation Lead owns the inventory and the risk-tiering schema. The Compliance Liaison maps internal controls to regulatory expectations and owns the gap assessment. The Chief Risk Officer reviews and approves the governance charter. Without these four roles named and empowered, the sprint produces documents, not governance.

Sprint 2 (Days 31–60): Evaluation Infrastructure and Assurance Pipelines

With an inventory in place, Sprint 2 shifts from knowing what you have to knowing whether it is safe to run. This is where most institutions stall — they have model validation processes inherited from traditional statistical modelling, and those processes are not sufficient for systems with language model components, reinforcement-learning reward signals, or agentic decision loops.

Component checklist for Sprint 2: define evaluation criteria for each risk tier established in Sprint 1; build or procure a test harness capable of running adversarial prompts, distributional shift scenarios, and bias audits against production or staging model versions; establish a red-teaming schedule — at minimum for any customer-facing AI system; document the evidence standard required before a model moves to production; and create a model card template that captures evaluation results in a format reviewable by the Compliance Liaison.

The evaluation criteria should be tailored to the system type. A credit-scoring model has different failure modes from a conversational loan-eligibility assistant. Conflating them into a single checklist produces coverage gaps. For automated systems that process personal data and affect data principals, there is a strong practical case for including accuracy and bias metrics in the evaluation pipeline — India's DPDP Act establishes data principal rights including correction rights, which create meaningful operational exposure if your model is producing systematically inaccurate outputs. This is a reasonable inference from the structure of the Act rather than a direct statutory mandate for automated-decision testing, and legal counsel should confirm the precise scope for your institution.

Compliance anchor — Sprint 2: The EU AI Act's Article 9 requires that the risk management system for high-risk AI be implemented as a continuous, iterative process throughout the system's lifecycle, including testing to identify the most appropriate risk management measures. This language supports the case for a standing evaluation pipeline rather than a pre-launch audit. Separately, the general principle behind ISO 42001:2023 — the AI management system standard — is that evaluation and monitoring processes should be planned against stated AI objectives and risk criteria. These two frameworks reinforce the same structural point: evaluation is not an event, it is infrastructure.

Roles and responsibilities — Sprint 2: The Model Validation Lead owns the test harness and the red-teaming schedule. A dedicated AI Assurance Engineer (which may be a contracted role in a Tier-2 institution) runs the adversarial and distributional shift scenarios. The Compliance Liaison reviews model cards against the regulatory gap assessment produced in Sprint 1. The AI Risk Owner approves the evidence standard for production entry.

Sprint 3 (Days 61–90): Continuous Monitoring, Escalation Protocols, and Board Reporting

The third sprint converts the capability center from a project into a standing function. The risk here is treating Sprint 3 as a wrap-up phase. It is not. It is the phase where governance becomes operational rather than preparatory.

Component checklist for Sprint 3: deploy a monitoring layer that tracks model performance, data drift, and output distribution in production; define escalation thresholds and the escalation path — who is notified, within what timeframe, and what remediation authority they hold; produce the first board-level AI governance report; document the cadence for re-evaluation (triggered by drift alerts, significant model updates, or material changes in the population served); and conduct a tabletop exercise simulating a model failure event to test whether the escalation protocol actually works.

Compliance anchor — Sprint 3: ongoing monitoring is a recurring expectation across the major AI governance frameworks. RBI's draft guidance, the EU AI Act's post-market monitoring obligations under Article 72, and the general continual improvement requirements of ISO 42001:2023 all point in the same direction: governance obligations do not end at deployment. A board-level report produced at the close of Sprint 3 serves two purposes — it satisfies the internal board mandate and it creates a documentary record that a regulator could reasonably review.

Roles and responsibilities — Sprint 3: The AI Risk Owner owns the escalation protocol and the board report. The Model Validation Lead owns the drift monitoring configuration and the re-evaluation cadence. The Compliance Liaison owns the mapping between monitoring outputs and regulatory reporting obligations. The Chief Risk Officer presents the governance report to the board.

What 90 Days Does and Does Not Deliver

At the end of 90 days, a disciplined execution of these three sprints produces a credible, operational first version of an AI governance capability center: a live inventory, a functioning evaluation pipeline, a monitoring layer with defined escalation, and a board report. It does not produce a fully mature function. Governance maturity — consistent coverage across an expanding AI portfolio, integrated tooling, and a trained internal red-team — takes longer. But credible and operational is the threshold that satisfies a board mandate and positions the institution to respond to a regulatory request without scrambling. That is the goal of the 90-day build.

Assurance infrastructure built in this sequence also compounds. The inventory built in Sprint 1 feeds the evaluation criteria in Sprint 2. The evaluation evidence in Sprint 2 feeds the monitoring baselines in Sprint 3. Each phase makes the next one faster and more defensible. Institutions that skip to use-case delivery without this foundation tend to revisit governance under pressure — which is a worse time to build it.