AI Governance Framework for Community Banks and Credit Unions

An AI governance framework for community banks does not need a new department, a data science team or a hundred-page policy. It needs five things an examiner can see: an inventory of every place AI is used (including inside software you already license), a risk tier for each use with the reasoning written down, controls that scale with the tier, a named owner and an approval record, and regular reporting to the board. Credit unions need the same five.

The reason to build it now is that state examiners just got a playbook. On September 16, 2026, the Conference of State Bank Supervisors released its AI Supervisory Framework, including a Core Examiner Guide, a document request list and an optional risk-tiering worksheet. State regulators supervise about 79 percent of U.S. banks, according to CSBS. Meanwhile the federal model risk guidance, SR 26-2, points itself at banks above $30 billion and leaves generative and agentic AI out of scope entirely.

This guide turns those documents into a program sized for a community institution: what applies to you, how to inventory and tier AI use, which controls go with which tier, what changes for credit unions, and a 90-day plan that ends with an exam-ready file. It is a practitioner's guide, not legal advice; confirm specifics with your compliance team and counsel.

Why community banks need an AI governance framework now

For most of the past two years, a community bank asking "what do regulators expect from us on AI?" got an unsatisfying answer: existing guidance applies, nothing AI-specific exists, use judgment. That answer is still technically true. What changed in 2026 is that the people who will exercise that judgment published how they intend to look.

Four developments matter for a community institution:

• The federal model risk guidance moved away from you. SR 26-2, issued April 17, 2026 by the Federal Reserve, OCC and FDIC, says it is "expected to be most relevant to banking organizations with over $30 billion in total assets," and a footnote excludes generative AI and agentic AI from its scope. We cover the details in our SR 26-2 model risk management guide. The practical effect: the most detailed federal governance document no longer covers either your size or the AI you are most likely to deploy.
• State examiners got a specific toolkit. The CSBS Core Examiner Guide, approved August 13, 2026, gives examiners eight scoping questions, a document request list and procedures for governance, inventory and generative AI. CSBS calls it "a discretionary tool" and says "each state agency will determine the extent to which this framework is incorporated into their supervisory programs." Discretionary or not, it tells you exactly what a prepared bank looks like.
• Third-party risk guidance is being rewritten. On September 15, 2026, the OCC, Federal Reserve, FDIC and, for the first time, the NCUA proposed replacement third-party risk guidance. Comments close November 16, 2026. Most community bank AI arrives through vendors, so this matters more to you than any model risk document.
• The promised federal AI guidance has not arrived. When SR 26-2 was issued, the agencies said they "plan to issue in the near future" a request for information covering banks' use of generative AI, agentic AI and AI-based models. As of October 17, 2026, a search of the Federal Register for documents from the OCC, Federal Reserve, FDIC and NCUA mentioning artificial intelligence since April 17 returns no such request.

The internationally coordinated view landed on October 15, 2026, when the Financial Stability Board finalized its Sound Practices for Responsible Adoption of AI: twelve practices in two groups, organization-wide governance and lifecycle risk management, offered as "a practical toolkit that financial institutions can tailor to their specific context and risk profile." The FSB writes for the global system, not for a $700 million bank in Iowa, but its list lines up closely with the CSBS framework. When international, federal and state bodies converge on the same handful of controls, those controls are the ones to build.

Demand is real, too. Federal Reserve Governor Michael Barr noted in October 2025 that AI for customer support was an important focus for 31 percent of respondents to the CSBS community bank survey in 2024, a share that "jumped to 47 percent" in 2025. Customer-facing AI is exactly the category that draws the most examiner attention.

Key takeaway: "We are below $30 billion" answers whether SR 26-2 applies. It does not answer whether your AI is governed. State examiners now have a written method for asking the second question.

Which rules actually apply to AI at a community bank or credit union

There is no single AI rule for community institutions. There is a stack of existing obligations, each of which reaches some AI uses. The table below is the map we would put at the front of an AI policy.

Two observations from that table drive the design of everything below.

