De Piloto a Producción: por qué es tan difícil escalar IA

El 85% de los proyectos de IA no llega a producción. El problema no es tecnológico. Las empresas construyen rápido, prototipan bien y demuestran en una demo que la tecnología funciona. El problema está antes: en no haber definido el problema real, en no haber preguntado al usuario, en no tener métricas desde el día cero. La IA no ha cambiado las reglas del product management, solo ha hecho que los errores de siempre sean más rápidos y más caros.

Diez decision makers. Diez proyectos de IA sobre la mesa. Y una pregunta sin trampa: ¿en qué estado se encuentra cada una de las iniciativas? Esa fue la premisa del breakout "De Piloto a Producción" en el Product & Tech Leadership Summit Madrid 2026, liderado por Ramiro Blázquez, CTPO en Eaship, y María Dancausa, consultora en Thiga España y Senior PM en Conwerwallet. 

La dinámica era simple: cada participante tenía que situar sus iniciativas en un mapa que iba de backlog a producción, con tres destinos posibles en esa última fase: exitoso, sufriendo o muerto. 

El resultado fue más que revelador: entre el 60 y el 70% de los proyectos siguen en fases tempranas. Solo dos han cruzado a producción: uno funciona, el otro no.

El síndrome del bot 

Revisando las iniciativas una a una, el primer patrón que aparece es también el más incómodo: la mayoría de los bloqueos no tienen solución técnica porque no son problemas técnicos.

Un bot de atención al cliente parado no por limitaciones del modelo, sino por falta de priorización interna y ausencia de ownership claro. Un proyecto de personalización frenado porque nadie había definido antes de construir qué significaba exactamente "cliente leal". Un sistema de código asistido bloqueado por resistencia del equipo de ingeniería y por una pregunta que nadie ha respondido: ¿quién es responsable cuando el código generado falla en producción?

Este patrón tiene nombre propio: el síndrome del bot. Cuando apareció la IA generativa, casi todas las organizaciones se lanzaron a construir chatbots de atención al cliente casi por reflejo, antes de preguntarse si ese era el caso de uso más valioso o si el usuario quería realmente interactuar de esa forma. El resultado habitual: proyectos que demuestran que la tecnología funciona, pero no que el problema valía la pena resolver

Construir con IA es tan rápido y barato que se ha convertido en el punto de partida por defecto. Y esa facilidad desplaza el trabajo que debería ir primero: entender el problema, definir el éxito, validar con el usuario.

No porque nadie lo sepa, sino porque la presión por mostrar avance es alta y construir algo parece más productivo que hacer preguntas.

Tres preguntas antes de abrir cualquier proyecto de IA: ¿Qué problema concreto resuelve y para quién? ¿Cómo mediremos que lo que hemos resuelto? ¿Quién es el owner cuando llegue a producción? Si alguna de las tres no tiene respuesta clara, el proyecto no debería arrancar.

El caso de éxito

De todos los proyectos compartidos, uno llega a producción y funciona: un sistema de apertura de siniestros con IA en el sector asegurador. No es el más sofisticado técnicamente, pero sí el más disciplinado en todo lo demás.

Los objetivos están definidos desde el día cero: reducir 15 minutos el tiempo de llamada y mantener la retención por encima del 90%. Métricas concretas con las que evaluar el sistema en tiempo real desde el primer usuario. El despliegue es progresivo y controlado: pocos usuarios al inicio, rollback activo, tests automáticos nocturnos para detectar degradación de modelos antes de que el usuario lo note.

Técnicamente, resuelven de forma explícita uno de los problemas que más proyectos tumba sin que lleguen a identificarlo: el contexto compartido entre múltiples modelos. Orquestan ML tradicional con IA generativa de forma que ambos sistemas mantienen coherencia y no se contradicen frente al usuario.

El resultado actual: cuando el usuario completa el flujo, el tiempo de llamada mejora un 25%. El reto que siguen resolviendo es que un 40% de usuarios abandona el nuevo flujo. El orden de las predicciones es rígido y si el usuario quiere modificar algo a mitad del proceso, los modelos pueden contradecirse. Lo están resolviendo permitiendo relanzar solo la predicción modificada sin perder la consistencia del resto.

Lo que hace instructivo a este caso no es que sea perfecto, es que falla de forma controlada y con métricas que permitían ver exactamente dónde y por qué.

En el extremo opuesto: un sistema de reportes vía chat para usuarios de un SaaS del sector restauración. La tecnología funciona. El chat responde correctamente. El problema aparece cuando se ofrece a los usuarios pagar por más funcionalidad y el 90% dice que no. El diagnóstico del propio equipo es honesto: construyeron sin hablar antes con el usuario. Los usuarios no quieren convertirse en analistas de sus propios datos, quieren que alguien les dé la respuesta, no la herramienta para encontrarla. Lo que funciona para power users no funciona para todos. Y esa pregunta debería haberse respondido antes de escribir una sola línea de código.

