AI Governance Operating Model and Committee Charter for Banks: A Practitioner Guide

A regional bank’s Chief Risk Officer was sitting in a Fed exam closing meeting when the conversation turned to artificial intelligence. The bank had models in production, a validation team, and a monitoring program that ran on schedule. What the examiners asked for was something the CRO could not produce on the spot: a description of the institution’s AI governance structure. Who owns the AI risk? Which committee reviews it? What is the formal cadence? What does the board see and when? The CRO described the validation program accurately, but could not name an AI risk owner, could not point to a committee charter that covered AI, and could not describe a regular reporting cadence to the board risk committee. The examiners noted it as a matter requiring attention. The bank had model risk management but not AI governance — and the examiners were asking about the distinction. This vignette is a composite illustration drawn from patterns in supervisory conversations, not a documented exam record from a specific institution. The pattern is real; the examiner’s specific articulation of that distinction as a formal AI governance requirement is an emerging expectation, not a codified standard.

That gap, between having models and having a governed AI program, is the problem this guide solves. The CRO left that meeting with three immediate tasks: name an AI risk owner, amend a committee charter, and build a reporting cadence. This guide walks through all three and the broader operating model that ties them together.

What an AI governance operating model is — and what it is not

The operating model is the set of roles, accountabilities, processes, and artifacts that govern the lifecycle of AI inside a specific institution. It is the answer to the question the examiners asked: how does your organization own, review, and oversee AI risk, from the moment someone proposes using an AI system through deployment, monitoring, and eventual retirement?

That definition demands a clean distinction from two things it is often confused with. The operating model is not a framework. NIST AI RMF 1.0 (NIST AI 100-1, January 2023) is a framework. It organizes AI risk management into four functions, GOVERN, MAP, MEASURE, and MANAGE, and it provides a vocabulary and a structure for thinking about AI risk. The operating model is how your institution runs those functions inside its actual organizational structure, with named people, a real committee, defined meeting cadences, and documented authorities. The framework tells you what to do. The operating model is how you actually do it.

The operating model is also not a policy. The AI use policy is one artifact the operating model produces. The operating model is the continuous governance discipline that creates, updates, enforces, and reports on that policy. A bank that treats the existence of an AI use policy as evidence of an AI governance operating model is making the same mistake as the bank that treats a vendor’s ISO/IEC 42001:2023 certificate as a substitute for its own controls: the document is real and necessary, but it is not the system.

Why does this distinction matter in practice? Because banks that conflate the framework with the operating model end up aligned to NIST on paper while having no actual governance. The board approved the NIST alignment statement, the policy binder is thick, and nobody can answer the examiner’s question about who owns the model. Banks that conflate the policy with the operating model update the acceptable-use document annually while the models it governs operate without named owners, oversight committees, or formal reporting lines. The operating model is the machinery that makes the framework and the policy real. It is what the examiners are asking about when they ask about AI governance structure.

Building on what you already have: the SR 11-7 foundation

The most useful thing most US banks can know when they begin building an AI governance operating model is that they already have most of its spine. SR 11-7, the Federal Reserve’s supervisory guidance on model risk management paired with OCC Bulletin 2011-12, establishes supervisory expectations for four things that any governance operating model should build on: a model inventory, independent validation, ongoing monitoring, and board and senior management oversight. Those four expectations are not an AI governance program, but they are the load-bearing foundation one is built on.

The mapping to NIST AI RMF is direct and useful. SR 11-7’s model inventory requirement corresponds to the MAP function, the establishment of context and identification of risk. Independent validation and ongoing monitoring correspond to the MEASURE function, the analytical testing and benchmarking work. Board and senior management oversight corresponds to the GOVERN function, the accountability and policy structure that makes everything else legitimate. MANAGE, the response and treatment function, runs through all of SR 11-7’s expectations for how discovered problems get escalated, remediated, and tracked.

One clarification before applying this mapping: NIST AI RMF 1.0 is a voluntary framework that no US banking regulator has formally required. The mapping to NIST functions is illustrative — a useful organizing language — but examiners assess AI governance primarily through an SR 11-7 and safety-and-soundness lens, not a NIST AI RMF lens. Institutions that use NIST as their organizing language benefit from its structure; those that do not are not automatically deficient.