First, the documents that reach community banks are about relationships and outcomes, not models. Vendor oversight, consumer protection and fair lending apply regardless of asset size or AI type. A framework built only around model validation would cover the smallest slice of your actual exposure.

Second, the CSBS framework is the most specific published examiner tool for AI, and it is explicitly scaled to institution size. Even a nationally chartered bank or a credit union can use it as a self-assessment, because CSBS says institutions can also use it to assess their own AI programs, set up governance and prepare for exams. That makes it the natural spine for a community bank program.

What a right-sized AI governance framework contains

Strip away the vocabulary and every serious framework, NIST, FSB, CSBS, asks for the same components. Here they are in the order a community institution should build them, with the scale that is realistic for a bank or credit union with a few hundred employees.

1. A policy that fits on a few pages. Scope (what counts as AI for your purposes), roles, the approval process, the tiering method, prohibited uses, data rules and reporting. Staff-facing rules for tools like chatbots and copilots belong in an acceptable use policy; our AI acceptable use policy template includes a banking variant.
2. An inventory. One row per AI use case, including vendor-embedded AI. This is the foundation every examiner procedure builds on.
3. A tiering method. A consistent way to decide which use cases need light-touch oversight and which need testing, monitoring and board visibility.
4. Controls that scale with tier. A short baseline for everything, more for anything customer-facing or decision-influencing, and the full set for anything that directly determines a customer outcome.
5. Vendor oversight for AI. Questions and contract terms that a standard security review misses, applied in proportion to the tier.
6. Named accountability. A business owner per use case, a coordinator for the program, a committee that approves higher tiers and a board that receives reporting.
7. Monitoring and change triggers. A rule for when a use case gets re-tiered: new data, new decision authority, a vendor model change, or a problem.

None of these require new technology. A spreadsheet inventory, a Word policy and a recurring committee agenda item are enough to start, and for most community institutions they are enough to finish.

How to build the AI inventory examiners will ask for

The CSBS document request list asks for an "inventory or list of AI systems, tools, models, or use cases," documentation of "business purposes, ownership, and use," and a "list of vendor products or services with known or potential embedded AI capabilities." The examiner work program is blunt about why: AI use "may be missed if it is embedded in software or treated as a feature rather than as a distinct system or use case."

That is the central problem for a community bank. You probably built very little AI. You almost certainly bought some.

Where to look

Run a structured data call rather than asking "do we use AI?" in a meeting. Ask each department head, and your core and major software vendors, the same questions:

• Fraud and BSA: Does any monitoring, screening or alert-scoring tool use machine learning, behavioral analytics or anomaly detection?
• Lending: Do any origination, decisioning, document processing or pricing tools use models, scorecards or AI-based document extraction?
• Customer service: Do your chatbot, contact center, call summarization or online banking platforms use generative AI or natural language processing?
• Marketing: Do any targeting, segmentation or content tools use AI?
• Productivity: Which generative AI tools (copilots, chat assistants, meeting transcription, email drafting) are licensed or in use, approved or not?
• IT and security: Does endpoint, email or network security tooling rely on machine learning detection?

Then confirm the answers against your vendor inventory, software inventory, approved tools list and recent product release notes. The CSBS guide tells examiners to do exactly this cross-check when an institution's answer is negative or unclear, so you should do it first.

What each inventory row should capture

Do not wait for the inventory to be perfect. An honest list with gaps marked "vendor has not confirmed" is more useful, and more credible in an exam, than a polished list that misses half your embedded AI.

How to tier AI use cases by risk

Tiering is what keeps a small institution's program proportionate. Without it, you either over-govern a meeting-notes tool or under-govern a credit decision engine.

CSBS published an optional AI Use Case Risk-Tiering Worksheet alongside the examiner guide, available from the framework page. It scores each use case on four factors, each rated low, moderate or high:

