AI Governance for Credit Unions and Community Banks: Start With the Models You Did Not Build

The AI governance conversation at most credit unions starts with a proposed project. It should start with an inventory, because the institution is already exposed.

Your fraud vendor scores transactions with a model. Your lending platform may run automated decisioning. Your core provider has been adding machine learning features to products you already pay for, sometimes announced in a release note. Your collections vendor prioritizes accounts somehow. None of that required a board decision, and all of it is your risk.

Here is the part most coverage of this gets backwards. NCUA's 2026 supervisory priorities do not mention artificial intelligence at all. Not once. The priorities are balance sheet management, operational risk covering payment systems and fraud, and BSA compliance. Third-party risk appears in a single sentence under lending: examiners will assess third-party risk-management practices where lending, servicing, or collection functions are outsourced.

Plenty of vendor commentary claims otherwise. Read the letter; it is short.

That absence is the point, and it cuts against you rather than for you. NCUA has said it supervises AI inside the existing framework rather than as a separate category, which means nobody arrives asking to see your AI program. They arrive asking about fraud controls, payment systems, and outsourced lending functions, and the models are sitting inside those. A model you cannot explain does not become a finding labeled "AI". It becomes a finding about underwriting, or vendor oversight, or an adverse action notice.

The vendor models are the real exposure

Institutions that build models tend to know they have models. Institutions that buy them frequently do not.

This is where the gap sits, and it produces an uncomfortable dynamic: you are accountable for decisions produced by a system you cannot inspect, sold to you by a vendor whose contract predates anyone thinking about model governance.

The questions worth asking every vendor whose product touches a member decision:

Does this product use machine learning or automated decisioning, anywhere in the workflow? Ask in writing. Ask again at renewal, because the answer changes without notice.
What data was it trained on, and does that include our members' data?
Can you produce, for a specific declined applicant, the factors that drove that outcome? If the answer involves a support ticket and several days, that is your adverse action timeline problem, not theirs.
What validation has been performed, by whom, and when? Ask for documentation rather than assurance.
How are we notified when the model is retrained or replaced? A silent retrain changes your risk profile without changing your contract.
What testing has been done for disparate impact?

Expect some of these to go unanswered. An unanswered question is itself a finding, and it is far better to have it documented in your own risk register than discovered in an examination.

What a minimum viable program contains

Small institutions do not need what a large bank needs. They do need four things, and the first one is cheap.

A model inventory. What is running, who owns it, what data it consumes, what decisions it influences, when it was last reviewed. This is a spreadsheet until it is not. Trivial with three entries, unmanageable at thirty, and examinable at any size. Build it before you need it.

An approval path. Who decides that a model may go into production, what evidence they require, and where that decision is recorded. Without this, institutions either ship nothing or ship things they cannot defend, and the second is worse.

Monitoring that watches inputs. Output accuracy is a lagging indicator. By the time approval rates or fraud catch rates move, the model has been making worse decisions for a while. Watching the distribution of what goes in catches drift earlier, and is usually easier to instrument.

Documentation that survives staff turnover. Why this model, what alternatives were considered, what its known limitations are. Written for someone who was not in the room.

That is a program a 20 to 40 person IT organization can actually run. Anything more elaborate tends to be designed, admired, and abandoned.

Explainability is a design constraint, not a feature

If a model contributes to a credit decision, you will be asked why a specific member was declined. That obligation shapes the architecture.

It means retaining the inputs to every scored decision, versioned against the model that produced it, in a form you can reconstruct months later. Bolting that on afterward is substantially more expensive than designing for it, and it is the most common reason a promising pilot never reaches production.

It also constrains model choice. A model whose decisions cannot be explained in terms a member and a regulator will accept is not usable for that decision, regardless of how it performs. This is a real cost of operating in regulated finance and it is better absorbed at design time than discovered at deployment.

Where AI is genuinely worth doing, and where it is not

Worth being direct, because a lot of the vendor conversation is not.

Reasonable near-term candidates: fraud and anomaly detection, where the models are mature and the vendor market is competitive. Document processing and data extraction, where errors are visible and correctable. Internal search and knowledge retrieval for staff, where the downside of a wrong answer is low and a human is always in the loop. Call summarization with review.

Approach carefully: anything touching credit decisions, pricing, or account closure. Not because it cannot work, but because the governance overhead is substantial and should be budgeted honestly alongside the benefit.

Be skeptical of: member-facing generative chat as a first AI project. It is the most visible, the most demanded by boards who have read an article, and the one with the worst ratio of governance burden to member value at this stage. If a member gets an incorrect answer about their account from your chatbot, that is your problem in a way that a slow web page never is.

The uncomfortable position, which we will state plainly: for many credit unions the correct AI roadmap for the next year is to inventory vendor models, fix the data foundation, and deploy nothing new. That is a defensible answer to a board, and it is more defensible than a pilot nobody can support.

First ninety days

Inventory vendor models. Send the questions above to every vendor touching a member decision. Record the non-answers.
Write a one-page position: what the institution will and will not do with AI this year, and who approves exceptions.
Identify the data foundation gaps that would block anything useful, because they will be the constraint regardless of which model you eventually choose.
Pick one low-stakes internal use case and run it end to end through your new approval path, to test whether the process works before it matters.

The institutions that will handle the next few years well are not the ones with the most ambitious AI programs. They are the ones that can answer, in one document, what is running and who owns it.

For how we approach this, see AI and ML for financial services and technology leadership for credit unions, or book a call.