La mayoría de los proyectos de IA en banca no falla por la tecnología: falla antes, en cómo se encuadró el problema. Tres investigaciones (RAND, McKinsey y el BIS) convergen en que el cuello de botella es organizacional, no técnico. Las tres fallas más comunes: comprar «una IA» en vez de un resultado de negocio medible, que nadie del negocio sea dueño del proyecto, y diseñar el piloto para impresionar en la demo en vez de sobrevivir a producción (core legacy, datos reales, riesgo y compliance). El antídoto es un checklist de cuatro preguntas antes de aprobar el piloto: resultado medible, owner de negocio, datos y sistemas reales, y camino a producción en el plan desde el día uno.
La IA generativa es una realidad actual en el sector financiero. Los casos de uso están claros, la tecnología está disponible, y los equipos que antes dudaban ahora están en modo de implementación. La pregunta ya no es «¿deberíamos explorar la IA?» sino «¿cómo hacemos para que el proyecto llegue a producción y genere valor real?». Esa pregunta tiene respuesta y, paradójicamente, tiene poco que ver con la tecnología. ¿Por qué algunos proyectos llegan y otros no? Hay un patrón que se repite en la industria y que tres investigaciones distintas documentaron por caminos distintos: los proyectos de IA en banca que no escalan no suelen fallar por el modelo, fallan antes, en cómo se definió el proyecto. RAND Corporation , que entrevistó a ingenieros con más de cinco años de experiencia en proyectos de IA en producción, identificó cinco causas raíz de fracaso. Solo una es técnica; las otras cuatro son de encuadre, liderazgo y organización. McKinsey describe un «purgatorio de pilotos» donde los proyectos impresionan en la demo y no avanzan. El BIS , al definir pautas de gobernanza de IA para el sector financiero (2025), pone el foco no en la capacidad del modelo sino en la gobernanza, los controles de riesgo y la claridad del propósito como los factores que determinan una adopción exitosa. El patrón converge en el mismo lugar: la diferencia entre los proyectos que generan valor real y los que no está en cómo se encuadró el problema, no en qué modelo se eligió. Y eso, en realidad, es una buena noticia. La buena noticia: el cuello de botella está bajo tu control Si la causa principal no es la tecnología, tampoco depende de esperar la próxima generación de modelos ni de cambiar de proveedor. Depende de decisiones organizacionales que el banco puede tomar hoy, antes de aprobar un piloto. La ventaja competitiva no está en acceder a una tecnología que nadie más tiene: está en saber cómo encuadrar el problema para que el proyecto sobreviva el paso de la demo al mundo real. Eso es lo que separa a los equipos que escalan de los que se quedan en el purgatorio de pilotos. Las tres fallas que detienen los proyectos (y cómo evitarlas) 1. Se compra «una IA», no un resultado de negocio El pedido llega como «necesitamos un chatbot» o «queremos IA en atención al cliente». No llega como «queremos reducir un 20% el tiempo de resolución en reclamos de tarjetas sin incrementar la tasa de fraude». Sin un resultado medible y un owner responsable de ese número, el piloto se evalúa por lo que impresiona en la demo, no por lo que mueve el negocio. Y en producción, donde los datos son reales y los comités de riesgo hacen preguntas difíciles, la demo ya no alcanza. La corrección es directa: antes de hablar de tecnología, el proyecto necesita un resultado escrito en una frase. «Mejorar la experiencia del cliente» no es un resultado. «Reducir el tiempo promedio de resolución de consultas de 8 a 4 minutos en el canal WhatsApp», sí. 2. Nadie del negocio es dueño del proyecto La iniciativa termina huérfana en Innovación o en TI. Cuando hay que pelear por presupuesto, por acceso a datos o por integración con el core, no hay un líder del negocio con algo real en juego que defienda el proyecto. Según RAND, los malentendidos sobre el propósito del proyecto son la causa raíz número uno que los propios ingenieros señalan. No la falta de datos ni el modelo, sino la falta de claridad sobre para qué existe el proyecto y quién responde por eso. La corrección es identificar, antes del piloto, a una persona del área impactada —no de TI ni de Innovación— que responda por un resultado concreto de negocio: ingresos, costos, o un indicador propio del área. 3. El piloto se diseña para impresionar, no para sobrevivir producción Producción corre sobre un core bancario de décadas, datos fragmentados, latencia real y cumplimiento regulatorio que no figura en ningún documento de la evaluación inicial. El salto de la POC a producción es donde se concentra la mayor parte del riesgo. Los proyectos que lo superan son los que incluyeron la integración, la gobernanza y los controles de riesgo en el plan desde el primer día, no como una «fase 2» que nadie termina de financiar. El checklist antes de aprobar el piloto Cuatro preguntas que, si tienen respuesta antes de firmar algo, aumentan significativamente las probabilidades de que el proyecto llegue a producción: ¿Cuál es el resultado de negocio medible? Un número, una línea base actual y una meta. Si no puede escribirse en una frase, el proyecto no está listo. ¿Quién del negocio es responsable de ese resultado? Una persona del área impactada que responda por el número, no por la tecnología. ¿El piloto corre sobre datos y sistemas reales? Si no, no estás probando el proyecto: estás probando una demo. ¿El camino a producción está en el plan desde el día uno? Integración, gobernanza, controles de riesgo y cumplimiento regulatorio como parte del diseño inicial, no como etapa futura. A tener en cuenta: si el proyecto solo puede explicarse en términos de tecnología («vamos a implementar IA generativa»), está mal encuadrado. Si se explica en términos de negocio («vamos a recuperar X horas de gestión / reducir Y costo de atención / aumentar Z tasa de contención»), tiene posibilidades reales. Una aclaración necesaria La tecnología sí importa: hay casos en los que el modelo es el límite real —problemas que la IA todavía no resuelve bien, o donde la calidad de datos es tan baja que ningún encuadre la compensa—. El propio RAND lo reconoce como una de las cinco causas de fracaso. El punto no es que la tecnología sea irrelevante, sino que en la distribución observada es el factor minoritario. Apostar primero a «mejor tecnología» cuando el problema es de encuadre es optimizar la variable equivocada. Dos aclaraciones de rigor: la evidencia de RAND y el MIT es cross-industry, no exclusiva de banca, aunque la lógica se refuerza en el sector financiero por las capas adicionales de regulación e integración legacy. Y los datos del MIT (Project NANDA, 2025) son recientes y todavía sin la validación longitudinal de estudios más consolidados: los usamos como señal potente, no como ley establecida. Cómo lo encaramos en Delto El patrón que describen las investigaciones es el mismo que vemos en proyectos reales: el piloto impresiona y después se choca con el core legacy, los datos reales, el comité de riesgo y las preguntas de cumplimiento que nadie anticipó en la evaluación inicial. Por eso en Delto empezamos con dos preguntas: qué resultado de negocio tiene que moverse y quién, del lado del negocio, es dueño de ese número. La tecnología viene después, cuando esas dos preguntas tienen respuesta, como instrumento para mejorar el negocio. No es una promesa de resultados garantizados, sino el orden que —según la evidencia disponible y lo que vemos en campo— separa los proyectos que llegan a producción de los que se quedan en el purgatorio de pilotos. Si tenés un proyecto en curso o una prueba de concepto que no terminó de escalar, hablemos de cómo encuadrarlo para que llegue a producción. Fuentes Gartner, «Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025» (julio 2024). Ver fuente RAND Corporation, Ryseff, De Bruhl y Newberry, «The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed» (2024). Ver fuente MIT, Project NANDA, «The GenAI Divide: State of AI in Business 2025» (julio 2025). Cobertura McKinsey & Company, «The State of AI in 2025» (QuantumBlack). Ver fuente Bank for International Settlements, «Governance of AI adoption in central banks» (enero 2025). Ver fuente Nota: las cifras provienen de las publicaciones primarias citadas. La evidencia de causas raíz (RAND, MIT) es cross-industry, no exclusiva de banca. La jerarquía causa-raíz/consecuencias es interpretación analítica de Delto, no una conclusión literal de las fuentes.
¿Por qué fracasan los proyectos de IA en banca? Según RAND, de cinco causas raíz de fracaso solo una es técnica; las otras cuatro son de encuadre, liderazgo y organización. La mayoría no falla por el modelo, sino por cómo se definió el proyecto.
¿Qué es el «purgatorio de pilotos»? Es el término que usa McKinsey para los proyectos de IA que impresionan en la demo pero nunca avanzan a producción ni generan valor real.
¿Cómo se encuadra bien un proyecto de IA en banca? Empezando por un resultado de negocio medible (un número, una línea base y una meta), con un owner del negocio responsable de ese número, probando sobre datos y sistemas reales, y con el camino a producción (integración, gobernanza, riesgo, compliance) en el plan desde el día uno.
¿Entonces la tecnología no importa? Sí importa: a veces el modelo o la calidad de datos es el límite real, y RAND lo reconoce. Pero en la distribución observada es el factor minoritario; apostar a «mejor tecnología» cuando el problema es de encuadre es optimizar la variable equivocada.