Part 1 made the strategic case. Part 2 drew the community-versus-regional split alongside the federal framework. Part 3 went underneath the framework with data governance as the foundation, five categories of model, and the authority question that agents create. This article closes the series with the operating playbook. What actually goes in the AI program, and how the bank knows the AI program is working.

The mistake to avoid is treating AI governance as a document. A document is the artifact, not the program. Examiners do not grade banks on whether they have a policy. They grade banks on whether the policy is operating, whether the controls are working, whether the workforce is trained, and whether the board is seeing the right metrics. The institution that confuses the binder with the program will find itself at the exam with a thick policy and no defensible evidence that it is in use.

The Twelve Things That Belong in the Policy

The policy is the foundational artifact. It does not have to be long. The ICBA Artificial Intelligence Governance Policy template runs roughly ten to fifteen pages in its base form, and most banks should target a similar footprint. What it has to cover is twelve elements, each tied to a specific FS AI RMF control objective or supervisory expectation.

1. Scope and definitions: what counts as "AI," covering traditional ML, generative AI, agentic AI, and vendor-embedded AI. The AIEOG AI Lexicon is the right terminology source.
2. AI inventory standard: the single most important section, mandating a comprehensive inventory of every AI system the bank uses, including third-party and vendor-embedded systems, capturing purpose, data sources, risk rating, owner, vendor, and review cadence (FS AI RMF GV-1.6.1).
3. Risk tiering: prohibited, high, moderate, and low, with examples for each, so the bank applies proportional controls rather than uniform ones.
4. Acceptable use: specific language on what employees can and cannot do with bank-licensed and public AI tools.
5. Third-party AI requirements: disclosure, contractual language, bias testing documentation, SOC 2 evidence, model cards, right-to-audit, and incident notification (FS AI RMF GV-6.1.1).
6. Data handling: the data governance prerequisites from Part 3 referenced explicitly.
7. Human-in-the-loop standards: which decisions require human review, at what threshold, on what cadence.
8. Model validation and monitoring: pre-deployment testing, ongoing performance monitoring, drift detection, bias testing, and explainability documentation (FS AI RMF MS-2.4.1 and MS-2.9.1).
9. Incident response: what an AI incident looks like and the escalation path for each type (FS AI RMF MG-4.3.1).
10. Decommissioning: handling data, access, and audit trail when an AI system is retired (FS AI RMF GV-1.7.1).
11. Roles and accountability: the AI Risk Champion, the governance committee, the model owners, the data stewards (FS AI RMF GV-2.1.1).
12. Board and committee reporting: frequency and content of board reporting, typically quarterly to the Risk Committee with an annual full-board review.

A policy that covers these twelve elements, written clearly and operated as a practice, will satisfy examiner expectations under both the FS AI RMF and ISO/IEC 42001 — and these twelve elements map directly to ISO/IEC 42001 Clauses 4 through 10. A policy that covers fewer than nine is structurally incomplete.

Four Control Areas Where Most Banks Have the Largest Gaps

1. Shadow AI in the browser. This is the part of the AI attack surface most bank cybersecurity programs have not yet addressed. Employees access public generative AI tools through their browsers, pasting customer information, lending decisions, internal memos, and contract drafts into chat windows. The bank's traditional DLP infrastructure was built for email and file uploads, not for browser-based copy-paste into a SaaS endpoint. Browser-layer controls — through enterprise browsers or browser security platforms — give the bank visibility into which AI tools employees are using, what data is being shared, and what risk that creates. For community and regional banks, this is increasingly the first AI control to deploy, ahead of policy refinement.
2. Enterprise-licensed versus public GenAI. The bank should treat these as different categories. Enterprise-licensed AI — Microsoft Copilot, Google Workspace AI, ChatGPT Enterprise, Claude for Work — all comes with data residency, no-training-on-customer-data commitments, audit logs, and SSO integration. Public GenAI does not. The acceptable-use policy should permit enterprise-licensed AI for a defined set of use cases and prohibit public GenAI for any task involving customer information, internal financials, employee data, or regulated content.
3. Vendor-embedded AI. The hardest control problem is the bank does not see the AI directly. The fraud platform's anomaly detection, the marketing engine's segmentation model, the contact center's natural-language router, the core platform's deposit pricing optimizer, the loan origination system's decisioning model — every one is AI, governed by the vendor's choices, not the bank's. The control framework extends to the vendor through three mechanisms: disclosure (inventory of AI components, training data sources, model cards), contract (specific AI clauses covering bias testing, fair-lending evidence, incident notification, right-to-audit), and monitoring (override rates, customer complaints, disparate-impact testing).
4. The three-tier acceptable use playbook. Most banks have one acceptable-use policy. They need three. Tier 1 prohibited: customer PII in public GenAI, AI-generated adverse-action notices without human review, autonomous AI actions on regulated decisions, and any AI tool not in the inventory. Tier 2 permitted with controls: internal document summarization in enterprise-licensed AI, generative drafting of customer correspondence with human review, AI-assisted underwriting analytics with explicit override authority, marketing copy reviewed by compliance before publication. Tier 3 encouraged: productivity tools operating on non-sensitive data — for example, meeting notes, calendar management, internal training materials, code completion in non-production environments. These should be promoted, not just permitted, because they build AI literacy across the workforce without creating governance exposure.

