NIST AI RMF GOVERN Function: Building AI Risk Culture, Accountability, and Inventory

Most financial institutions have a NIST AI RMF slide in their board deck. Very few have operationalized the GOVERN function to the point where an examiner could pull a thread on any deployed AI model and find documented accountability, a current risk tolerance statement, and evidence of independent oversight.

The gap is real. The GAO’s May 2025 report on AI in financial services found that while institutions are rapidly adopting AI, oversight frameworks are still catching up — even the regulators acknowledged their own AI inventories were incomplete when the audit work concluded. The message for practitioners isn’t reassuring: if your regulator can’t tell you how many AI tools they’re running internally, imagine what they’ll ask you when they show up at your institution.

The GOVERN function isn’t a checkbox. It’s the foundation that makes everything else in the framework credible.

TL;DR:

• GOVERN is the prerequisite layer of NIST AI RMF — without it, your MAP, MEASURE, and MANAGE functions have no institutional backbone
• The Treasury FS AI RMF (February 2026, 230 control objectives) maps GOVERN to specific bank-ready controls — this is now the de facto implementation standard for US financial institutions
• Most institutions fail GOVERN on the same three gaps: incomplete AI inventories, accountability structures that don’t match who actually owns deployed models, and executive risk tolerance statements written before generative AI arrived
• GOVERN 1.6 (AI Inventory) and GOVERN 2.1 (Roles and Responsibilities) are the two sub-categories examiners pull first

What GOVERN Actually Requires

NIST AI RMF 1.0 structures the GOVERN function across six sub-functions. Here’s what each one actually means in a financial institution context — not the abstract framework language, but what you’d need to show an examiner.

GV-1: Risk Management Policies and Processes

This is the policy layer. Seven outcomes cover the full lifecycle from legal compliance to decommissioning.

GV-1.1 — Legal and Regulatory Compliance: Your AI program must document which laws and regulations apply to each AI use case. In financial services, that means mapping models to SR 11-7, CFPB adverse action requirements, ECOA/Reg B (for credit models), GLBA (for models using customer data), and state-level AI laws like Colorado SB 205. Generic “AI policy” language doesn’t cut it — examiners want to see use-case-specific regulatory mapping.

GV-1.3 — Risk Tolerance Framework: Organizations must define a risk tolerance scale and assign AI systems to risk categories. Most banks use a High/Medium/Low tiering, but the FS AI RMF pushes for more specificity: what types of risk are you tolerating (model error, bias, explainability gaps), and at what level does each type trigger escalation? If your risk committee approved a “low risk tolerance for AI in credit decisioning” three years ago and you’ve since deployed an LLM for customer communications, that statement needs updating.

GV-1.6 — AI System Inventory: This is the foundational deliverable. An organized database of AI systems and models with defined attributes — preferably all models, at minimum high-risk systems in high-stakes settings. The Treasury FS AI RMF maps this to control objective GV-1.6, with six sub-objectives that span from initial shadow AI discovery to portfolio-level risk analysis. The inventory isn’t a one-time project. It requires a process for ongoing discovery — because business lines will keep buying and deploying AI tools without telling compliance.

GV-1.7 — Decommissioning Processes: The part every AI governance program forgets. When a model goes offline, what happens to the data? To dependent systems? To regulatory obligations tied to the model’s outputs? For institutions subject to examination, records relevant to model decisions may need to be preserved for years after decommission. Establish the process before you need it.

GV-2: Accountability Structures and Training

GV-2.1 — Roles and Responsibilities: Documentation of who owns what across the AI lifecycle. Not “the technology team” — specific named roles with defined responsibilities. In practice at large financial institutions, this means:

For smaller institutions without a full MRM function, the key principle from SR 11-7 still applies: the person building the model shouldn’t be the only person validating it. Independence is the requirement, not headcount.

GV-2.2 — Personnel Training: Training must be ongoing, use-case-tailored, and documented. Generic AI ethics training doesn’t satisfy GV-2.2 — examiners want to see that staff who interact with AI systems (developers, validators, compliance reviewers, business users) received training on applicable laws, specific organizational policies, and how to identify and escalate AI-related concerns. Training for model validators is different from training for loan officers using AI decision support.

GV-2.3 — Executive Leadership Accountability: Senior leadership must formally declare risk tolerances, allocate resources, and demonstrate an active role in AI risk oversight — not just “receive reports.” The AI Governance Program Checklist we published last month shows what examiners look for in board-level AI governance. The short version: documented board-level approval of AI risk appetite, evidence that the board received and acted on AI risk reporting, and clear delegation of authority for AI risk decisions below board level.

GV-3: Workforce Diversity and Inclusion

GV-3.1 — Diverse Team Composition: Risk mapping, measuring, and management should involve teams that reflect demographic diversity, multiple disciplines, and varied experiences. The practical rationale: homogeneous teams systematically miss certain categories of AI harm. A credit risk model reviewed only by quant developers and risk managers is less likely to catch discriminatory impacts than a team that also includes compliance, legal, and representatives with lived experience of credit access challenges.

