Responsible AI Adoption for Community Banks: What the FSB’s Proposed Practices Mean

AI may already be operating inside your community bank, even if nobody purchased an “AI platform.” Fraud detection, cybersecurity, document processing, customer service, underwriting, and other technology products can contain AI functionality. The governance challenge is knowing where AI operates, what it can affect, and whether existing controls are keeping pace.

If your institution has questions about AI governance, risk assessments, vendor oversight, or audit readiness, contact NETBankAudit to discuss practical next steps.

The FSB’s Proposed AI Practices Are a Menu, Not a Mandate

The Financial Stability Board’s June 10, 2026 consultation report on responsible AI adoption proposes 12 sound practices for financial institutions.

The practices are not binding requirements, an international standard, or a prescriptive implementation plan. The FSB emphasizes proportionality, noting that smaller, less complex institutions and lower-risk AI uses may apply only the relevant practices or adapt them appropriately.

That distinction matters for community banks. Responsible AI governance does not require recreating the infrastructure of a global bank. It does require enough visibility, ownership, testing, human oversight, and vendor management to understand material AI-related risks.

The 12 practices fall into three broad areas: four organization-wide governance practices, six practices addressing AI use throughout its lifecycle, and two practices covering cyber/ICT and third-party risk.

This article addresses the June consultation report. Institutions should review any subsequent final FSB report for changes before relying on the proposed framework.

AI Governance Should Start With Ownership and Boundaries

The first four FSB practices focus on strategic direction, accountability, integration with risk management, and organizational adaptability. The board and senior management are expected to establish direction and oversight so AI adoption remains consistent with the institution’s business model, strategy, and risk appetite.

For a community bank, that does not necessarily mean creating a separate AI committee. Existing technology, risk, compliance, information security, vendor-management, and management committees may already provide much of the needed structure.

The important issue is whether responsibility is clear.

Banks should be able to identify who approves AI uses, who evaluates risk, who monitors performance, who handles exceptions, and who can escalate or stop a use that moves outside approved boundaries.

Policies or governance documentation should also address permitted, restricted, and prohibited AI uses. Higher-risk activities may require additional approval, testing, or human review.

Internal audit should remain independent from these management decisions. Its role is to determine whether governance and control processes are appropriately designed and operating as intended.

The FSB also references the NIST AI Risk Management Framework, which provides another useful structure for institutions developing or refining AI governance.

Banks Need to Know Where AI Is Being Used

Governance becomes difficult when management does not have reliable visibility into AI use.

The FSB supports maintaining documentation throughout the AI lifecycle and notes that institutions can build on existing use-case inventories, model inventories, third-party registers, or systems registries. A bank with limited AI adoption may not need specialized inventory software. The important issue is whether the record is complete enough to support oversight.

An AI inventory should generally identify:

• The AI-enabled product, system, or use case.
• The business owner and relevant provider.
• The intended purpose and any prohibited uses.
• The data the system can access.
• Connected systems and permissions.
• The level of autonomy or human approval required.
• Material risks and important dependencies.
• Approval, testing, monitoring, and review status.

The Independent Community Bankers of America’s response to the FSB consultation highlights an important community-bank issue: smaller institutions often encounter AI through established technology providers rather than through internally developed AI systems.

That means AI inventory work should extend beyond products explicitly marketed as AI. A core provider, cybersecurity platform, fraud tool, productivity application, or other existing vendor may add AI functionality through a product update.

Vendor release notes, procurement records, system inventories, and business-owner interviews can help identify those changes. An inventory that captures the original purchase but misses later AI-enabled features can quickly become incomplete.

Materiality Should Determine the Depth of Review

FSB Practice 5 calls for a systematic assessment of materiality and risk when an AI use begins and as it changes.

Not every use requires the same level of review.

An internal drafting tool working with nonsensitive information presents a different risk profile from an AI system influencing credit decisions, moving money, detecting fraud, interacting directly with customers, or executing actions inside a production environment.

A practical assessment should begin with what the AI can affect.

Questions should include:

• Does the system influence a significant customer, credit, fraud, security, or operational decision?
• What confidential or customer information can it access?
• Can it execute actions, or does it only provide recommendations?
• What happens if its output is wrong or misleading?
• Will a person review the output before it affects a customer or production process?
• Can staff adequately understand, test, and challenge the output?
• Could failure of the AI or its provider disrupt an important service?

Review depth should increase as the potential consequences, autonomy, complexity, data sensitivity, or dependency increase.

Institutions reviewing generative AI can also refer to Generative AI Controls and Risk Assessments for Financial Institutions for additional discussion of governance, data, model, vendor, and compliance controls.

AI Lifecycle Controls Need Evidence, Not Just Policy

FSB Practices 6 through 10 address selection, data governance, explainability and transparency, performance management, and human oversight.

Together, they reinforce a familiar audit principle: a control should be supported by evidence that it actually operates.

Select AI for a Defined Business Need

The business objective should be documented before deployment. Management should understand why the tool was selected, what alternatives were considered, which risks were identified, and which restrictions apply to its use.

A more complex AI solution is not automatically better if a simpler approach can achieve the same objective with less uncertainty.

Understand What Data the AI Uses

