Según el estudio que leas, entre el 60 % y el 95 % de los pilotos de IA nunca llegan a producción. RAND lo sitúa por encima del 80 %, el doble que los proyectos de IT sin IA. Y la tendencia empeora: la encuesta empresarial 2025 de S&P Global detectó que el porcentaje de empresas que abandonan la mayoría de sus iniciativas de IA saltó del 17 % al 42 % en un solo año, y que la organización promedio descarta casi la mitad de sus pruebas de concepto antes de producción. Bajo los números hay un costo más silencioso: al tercer piloto fallido, los ejecutivos dejan de aparecer por las revisiones y la organización decide, sin decirlo, que «la IA aquí no funciona».
Y esta es la parte que importa: el modelo casi nunca es la causa del fracaso. Un consultor de NTT DATA lo dijo sin anestesia: «el modelo rara vez es el problema principal». Los fracasos son organizativos y operativos, y son previsibles. O sea, evitables.
De qué mueren en realidad
Las causas que se repiten, y ninguna tiene que ver con el LLM:
- Ningún objetivo medible desde el día uno. La causa raíz más frecuente. «Exploremos la IA» sin un número al lado produce una demo que nadie sabe si es buena, así que nunca sale.
- Datos que no están listos. Una encuesta de Gartner del tercer trimestre de 2024 encontró que el 63 % de las organizaciones no tiene —o no sabe si tiene— datos listos para IA. La demo corre sobre datos curados; producción no goza de ese lujo.
- Una arquitectura que nunca se pensó para durar más que la presentación. Las PoC se acotan para lucir capacidad, no para aguantar autenticación real, integraciones, cumplimiento y la cola larga y rara. La demo pasa un sandbox; no pasa producción.
- Nunca fue operable. Si durante el piloto el equipo prepara prompts a mano y cura datos a mano, el sistema no es operable: es una persona haciendo el trabajo con una IA en el loop. Eso no sobrevive al handover.
Cada una de estas es una decisión tomada —u omitida— en las primeras semanas, cuando cambiarla todavía sale barato. Se vuelven letales 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.
- El eval antes que el prompt. Cada build arranca con un eval y umbrales explícitos: justo el objetivo medible que les falta a los proyectos que fracasan. Si no podemos escribir un eval defendible en las dos primeras semanas, matamos el proyecto y devolvemos el fee de discovery. Sin eval en verde no hay merge. Esa regla, ella sola, elimina la muerte por «nadie sabe decir si esto es bueno».
- Un usuario real dentro del sistema en la semana 2. Una PoC sin camino a producción esconde las decisiones difíciles. Metemos a 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 descubrirlas en producción.
- Handover operable, no un repo. Entregamos el runbook que tu guardia abre a las 3 a.m., los dashboards y las claves, todo a tu nombre. La prueba no es «¿queda bien en la demo?», sino «¿puede tu equipo operarlo sin nosotros?». Un sistema que no se puede operar es un piloto con fecha de caducidad.
El encuadre honesto
Ese 80 % no fracasa porque la IA sea difícil de construir. Fracasa porque casi todos los equipos construyen la demo y se saltan el sistema operativo que la rodea. El modelo es el 10 %. El eval, la disciplina de datos, el runbook, los checkpoints humanos, la observabilidad —el aburridísimo 90 %— es lo que decide si tu proyecto cae en el 20 % que sobrevive.
Si ya te tocó un piloto encallado, conoces la sensación y desconfías con razón del próximo pitch. Haces bien. Pídele a la próxima firma que contrates el eval, el usuario de la semana 2 y el runbook. Si no puede 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.