Training the Workforce and the Board

AI literacy requirements should be role-based, not generic. Front-line and customer-facing staff need to know what AI the bank uses in customer-facing channels, how to recognize when a customer is interacting with AI, how to handle complaints about AI-driven decisions, and what to escalate. Lending and credit staff need to understand AI's role in underwriting, fair-lending obligations when AI is in the decision path, how to interpret explainability outputs, and how to write adverse-action notices when AI was involved. Marketing and product staff need rules on permitted AI in marketing automation and consumer-protection considerations when AI personalizes offers. Compliance, audit, and risk staff need detailed training — FS AI RMF control objectives, ISO/IEC 42001 audit methodology, NIST AI RMF crosswalks. IT and information security staff need the technical layer — browser controls, enterprise GenAI configuration, agentic AI access management, audit trail engineering, kill-switch procedures. The executive team needs the portfolio view, the vendor concentration view, and the examination posture. And the board itself needs training that most banks are skipping today — ISO/IEC 38507 is purpose-built for director-level AI oversight and is the most efficient curriculum source.

Four case studies should reinforce every training cycle. The deepfake CEO — a video or voice call appearing to come from the CEO requesting an urgent wire transfer — covers detection, out-of-band verification, and escalation. The prompt injection in customer chat — an AI customer service tool manipulated into bypassing its constraints — covers the failure mode, detection signal, and containment. The hallucinated account balance — an AI assistant tells a customer they have funds they do not — covers detection, customer remediation, and incident reporting. The biased adverse-action notice — an AI-assisted credit model generating language that implies protected-class characteristics or producing disparate impact — covers detection, remediation, regulatory exposure, and the human-review controls that should have prevented it. Training cadence should be annual at minimum, with policy-update refreshes pushed within thirty days of any material change.

Eight Metrics That Belong on the Board Scorecard

The board scorecard — what ISO/IEC 42001 Clause 9 calls Performance Evaluation — should fit on a single page. Eight metrics, current period, prior period, target, trend, and one-line commentary.

1. Inventory completeness: percentage of known AI systems fully documented; 100 percent target for high-risk systems.
2. Vendor disclosure coverage: percentage of third-party AI systems for which the bank has received complete disclosure (model cards, training data summary, bias testing).
3. Override rates: for each AI system in production, the rate at which human reviewers override the AI's recommendation; both high and low override rates are worth investigating.
4. Bias testing outcomes: disparate-impact testing results and trends across credit, pricing, marketing, and any AI-influenced customer decision.
5. AI incidents: number per quarter, severity, time to containment, time to remediation.
6. Training completion: percentage of workforce, by role band, completing required AI training within cadence; below 90 percent is board reportable.
7. Vendor remediation timelines: from identification of a vendor AI gap to resolution; long tails indicate vendor management weakness.
8. Examiner findings: trend of AI-related comments across regulatory examinations; the leading indicator of where supervisory expectations are moving.

The Risk Committee should see this scorecard quarterly. The full board should see it annually with the AI program review.

At examination, the regulator's first question will not be "do you have a policy?" The first question will be "show me your AI inventory." The second will be "show me how you control vendor AI." The third will be "show me how you handle an AI incident." The institutions that have built the policy, the controls, the training, and the metrics will be able to answer those three questions in fifteen minutes with documented evidence. The institutions that have built only the policy will discover, when sitting across from the examiner, that the binder was the smallest part of the program.

The Bottom Line

AI governance is not a document. It is a practice. The bank that treats AI governance as a one-time policy will discover, the first time an agent does something unexpected, that it never had governance at all. The bank that operates the program — policy, controls, training, measurement, refresh — will not only stay defensible. It will move faster, because the rest of the organization trusts the guardrails.

The work is not glamorous. It is inventory. It is contract language. It is training the workforce takes seriously because the board takes it seriously. It is metrics on a single page the Risk Committee actually reviews. It is a kill switch that has been tested. It is a vendor list someone has read.

The institutions that build the practice, not just the binder, will turn AI from a vendor-imposed risk into a deliberate strategic capability. The institutions that build only the document will find out what their governance gaps look like at exam time, in customer complaints, or after an incident.

This is the closeout of the four-part series. Hopefully, you found the content informative. The next chapter of community and regional banking will be written by the institutions that did the work and the institutions that did not.

CCG Catalyst advises community and regional banks, credit unions, and fintech companies on AI strategy, governance design, and regulatory readiness. If your institution is evaluating its AI governance framework, reach out to our team at www.ccgcatalyst.com.

See our latest announcement: CCG Catalyst's Paul Schaus Named a 2026 Top Consultant by Consulting Magazine

By: Paul Schaus | Founder & Managing Partner, CCG Catalyst Consulting

Disclaimer: The views expressed in this article represent the perspective of CCG Catalyst Consulting based on our direct experience advising financial institutions. This commentary is intended to stimulate industry discussion and does not constitute legal, accounting, or regulatory advice.