Nine questions a risk committee asks about AI

AI can make financial education more responsive, personal and available. It can also create unacceptable risk when its role is vague. The safest starting point for a bank or credit union is a narrow one: an AI tutor that explains approved educational material, adapts practice and knows when to stop.

A risk committee does not need to approve AI in the abstract. It needs to approve a defined use case, a controlled data flow and evidence that the system stays inside its boundary. These are the nine questions that turn a broad technology discussion into a practical review.

Begin by defining the role

Words such as assistant, coach and adviser are often used interchangeably, but they imply very different behaviour. Define the role in plain language before discussing the model, vendor or interface.

A financial education tutor can explain a concept, ask a learner a question, give feedback and guide someone back to approved material. It should not recommend a financial product, infer what a person ought to do from their circumstances or make any decision that affects access to financial services.

1. What is the AI allowed to do?

Ask for a precise capability list and real examples. “Explain how compound interest works” is a bounded educational task. “Tell me which savings product is best for me” crosses into a different category. The interface, system logic, policies and staff training should all use the same definition.

The approved role should also describe the audience, topics, channels and languages in scope. A control is much easier to test when the permitted behaviour is specific.

2. What is it technically prevented from doing?

A policy statement or prompt instruction is not enough on its own. Advice boundaries should be enforced outside the conversational model, with checks that can block or redirect prohibited requests before a response reaches the member.

Review evidence from adversarial testing, including indirect, emotional and persistent attempts to obtain a recommendation. The test is not whether the tutor refuses a perfectly phrased advice request. It is whether the boundary holds when a real person approaches it in an unexpected way.

3. Which information can it use?

The safest educational answer is grounded in a controlled body of institution-approved content. The committee should know who owns that content, who approves changes, how sources are versioned and whether the tutor can answer beyond them.

A useful response should be traceable to the lesson or source that supports it. If the system cannot find adequate approved material, it should say so and offer a next step rather than fill the gap with a plausible answer.

4. What member data reaches the model?

Map the data from the member’s message to the response and any stored record. Separate what is required to provide the learning experience from what is merely convenient. Confirm residency, retention, access controls, subprocessors and deletion arrangements.

Free-text conversation needs particular attention because members may enter information they were never asked to provide. The experience should discourage unnecessary personal detail, detect higher-risk content where appropriate and avoid reusing conversations for unrelated purposes.

5. How is the member told they are interacting with AI?

Disclosure should be clear at the point of interaction, not buried in terms and conditions. Members should understand that they are speaking with an AI tutor, what it is designed to do, what it cannot do and how to reach a person.

The language should be readable and accessible. It should remain available during the interaction, especially when the conversation moves toward a personal decision or a topic the tutor cannot handle.

6. When does the AI hand over to a human?

Define triggers for advice requests, complaints, distress, vulnerability, suspected fraud and questions the approved content cannot answer. A refusal is only useful when it explains the boundary and offers a clear route forward.

Test whether the handoff gives the human enough context to help without sharing more information than necessary. The ownership of the handoff also matters: the committee should know which team receives it, the expected response and what happens outside service hours.

7. How are accuracy and harmful behaviour tested?

Pre-launch evaluation should cover factual accuracy, misleading certainty, prohibited advice, bias, accessibility and attempts to bypass controls. Testing must reflect the language members actually use, including incomplete questions, spelling errors and ambiguity.

Ongoing evaluation should use approved test cases and real failure patterns. The committee should see thresholds, owners and remediation times, not just an overall accuracy percentage that averages serious and minor errors together.

8. Can every material interaction be investigated?

The institution needs enough evidence to understand what the member asked, which approved source was used, which controls ran and why the system responded as it did. That evidence supports complaints, incidents, control testing and continuous improvement.

Logging should be proportionate. Keep what is necessary for oversight and service quality, apply retention limits and restrict access. More data is not automatically better governance.

9. Who can change the system, and who approves those changes?

Model updates, content changes and guardrail revisions can all alter behaviour. Define change control, testing requirements, approval roles and rollback procedures. Compliance teams should be able to review educational content before publication, and material control changes should not reach members silently.

The same discipline should apply when the institution adds a new topic, channel or audience. A system approved for explaining budgeting basics is not automatically approved for every financial conversation.

What good evidence looks like

A strong review pack contains artefacts the committee can inspect, not only assurances from a vendor. Ask to see:

• The purpose statement and permitted-capability list.

• A diagram of the data flow, storage, subprocessors and deletion path.

• The advice-boundary specification and examples of prohibited responses.

• Sample refusals, disclosures and human handoffs.

• Content approval and version-control records.

• Accessibility testing and supported-language evidence.

• Evaluation cases, thresholds, incident procedures and named owners.

A live demonstration is equally important. Ask a legitimate educational question, then a product recommendation, then a personal question that tries to move the tutor toward advice. The difference between those responses should be obvious. If the boundary exists only in a policy document, it is not yet a reliable product control.

Govern the use case you actually have

AI governance is strongest when it is proportionate and specific. A tutor grounded in approved content should not be reviewed as though it makes lending decisions, but it should not receive a lighter review simply because it sits inside an educational experience.

Define the role, enforce the boundary, control the source material, minimise data, keep the member informed and make human support easy to reach. That creates an AI experience that can improve access to financial understanding without asking the institution or its members to accept an undefined risk.