Opening
Most GenAI in banking never leaves the pilot. The demos work; the programs stall in architecture review, risk, compliance and core integration, and in the change management that decides whether anyone uses the result. I lead AI strategy and delivery for banks and credit unions and built a generative AI practice for banking, with RAG pipelines, reusable accelerators and adoption roadmaps, and one accelerator published on AWS Marketplace. This page is about the gap between pilot and production and how to close it.
Where pilots actually stall
A pilot is built to show that something is possible. Production is built to be relied on. The distance between the two is not model quality; it is everything the pilot was allowed to skip. A pilot runs on an extract of data; production needs a governed connection to the systems of record, and every connection is a data-sharing decision compliance has to sign. A pilot is judged by whether the output looks right; production has to prove where each statement came from. A pilot is used by the team that built it; production is used by bankers and relationship managers whose work it changes, who did not ask for it and who have to trust it.
Banks and credit unions have been approving generative AI use cases faster than they can get them through risk review and into adopted use. The result is a backlog of impressive demonstrations and very few systems in service. Closing the gap means building for production from the first day of the pilot, which changes which use cases are chosen and how they are built.
Pick use cases that survive a risk review
Start from the business case rather than the technology. A use case that touches a regulated decision, has an owner, a measurable outcome and known data permissions can be governed; one chosen because the demo impressed cannot. The test is simple to state and hard to pass: who owns this, what decision does it influence, how will we know it worked, and which data is it allowed to use. Use cases that can answer those four questions move through review. Those that cannot produce a pilot and then a long pause.
The discipline is older than generative AI. The investment governance I ran at IBM India between 2011 and 2014 required a written business case and a quantified ROI model on every proposal, and the approval cycle fell from more than thirty days to five once the standard was explicit. AI use-case portfolios respond to the same treatment.
Retrieval, not recall
Banking facts change daily and a model's training knowledge is frozen. Retrieval-augmented generation, retrieving the relevant and recent evidence at generation time and grounding the output in it, is what makes generated text current and traceable.
The client briefing system for a global card network fused internal transaction intelligence with continuously ingested external signals through exactly this pattern, and replaced a multi-week manual research process. Internal data, such as charge volume and transaction, relationship and contract history, sat alongside external news, announcements, regulatory sources and public signals that were continuously ingested, cleaned, de-duplicated, entity-resolved, chunked and embedded into a vector index with freshness management. At generation time the system retrieved the most relevant and recent evidence for a merchant, combined it with precomputed analytics and forecasts, and an orchestration layer prompted a large language model to write each section of the brief. Every number was injected from the analytics layer, never generated, and an automated validation step checked figures against source before release. It went from proposal to production in roughly one quarter.
Two things about that design matter for any bank. The model was never the source of a fact; it was the writer of a narrative around facts supplied to it. And every fact carried provenance, so a reader could trace it. Those two properties are what turn "the output looks right" into something a compliance team can approve.
Agents and agentic AI
AI agents follow instructions within bounds; agentic systems take initiative and orchestrate several agents toward an outcome. The distinction is instruction versus initiative, specialized versus adaptive, bounded versus autonomous. The length of tasks AI systems can complete autonomously has been doubling roughly every seven months, so the question for a bank is no longer whether these systems will be capable enough but where to let them work.
The answer is to start where trust is cheapest to earn: bounded, auditable tasks first, a human in the loop, and governance scaffolding before autonomy. A multi-agent design for business credit underwriting, with specialized agents from data collection through to documentation, is a useful illustration of how the pattern decomposes a workflow, and I present it as a design walkthrough rather than a client deployment. The same shape applies to wealth advisory, customer onboarding, fraud monitoring and personalized communication. What each needs before it goes live is the same: explicit bounds on what an agent may do, a record of what it did and why, and a person who can intervene. This is the subject of my second talk, Unpacking Digital Labor.
Accelerators instead of bespoke builds
Every bank rebuilding the same identity, compliance and epic-writing scaffolding is why GenAI programs are slow and expensive. Each engagement re-solves problems the last one solved, and each solution goes through risk review as if it were new.
Myridius Ascend, the banking accelerators program I lead, exists to replace bespoke build with reusable IP: an accelerator for an identity verification provider published on AWS Marketplace, a second running in the Myridius environment, and one that turns a single-line business request into a structured epic and story set with compliance, privacy and security guardrails built in. The last of these shows what an accelerator does for governance as well as speed. A business user states a request in one line; the system produces the epics and stories a delivery team needs, and the compliance, privacy and security requirements arrive with them rather than being added by a reviewer weeks later.
It is the same instinct I ran as a function at IBM: find where repeatable IP replaces bespoke build, then take it to client adoption. There the flagship asset took a service specification as input and generated, built, tested and deployed microservices end to end. Generative AI has made that kind of leverage available to far more of the delivery process, and the banks that capture it will be the ones that treat accelerators as governed products rather than one-off scripts.
Adoption is the finish line
The measure of a generative AI program is not the demo or even the go-live; it is whether the people whose work changed adopted it. Roadmaps, executive alignment on build-versus-buy, and change management are delivery work, not follow-up.
In practice that means three things run alongside the build. An adoption roadmap that says who will use the system, for what, and in what order, so that the first users are the ones with the clearest need. Executive alignment on what to build and what to buy, because a bank that builds what it could have bought spends its scarce governance capacity on the wrong thing. And change management with the users themselves, so that a relationship manager receiving a generated brief, or a banker seeing only the applications a system could not decide, understands what has been checked and what has not.
The five-point playbook I use with leadership teams is short: start small and think big, keep a human in the loop, invest in talent and reskilling, prioritize ethical frameworks, and foster a culture of adaptability. None of it is about model selection. All of it is about the part after the demo, which is where generative AI in banking is won or lost.