A model risk committee and an AI governance committee are not the same body — here's where they diverge
Most Indian banks above a certain size already have a model risk committee, usually sitting under the Risk Management Committee of the Board or operating as its own Model Risk Management Committee. Far fewer have a separate AI governance committee, and the gap between the two is not cosmetic.
A model risk committee reviews validation status, approves model deployment, and tracks issue resolution to closure. An AI governance committee does all of that and more: it approves the bank's AI risk appetite statement, reviews fairness testing results for every customer-facing model, escalates AI security incidents on its own authority, and hands the board a residual-risk heat map broken out by business domain — not just by model.
FREE-AI's Governance pillar and Accountability Sutra point toward board-level ownership of AI risk, and RBI's Draft MRM Guidance — while still in consultation — is considerably more specific about what that ownership should look like in practice: documented committee mandate, defined membership, and a reporting line to the board that an examiner can actually trace. SR 11-7, for its part, expects the board and senior management to own model risk governance and requires an independent validation function, but it was written for statistical credit and market-risk models years before generative or agentic AI existed. It has nothing to say about behavioral-consistency monitoring, RAG corpus governance, or agentic scope manifests — which is exactly why a committee built to satisfy SR 11-7 alone will have blind spots the moment the bank deploys an LLM-based product.
This guide covers how to structure that committee: who sits on it, what authority it actually has, when it meets, what forces an emergency session, and what the board report needs to contain to survive an examiner's follow-up questions.
Why a model risk committee's structure doesn't transfer to LLMs, chatbots, or agentic systems
A model risk committee's scope is defined by the kind of model it was built to review: a statistical model with a fixed output space, a validation test set, and a monitoring approach built on backtesting and drift detection. That structure works well for credit scoring and fraud models. It doesn't transfer cleanly to generative or agentic AI.
An LLM has no fixed output space and no ground-truth validation set to backtest against. An agentic system's behavior emerges from a sequence of tool calls that can't be fully pre-validated — the risk lives in the sequence, not in any single step. A customer-facing chatbot's governance obligations are driven by disclosure requirements and DPDP Act data-principal rights, not by a statistical performance metric at all.
Put the same LLM deployment in front of each committee and you get two different findings. A model risk committee says "output quality within acceptable range on our test prompts." An AI governance committee asks whether behavioral-consistency monitoring is actually running against a baseline, whether customer disclosures are adequate, whether the RAG retrieval corpus is itself governed for data quality and provenance, and whether the chatbot's escalation path to a human agent satisfies the bank's grievance-redress obligations. Those are governance questions a model risk committee was never built to ask — and in our experience, the committees that try to stretch their existing mandate to cover this instead of building a parallel one end up producing minutes that look thorough but don't actually answer an examiner's question.
Committee mandate: the seven responsibilities a model risk committee doesn't already own
1. AI risk appetite setting and review. Annual board approval of the AI risk appetite statement — residual-risk tolerances defined by domain and by AI system tier (Critical/High/Medium/Low/Minimal). Quarterly review of whether actual residual-risk scores across the portfolio sit inside those approved tolerances, not just whether each model individually passed validation.
2. High- and Critical-tier AI system approvals. Approval authority for deploying any High- or Critical-tier AI system, for re-deployment after a material change, and for decommissioning a Critical-tier system. Medium- and Low-tier approvals get delegated to the model risk function, with the committee notified rather than asked to approve each one.
3. AI risk monitoring oversight. Monthly review of monitoring exceptions — performance breaches, fairness threshold breaches, behavioral-consistency alerts, and security incident notifications — with authority to require immediate corrective action when a threshold is breached, not just a note for the next quarterly cycle.
4. Fairness and non-discrimination oversight. Quarterly review of fairness testing results across every customer-facing AI system, including India-specific proxy variable testing for caste, religion, language, and disability proxies — the categories FREE-AI's Fairness and Equity Sutra is built to catch and that no imported fairness-testing toolkit was designed to test for. Authority to suspend a production AI system when a fairness threshold is materially breached, exercised without waiting for the next scheduled meeting.
5. AI incident governance. Oversight of significant AI incidents end to end — classification, escalation, remediation, and root cause analysis — with authority to pause deployment of any AI system involved in a Critical incident pending investigation.
6. Regulatory horizon scanning. Active tracking of new AI-relevant regulatory output: RBI's FREE-AI recommendations as they get operationalized, the Draft MRM Guidance as it moves (or doesn't) from consultation to final, SEBI's circulars on AI/ML use by market intermediaries, IRDAI's guidance for AI in insurance distribution where the bank has a bancassurance arm, and the DPDP Act's implementing rules as they're notified. The committee directs policy updates when a new obligation actually lands — not after an examiner points out the bank missed one.
7. Board reporting. Quarterly preparation of the board AI risk report: residual-risk heat maps, incident summary, fairness testing results, regulatory compliance status, and a governance maturity assessment the board can actually act on.
Committee membership: who sits in the room, who votes, and why the CRO has to chair it
Chair — Chief Risk Officer. Chairs the committee and holds final authority on escalation decisions. Accountable to the board for AI governance outcomes, full stop — not shared accountability with the business line that deployed the system.
Voting — Chief Data Officer / Chief AI Officer. Accountable for the AI strategy and portfolio, and the primary approval authority proposing new AI initiatives before they reach committee review.
Voting — Head of Model Risk Management. Responsible for independent validation outcomes, model documentation standards, and SR 11-7-aligned governance across all AI systems, statistical or generative.
Voting — Chief Compliance Officer. Accountable for regulatory compliance across RBI, SEBI, the DPDP Act, and — for banks with EU-facing operations or GIFT City entities — the EU AI Act. First point of contact when an examiner opens an inquiry.
Voting on a rotational basis — Head of Internal Audit. Sits as an observer with standing rights to participate in discussion, and gets voting rights specifically when the agenda item falls inside the current audit scope.
Non-voting — Chief Information Security Officer. Subject-matter input on AI security incidents, adversarial robustness testing, and the effectiveness of security controls specific to AI systems.
Non-voting — CTO / Head of Engineering. Technical context on deployment feasibility, infrastructure risk, and system architecture — input the committee needs, but not a vote on whether the bank's risk appetite permits the deployment.
Non-voting — Head of Legal & Regulatory Affairs. Interpretation of new regulatory guidance, legal review of customer disclosures, and third-party AI contract terms.
The committee cannot be chaired by the technology function, and this isn't a formality — it's the same three-lines-of-defence logic that underpins both SR 11-7 and RBI's own governance expectations for outsourced and critical functions. A function that builds and deploys AI systems cannot also be the function that decides whether those systems are safe to deploy.
The India detail: at a large private or public-sector bank, these eight roles are genuinely eight different people, and the committee functions as designed. At a mid-size NBFC-ND-SI, an SFB, or a UCB large enough to be running meaningful AI in lending or collections, it's common to find the CRO, CCO, and Head of Model Risk are effectively the same two or three people wearing multiple hats — which isn't automatically a finding, but it is exactly the kind of structural gap an RBI examiner will ask about directly, and "we're a smaller institution" is not an answer that satisfies the question.
Meeting cadence: what gets reviewed monthly, quarterly, and annually
Monthly — standard governance. Model inventory updates, monitoring exceptions, deployment approvals, incident review.
Quarterly — risk appetite review. Fairness testing results, risk appetite utilisation against approved tolerances, board report preparation, regulatory horizon scanning.
Annual — policy and maturity. Full AI governance policy review, governance maturity assessment, full-year risk appetite setting, strategic alignment with the bank's broader AI roadmap.
Within 48 hours — emergency session. Triggered by a Critical AI incident, a regulatory finding, a material fairness breach, or a decision to pause a production deployment.
A committee that only ever meets on the scheduled monthly cadence and never once convenes an emergency session in a full year is itself worth questioning — either nothing Critical happened all year, which is possible but worth verifying against the incident log, or the escalation triggers below aren't actually firing when they should.
Escalation triggers: what forces an emergency session versus what waits for the next meeting
| Trigger event | Severity | Response required | Timeline |
|---|---|---|---|
| AI-influenced decision causing material customer harm | Critical | Emergency session, deployment pause consideration, regulatory notification assessment | Within 24 hours |
| Fairness metric gap exceeding 10 percentage points between the best- and worst-performing customer segment in a customer-facing model | Critical | Emergency session, mandatory deployment review, remediation plan within 30 days | Within 48 hours |
| AI security incident with customer data exposure | Critical | Emergency session, CISO escalation, breach-notification assessment under the DPDP Act's security-safeguards provisions | Within 24 hours |
| RBI or SEBI inquiry regarding AI governance | Critical | Emergency session, evidence preparation, CCO-led response coordination | Within 24 hours |
| Residual risk score exceeds approved appetite in a domain | High | Next committee meeting, remediation plan required, exception report to board if unresolved after 90 days | Next meeting |
| New Critical-tier AI deployment request | High | Out-of-cycle review if the next scheduled meeting is more than 14 days away; full validation evidence required | Within 14 days |
| New regulatory guidance with material governance implications | Medium | Impact assessment at next quarterly meeting, policy update timeline agreed | Next quarterly |
| Vendor AI system material change (model update, underlying data source change) | Medium | Re-validation trigger assessment at next monthly meeting, vendor notification required | Next meeting |
The fairness-gap trigger is written as a segment-to-segment comparison rather than a single aggregate number on purpose: an aggregate fairness metric that looks fine can still be hiding a double-digit gap between your best- and worst-served customer segment, and that gap — not the aggregate — is what an examiner or a fair-lending review will actually test for.
What an RBI examiner actually asks for when reviewing committee governance
When an RBI Annual Financial Inspection team reviews AI governance, they ask for evidence the committee functions — not evidence that it exists on an org chart. In practice, the examination typically requests:
- The committee charter or terms of reference, board-approved, with a version history
- The last 12 months of meeting minutes, showing substantive engagement with specific AI risk topics rather than a presentation summary
- The approval record for every Critical-tier AI deployment in the review period, with the risk assessment actually attached, not referenced
- Fairness testing results the committee reviewed, specifically the India proxy variable testing for caste, religion, language, and disability categories
- At least one instance of the committee escalating an AI governance issue to the board during the review period
- Board minutes showing the board engaged with the AI governance report rather than simply receiving it
A committee that meets on schedule but produces minutes summarizing what was presented, rather than what was decided, will not satisfy an examiner looking for governance function. Minutes need to record the decision made, the issue escalated, and the action assigned — with a named owner and a due date, not "to be followed up."
In our experience reviewing these files, the single most common gap isn't a missing committee — it's a committee whose minutes read like meeting notes rather than decision records, which is indistinguishable from "no decision was made" to an examiner reading them cold eighteen months later.
What the board report needs to contain every quarter
| Report section | Content | Format |
|---|---|---|
| AI risk appetite utilisation | Residual risk score by domain against approved appetite — which domains sit within tolerance, which are approaching the limit, which have breached it | Heat map by domain (Critical/High/Medium/Low residual) |
| AI portfolio overview | Number of AI systems by tier and business line; new deployments approved; systems decommissioned; systems on a watch list | Summary table with period-over-period change indicators |
| AI incidents | Incidents since the last report — severity, business impact, resolution status, and the governance lesson learned, not just the technical fix | Incident register extract; trend line over the rolling 12 months |
| Fairness testing results | Fairness metric results for every customer-facing Critical- and High-tier model, including India proxy variable testing; any threshold breaches and remediation status | Model-by-model table with pass/warn/breach status |
| Regulatory compliance status | Open regulatory items, exam findings in remediation, new regulatory guidance and the bank's planned response | Status table with named owner and due date |
| Governance maturity | Current maturity level by domain, progress against the maturity roadmap, investment required to close remaining gaps | Maturity level chart with delta from the prior period |
The board report should require an actual decision at every meeting, not passive receipt: the board approves the risk-appetite utilisation status, or formally escalates concern about a breach, and it notes any significant incident on the record. A board that receives the AI governance report without responding to it in the minutes hasn't demonstrated the engagement an RBI examiner is checking for — and "the board was informed" is a materially weaker finding than "the board reviewed and approved."
Action checklist: what to confirm before your next committee cycle
- Check whether your AI governance committee is a committee or a standing agenda item bolted onto the model risk committee. If fairness testing, AI incident escalation, and risk appetite approval are buried in a model risk committee's agenda rather than owned by a separately chartered body, you don't yet have the structure RBI's Draft MRM Guidance and FREE-AI Governance pillar are pointing toward.
- Pull the last four sets of committee minutes and check whether they record decisions or just summarize presentations. If you can't find a named owner and a due date attached to every escalated issue, rewrite the minutes template before your next meeting, not after an examiner asks for them.
- Verify your escalation triggers actually fire. If your committee hasn't held an emergency session in the last 12 months, confirm that's because nothing Critical happened — not because the fairness-gap or incident thresholds are set too loose to ever trip.
- Map your committee membership against the eight roles above and flag any role held by the same person twice. For smaller NBFCs and UCBs, this is often unavoidable in the short term — but it needs to be a documented, risk-accepted gap with a remediation timeline, not an unstated fact the examiner discovers first.
- Replace any internal reference to an "RBI 2024 AI Circular" with the FREE-AI Framework (Aug 2025) and the Draft MRM Guidance (June 2026, cited as draft) by name. A policy document citing a circular that doesn't exist is a worse finding than a policy document that correctly hedges an instrument still in consultation.
Related: AI governance structure and oversight
Give your AI governance committee the evidence it needs at every meeting
Zytra generates examination-ready committee packs automatically — residual risk heat maps, fairness testing results, monitoring exception reports, and hash-chained approval records. No manual preparation before board meetings.