What this means practically is that a bank with a credible SR 11-7 program has MEASURE and MANAGE substantially covered already. The validation calendar, the monitoring dashboards, the escalation paths, and the issue logs are already running. The work the bank needs to do to build an AI governance operating model is not to construct those disciplines from scratch. It is to extend them to cover what traditional model risk management was not built for, and to add the GOVERN and MAP structure that connects the technical validation work to accountable human ownership and formal committee oversight.

Four categories of AI-specific risk require additions to what SR 11-7 MRM typically covers. First, the scope of what counts as a “model” must expand. SR 11-7 was written for statistical and econometric models, and many MRM programs have historically applied it narrowly to credit scorecards and pricing models. AI systems in production at most banks are broader: they include agentic AI tools that call external services and take actions, retrieval-augmented generation (RAG) pipelines in which a document store and a foundation model together produce outputs, and generative AI tools used for customer communications and internal workflows. These systems produce estimates and drive decisions within SR 11-7’s own broad definition, and they must be in scope.

Second, bias and fair-lending testing must be extended beyond credit-decisioning models. A model that influences credit access, credit pricing, or credit-adjacent decisions can carry disparate-impact risk under ECOA and Regulation B. AI systems used in service routing, queue prioritization, or offer personalization may additionally implicate UDAAP and other consumer protection frameworks depending on the specific use case and the CFPB’s evolving interpretations — the precise regulatory exposure depends on the facts and warrants legal review rather than a categorical assumption. Traditional MRM programs often run disparate-impact analysis only for models that directly affect credit access. An AI governance operating model for a bank covers the broader set, but the applicable legal framework for each system depends on how it is used and what regulatory guidance applies to that use.

Third, third-party AI vendor oversight must be formalized under the June 2023 Interagency Guidance on Third-Party Relationships: Risk Management (OCC, Fed, and FDIC), which organizes oversight across planning, due diligence, contracting, ongoing monitoring, and termination. Most AI systems at a bank today run on foundation models the bank did not train and vendor infrastructure it does not control. The operating model must assign that dependency to a named owner with an ongoing monitoring obligation, not just a one-time onboarding review. For the detailed checklist, see third-party AI vendor risk assessment for banks.

Fourth, documentation must capture AI-specific risks that do not exist for traditional models: hallucination and non-deterministic output in generative AI, prompt injection as an attack surface, emergent behavior at the boundary of the system prompt and the retrieval layer, and the risk that a foundation model provider silently updates the underlying weights. Each of these is a named, documented risk with an owner, a mitigation, and a monitoring approach in a complete AI governance operating model. They cannot remain informal caveats or verbal acknowledgments in a validation debrief.

The AI governance committee: structure and charter elements

The question most institutions ask first is whether to stand up a new AI governance committee or amend an existing committee’s charter. For the large majority of US regional and community banks, the answer is to amend, not create. A new committee means a new meeting cadence, new quorum requirements, a new reporting line to establish, and a new set of members whose attendance and engagement must be sustained. Most banks cannot sustain that reliably, which is why the governance-on-paper pattern is so common: a committee that exists in a charter but does not meet, or meets without reviewing any substantive AI risk information.

The more durable solution is to amend the charter of the existing Model Risk Committee or Technology Risk Committee to include AI oversight as a named, standing agenda item with defined responsibilities. This produces a committee that is already meeting, already attended by the right people, and already reporting to the board risk committee. The amendment adds an AI risk scope, names an AI risk owner who brings prepared materials to each meeting, and specifies the KRI dashboard and reporting cadence that the committee reviews.

Where a dedicated AI governance committee makes sense is for an institution whose AI portfolio is large enough, complex enough, or strategically important enough that AI risk deserves dedicated committee attention that a crowded Technology Risk Committee agenda will not give it. A bank with active deployment of AI in credit, fraud, customer service, and operations simultaneously, with a material generative AI program and significant third-party AI dependencies, may genuinely benefit from a dedicated forum. The test is not prestige or optics; it is whether the existing committee can actually give AI risk the substantive attention it requires in the time available.

Whether the committee is new or an amendment to an existing charter, the charter elements a sound AI governance committee charter should contain are the same.

AI Governance Committee Charter: Required Elements

Name and purpose. The committee’s name and a statement of its purpose: to provide governance oversight of the institution’s AI program, including the inventory, validation, monitoring, and policy framework for AI systems, and to ensure that AI risk is identified, assessed, and managed within the institution’s risk appetite.

