La mayoría de los pilotos de inteligencia artificial no fracasan: se quedan atrapados. Funcionan, impresionan en la demo, reciben felicitaciones y después no pasan a producción nunca. Se quedan en un limbo donde nadie los cancela formalmente —cancelarlos sería admitir un error— y nadie los despliega —desplegarlos exigiría resolver problemas que el piloto evitó por diseño.
Ese limbo tiene un coste que no aparece en ningún informe: presupuesto consumido, credibilidad interna gastada y, sobre todo, la conclusión errónea de que «la IA no funciona en nuestro sector».
Las cifras varían mucho según quién mida y cómo, así que conviene mirar varias fuentes en lugar de fiarse de un titular.
El CEO Study de IBM de 2025, con 2.000 directores generales de 33 países, encontró que solo el 25% de las iniciativas de IA había producido el retorno esperado y solo el 16% se había escalado a nivel de organización. Es la fuente más sólida metodológicamente de las tres.
S&P Global Market Intelligence publicó en marzo de 2025 que el 42% de las empresas había abandonado la mayoría de sus iniciativas de IA, frente al 17% del año anterior, y que de media se descartaba el 46% de las pruebas de concepto antes de llegar a producción.
Y está el dato que más circuló: el informe MIT Project NANDA de 2025 según el cual alrededor del 95% de las organizaciones no obtuvo retorno medible de la IA generativa. Este último conviene citarlo con honestidad: es un informe preliminar, no revisado por pares, basado en 52 entrevistas y 153 encuestas, y ha recibido críticas metodológicas serias por su ventana de medición y su muestra. La dirección coincide con el resto de fuentes; la magnitud exacta, no está establecida.
Lo relevante no es cuál de las tres cifras es la buena. Es que las tres apuntan al mismo punto de ruptura: no está en construir el piloto, está en el trayecto entre el piloto y la producción.
Causa | Qué evitó el piloto | Qué exige producción |
Datos | Un conjunto limpio y seleccionado | Datos reales, incompletos y contradictorios |
Permisos | Un usuario con acceso total | Roles distintos, visibilidad limitada, trazabilidad |
Excepciones | El camino feliz | El 15-30% de casos raros que no se diseñaron |
Integración | Copiar y pegar entre pantallas | Conexión con ERP, CRM e identidad |
Propiedad | Un equipo de innovación | Un responsable de negocio y un equipo de soporte |
Coste | Volumen de prueba | Coste unitario a escala real, con picos |
Los datos. El piloto se ejecuta sobre un extracto preparado. En producción los datos llegan incompletos, duplicados y en desacuerdo entre sistemas. El modelo no falla de forma visible: elige una de las versiones contradictorias sin avisar.
Los permisos. Durante la prueba, el sistema ve todo. En producción, un comercial no puede ver los márgenes, un técnico no puede ver los datos de salud y un externo no puede ver nada que no sea suyo. Si el modelo de permisos no estaba en el diseño, no es un ajuste: es una reconstrucción.
Las excepciones. El piloto demuestra el camino feliz porque es lo que se puede demostrar en veinte minutos. La operación real es, en buena medida, la gestión de lo que no encaja. Ese porcentaje —entre el 15% y el 30% del volumen en la mayoría de procesos que hemos analizado— es donde la automatización se rompe y donde hay que decidir qué se escala a un humano y cómo.
La integración. Una demo puede funcionar con el usuario copiando información entre ventanas. Un sistema en producción tiene que leer el contexto operativo y ejecutar acciones dentro de los sistemas existentes, respetando permisos y dejando registro.
La propiedad. Los pilotos suelen nacer en innovación o en tecnología. Producción requiere un dueño de negocio: alguien cuyo objetivo anual dependa de que ese proceso funcione mejor. Sin ese dueño, no hay quien defienda el presupuesto de la fase siguiente ni quien decida sobre las excepciones.
El coste unitario. En el piloto el coste es irrelevante porque el volumen es pequeño. A escala real, con picos y reintentos, el coste por caso puede convertir en inviable un proyecto que era brillante en la demo. Este cálculo debería hacerse antes, no después.
Hemos desarrollado el recorrido completo entre ambas fases en de la PoC de IA a producción
La solución no es hacer pilotos más grandes. Es hacerlos con las restricciones de producción desde el primer día, aunque en escala reducida.
Define la métrica de negocio antes de empezar. No «número de consultas» ni «usuarios activos»: tiempo de ciclo, tasa de error, coste por caso, conversión o margen. Y define el umbral que decide si continúa o para. Un piloto sin criterio de parada no es un experimento, es un compromiso encubierto.
Usa datos reales desde el principio, aunque sean pocos. Un piloto con cien casos reales enseña más que uno con diez mil casos limpios, porque los cien reales incluyen los problemas que vas a tener.
Incluye una excepción real en el alcance. Elige el caso raro más frecuente y resuélvelo dentro del piloto. Si el diseño no aguanta una excepción, no aguantará treinta.
Nombra al dueño de negocio antes que al equipo técnico. Y que sea alguien con responsabilidad sobre el resultado del proceso, no sobre la tecnología.
Calcula el coste unitario a volumen real. Extrapola desde el primer día. Si a escala el número no sale, es mejor saberlo en la semana dos.
Ponle fecha de caducidad. Cuatro semanas es un plazo suficiente para saber si algo funciona y demasiado corto para que se convierta en un proyecto zombi. Es exactamente la razón por la que nuestras pruebas de concepto tienen ese formato: un PoC funcional en un mes, con guardarraíles, trazabilidad y supervisión humana. No porque sea comercialmente atractivo, sino porque un plazo corto obliga a acotar el alcance a algo que se puede validar de verdad.
Si el piloto ya existe y no avanza, hay tres salidas honestas y ninguna de ellas es esperar.
Diagnosticar y decidir. Un análisis de modelo, datos, integración y coste que responda a tres preguntas: qué se puede salvar, qué hay que reescribir y qué hay que parar. Es el objetivo de una auditoría de proyecto de IA , y suele resolverse en semanas.
Reducir el alcance hasta algo que sí pueda desplegarse. A menudo el 20% del alcance original produce el 80% del valor y es desplegable en un mes. La resistencia a hacerlo es política, no técnica: reducir el alcance parece admitir un fracaso parcial.
Pararlo y documentar por qué. Es la opción más infravalorada. Un piloto parado con un documento claro de lo aprendido es un activo. Un piloto en el limbo es un pasivo que consume atención cada trimestre.
Cuando se analizan los pilotos atascados, casi ninguno murió por el modelo. Murieron por los datos, por los permisos, por las excepciones, por la integración o por la ausencia de un responsable. Es decir: murieron por las mismas razones por las que fracasan los proyectos de software desde hace treinta años.
Eso es, en el fondo, una buena noticia. Significa que el problema no es un misterio tecnológico, sino un problema de ingeniería y de gobierno del proyecto. Y esos sí sabemos cómo resolverlos.
La pregunta que conviene llevar al próximo comité no es si la IA funciona. Es qué habría que arreglar en nuestros datos, nuestros permisos y nuestra integración para que cualquier automatización, con o sin IA, pudiera llegar a producción.
Por seis causas recurrentes: datos reales incompletos y contradictorios, un modelo de permisos que el piloto no contempló, excepciones no diseñadas, falta de integración con los sistemas existentes, ausencia de un responsable de negocio y un coste unitario que no se sostiene a escala real.
Según el CEO Study de IBM de 2025, solo el 25% de las iniciativas de IA ha dado el retorno esperado y solo el 16% se ha escalado. S&P Global situó en marzo de 2025 en un 42% las empresas que habían abandonado la mayoría de sus iniciativas. Las cifras varían mucho según la metodología del estudio.
Alrededor de cuatro semanas. Es tiempo suficiente para validar si el caso funciona con datos reales y demasiado corto para que el piloto se convierta en un proyecto indefinido sin criterio de parada. Un plazo corto obliga a acotar el alcance a algo verificable.
Métricas de negocio definidas antes de empezar: tiempo de ciclo, tasa de error, coste por caso, conversión o margen, con un umbral explícito que determine si el proyecto continúa o se detiene. El número de consultas o de usuarios activos no prueba impacto empresarial.
Hay tres salidas: diagnosticarlo mediante una auditoría que determine qué salvar, qué reescribir y qué parar; reducir el alcance a la parte que sí puede desplegarse en semanas; o pararlo documentando lo aprendido. Mantenerlo en el limbo es la única opción que solo genera coste.
Esa cifra procede de un informe preliminar del MIT Project NANDA de 2025, no revisado por pares y basado en una muestra reducida, que ha recibido críticas metodológicas. Otras fuentes más sólidas, como IBM, apuntan en la misma dirección con magnitudes distintas: el problema del escalado es real, la cifra exacta no está establecida.
¿Tu piloto de IA lleva meses sin moverse? Diagnosticamos modelo, datos, integración y coste, y te decimos qué salvar, qué reescribir y qué parar. Si el caso es viable, lo llevamos a un PoC funcional en cuatro semanas, con guardarraíles y trazabilidad. Hablemos de tu caso → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