Data governance should address more than model-training data. Banks should understand what information employees enter into AI tools, what documents can be uploaded, what internal systems an AI application can retrieve information from, what data a vendor can retain, and whether the information can be reused for model training or other purposes.

Sensitive customer or institutional information should not flow into AI systems without appropriate authorization and controls.

Understand Enough to Explain and Challenge the Outcome

Explainability needs will vary by use case. A low-risk productivity tool may not require the same level of explanation as AI influencing credit, customer treatment, fraud decisions, or other material outcomes. Institutions should understand enough about the system’s inputs, limitations, and decision process to test its use, challenge questionable outputs, and provide appropriate information to management, auditors, customers, or regulators when needed. When meaningful explanation is limited, narrower use, additional testing, or stronger human oversight may help compensate for that uncertainty.

Test Whether the System Performs as Expected

Performance should be evaluated before deployment and monitored afterward at a level appropriate to the use case.

Testing records, exceptions, overrides, monitoring results, complaints, performance deterioration, and material system changes can all provide evidence that the institution is evaluating whether the AI continues to operate as intended.

A material change to the model, data, provider, functionality, or permitted actions may justify reassessment.

Human Oversight Must Be Meaningful

Assigning a human reviewer does not automatically create effective oversight.

The reviewer must have enough information, authority, and time to challenge the AI output. For higher-risk activities, institutions should define who can override a recommendation, stop an automated action, escalate an exception, or suspend the system.

Audit testing should look beyond policy statements that say a human is involved. Actual overrides, exception records, escalation activity, and monitoring can show whether human oversight works in practice.

Third-Party AI Risk Deserves Particular Attention

FSB Practice 12 focuses on third-party AI risk, including performance, transparency, data quality, supply-chain dependencies, concentration risk, and business continuity.

This is especially relevant to community banks because many AI capabilities will come from external providers.

Existing third-party risk processes provide a useful starting point. The federal banking agencies’ Interagency Guidance on Third-Party Relationships: Risk Management already establishes risk-based principles for due diligence, contracts, ongoing monitoring, and termination planning.

AI adds several questions to that review.

Institutions should understand:

• What AI functionality the provider uses or has added.
• What bank or customer information the AI can access.
• Whether data may be used to train or improve vendor models.
• What notice the bank receives when models, features, or subprocessors change.
• What testing, validation, certifications, or other assurance the provider can supply.
• What audit, information-access, incident-notification, and termination rights exist.
• How the institution will continue the activity if the AI functionality or service becomes unavailable.

Third-party AI can also create a transparency problem. A bank may not have access to the provider’s underlying model, training data, or technical design.

The FSB discusses compensating controls when full transparency is unavailable. Depending on the risk, those controls may include additional testing, narrower deployment, stronger human oversight, or limiting the system to lower-risk activities.

For material services, contingency planning should also address what happens if the AI component fails or becomes unacceptable. A proposed manual workaround is only useful if it can realistically support expected transaction volume and service requirements.

AI Cybersecurity and Agentic AI Should Connect to Existing Programs

FSB Practice 11 addresses AI-related cyber and ICT risk and encourages institutions to incorporate appropriate AI scenarios into testing and exercises.

Those risks should connect to existing cybersecurity, incident-response, and business-continuity programs rather than creating a separate AI security structure.

Relevant scenarios may include AI-enabled phishing and impersonation, prompt injection, sensitive-data exposure, malicious model inputs, or compromise of AI-connected systems.

For additional security considerations, see Risks and Strategies for AI Cybersecurity Risks.

Agentic AI creates additional questions because AI agents may have persistent access to systems, APIs, sensitive information, or authority to take actions without individual human approval. Controls should reflect what an agent can actually do, including permissions, logging, intervention authority, and escalation.

See Agentic AI in Banking: What Fiserv agentOS Means for Financial Institutions for a deeper discussion of agentic AI controls.

Five Questions for the Next AI Governance Review

The FSB proposal gives financial institutions a useful framework, but the goal should not be to create a new checklist simply to demonstrate “FSB compliance.”

For community banks, the practical starting point is determining whether existing governance can answer five questions.

1. Can we identify our material AI-enabled uses, including AI embedded in vendor products?
2. Does each material use have an accountable owner and a documented approval path?
3. Have we evaluated data access, customer impact, autonomy, dependencies, and potential failure consequences?
4. Can we demonstrate appropriate testing, monitoring, exception handling, and human oversight?
5. Have AI-specific vendor changes, dependencies, and continuity risks been incorporated into third-party oversight?

Gaps in those areas can help management determine where additional controls, documentation, testing, or audit work is warranted.

How NETBankAudit Can Help

Responsible AI adoption should build on risk-management disciplines financial institutions already use. Governance, cybersecurity, vendor management, data controls, internal audit, and business continuity all have a role when AI becomes part of banking operations.

NETBankAudit helps community banks, regional banks, and credit unions evaluate AI governance, technology controls, third-party risk, cybersecurity, and audit readiness. AI-related work can also be incorporated into risk assessments and independent audit reviews based on the institution’s activities and risk profile.

If your institution is evaluating AI use, reviewing vendor-embedded AI, or preparing its governance and control documentation, contact NETBankAudit to discuss the appropriate scope for an assessment or audit review.