Your First AI Win Should Solve One Small Problem

Most community banks that talk about AI never start a project. The idea comes up in a strategic planning session, someone raises a fair concern about vendor risk or cost, and it gets tabled until next year. That isn't reluctance to modernize. It's that "AI" gets translated in the room into something enormous: a platform decision, a multi-year contract, a line item the board has to approve twice before anyone touches a keyboard.

That translation is the actual obstacle, not the technology. Every operations leader at a bank this size can name three or four workflows worth fixing without thinking hard: the loan file that takes thirty emails to complete, the new account that sits in a queue for three days for no clear reason, the report someone rebuilds from scratch every Monday morning. The problem is that "let's fix this one thing" gets discussed and budgeted as if it were "let's replace our core."

The bankers who are successfully implementing AI right now are not describing sweeping platform bets. They are describing narrow, closely governed first steps, which tells you what a realistic first project looks like at a bank your size, and points to a different way of scoping the decision than the one that usually stalls it in committee.

The Conversation Has Shifted From Capability to Control

Talk to bankers who are further along with AI and the conversation isn't really about what the technology can do. It's about how much access it gets and what happens if something goes wrong. American Banker's reporting on, "What Small Banks Want From Their Vendors" captures this shift in the executives' own words.

Steven Gonzalo, CEO of the $2 billion-asset American Commercial Bank & Trust in Ottawa, Illinois, took a conservative first step: he initially restricted employee AI use altogether, concerned that customer information could end up incorporated into a vendor's training data. He has said his bank's decision to expand access further now depends on vendors providing clear guarantees around data anonymity, not on the AI tools getting more capable.

Kevin Day, CEO of the $320 million-asset State Bank in Waterloo, Illinois, took a different path to the same underlying concern. Rather than hand a vendor broad access to bank data, Day's team is building a large language model in-house, run on their own server and deliberately kept off the open internet, so information never has to leave the building. Inside that contained environment, his team has already assigned agents to nearly a hundred internal tasks, from inbox triage to producing the bank's monthly funds management report.

Gonzalo and Day are solving the same underlying concern from different angles, one cautious about outside vendors, one building in-house, but neither is describing a big rollout. Both started with something bounded enough that unwinding it, if needed, wouldn't touch anything else the bank depends on. That's the pattern worth borrowing, regardless of which specific approach a bank eventually chooses.

This isn't just two banks being individually cautious. Industry groups are flagging the same concern at a systemic level. The Independent Community Bankers of America has pointed out that as banks lean harder on outside vendors to deploy AI, many contracts still lack clarity about who owns the data, and oversight gets harder to track as the chain of subcontractors behind any given tool grows longer. Anjelica Dortch, the ICBA's vice president of operational risk and cybersecurity policy, has said that without clearer regulatory guidance on contracting, the current environment is "really the wild, wild west." That's the backdrop any new AI initiative gets evaluated against, and it's a large part of why the size of the first ask matters as much as what it's supposed to accomplish.

This matters for how a first project gets pitched internally. A board that hears "we want to build an AI platform" is right to ask hard questions about vendor access, data handling, and what happens if the relationship doesn't work out. A board that hears "we want to test whether one specific, contained task can be handled more reliably, with data staying where it already lives" is looking at a much smaller and more answerable question. The scope of the ask should match the scope of the actual decision being made.

The Case for One Workflow, Not One Platform

The platform approach asks leadership to commit before there's any evidence it will work in this specific bank, with this specific staff, against this specific set of legacy systems. That's a hard sell to a board, and it should be. A scoped pilot asks for something much smaller: permission to try one contained fix, measure what happens, and decide from there with real information instead of a vendor's projections.

This isn't an argument against eventually doing more, it's an argument about sequencing. A bank that proves out one workflow has a template and a real result to point to when it scopes the next one. A bank that commits to a platform first is betting the whole outcome on an implementation that hasn't happened yet.

What "Small" Actually Looks Like

"Small" has a specific shape, not just a vague instruction to start modest.

One recurring task. Not a department's entire workload, one specific, repeatable piece of it: sorting a loan package by document type, routing a flagged transaction to the right analyst, pulling the numbers for a report that goes out every week regardless.

One department, not an enterprise rollout. The people who touch the workflow should be countable on one hand, and the sponsor should be able to explain the whole thing in two sentences without needing a slide deck.

A result visible in weeks, not a quarter. If the pilot can't show something concrete inside a few weeks, either the scope is too big or the task wasn't a real candidate. A first project should be sized so the bank knows whether it worked before the next board meeting, not the one after.

Notice what's absent from that definition. It doesn't require a specific technology or vendor. It requires a task narrow enough to actually finish.

How to Pick the First One

Not every workflow makes a good first project, even if it's genuinely annoying to staff. A few criteria separate the ones worth starting with from the ones to save for later.

• It should be visible to leadership without a translator. If explaining the fix requires walking someone through the current process first, it's too buried to make a convincing first case, even if it's a real problem.

• It should be contained in scope. The fewer systems and people it touches, the easier it is to measure and the less there is to unwind if it doesn't pan out.

• It should be low risk if it has to be reversed. A first project is, by definition, a test. Pick one where reverting to the old process is a Tuesday afternoon, not a project of its own.

• It should have an owner who wants it to succeed, not one who's been assigned it. The workflows that actually get fixed are usually ones a specific person has already complained about more than once. That person is your sponsor.

• It should limit what data leaves your existing systems. A pilot scoped to one task naturally limits what a vendor or new tool needs to see, compared to a platform that needs broad access just to get off the ground. Before agreeing to try anything, ask what data it touches, where it lives while being processed, and whether it's copied anywhere outside the bank's environment. If those questions don't have clear answers, that's worth knowing before the pilot starts, not after.

What This Looks Like in Practice

Picture a $650 million community bank whose commercial lending team spends the first several days of every loan file just sorting and re-entering the same information. A borrower submits a packet with tax returns, bank statements, a P&L, and a handful of supporting documents, and an analyst manually splits the packet, identifies each document type, and keys the relevant figures into the spreading tool before anyone starts the actual credit analysis.

That task meets every criterion above. It's one recurring, repeatable step, not the whole lending function, and it lives inside one department. The COO can explain it in two sentences: documents come in, someone manually sorts and re-keys them before real analysis can start. A pilot scoped to that single step usually looks the same wherever it's tried: the packet comes in, gets automatically classified and split by document type, files get named consistently, and anything the system isn't confident about gets flagged for a person to check before the clean file moves downstream. Nothing changes about how the credit team makes decisions, and there's no new system for underwriters to learn, just the sorting and re-keying step handled before anyone touches the file, with a person still reviewing anything flagged as uncertain. If it doesn't work out, the bank reverts to the manual process the same afternoon, with nothing else disrupted.

Have a Problem To Solve?

If your team has a workflow everyone has quietly learned to live with, that's usually the clearest sign it's worth a second look. The most effective approach is to start small, one problem at a time, rather than looking for a single platform to fix everything at once.

Plenty of these get solved with a small script, a quick automated workflow, or a purpose-built tool running inside your own environment. Our automation and micro-apps page covers that approach. If you'd like to talk through a first project, schedule a discovery call with one of our operations experts.