• Consumer impact: internal use only; informs decisions affecting consumers with a human making the final call; or directly determines outcomes such as access to credit, pricing or account status with no human review.
• Human oversight: every output reviewed before action; only exceptions reviewed; or fully automated, including cases where human review happens only after the customer is affected.
• Harm potential from errors or outage: minor and easily reversed; financial, compliance or reputational harm; or significant, hard-to-reverse harm such as wrongful denial of credit or unlawful discrimination.
• Data sensitivity: aggregated or non-personal data; non-sensitive personal data such as contact details or transaction history; or sensitive data including nonpublic personal information, protected class data, biometrics or likely proxies for protected characteristics.

The rule that makes it work: "The highest-rated risk factor should generally establish the preliminary tier assignment." A final tier can differ "when supported by documented rationale," and any downward adjustment "should be reviewed and approved consistent with the institution's governance process."

Worked examples for a typical community bank

The table below applies the worksheet to use cases common at community institutions. These are our illustrative assessments, not CSBS determinations; your facts, especially data flows and how much humans actually review, will change the answers.

The loan-summary row shows why the documented rationale matters. Strictly applied, sensitive data alone makes it Tier 3. Many institutions will reasonably argue that an underwriter reviewing every summary against the source file, inside a private deployment with no retention by the vendor, justifies Tier 2. The worksheet permits that, as long as the reasoning is written down and the downgrade is approved through governance. What it does not permit is skipping the analysis.

Which controls go with each tier

The CSBS worksheet lists suggested controls by tier, and they are cumulative: "Tier 3 use cases are expected to have Tier 1 and Tier 2 controls as well." Condensed, with the work involved at a community institution:

Two practical notes.

Testing is the control most institutions underestimate. "Pre-deployment testing addresses accuracy" means a set of real cases with known correct answers, run before launch and re-run after every vendor model change. For chatbots and document tools, our guide on how to evaluate AI chatbot accuracy explains how many test cases you need before an accuracy number means anything.

Logging is the control that is hardest to add later. Incident response, complaint investigation and fair lending review all depend on being able to reconstruct what the AI saw and produced. Decide what to log when you approve a use case, not after the first complaint. Our AI audit trail requirements guide has a field-by-field list.

Key takeaway: Most community banks will find that the bulk of their AI sits in Tier 1, with a few Tier 2 uses and perhaps one or two Tier 3. Spend most of the effort there. Proportionality is the point of tiering, and it is what examiners are told to expect.

Generative AI and AI agents: the questions examiners will add

The CSBS guide has a separate section for generative AI, large language models and agentic tools, triggered whenever scoping finds them. Its eight procedures boil down to five questions your file should answer for each generative use case:

1. What kind of deployment is it? Public, private, internally deployed or vendor-provided. A consumer chatbot app that staff use with personal accounts is a very different risk from an enterprise tenant with no training on your data.
2. What data may go in? The work program says public or lightly controlled tools "may warrant closer attention because of data, access, and output-control risks." Your answer is a written data rule plus technical enforcement where you can get it.
3. Who reviews the output, and how? "Human in the loop" is only a control if you can say who reviews what, against which source, before which action.
4. Have you identified the specific risks? The guide names "inaccuracy, hallucination, prompt injection, and data exposure." Document how each is addressed or accepted for each use case.
5. Can you restrict or stop it? For systems that take actions, procedure GE-8 asks how the institution "defines the actions the system is permitted to take, human checkpoints, logging, reversibility, and the ability to restrict or halt the system."

That last question is the one community banks are least prepared for, and it will matter more as vendors add agent features to core, digital banking and contact center platforms. The FSB's final sound practices include human oversight and explainability with compensating controls among its twelve items. If a vendor proposes an agent that can move money, change account settings or send customer communications, ask for the permission list, the approval step and the off switch in writing before the pilot, not after. Our guide to building AI agents describes the permission and checkpoint design we would expect to see.

Vendor AI: where most community bank AI actually lives

For a community institution, AI governance is mostly third-party risk management with a few new questions. The 2023 interagency guidance, issued by the Fed as SR 23-4, states that using a third party does not diminish a banking organization's responsibility to operate safely and soundly and in compliance with law. The CSBS work program quotes that principle directly in its scoping questions on vendor and embedded AI.