GV-3.2 — Human-AI Configuration Roles: Define who does what when humans and AI systems work together. For a loan officer using AI decision support, what decisions require human judgment versus AI recommendation? What training confirms the loan officer can actually identify when the AI is wrong? This sub-function matters most for institutions deploying AI in consequential decision-making — credit, employment, insurance.

GV-4: Risk-Aware Organizational Culture

GV-4.1 — Critical Thinking and Safety Culture: This is the hardest one to demonstrate and the one most organizations paper over. NIST AI RMF calls for mechanisms like three-lines-of-defense, model audits, or red-teaming — plus whistleblower protections that enable staff to raise AI risk concerns without retaliation. For financial institutions, the three-lines model maps well: first line owns AI deployment and day-to-day controls; second line provides independent risk oversight; third line (internal audit) tests whether first and second line are functioning. The question examiners ask: is your second line actually independent, or are they rubber-stamping first-line decisions?

GV-4.2 — Risk and Impact Documentation: AI risks and potential impacts should be documented and communicated broadly. Impact assessments — covering effects on customers, employees, communities, and the institution itself — should be applied iteratively throughout the lifecycle. The FS AI RMF maps this to specific deliverables: pre-deployment impact assessments, model monitoring reports, and incident analyses. Not documentation for its own sake, but a paper trail that shows the institution understood the risks before it deployed and updated its understanding as the system ran.

GV-5: Stakeholder Engagement

GV-5.1 — External Feedback Integration: Mechanisms to collect and act on feedback from external stakeholders — customers, communities, and affected individuals — about AI impacts. For consumer-facing AI (chatbots, credit models, fraud detection), this means more than a complaint hotline. It means a process for analyzing feedback patterns, identifying systemic AI-related issues, and routing findings back to model owners. Institutions with a robust consumer complaint management program already have the plumbing. The gap is usually that AI-related feedback isn’t tagged or routed separately.

GV-5.2 — Feedback Incorporation and Risk Tolerance: How adjudicated feedback actually changes system design and implementation. If your complaint data shows customers are systematically unable to get adverse action explanations for AI-driven credit decisions, that should feed back into how the model is deployed or documented. GV-5.2 is where the rubber meets the road: feedback without response is worse than no feedback process at all.

GV-6: Third-Party Risk Management

GV-6.1 — Third-Party Governance: Policies for AI risks from third-party entities, including transparency requirements. For most financial institutions, this means your third-party AI vendor risk assessment needs to go deeper than standard vendor questionnaires. You need to understand how the vendor’s model was trained, what fairness testing they performed, how they monitor for drift, and what they’ll tell you when something goes wrong. Vendor assurance letters are not sufficient.

GV-6.2 — Third-Party Contingency Planning: Contingency processes for failures in high-risk third-party AI. What happens when your credit underwriting vendor’s API goes down? What manual override exists? Have you tested it? For institutions that have outsourced critical AI functions to vendors, GV-6.2 is a BCP problem as much as an AI risk problem.

The Treasury FS AI RMF: Where GOVERN Gets Operational

In February 2026, the US Treasury released the Financial Services AI Risk Management Framework developed through the Cyber Risk Institute with input from over 100 financial institutions. This is the most significant practical development in financial services AI governance since the NIST framework itself.

Where NIST AI RMF gives you principles and outcomes, the FS AI RMF gives you 230 specific control objectives mapped to the financial services context. For the GOVERN function, the key additions:

• AI inventory scoping: The FS AI RMF explicitly addresses shadow AI discovery — you can’t just inventory approved models. Business lines are buying AI tools through SaaS subscriptions that never touch IT procurement. Your GOVERN program needs a shadow AI discovery process.
• Risk tolerance specificity: Generic “low risk tolerance for AI” statements don’t satisfy the FS AI RMF. The framework asks for specific tolerance thresholds by risk type and use case — what’s acceptable model error in a fraud detection context is different from what’s acceptable in a credit decisioning context.
• Board reporting cadence: The FS AI RMF includes specific guidance on what AI risk information should reach the board and how often. AI risk should not live only in operational risk reports — it needs dedicated board-level attention with AI-specific metrics.

What Good Looks Like: A 90-Day GOVERN Implementation Roadmap

Most financial institutions aren’t starting from scratch, but they’re also not where they need to be. Here’s a realistic 90-day trajectory for operationalizing the GOVERN function.

Days 1–30: Inventory and Accountability Foundation

Week 1-2:

• Launch AI discovery scan: survey all business lines for AI tools in use (approved or not)
• Pull vendor contract inventory: flag any vendor contract where AI is embedded in the service
• Map discovered systems against your existing model inventory — identify gaps

Week 3-4:

