News
A Bank's AI Demo Is Easy. Showing Its Work Is Harder.
September's supervisory framework gives state-regulated institutions a clearer view of the questions behind the AI conversation.
The impressive answer is only the beginning. A bank also needs to understand how an AI tool reached it, which information it touched and who can stop it. On September 16, the Conference of State Bank Supervisors released an AI Supervisory Framework for state examiners assessing AI at state-chartered banks and state-licensed nonbank institutions. It describes a principles-based, risk-sensitive approach and helps institutions anticipate the questions and information an examiner may request.
This is not a blanket new AI law or a universal approval checklist. CSBS says each state agency will decide how to incorporate the framework. Its intended approach considers an institution's size, complexity, risk profile and use of AI.
A separate September 11 OCC announcement addressed third-party risk-management burden for community banks. These developments belong to different supervisory contexts; an institution should confirm which guidance applies with its own risk and legal teams, rather than treating every announcement as interchangeable.
Our read: a smaller institution can make an AI pilot easier to evaluate by making its boundaries visible from day one. Identify the owner, permitted data, source records and decisions the tool is not allowed to make. Explain what happens when the answer is uncertain or a connected vendor is unavailable.
A practical starting point is an internal, read-only evidence brief for a recurring review. The assistant gathers approved material and shows where each statement came from; an employee evaluates it. That keeps the trial separate from credit decisions, compliance determinations and customer-facing advice. It does not remove the need for appropriate vendor, privacy and security review.
Measure factual errors, omitted evidence and correction effort alongside time saved. Keep the evaluation examples and version history so the team can distinguish a promising demonstration from a dependable tool.
The useful engineering question is simple: can this system show its work when the person reviewing it was not in the room for the demo?