Scope. A definition of which AI systems are subject to the committee’s oversight. The scope statement should use a broad definition aligned to SR 11-7’s model definition: any AI system that applies algorithmic, statistical, or machine-learning methods to produce estimates, recommendations, or automated decisions, including vendor-hosted systems and third-party foundation models. The scope should explicitly include generative AI tools used in any business process, agentic AI systems, and RAG pipelines.

Membership and roles. The committee should include the CRO or a named delegate with model risk accountability, the Chief Compliance Officer or a named delegate, the head of model risk management, heads of each business line with material AI use, and, as a consulted or invited member, the CISO for AI security risk. For a bank with a dedicated data and AI function, the Chief Data Officer or equivalent should also be a member. Each seat should have a named primary and a designated alternate so that quorum is achievable when principals are unavailable.

Chair and secretary. The chair should be the CRO or the head of model risk management with direct CRO accountability. The chair’s role is to ensure the committee reviews substantive AI risk information at each meeting and documents its decisions. The secretary is responsible for minutes, action item tracking, and the distribution of prepared materials before each meeting.

Meeting cadence and quorum. The committee meets at minimum quarterly. Ad-hoc meetings are required for material risk events: the proposed deployment of a new Tier 1 (high-risk) AI system, a material adverse event attributable to an AI system, a significant change to a high-risk AI system, or material new regulatory guidance on AI. Quorum requires a majority of named members, including the CRO or delegate and the compliance officer or delegate.

Authorities. The committee has authority to approve the deployment of new high-risk AI systems (defined in the tiering standard), to require validation or re-validation of any AI system, to restrict or suspend the use of an AI system pending remediation, to approve material changes to the AI use policy, and to accept residual risk within the institution’s AI risk appetite. The committee has authority to recommend restriction or suspension of a live system to the CRO and the relevant business line executive. The CRO retains executive decision-making authority; the committee’s role is to surface the risk and make the recommendation with supporting evidence, not to unilaterally execute operational changes to production systems.

Reporting obligations. The committee reports quarterly to the board risk committee via a KRI dashboard and a narrative summary of material AI risk events. The CRO provides an annual AI risk narrative to the full board that frames AI risk in the context of the institution’s risk appetite and strategic AI use. Minutes of each committee meeting are provided to internal audit.

Amendment process. The charter may be amended by a two-thirds vote of the full committee membership, subject to CRO approval and board risk committee notification. Material scope changes, such as adding or removing covered AI system categories, require board risk committee approval.

Roles and accountability: the AI governance RACI

The RACI is the first thing examiners ask for after the committee charter: who owns this model, and who validated it? A well-designed RACI answers that question for every material AI system in the institution’s inventory, across four lifecycle stages that correspond to the NIST AI RMF four functions.

At the MAP stage, inventory and tiering, the model risk function is Responsible for maintaining the AI inventory and applying the tiering standard to each system. Business line AI owners are Responsible for registering new systems and providing the context of use information the inventory requires. The CRO is Accountable for the completeness and tiering accuracy of the inventory. Compliance and the CISO are Consulted on tiering decisions for systems that touch customer data or have significant security exposure. The board risk committee is Informed of inventory changes through the quarterly committee report.

At the MEASURE stage, validation and testing, the model risk function and the independent validation team are Responsible for executing validation, including conceptual soundness review, behavioral and adversarial testing, and bias and fair-lending testing for applicable systems. The head of model risk management is Accountable for ensuring validation is completed within the required cycle for each tier and that findings are tracked to resolution. The committee chair holds that accountability — through the oversight role and the quarterly validation backlog review — but does not execute the validation function. Business line AI owners are Consulted on the use-case context the validation team needs to scope the review correctly. The committee and internal audit are Informed of validation results and open findings through the quarterly dashboard.

At the MANAGE stage, ongoing monitoring and issue management, business line AI owners are Responsible for the day-to-day operation of monitoring programs for the AI systems in their lines. Model risk is Responsible for reviewing monitoring outputs and escalating material findings. The head of model risk is Accountable for maintaining a current issue log and ensuring findings drive remediation. Legal and compliance are Consulted when a finding carries potential regulatory, fair-lending, or consumer protection exposure. The committee is Informed of the issue log and remediation status at each quarterly meeting.