• Risk-tier all discovered AI systems using your existing tiering criteria (or establish criteria if none exist)
• Assign provisional owners to each system; escalate High-risk systems without identified owners immediately
• Draft accountability matrix: who owns each role described in GV-2.1

Deliverable: Complete AI system inventory (current state, not aspirational), accountability matrix with named owners.

Days 31–60: Policy and Training Alignment

Month 2 priorities:

• Review AI risk policy against GV-1.1 requirements: does it address all applicable laws for your use cases?
• Update executive risk tolerance statement to reflect current AI deployment landscape (if it hasn’t been touched since 2023, it’s out of date)
• Develop use-case-specific training modules for the three groups most likely to be examined: model developers, validators, and business unit users
• Document decommissioning process for High-tier AI systems

Deliverable: Updated AI risk policy with use-case regulatory mapping, training records for identified personnel, decommissioning procedure.

Days 61–90: Culture, Feedback, and Third-Party Closure

Month 3 priorities:

• Establish feedback loop: route AI-tagged customer complaints to model owners
• Run first tabletop exercise on a high-risk AI failure scenario
• Review all High-tier third-party AI vendors against GV-6.1 requirements; identify gaps in transparency documentation
• Present GOVERN implementation status to board/risk committee — include inventory summary, accountability matrix, training completion rates, and outstanding gaps with remediation timeline

Deliverable: Board presentation on AI governance status, third-party AI vendor gap analysis, documented feedback routing process.

The Exam Reality Check

The Common Regulatory Exam Findings on AI post from earlier this month documents what examiners are actually finding. The GOVERN deficiencies that show up most frequently:

1. AI inventory doesn’t match reality: Examiners ask for the inventory; it’s 40 models. They ask business lines what they’re running; it’s 140. Shadow AI is endemic.

2. Accountability gaps: The RACI for AI exists, but when an examiner asks “who owns Model X,” nobody can answer without a five-minute search. Documented accountability means findable accountability, not buried accountability.

3. Risk tolerance written for a different era: Board-approved AI risk appetite statements that talk about “statistical models” and don’t address LLMs, generative AI, or agentic systems. These need updating before the next board cycle, not after the exam finding.

4. Third-party assumption: Institutions that treat vendor AI as “their problem.” If you’re deploying a vendor LLM in customer service, you own the customer outcome risk. The vendor is part of your AI risk program, not outside it.

5. Training theater: Completion rates are excellent; actual comprehension of how to escalate AI-related concerns is zero. Examiners ask: “If you noticed an AI model was producing biased outputs, what would you do?” Staff who can’t answer that clearly haven’t been trained to NIST AI RMF GV-2.2 standards.

So What?

The GOVERN function isn’t a compliance exercise. It’s the organizational plumbing that makes AI risk management possible. Without an accurate inventory, you don’t know what you’re managing. Without clear accountability, you don’t know who makes the call when something goes wrong. Without a risk tolerance that reflects your actual AI deployment, your second-line oversight is flying blind.

Start with the inventory. Document accountability. Update the risk tolerance statement. The rest of the framework builds on those three things.

Building the AI inventory and governance structure from scratch? The AI Risk Assessment Template & Guide includes an AI model inventory template, pre-deployment risk assessment checklist, and third-party AI vendor questionnaire aligned to NIST AI RMF and SR 11-7 — the practical toolkit for GOVERN operationalization.

FAQ

Q: What does the NIST AI RMF GOVERN function actually require? The GOVERN function establishes organizational infrastructure for AI risk management across six sub-functions: risk management policies (GV-1), accountability structures (GV-2), workforce diversity (GV-3), risk-aware culture (GV-4), stakeholder engagement (GV-5), and third-party risk management (GV-6). Core deliverables include a maintained AI system inventory, documented roles and responsibilities, and executive accountability structures.

Q: Is NIST AI RMF mandatory for financial institutions? Technically voluntary, but increasingly unavoidable. The Treasury’s FS AI RMF (February 2026) maps NIST AI RMF to 230 bank-ready control objectives. OCC, Federal Reserve, and FDIC examiners reference NIST AI RMF language in supervisory guidance. Institutions that haven’t adopted the framework face questions they can’t answer well.

Q: What is an AI system inventory and what should it include? An organized database covering model name, purpose, risk tier, use case, data inputs, output type, deployment environment, accountable team, validation date, and known limitations — for all models, including vendor-supplied and shadow AI discovered through business line scans.

Q: Who owns AI risk governance in a bank or fintech? CRO or MRM team for large banks; typically compliance/risk functions for mid-size institutions. The requirement isn’t a specific title — it’s documented accountability with named individuals responsible for each model, independent validation, and board-level reporting.

Q: What are the most common GOVERN function deficiencies in AI exams? Incomplete inventories missing shadow AI, accountability structures that don’t reflect who actually owns models, executive risk tolerance statements written before LLMs arrived, and third-party AI governance that relies entirely on vendor assurances instead of independent assessment.