Every bank compliance officer we talk to knows AI is a problem. Their employees are using ChatGPT, Microsoft Copilot, and a dozen other AI tools — some approved, some not, some a mystery. The compliance team is worried. The technology committee hasn't decided what to do. And meanwhile, client data is flowing into systems nobody has reviewed. Here are the three mistakes we see most often — and what to do instead.
Treating AI Like Any Other Software Tool
Banks have software approval processes. IT reviews a new tool, security runs a vulnerability scan, the vendor fills out a questionnaire, legal checks the contract, and you're done. Most institutions have tried to run AI tools through this same process — and it's the wrong approach.
The problem is that AI tools aren't passive software. They don't just process data on your behalf and return it. They potentially learn from the data you provide. They may retain your inputs. They may use your employees' queries to improve their models. The geographic location of data processing may change without notice. And unlike your core banking system, AI tools are often consumer-grade products that have been adopted by your employees long before anyone in compliance knew they existed.
Create a separate AI Vendor Assessment track. Your standard software questionnaire doesn't capture the right risks. An AI-specific assessment needs to explicitly address:
- Does user input train future models? Can you opt out?
- What is the vendor's data retention policy for queries and outputs?
- Where does data physically reside? Is processing US-only?
- Is there a data processing agreement (DPA) or equivalent available?
- What compliance certifications does the vendor hold? (SOC 2 Type II, ISO 27001)
- Is the vendor on the vendor's own enterprise/commercial tier, or a consumer tier?
Issuing a Prohibition Instead of a Policy
"Don't use AI tools with client data." You've probably said something like this — either formally or informally. It feels like a policy. It isn't.
Prohibitions don't work. Employees will use the tools anyway, because the tools are genuinely useful and the prohibition feels like bureaucratic overreach. The only thing a prohibition does is push the behavior underground — now they're using AI tools with client data, and they're not telling you about it.
This isn't a compliance failure. It's human nature. Every bank that deployed internet email in the 1990s dealt with the same problem. The employees who ignored the prohibition weren't bad actors; they were people trying to do their jobs more efficiently.
Write an actual AI Acceptable Use Policy. A real policy defines three things clearly:
- Permitted: What employees can do without asking permission (draft internal memos, summarize public documents, write code, research non-client topics)
- Requires approval: What needs a use-case review before proceeding (anything that involves client data in any form)
- Prohibited: What is never acceptable (inputting regulated data, bypassing approved platforms, using consumer AI on bank hardware for business purposes)
The goal is to give employees a framework for decision-making — not a list of rules to route around.
Writing a Policy Without Assigning an Owner
This is the most common mistake of all. The bank writes an AI policy — often a good one — and files it. Six months later, three new AI tools are in use that aren't covered by the policy, nobody has been trained on it, and there's been one incident that was handled informally and never documented.
Ask yourself: if an examiner walked in tomorrow and asked "who is responsible for AI governance at this institution?" — could someone answer that question with a name and a job title?
If the answer is "the IT department" or "compliance generally" or "we all kind of own it," you don't have a named owner. And policies without owners are policies that don't get maintained, enforced, or updated when something changes.
Designate an AI Platform Administrator. This doesn't need to be a full-time role or a new hire. It can be your existing IT or compliance lead. What matters is that the role is defined in writing with specific responsibilities:
- Maintain and update the approved AI tools list
- Review and approve use-case exceptions
- Ensure the AI Acceptable Use Policy is reviewed at least annually
- Receive and document AI-related incident reports
- Track regulatory changes affecting AI governance and update policies accordingly
The Pattern
These three mistakes share a common thread: they're all ways of treating AI governance as a one-time event rather than an ongoing program. You approve a tool, write a prohibition, file a policy — and consider the problem solved. But AI tools change rapidly, regulations are evolving, and your employees' use cases are expanding constantly.
The banks that get this right aren't necessarily the biggest or most sophisticated. They're the ones that assigned a person, wrote a real policy, and built a lightweight review process that keeps them current without adding significant overhead. That's what AI governance actually looks like in practice.
If any of the three mistakes above sounded familiar, you already know where to start.
Find Your Gaps in 2 Minutes — Free
Our AI Readiness Audit identifies which of these gaps apply to your organization — and tells you exactly what to do about each one. No email required to see your results.
Take the Free Audit →