At the GOVERN stage, policy and oversight, the model risk function and compliance are jointly Responsible for maintaining the AI use policy, the tiering standard, and the committee charter. The CRO is Accountable for those documents and for the committee’s operation. Legal is Consulted on policy provisions that carry regulatory interpretation questions. The board risk committee is Informed through the annual AI risk narrative and the quarterly KRI dashboard.

The RACI is not a document that lives in a binder and surfaces at exam time. It is an operational document that is reviewed and updated when organizational structures change, when new AI systems are inventoried, and when the committee charter is amended. Examiners who review the RACI and then interview the named owners to verify that the owners know their responsibilities are running a test the RACI alone cannot pass. The owners must actually own the work.

Operating cadence: what governance actually does on a schedule

An AI governance operating model is defined by what it actually does on a recurring schedule, not by what its charter says it will do. The following cadence is the minimum operating rhythm for a regional bank with a material AI program. Institutions with larger or higher-risk AI portfolios should run at greater frequency in the continuous and monthly tiers.

The continuous layer is always-on work that does not wait for a scheduled meeting. The AI system inventory is maintained in a live system of record, updated whenever a new AI system is proposed, deployed, materially changed, or retired. Monitoring programs for high-risk AI systems are running and producing outputs on their defined schedule. The issue log is current, with every open finding in an active remediation track with a named owner and a target resolution date. This layer is owned by the model risk function and the business line AI owners together, and it is what enables every scheduled review to be substantive rather than retrospective.

At the monthly layer, the model risk function reviews the monitoring dashboard for all in-scope AI systems and escalates material findings to the CRO or the committee chair between scheduled meetings. A finding is material if it indicates a performance threshold breach, a significant drift event, a bias or fairness signal, a security incident, or a significant change in the behavior of a third-party AI vendor’s model. The monthly review produces a brief written record that demonstrates the monitoring program is functioning and that findings are being acted on between quarterly meetings.

At the quarterly layer, the committee meets with a prepared agenda that covers four standing items: the inventory update (any new systems added, changed in tier, or retired since the last meeting), the validation backlog (systems due for validation, completion status of in-progress validations, any validations overdue), the KRI dashboard (the seven indicators described in the next section, with trend lines), and material risk events (any incidents, adverse findings, or significant regulatory developments since the last meeting). The committee documents its review and any decisions in minutes that are circulated to members and provided to internal audit within ten business days of the meeting.

At the annual layer, the institution completes a full AI risk assessment that covers the entire AI portfolio, rates each system’s risk contribution, and identifies program-level gaps in validation, monitoring, and policy coverage. The AI use policy is reviewed by compliance and submitted to the committee for approval of any material changes. Every material AI vendor is subject to a third-party risk review that applies the June 2023 interagency guidance’s five-phase lifecycle principles to AI vendors, including AI-specific practitioner considerations such as model version change notification, data handling, sub-processor exposure, and incident response. (These AI-specific items are practitioner-derived applications of the guidance’s general principles, not enumerated requirements of the guidance itself, which is technology-neutral.) The CRO provides an annual AI risk narrative to the full board.

Event-driven actions sit outside the scheduled cadence and must be triggered on occurrence. A proposed new high-risk AI system deployment requires committee review and approval before go-live, which means the model risk function must be in the product development lifecycle early enough to complete tiering, validation, and committee review before the launch date. A significant model change to a Tier 1 or Tier 2 system requires a material-change assessment that determines whether re-validation is required. A material adverse event attributed to an AI system requires an incident review completed within a defined timeframe, with findings reported to the committee in an ad-hoc meeting or a written briefing within 30 days. New regulatory guidance on AI triggers a policy gap assessment within 60 days of publication.

Key Risk Indicators and board reporting

Board reporting for AI governance should be anchored to a small, durable set of KRIs that the board risk committee can monitor over time. A committee that sees different metrics every quarter cannot build institutional pattern recognition about AI risk. The following seven KRIs are designed to be computable from the data a model risk function already maintains, expressible in a one-page heat map, and meaningful to a board member who is not a technical practitioner.

The first KRI is AI inventory completeness rate: the percentage of production AI systems confirmed to have a complete MRM record, including a named owner, a risk tier, and a documented scope of use. A bank that discovers AI systems in production that are not in the inventory has a governance failure, and this KRI surfaces that failure before an examiner does.