La práctica que separa al caso de éxito del resto: los primeros 30 a 60 días post-despliegue son calibración, no mantenimiento. Las métricas se definen antes de lanzar. Y antes de construir cualquier funcionalidad, una conversación real con usuarios sobre si quieren lo que estás a punto de hacer.

Cinco patrones que se repiten

Ninguno es nuevo. Todos se amplifican con la IA.

• Construir antes de entender. Casi todos los proyectos bloqueados en backlog tienen el mismo origen: se empieza sin claridad sobre el porqué, para quién y con qué criterio de éxito. La velocidad de construcción ha hecho más barato saltarse el trabajo previo y más caro el error cuando aparece.

• Confundir la velocidad con progreso. Lo que costó dos horas construir necesita, para sobrevivir en producción, un equipo, gobernanza, SLAs, observabilidad y seguridad. El prototipo impresiona en la demo. El sistema real choca con el entorno organizacional. Planificar ignorando ese gap es uno de los errores más caros del ciclo.

• Lanzar sin evaluación ni baseline. Sin métricas de referencia claras desde el inicio, no hay forma de distinguir si el sistema mejora, empeora o simplemente alucina de forma diferente. Construir buenos evals y un baseline sólido no es una fase posterior al desarrollo, es una condición previa. Los proyectos que lo omiten no pueden iterar con criterio porque no saben desde dónde parten.

• Ignorar el contexto compartido entre modelos. Modelos que operan en silos, decisiones que se contradicen, experiencias de usuario que se rompen porque el sistema no mantiene coherencia interna. Es el problema técnico más común y más subestimado en proyectos con múltiples modelos y casi ningún equipo lo identifica como tal hasta que ya se ha generado el daño.

• Tratar el change management como comunicación y no como estrategia. Por encima del talento, del presupuesto o de las capacidades tecnológicas, la cultura organizacional es el bloqueador más citado. En grandes corporates y sectores regulados, donde siempre aparece alguien que frena. Los proyectos que no trabajan el buy-in interno desde el principio no llegan a producción. De nuevo, no es un problema de tecnología, es un problema de estrategia interna.

Las decisiones que no se pueden seguir aplazando

Hay un segundo nivel de problema: decisiones estructurales que las organizaciones postergan indefinidamente y que, cuando llega el momento de escalar, se convierten en el mayor obstáculo.

• Centralizar o descentralizar la capacidad de IA. Tener un equipo central que habilita al resto, o distribuir la capacidad directamente en cada equipo de producto. Ambos modelos funcionan en contextos distintos, pero no tener uno definido genera duplicidades, aprendizajes que no se comparten y presupuesto fragmentado.

• Construir o comprar. Desarrollar capacidades propias o integrar soluciones existentes. La respuesta depende del caso de uso y del nivel de diferenciación que aporta, pero requiere tomarse explícitamente, no derivarse por inercia hacia lo que parece más rápido en el momento.

• Plataforma horizontal o casos de uso verticales. Invertir en infraestructura compartida que habilite múltiples iniciativas o priorizar casos de uso concretos con impacto directo en negocio. Las organizaciones que no responden esta pregunta acaban haciendo las dos cosas a medias y ninguna bien.

• Más experimentación o consolidación de lo que ya funciona. Seguir generando pilotos o invertir en hacer escalar lo que ya tiene tracción. La mayoría de las organizaciones siguen en modo experimentación cuando ya tienen aprendizajes suficientes para dar el siguiente paso.

Ninguna de estas decisiones tiene una respuesta universal. Pero todas requieren tomarse y, cuanto más se aplazan, más caro resulta el caos que generan. 

El juicio no se automatiza

La IA no ha cambiado las reglas del product management, las ha amplificado. Los proyectos que fallan, fallan por las razones de siempre: no entender el problema, no conocer al usuario, no tener métricas, no conseguir el buy-in. La diferencia es que ahora se fracasa más rápido y más caro.

Lo que sí ha cambiado es dónde está el valor. Construir ya no es el reto, cualquier equipo puede tener un prototipo funcional en horas. Lo que no se ha democratizado es la capacidad de entender qué merece construirse, para quién y con qué criterio de éxito. El cuello de botella se ha desplazado de la ejecución al juicio.

Y ese juicio tiene implicaciones directas para los perfiles que lideran estas iniciativas. El PM que marca la diferencia en la era de la IA no será el que mejor sepa usar las herramientas, será el que mejor entienda problemas. Y eso, solo se entrena con escucha real del cliente, con la disciplina de no construir antes de haber entendido y con la honestidad de medir resultados aunque los números no sean los que esperabas.

Las organizaciones que cruzan el umbral de piloto a producción no lo hacen con tecnología más sofisticada, lo hacen con más disciplina en lo básico. Y eso, a diferencia de la tecnología, no se compra, se construye.