When Brian Moynihan told investors that more than 200,000 Bank of America employees were using AI-enabled capabilities, the headline practically wrote itself.
It is a remarkable number. The bank is using AI across productivity tools, coding support and agentic workflows. Yet the part I found most useful was the history behind it.
Bank of America has been developing AI capability for more than a decade, including fraud applications dating back to the early 2010s. Its current scale came from years of choosing use cases, developing controls, training people and learning how to operate the technology inside a regulated bank.
There is an important lesson there for the rest of us. The technology may be available quickly. An institution’s ability to use it well takes longer to build.
Scale follows process discipline
Any executive who has managed a core conversion has seen what happens when a new system lands on top of poorly defined processes. The technology can perform exactly as designed while people spend months debating exceptions, handoffs and ownership.
AI introduces the same problem with a few extra complications. A traditional processing system follows predetermined instructions. A generative or agentic system may produce variable outputs or take a series of actions within defined parameters. That puts even more weight on the workflow.
Somebody has to select the right work. Somebody has to agree on the expected outcome. Somebody has to decide which actions require a person to review the result and who can intervene if the process begins producing unacceptable outcomes.
The bigger the deployment, the more those decisions matter.
Governance that people can actually use
Bank of America’s AI review process covers 16 risk pillars, including privacy, bias, workforce impact and intellectual property. The number of pillars is interesting. The operating habit is what I would borrow.
A review process needs to be repeatable. It needs an identified decision maker and an evidence trail. It also needs to fit the size and complexity of the institution using it.
A community bank may have fewer use cases and a smaller risk team. It can still maintain an inventory, review material deployments and document who approved them. It can still specify when a human decision is required. It can still test whether the control works once a feature moves from pilot to production.
That is practical governance. It belongs in the normal management rhythm of the bank.
Traceability matters just as much. Bank of America and S&P Global have emphasized the ability to connect high-stakes AI outputs to underlying data. When a model influences a credit decision or raises a fraud alert, the bank needs enough evidence to explain what happened and why.
A polished answer on a screen is a poor substitute for that evidence.
Start smaller and operate better
I would take three steps before worrying about enterprise-wide adoption.
- Choose a workflow with a measurable outcome. Start with a process that has a clear owner and a defined service or risk problem to solve.
- Design the exception path before launch. Identify what the system may handle, what a person must approve and how the team can recover when a result is wrong.
- Make the evidence part of the workflow. Record data sources, approvals, monitoring results and changes as the process evolves.
Then expand when the operation is stable and people are comfortable challenging the results.
Banks sometimes look at the largest institutions and dismiss their examples because the budgets are out of reach. That reaction can make us miss the useful part of the story.
You do not need 200,000 users to benefit from clear ownership, disciplined rollout and traceable decisions. You need to treat them as part of the operating model from day one.
The number makes the headline. The discipline behind it is the part worth copying.
Covered in Don’t Blink, my weekly Banking Intelligence Service brief: Issues #25 and Issue #36.
