AI readiness starts below the model. Banks need a strong architectural foundation, clean data, modular services, clear governance, and systems designed for continuous change.
For most of the past decade, artificial intelligence in banking meant a future consideration, something to prepare for after the core was modernized, a line item you could push to next year’s roadmap without much cost. That window has closed. AI is no longer a roadmap item. It’s a live architectural force, and it arrived whether or not the foundation underneath it was ready.
Here’s the part that surprises executives who’ve been treating this as a budget or talent question: it isn’t. What separates banks that can actually deploy AI effectively from banks that can’t is architecture, full stop. Six conditions determine whether an AI initiative can move from pilot to production:
- Clear domain separation in the core
- Modular services with clean APIs
- Event visibility across key journeys
- A unified data architecture with shared meaning
- Governance embedded in the stack rather than bolted on afterward
- An operating model built for continuous change instead of periodic transformation programs
Banks that designed their systems with these properties find that AI accelerates almost everything they try. Banks that didn’t find that AI exposes every legacy decision they’d been quietly deferring for years, all at once, usually at the worst possible time.
I spent a lot of time with Harvey Koeppel on this while working on the book, and his framing is the one I keep coming back to:
“Risk belongs up front as a design input.”
— Harvey Koeppel, former CIO, Citigroup
Most banks still treat risk like paperwork that gets attached after the plan is already baked. That’s exactly how theater slips in: activity that looks like diligence without changing a single design decision. Real discipline moves risk to the front of the work and keeps it there. Design choices get made with risk and audit in the room, not three weeks later in a review. Outcomes have a named business owner from day one. Pilots have a clock and a decision date set at kickoff, not discovered when someone finally asks how it’s going.
Applied to AI specifically, that means treating readiness as an architecture question, not an AI question, and answering it before the model goes to production, not after a regulator asks why nobody did. A bank that already knows who owns which data, already has clean service boundaries, and already treats governance as part of the stack rather than a checklist bolted on at the end isn’t doing anything special to prepare for AI. It’s just discovering that the discipline it built for entirely different reasons happens to be exactly what AI readiness requires.
The banks that will struggle aren’t the ones moving slowly on AI out of caution. They’re the ones who assume readiness is a decision they can make the week they need it, and discover, usually mid-pilot, that six years of deferred architectural debt doesn’t clear itself just because the initiative is urgent now.
That’s the last idea in this series, and it’s not a coincidence it comes last. Everything earlier in this run (the calendar discipline, the balance across gears, the bright lines, the incentive fix, the pilot clock, the operating rhythm, the budget that actually funds cleanup) is what builds the foundation this chapter is about. AI readiness isn’t a separate initiative bolted onto the flywheel. It’s what the flywheel was already building, whether or not you called it that.
— Rick Mavrovich