The second is validation coverage rate: the percentage of Tier 1 and Tier 2 AI systems that have been independently validated within their required validation cycle. High-risk AI systems that are running without current validation are the single most common examiner finding in AI governance reviews. Note that this KRI can be gamed by downgrading high-risk systems to lower tiers to reduce the denominator, or by completing perfunctory validations that satisfy the threshold without providing substantive review. It should be paired with a tiering-integrity control and, at minimum, a finding rate sub-metric that tracks the percentage of validations that surfaced material findings.

The third is monitoring gap rate, which tracks two related but distinct conditions: the percentage of high-risk AI systems with a monitoring program producing outputs within the defined schedule, and the percentage of those programs for which a documented review record exists showing a named owner received and acted on the outputs. The second condition requires a documented review workflow, not just a named owner in the inventory — most MRM functions will need to build that workflow before this metric is reliably computable. A monitoring program that exists on paper but is not producing reviewed outputs is not a monitoring program; it is a documentation artifact.

The fourth is open findings aging: the count and severity distribution of open validation and monitoring findings by age bucket, typically 0 to 30 days, 31 to 90 days, and over 90 days. A growing tail of aged findings, particularly at high severity, indicates a management problem that the committee needs to address. Examiners read the findings age profile as a signal of how seriously the institution takes its own validation outputs.

The fifth is vendor AI risk coverage: the percentage of material AI vendors, those hosting Tier 1 or Tier 2 AI systems, with a current third-party risk review that applies the June 2023 interagency guidance’s five-phase lifecycle principles to AI vendors, covering AI-specific practitioner considerations including model version change notification, data handling, sub-processor exposure, and incident response. (These AI-specific items are practitioner-derived applications of the guidance’s general principles, not enumerated requirements of the guidance itself, which is technology-neutral.) An institution that has strong internal validation but has not reviewed the third-party AI vendors it depends on has a material gap.

The sixth is bias and fair-lending testing coverage: the percentage of AI systems used in or proximate to credit, servicing, or customer-treatment decisions that have a current disparate-impact analysis on file. This KRI matters because the scope of what counts as “proximate to a credit decision” has expanded, and institutions that apply the testing only to formal credit-scoring models may be carrying fair-lending exposure in other AI systems.

The seventh is AI incident rate: the count of AI-related incidents or control failures in the reporting period, categorized by severity. This KRI anchors board reporting to actual outcomes, not just process compliance, and trends in incident rate over time are the clearest signal the board has of whether the operating model is working. For this KRI to support trend analysis, the institution must define ‘AI-related incident’ — the boundary between an AI incident, a technology incident, a model performance event, and a control failure is often contested internally. A working definition: any event in which AI system output directly contributed to a customer harm, a control failure, a regulatory breach, or a significant operational disruption. Establish the definition before computing the first period.

Board reporting for most institutions should be a one-page KRI heat map delivered quarterly to the board risk committee, with a brief narrative of any material events since the last report. An annual narrative that frames the AI risk profile in the context of the institution’s risk appetite and the year’s key governance activities, including the annual risk assessment results and the policy review, is required. The board does not need raw validation reports or technical model documentation; it needs a clear view of the program’s health, the material risks, and the trends in the KRIs over time.

Policy lifecycle: the AI use policy and its governance

The AI use policy and the AI governance operating model are related but distinct. The operating model is the governance structure. The AI use policy is one artifact that structure produces, maintains, and enforces. Understanding the distinction matters because institutions that treat the policy as the governance program leave the structure that should sustain it unbuilt.

A sound bank AI use policy should address six elements to be adequate as a governance instrument. First, scope: which AI systems, which employees, and which use cases the policy covers, with a definition of “AI system” consistent with the inventory’s tiering standard. Second, permitted and prohibited uses: a clear delineation of use cases the institution has approved, use cases that require prior review and committee approval, and use cases that are prohibited outright. Common prohibitions include using generative AI to produce customer-facing disclosures without human review, using AI for credit decisions without independent validation, and using any AI tool that sends confidential or customer data to a vendor whose data-handling terms have not been reviewed and approved. Third, data classification requirements: which data classifications may be processed by which categories of AI systems, with explicit rules for confidential, personally identifiable, and customer data. Fourth, third-party AI use requirements: the approval process for using any AI tool, including commercial tools not procured through formal IT channels, specifying what vendor review is required before an employee may use a new AI tool. Fifth, human-in-the-loop requirements: for decisions at defined risk levels, particularly credit, fraud, servicing, and employment decisions, the policy must specify where a qualified human must review an AI-generated output before it drives action. Sixth, reporting obligations: the obligation to report incidents, unexpected AI behaviors, and new AI use cases discovered in business lines to the model risk function, with a defined reporting channel and timeframe.

