Before You Approve AI, Ask What Data It Will Believe
A practical weekly article for community bank and credit union boards and senior leaders on why AI approval packets should govern the data an AI tool will rely on before approvi...
The AI demo is usually the cleanest part of the meeting.
The model answers quickly. The workflow looks polished. The vendor says implementation is straightforward. Someone in the room says the institution cannot afford to fall behind, which is usually true enough to be dangerous.
Then the approval packet moves to budget, timeline, security review, and vendor due diligence.
All necessary.
But there is a quieter question that should come before the vote.
What data will this thing believe?
That sounds like a technical detail. It is not. For a community bank or credit union, it is a governance question. If an AI tool is going to summarize member conversations, support lending workflows, review exceptions, draft policy language, triage fraud alerts, or guide frontline staff, then the board and senior team need to understand the information supply chain behind it.
Bad data does not become strategic because a model touched it. It becomes faster, more confident, and harder to unwind.
That is the part I want boards to catch before the pilot starts, not after the first awkward exception lands in the risk committee packet.
AI does not fix the operating model underneath it
A lot of AI proposals are really operating model proposals wearing better clothes.
The institution wants faster servicing. Better fraud detection. Cleaner documentation. More consistent answers. Less manual work. Fewer backlogs. Nobody is wrong for wanting those things.
But AI is not magic grout for cracked processes. If customer data is duplicated across systems, if account notes are inconsistent, if policies disagree with procedures, if exception codes mean different things in different departments, the model is going to inherit that mess.
Worse, it may smooth the mess into something that sounds official.
That is the governance danger. A messy spreadsheet looks messy. A conflicted policy binder looks conflicted. A bad AI answer can look calm, complete, and executive-ready. Very helpful. Very dangerous. Like a toddler in a blazer.
Before approving an AI use case, leaders should know which systems feed it, who owns those data fields, how errors are detected, and what happens when the model relies on stale, conflicting, or unauthorized information.
If nobody owns the data, nobody really owns the AI outcome.
Case one: data governance is already a regulatory issue, not a cleanup project
The biggest institutions make the headlines, but the lesson travels down-market.
In 2020, the Office of the Comptroller of the Currency assessed a $400 million civil money penalty against Citibank related to deficiencies in enterprise-wide risk management, compliance risk management, data governance, and internal controls. The OCC said the action was based on unsafe or unsound practices tied to long-standing failure to establish effective risk management and data governance programs and internal controls.
Four years later, the Federal Reserve fined Citigroup $60.6 million for violating the Board's 2020 enforcement action. The Fed specifically cited insufficient progress with data quality management and failure to implement compensating controls to manage ongoing risk.
Community institutions are not Citigroup. The size, complexity, and supervisory posture are different.
But the principle is not different.
Data governance is not housekeeping. It is part of the control environment. If leadership treats data quality as something that gets cleaned up after the AI project, the institution has the sequence backwards.
A board does not need to review every field mapping. Please do not make directors sit through that unless you want them to fake a medical emergency.
But the board should expect management to explain the important parts in plain English.
Which data sources are authoritative? Which data sources are known to be messy? Which business owner can certify that the data is fit for this use case? Which compensating controls exist while cleanup is still in progress? Which errors would create customer harm, compliance exposure, or credit risk?
That is not micromanagement. That is oversight.
Case two: the institution owns the answer, even when the system generated it
AI risk is not limited to banking, and that is useful because other industries are already leaving breadcrumbs.
In 2024, CBC reported that Air Canada was ordered to compensate a customer after its chatbot gave incorrect information about bereavement fares. The company argued that the chatbot was responsible for its own actions. The tribunal member called that submission remarkable.
That is the sentence every bank and credit union leader should remember.
The system does not become a separate moral actor because it has a chat window. If your institution's tool gives a customer, member, employee, lender, collector, or support representative the wrong answer, the institution still owns the governance problem.
In financial services, that can get ugly quickly.
A chatbot summarizes the wrong fee rule. A lending assistant pulls outdated policy language. A fraud triage tool underweights a signal because a mapping table was stale. A frontline knowledge tool tells staff to follow a procedure compliance already replaced. An AI-generated board summary leaves out the operational caveat that made the recommendation risky.
None of those failures require science fiction. They require ordinary data drift, weak ownership, poor testing, and too much confidence in a polished interface.
That is why the approval discussion should separate three things that often get blended together:
The model: what the tool can do. The data: what the tool is allowed to believe. The decision rights: who can accept, override, stop, or escalate the output.
If those three are not clear, the AI approval is not ready.
What should be in the board packet
A useful AI packet does not need to turn directors into machine learning engineers.
It should translate the risk into decisions they can govern.
Start with the use case. Not "deploy AI." That phrase should be illegal in board packets, or at least punished with extra committee minutes. Say what the tool will actually influence.
Will it draft responses? Summarize calls? Prioritize alerts? Recommend next-best actions? Review loan documentation? Support BSA investigation notes? Assist employees with procedure questions?
Then name the data path.
Where does the information originate? Which system is the source of truth? How often is it refreshed? Which data is excluded? Are customer or member records being used? Are third-party datasets involved? What happens when records conflict?
Then name the ownership.
Technology may run the platform. Compliance may review the control. Risk may monitor exposure. Operations may live with the outcome. But someone in the business has to own whether the data is fit for the decision the tool is supporting.
That owner should be named before approval.
Finally, name the control boundary.
What can the AI do without human review? What requires approval? What must never be automated? What evidence is retained? How are errors reported? When does the pilot pause? Who has authority to stop it?
That last question matters because a bad AI workflow does not always fail loudly. Sometimes it just gets used every day until the wrong assumption becomes normal.
The board's job is not to be impressed
The board's job is not to be impressed by the demo. The CEO's job is not to win the innovation theater portion of the agenda. The risk committee's job is not to bless a tool because a peer institution is experimenting with the same category.
The job is to make sure the institution understands what it is putting into production.
For community banks and credit unions, that means AI governance has to stay close to real operating decisions. Member communication. Lending fairness. Fraud response. BSA documentation. Exception handling. Vendor oversight. Board reporting.
That is where bad data becomes bad judgment.
And that is why the most useful AI question may be the least glamorous one in the room:
What data will this thing believe, and who is accountable when that belief is wrong?
Questions for the next AI approval meeting
1. Which specific customer, member, operational, or compliance decisions will this AI tool influence, even indirectly? 2. Who owns the quality, timeliness, and authorized use of the data the tool relies on? 3. What condition would cause management to pause or roll back the pilot before the next board meeting?