The proposed replacement guidance, published September 15, 2026, keeps that responsibility but changes the tone. The agencies say the 2023 guidance "frequently has been interpreted in an overly broad manner and with an insufficient focus on tailoring," and propose a risk-based approach in which oversight scales with significance. It also states that "there are no generally applicable expected contract terms for third-party relationships--even for higher-risk relationships." Until it is finalized, the 2023 guidance remains the operative document for banks.

For AI specifically, the CSBS document request list is a useful guide to what you will be asked for: "contract terms, service terms, or vendor documentation addressing the use, retention, sharing, or training of AI systems on customer, consumer, confidential, or institutional data." In plain terms, every AI vendor file should answer:

• Does the vendor or its model provider train on our data, and where is that prohibited in writing?
• How long are prompts, documents and outputs retained, and where?
• Which underlying models and subprocessors are used, and will we be told when they change?
• What testing evidence can the vendor share, and can we run our own?
• What happens to our data and the service if we leave?

Our AI vendor risk assessment questionnaire has the full question set with evidence to request and red flags. Use the tier from the worksheet to decide how much of it to send; a Tier 1 productivity tool does not need the same review as a Tier 3 decisioning model.

What changes for credit unions

Credit unions should build the same framework, with three differences in emphasis.

The supervisor's stance is technology-neutral. NCUA's AI resources page says the agency has issued no AI-specific rules, supervises AI "within the existing supervisory framework," and that "our supervisory focus is on risk management, not the tool itself." Examiners look at safety and soundness, compliance, internal controls over AI tools, ongoing risk monitoring and third-party due diligence. The same page points to NCUA Letters to Credit Unions 07-CU-13, Evaluating Third Party Relationships, and 01-CU-20, Due Diligence Over Third Party Service Providers, as the vendor reference points.

Model risk guidance is thinner. The Government Accountability Office reported in GAO-25-107197, published May 19, 2025, that NCUA's model risk management guidance is limited in scope and detail and does not give staff or credit unions sufficient detail on managing model risks, including AI models. GAO recommended an update. As of GAO's latest status note, the recommendation remains open; NCUA pointed to its AI resources page, and GAO responded that the page does not provide detailed model risk guidance covering a broad variety of models. A credit union that adopts a CSBS-style tiering method is filling that gap itself, which is a defensible position in an exam.

Vendor oversight carries more weight. The same GAO report notes that NCUA lacks authority to examine technology service providers, despite credit unions' growing reliance on them for AI-driven services, and reiterates GAO's 2015 recommendation that Congress consider granting it. Banks benefit indirectly when federal banking agencies examine major service providers; credit unions cannot rely on that. Your own due diligence is the main line of defense.

State-chartered credit unions may also meet state examiners, and the CSBS framework covers state-licensed nonbanks; whether a given state applies it to credit unions is a question for that state's regulator. The NCUA also joined the September 2026 third-party risk proposal, so its outcome matters to credit unions for the first time.

Fair lending, adverse action and consumer protection

The fastest way for an AI system to create a real violation at a community institution is in lending and customer communications, not in model documentation.

Regulation B requires that the statement of reasons for adverse action "must be specific and indicate the principal reason(s) for the adverse action," and says statements that the decision was based on internal standards or policies are insufficient. The official commentary adds that reasons "must relate to and accurately describe the factors actually considered or scored by a creditor." The CSBS work program draws the AI conclusion directly: using AI or other complex tools "does not eliminate the need to identify the principal reasons for adverse action where such notices are required."

So for any AI that touches credit decisions, including vendor scorecards and underwriting assistants, your file needs to show:

• Reason codes that map to real factors. If you cannot get them from the vendor, the use case is not ready.
• A fairness review before launch and periodically after. The CSBS Tier 3 controls call for a documented pre-deployment review of fairness and fair lending risk, plus ongoing monitoring.
• Proxy awareness. The worksheet's high data-sensitivity rating explicitly includes "data elements that could serve as proxies for protected characteristics." Ask what inputs the model uses, not only whether it uses protected class data.
• Complaint capture. Tier 2 controls include a complaint process that captures AI-related issues. Tag them so you can find them.