For a practical starting point on the core elements of an acceptable-use policy, the AI acceptable-use policy generator provides a structured template that a compliance team can adapt to the institution’s context.

The policy governance cycle has three recurring elements. Compliance reviews the policy annually and identifies provisions that require updating in light of regulatory developments, changes in the AI vendor landscape, or material incidents in the prior year. The committee approves any material changes to the policy, with “material” defined as changes to permitted or prohibited uses, scope changes, or changes to human-in-the-loop requirements. The compliance function is responsible for employee training on the policy, which must be completed by all employees in AI-using roles at least annually and for any new material policy change within 60 days of adoption.

The three gaps examiners most commonly find

Supervisory findings vary by institution, examiner, and examination scope. The following patterns appear with frequency in public enforcement actions, supervisory speeches, and examination feedback — they are not guaranteed findings, and an institution may face different or additional concerns.

Examiner reviews of AI governance at US banks have surfaced three recurring patterns that generate MRAs. Knowing them in advance allows an institution to close them before the examiners arrive.

The first is the inventory gap. AI systems are running in production that are not in the MRM inventory because the institution defined “model” narrowly, typically as traditional statistical models used in credit decisioning, and did not include vendor AI tools, AI-powered business applications, internal tools built on foundation models, and automation that uses machine learning. The examiners walk through business units and ask what AI systems they use. The answers reveal a population of AI systems that model risk did not know existed. A common approach to addressing this gap is to expand the inventory scope using a broad definition of AI system aligned to SR 11-7’s own broad model definition, to create a mechanism for business lines to register new AI tools before deployment rather than after discovery, and to run a periodic sweep of the AI tool landscape across the institution. The AI system inventory generator is a structured starting point for documenting existing AI systems with the fields an MRM inventory requires.

The second is the validation lag. High-risk AI systems have been deployed and are in active use, driving decisions or influencing customer outcomes, without prior independent validation. In some cases, validation was planned but deprioritized when deployment moved faster than the validation queue could absorb. In others, the institution treated vendor-provided documentation as a substitute for independent validation. Examiners view both as the same problem: the institution is running a high-risk system it has not independently assessed. A common approach to addressing this gap is to build pre-deployment validation into the product development and procurement lifecycle as a gate, not an afterthought, so that no Tier 1 or Tier 2 AI system goes live without a completed validation on file. The committee charter’s authority to approve high-risk deployments is the formal mechanism that enforces this gate.

The third is governance on paper. A committee exists in the charter but does not meet, or meets on schedule but reviews no substantive AI risk information: no KRI dashboard, no validation backlog, no issue log, no monitoring results. The minutes record attendance and a brief discussion but no decisions. Examiners ask for the minutes and the materials the committee reviewed. When the materials are absent or perfunctory, it is evidence that the governance structure exists in documentation but not in practice. The approach to closing this gap is the operating cadence described in the previous section, particularly the standing quarterly agenda items, the prepared materials requirement, and the mandatory documentation of committee decisions and accepted risks. Minutes are the evidence trail. They need to show that the committee reviewed real information about real AI risk and made real decisions about it.

A fourth pattern that appears in supervisory feedback and enforcement actions is the absence of effective challenge. Examiners assess not just whether an independent validation function exists but whether it is empowered and expected to substantively challenge model developers and business line owners, and whether those challenges are taken seriously by management. Governance-on-paper and effective-challenge failure often coexist: the validation team produced findings, but no one with authority required the business to remediate them, and the committee minutes show the findings were noted but not acted on. The RACI’s ‘Accountable’ role at the MANAGE stage — the head of model risk — is the position responsible for ensuring findings drive actual remediation, not just documentation.

FAQ

Does a bank need a separate AI governance committee?

Most regional and community banks do not. The more durable and practical approach for most institutions is to amend the charter of the existing Model Risk Committee or Technology Risk Committee to include AI oversight as a named, standing responsibility with defined authorities, reporting obligations, and a required KRI dashboard. A new dedicated AI governance committee makes sense when the AI portfolio is large enough, complex enough, or strategically central enough that existing committee time is genuinely insufficient. The test is not organizational prestige; it is whether the existing committee can actually give AI risk the substantive attention it requires.

