Según el estudio que leas, entre el 60% y el 95% de los pilotos de IA nunca llegan a producción. RAND lo ubica en más del 80% — el doble que los proyectos de IT que no involucran IA. Y la tendencia empeora: la encuesta empresarial 2025 de S&P Global encontró que la proporción de empresas que abandonan la mayoría de sus iniciativas de IA saltó del 17% al 42% en un solo año, y la organización promedio descarta casi la mitad de sus pruebas de concepto antes de producción. Debajo de los números hay un costo más silencioso: para el tercer piloto fallido, los ejecutivos dejan de asistir a las revisiones y la organización decide, implícitamente, que "la IA no funciona aquí".
Esta es la parte que importa: el modelo casi nunca es la razón del fracaso. Un consultor de NTT DATA lo dijo sin rodeos — "el modelo rara vez es el problema principal". Los fracasos son organizacionales y operativos, y son predecibles. Lo que significa que son evitables.
Por qué mueren de verdad
Las causas recurrentes, ninguna sobre el LLM:
- Ningún objetivo medible desde el día uno. La causa raíz más común. "Exploremos la IA" sin un número asociado produce una demo que nadie puede decidir si es buena, así que nunca se lanza.
- Datos que no están listos. Una encuesta de Gartner del tercer trimestre de 2024 encontró que el 63% de las organizaciones no tienen —o no están seguras de tener— datos listos para IA. Una demo corre sobre datos curados; producción no recibe ese lujo.
- Una arquitectura que nunca se construyó para sobrevivir más allá de la presentación. Los PoC se acotan para mostrar capacidad, no para manejar la autenticación real, la integración, el cumplimiento y la larga y rara cola. La demo pasa un sandbox; no puede pasar producción.
- Nunca fue operacional. Si el equipo prepara prompts a mano y cura datos durante el piloto, el sistema no es operable — es una persona haciendo el trabajo con una IA en el loop. Eso no sobrevive al traspaso.
Cada una de estas es una decisión tomada (u omitida) en las primeras semanas, cuando todavía es barato cambiar. Se vuelven fatales en el mes seis, cuando ya no lo es.
Las tres reglas que mantienen vivos los nuestros
No inventamos los modos de fallo — construimos la práctica alrededor de evitarlos.
- La evaluación antes del prompt. Cada build empieza con un conjunto de evaluación y umbrales explícitos — el objetivo medible que les falta a los fracasos. Si no podemos escribir una evaluación defendible en las primeras dos semanas, matamos el proyecto y devolvemos la tarifa de discovery. Sin evaluación en verde, no hay merge. Esa sola regla elimina la muerte de "nadie puede decidir si es bueno".
- Un usuario real en el sistema para la semana 2. Un PoC sin camino a producción esconde las decisiones difíciles. Ponemos un usuario real temprano, para que las decisiones de arquitectura se tomen contra una transcripción real — mientras todavía son baratas — en lugar de descubrirse en producción.
- Traspaso operable, no un repo. Entregamos el runbook que tu guardia abre a las 3 a.m., los dashboards y las llaves — a tu nombre. La prueba no es "¿demuestra bien?", es "¿puede tu equipo operarlo sin nosotros?". Un sistema que no se puede operar es un piloto con fecha de lanzamiento puesta.
El encuadre honesto
La razón por la que el 80% fracasa no es que la IA sea difícil de construir — es que la mayoría de los equipos construye la demo y se salta el sistema operativo a su alrededor. El modelo es el 10%. La evaluación, la disciplina de datos, el runbook, los checkpoints humanos, la observabilidad — el aburrido 90% — es lo que decide si tu proyecto está en el 20% que vive.
Si ya tuviste un piloto estancado, conoces esta sensación y desconfías con razón del próximo pitch. Bien. Pídele a la próxima firma que contrates la evaluación, el usuario de la semana 2 y el runbook. Si no pueden producir los tres, estás mirando el piloto número cuatro.
Esa es la conversación que queremos tener. Tráenos el problema, el responsable, el presupuesto y la fecha.