For customer-facing generative AI, the CSBS document request list includes "samples of recent AI-generated or AI-assisted consumer-facing outputs," such as chatbot transcripts and generated communications. Expect examiners to read what your chatbot actually said. Review a sample yourself every month, against your product terms and disclosures, before they do.

Who owns AI governance at a small institution

Large banks build AI offices. Community institutions should not. A structure that works at most banks and credit unions with a few hundred staff:

The CSBS governance procedures ask whether governance is aligned "to the size, complexity, risk profile, and scope of the institution's AI use." A coordinator, a standing agenda item and a named owner per use case meet that test at a community bank. A committee charter that nobody follows does not.

A 90-day plan to an exam-ready AI governance file

This is the sequence we would run at a community bank or credit union starting from little or nothing. Durations assume a handful of AI use cases and no Tier 3 system that needs outside validation; adjust if you have more.

Weeks 1 to 3: discover. Name the executive sponsor and coordinator. Run the data call across departments and vendors. Cross-check against vendor and software inventories. Find shadow use of generative AI tools by asking, and by checking network and expense records with IT. Produce a first inventory with gaps marked.

Weeks 3 to 6: tier and write. Complete a risk-tiering worksheet for each use case. Draft the AI policy and the staff acceptable use rules. Get committee approval for the tiering of anything at Tier 2 or above, and record any downward adjustments with their rationale. Send AI-specific questions to vendors behind Tier 2 and Tier 3 use cases.

Weeks 6 to 10: control the top tiers. For Tier 2 and Tier 3 use cases, build or obtain test sets and run them, confirm escalation paths, check adverse action processes where credit is involved, turn on logging and add AI tags to the complaint system. Write the AI incident response procedure, including who can switch a tool off and how fast.

Weeks 10 to 12: report and assemble. Deliver the first board report: inventory by tier, open issues, vendor gaps, incidents and the plan for the next two quarters. Assemble the exam file in the order of the CSBS document request list: policies, committee materials, board reporting, the inventory, tiering worksheets, generative AI rules and approved tools, vendor materials, testing results, consumer-facing samples and any independent review.

Then keep it current. The worksheet says to update the tier when "the business purpose for a use case expands, more decision-making authority is granted, or issues arise from a vendor." Make those events triggers in your intake process so the inventory never drifts more than a quarter out of date.

What to watch for the rest of 2026

Three things could change the picture before year end, and none of them change the core of the framework above.

• The federal AI request for information. The agencies said in April they would issue one "in the near future." It had not appeared as of October 17. When it does, it is the clearest signal of where federal expectations for generative and agentic AI are heading, and community bankers' comment letters will matter.
• The final third-party risk guidance. Comments on the September proposal close November 16. If finalized broadly as proposed, it would give community banks more room to tailor vendor oversight, including for AI vendors, and would bring credit unions under the same interagency text.
• State adoption of the CSBS framework. Each state decides how far to use it. Ask your state regulator directly whether it will be used in your next exam and in what form.

Where this leaves you

An AI governance framework for community banks and credit unions is no longer a guess about what regulators might want. The CSBS examiner guide spells out the questions, its worksheet spells out the tiering, and the FSB, NIST and federal agencies point the same way. What none of them do is require a large program. They ask for an honest inventory, proportionate controls, named owners and a board that knows what is running.

Start with the inventory this month, because every other control depends on it, and expect to find more embedded vendor AI than you thought. Tier each use case with the reasoning written down. Put real testing, logging and an off switch on the few that touch customers or decisions. Then report it.

Fleurant AI builds AI for regulated industries, including the evaluation harnesses, logging and control documentation that make an AI system defensible in an exam, alongside custom AI development for institutions that want to build rather than buy. If you are working out how a specific AI use case should be tiered and controlled, talk to a specialist. For questions of legal interpretation, your counsel and compliance team make the call. You can also see everything we do on the Fleurant AI home page.