What is the difference between AI governance and model risk management?

Model risk management is the validated discipline that SR 11-7 requires: inventory, independent validation, ongoing monitoring, and governance. AI governance is the broader operating model that organizes accountabilities, policy, committee oversight, and reporting for AI as a risk category, and it includes model risk management as its core technical discipline. The distinction matters because a bank with a strong MRM program still needs the ownership, committee structure, and policy framework that constitute AI governance. For the full conceptual map, see AI governance vs AI compliance for financial services.

What SR 11-7 requirements apply to AI?

SR 11-7 defines a model as ‘a quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories, techniques, and assumptions to process input data into quantitative estimates.’ The elements ‘system, or approach’ and ‘process input data’ are what make this definition broad enough to cover AI systems — a narrow reading of ‘quantitative method’ alone would not. Its three pillars of development, validation, and governance apply to AI models, though the specific techniques required to satisfy each pillar are more demanding for non-deterministic AI systems. The OCC, Federal Reserve, and FDIC have each indicated, through supervisory statements, examination feedback, and interagency papers (including the OCC’s 2021 paper on AI in banking), that existing model risk guidance is broadly applicable to AI systems — though no single joint interagency statement formally codifies this as binding rule. For the detailed treatment of how each pillar applies and where it breaks down, see AI model risk management and SR 11-7.

What should the AI governance committee review each quarter?

At each quarterly meeting, the committee should review four standing items with prepared materials: the AI inventory update covering new systems, tier changes, and retirements since the last meeting; the validation backlog showing completion status and any overdue validations; the KRI dashboard showing the seven indicators described in this guide with trend lines; and a summary of material risk events including incidents, adverse findings, and significant regulatory developments. Decisions, accepted risks, and action items must be documented in minutes that are circulated to members and provided to internal audit.

Who should be the AI risk owner at a bank?

The AI risk owner should be the head of model risk management, reporting to the CRO, with the CRO holding ultimate accountability for the AI risk program. The AI risk owner is the person who brings prepared materials to the committee, maintains the inventory, drives the validation calendar, and escalates material findings. The title matters less than the clear organizational accountability: one named person is responsible for the health of the AI governance program, and that person has direct access to the CRO and a defined reporting path to the committee and the board.

What this guide is / What it is not

What it is: a practitioner template for structuring an AI governance operating model and committee charter at a US bank or fintech, aligned to SR 11-7, NIST AI RMF 1.0 (NIST AI 100-1, January 2023), and the June 2023 Interagency Guidance on Third-Party Relationships. What it is not: legal or regulatory advice, a certification, or a guarantee of any exam or audit outcome. The RACI, charter elements, and KRIs above are a practitioner starting point, not a final document. Institutions with complex AI portfolios, a recent MRA, or an upcoming exam cycle should engage a senior practitioner to adapt them to the actual structure and risk profile of the institution. DSE prepares organizations for audit and examination and does not certify. Consult qualified legal counsel on charter adoption and on the regulatory interpretation questions the policy lifecycle raises.

The Bottom Line

The regional bank CRO who left that exam closing meeting with three tasks had something useful: a clear picture of the gap. The models existed. The validation existed. The monitoring ran on schedule. What was missing was the governance layer: a named owner, a committee with a charter that covered AI, and a reporting cadence that let the board see the AI risk program’s health. Those three things, along with the RACI, the operating cadence, and the KRI dashboard, are what the AI governance operating model produces. They are also exactly what SR 11-7 and the supervisory guidance have always required of a mature risk program. AI did not create a new regulatory requirement for governance; it extended an existing one to a risk category the original guidance did not fully anticipate.

For institutions that want to use NIST AI RMF 1.0 as the organizing language for this work, the NIST AI RMF checklist provides a structured starting point for assessing coverage across the four functions. For the broader examination posture, see AI governance readiness and NIST AI RMF for financial services.

This guide is a starting template. The RACI, charter, and KRIs above are a practitioner starting point, not a final document. Institutions with complex AI portfolios, a recent MRA, or an upcoming exam cycle should engage a senior practitioner to adapt them to the actual structure and risk profile of the institution. If your institution needs to build this operating model before an exam cycle, our banking AI governance engagement starts with a readiness assessment that maps where the program currently stands against the components in this guide. To discuss your situation directly, visit /engage.html.