El informe de 2025 de MIT Project NANDA, «The GenAI Divide: State of AI in Business», encontró que alrededor del 95% de los pilotos corporativos con IA generativa no produjeron un efecto medible en la cuenta de resultados. La cifra se cita como prueba de que la tecnología no funciona. No es eso lo que mide.
Mide un fallo de entrega. Los pilotos hicieron en general aquello para lo que se construyeron; se construyeron para demostrar una capacidad, no para cambiar un proceso, y una capacidad no aparece en la cuenta de resultados. Ese 5% que sí tuvo efecto son, en su inmensa mayoría, proyectos cosidos a un flujo de trabajo real y con un número atado a ellos desde el principio.
Si la métrica se elige después de que el piloto haya corrido, el piloto no puede fracasar, lo que significa que tampoco puede triunfar. Todos declaran una victoria parcial, el proyecto termina en silencio y no se despliega nada.
El remedio es aburrido y eficaz: nombre un número, mídalo antes de empezar y acuerde de antemano qué valor cuenta como éxito. «Tiempo medio de gestión en esta categoría de tickets, hoy 11 minutos, objetivo por debajo de 7» es una métrica. «Mejorar la experiencia de cliente» es una forma de eludirla.
Acordamos la métrica de éxito en la auditoría, antes de diseñar el piloto. Si no se encuentra un número que ambas partes acepten, eso ya es una conclusión, y normalmente significa que el proceso no sirve como primero.
Los pilotos se demuestran sobre el 80% limpio. Producción es sobre todo el 20% restante: entradas deformes, un proveedor que no está en el maestro, un cliente que además es partner, un caso que las reglas no previeron.
Un piloto sin ruta de excepción luce impresionante y no se puede desplegar, porque el primer día en producción aparece un caso que procesará mal en silencio. Diseñar las rutas de fallo — reintento, entrega a una persona, parada del flujo — no es el barniz del final. Es la diferencia entre una demo y un sistema.
Una automatización no es un entregable que se queda hecho. Los proveedores cambian formatos, un sistema publica una versión nueva, los volúmenes se desplazan, la política cambia. Sin un responsable con nombre y un panel que muestre la deriva, el flujo se degrada en silencio y alguien acaba apagándolo.
No hace falta un equipo. Hacen falta una persona que lo tenga en sus funciones y un tipo de monitorización que haga visible la degradación antes de que la encuentre un cliente.
El error de secuencia más caro es demostrar primero el modelo y conectar los sistemas después. El riesgo de plazo vive precisamente en la integración: accesos, entornos de pruebas, límites de peticiones, un sistema sin API, un proveedor que tarda tres semanas en contestar.
El orden inverso — asegurarse primero de que los datos pueden moverse y demostrar después el modelo con datos reales en su sitio — no cuesta nada adicional y elimina el modo de fallo en el que un piloto exitoso no se puede desplegar por razones descubiertas al tercer mes.
Un piloto que funciona sobre hojas exportadas no está probado contra lo que con más probabilidad lo matará.
Un proceso, entero, con datos reales, en sistemas reales, con una métrica nombrada y medida antes y después, con ruta de excepción en cada paso y con responsable desde el primer día. Más modesto que un piloto habitual en ambición y mucho más amplio en lo que demuestra.
En eso consiste todo el argumento a favor del alcance estrecho: algo estrecho en producción vale más que algo amplio en una presentación, y además es la única versión que produce la evidencia necesaria para financiar la siguiente.
Auditoría, piloto con métricas acordadas de antemano y despliegue por fases.
Cómo elegir el número con el que se juzgará el piloto.
La mayoría de los pilotos fallidos fallan en una elección hecha antes de construir.
Usamos cookies solo para analítica: para ver desde qué páginas llegan las consultas. Nada más, y nada antes de que aceptes. Política de cookies