Most AI projects in banking don't fail because of the technology: they fail earlier, in how the problem was framed. Three research efforts (RAND, McKinsey and the BIS) converge on the bottleneck being organizational, not technical. The three most common failures: buying “an AI” instead of a measurable business outcome, having no business owner of the project, and designing the pilot to impress in the demo rather than survive production (legacy core, real data, risk and compliance). The antidote is a four-question checklist before approving the pilot: measurable outcome, business owner, real data and systems, and a path to production in the plan from day one.
Generative AI is a present-day reality in the financial sector. The use cases are clear, the technology is available, and the teams that once hesitated are now in implementation mode. The question is no longer “should we explore AI?” but “how do we get the project to production and generate real value?”. That question has an answer and, paradoxically, it has little to do with the technology. Why do some projects make it and others don't? There's a pattern that repeats across the industry, documented via different routes by three separate research efforts: the AI projects in banking that don't scale usually don't fail because of the model — they fail earlier, in how the project was defined. RAND Corporation , which interviewed engineers with over five years of experience on AI projects in production, identified five root causes of failure. Only one is technical; the other four are about framing, leadership and organization. McKinsey describes a “pilot purgatory” where projects impress in the demo and never move forward. The BIS , in defining AI governance guidance for the financial sector (2025), puts the focus not on model capability but on governance, risk controls and clarity of purpose as the factors that determine successful adoption. The pattern converges on the same place: the difference between the projects that generate real value and those that don't lies in how the problem was framed, not in which model was chosen. And that, in fact, is good news. The good news: the bottleneck is under your control If the main cause isn't the technology, it also doesn't depend on waiting for the next generation of models or switching vendors. It depends on organizational decisions the bank can make today, before approving a pilot. The competitive edge isn't in accessing technology no one else has: it's in knowing how to frame the problem so the project survives the jump from demo to the real world. That's what separates the teams that scale from those stuck in pilot purgatory. The three failures that stall projects (and how to avoid them) 1. You buy “an AI,” not a business outcome The request arrives as “we need a chatbot” or “we want AI in customer service.” It doesn't arrive as “we want to cut card-dispute resolution time by 20% without increasing the fraud rate.” Without a measurable outcome and an owner accountable for that number, the pilot is judged by what impresses in the demo, not by what moves the business. And in production, where the data is real and risk committees ask hard questions, the demo is no longer enough. The fix is direct: before talking about technology, the project needs an outcome written in one sentence. “Improve the customer experience” is not an outcome. “Reduce the average query resolution time from 8 to 4 minutes on the WhatsApp channel” is. 2. No one on the business side owns the project The initiative ends up orphaned in Innovation or IT. When it's time to fight for budget, for data access or for core integration, there's no business leader with something real at stake defending the project. According to RAND, misunderstandings about the project's purpose are the number-one root cause the engineers themselves point to. Not the lack of data or the model, but the lack of clarity about why the project exists and who is accountable for it. The fix is to identify, before the pilot, a person from the impacted area —not from IT or Innovation— accountable for a concrete business outcome: revenue, costs, or an indicator owned by that area. 3. The pilot is designed to impress, not to survive production Production runs on a decades-old banking core, fragmented data, real latency and regulatory compliance that appears in no document of the initial evaluation. The jump from POC to production is where most of the risk concentrates. The projects that make it are the ones that included integration, governance and risk controls in the plan from day one, not as a “phase 2” no one quite funds. The checklist before approving the pilot Four questions that, if answered before signing anything, significantly raise the odds the project reaches production: What is the measurable business outcome? A number, a current baseline and a target. If it can't be written in one sentence, the project isn't ready. Who on the business side is accountable for that outcome? A person from the impacted area who answers for the number, not for the technology. Does the pilot run on real data and systems? If not, you're not testing the project: you're testing a demo. Is the path to production in the plan from day one? Integration, governance, risk controls and regulatory compliance as part of the initial design, not as a future stage. Keep in mind: if the project can only be explained in technology terms (“we're going to implement generative AI”), it's poorly framed. If it's explained in business terms (“we're going to recover X hours of handling / cut Y support cost / raise Z containment rate”), it has real chances. A necessary caveat Technology does matter: there are cases where the model is the real limit —problems AI still doesn't solve well, or where data quality is so low that no framing compensates for it—. RAND itself recognizes it as one of the five causes of failure. The point isn't that technology is irrelevant, but that in the observed distribution it's the minority factor. Betting first on “better technology” when the problem is framing is optimizing the wrong variable. Two caveats for rigor: the evidence from RAND and MIT is cross-industry, not exclusive to banking, though the logic is reinforced in the financial sector by the additional layers of regulation and legacy integration. And the MIT data (Project NANDA, 2025) is recent and still lacks the longitudinal validation of more consolidated studies: we use it as a strong signal, not an established law. How we approach it at Delto The pattern the research describes is the same one we see in real projects: the pilot impresses and then collides with the legacy core, the real data, the risk committee and the compliance questions no one anticipated in the initial evaluation. That's why at Delto we start with two questions: what business outcome has to move, and who, on the business side, owns that number. The technology comes later, once those two questions have answers, as an instrument to improve the business. It's not a promise of guaranteed results, but the order that —according to the available evidence and what we see in the field— separates the projects that reach production from those that stay in pilot purgatory. If you have a project underway or a proof of concept that never quite scaled, let's talk about how to frame it so it reaches production. Sources Gartner, “Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025” (July 2024). View source RAND Corporation, Ryseff, De Bruhl and Newberry, “The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed” (2024). View source MIT, Project NANDA, “The GenAI Divide: State of AI in Business 2025” (July 2025). Coverage McKinsey & Company, “The State of AI in 2025” (QuantumBlack). View source Bank for International Settlements, “Governance of AI adoption in central banks” (January 2025). View source Note: the figures come from the primary publications cited. The root-cause evidence (RAND, MIT) is cross-industry, not exclusive to banking. The root-cause/consequence hierarchy is Delto's analytical interpretation, not a literal conclusion of the sources.
Why do AI projects in banking fail? According to RAND, of five root causes of failure only one is technical; the other four are about framing, leadership and organization. Most don't fail because of the model, but because of how the project was defined.
What is “pilot purgatory”? It's the term McKinsey uses for AI projects that impress in the demo but never advance to production or generate real value.
How do you frame an AI project in banking correctly? By starting with a measurable business outcome (a number, a baseline and a target), with a business owner accountable for that number, testing on real data and systems, and with the path to production (integration, governance, risk, compliance) in the plan from day one.
So the technology doesn't matter? It does matter: sometimes the model or data quality is the real limit, and RAND acknowledges it. But in the observed distribution it's the minority factor; betting on “better technology” when the problem is framing is optimizing the wrong variable.