El dato más citado sobre IA empresarial viene del informe del MIT “The GenAI Divide: State of AI in Business 2025”: 95% de los pilotos de IA no generan impacto medible en el estado de resultados. El número se presta a una lectura fácil, que la tecnología no sirve, y esa lectura no aguanta el primer minuto de conversación con alguien que haya intentado poner un sistema a operar de verdad.
Casi ningún piloto muere por el modelo. Muere porque nunca se diseñó para operar.
Qué es, exactamente, un piloto
Un piloto es una demostración en condiciones controladas: un conjunto de datos limpio, un usuario que ya sabe qué preguntar, un ambiente sin permisos que negociar y ninguna consecuencia si la respuesta sale mal. Cumple su función, que es probar que algo es posible. El problema empieza cuando esa prueba se confunde con un compromiso de producción.
Un sistema en producción vive en el otro extremo. Los datos llegan sucios, incompletos y a veces duplicados. Los usuarios preguntan cosas que nadie anticipó. Cada acción toca un sistema que ya tiene dueño, permisos y auditoría. Y cuando la respuesta sale mal, alguien dentro de la empresa tiene que responder por ella.
Lo que le falta a un piloto para cruzar
La distancia entre los dos no es de modelo. Es de todo lo que rodea al modelo:
- Una línea base medida. Cuánto tarda hoy el proceso, cuánto cuesta y dónde falla, antes de escribir una línea de código. Sin ese número no hay manera de saber si el sistema mejoró algo.
- Permisos por rol. Quién puede consultar qué, y qué ocurre cuando alguien pregunta por información que no le corresponde.
- Trazabilidad: bitácora de cada acción, con qué consultó el sistema, qué respondió y sobre qué fuente.
- Evaluación que corre en cada cambio. Si una versión se degrada, no sale a producción.
- Un punto de revisión humana donde el riesgo lo exige, con ruta de escalación definida.
- Un dueño operativo dentro de la empresa: alguien cuyo trabajo incluye que ese sistema siga funcionando el mes entrante.
Ninguna de estas piezas luce en una demostración. Todas son la diferencia entre un sistema que opera y uno que termina en una carpeta de capturas de pantalla.
Señales de que un piloto no va a cruzar
- No hay número de partida. Si nadie midió el proceso antes, cualquier resultado se puede discutir y ninguno se puede defender frente a un CFO.
- El caso de uso se eligió por entusiasmo. Se escogió el flujo más vistoso y no el que tenía datos disponibles, dueño claro y un costo real que reducir.
- La integración se dejó para el final. Conectar con el ERP, el CRM o el repositorio de documentos es el trabajo, no el último paso.
- Nadie definió qué pasa cuando falla. Un sistema sin ruta de escalación es una demostración con más usuarios.
Diseñar para producción desde el día uno
La alternativa no es un piloto mejor. Es invertir el orden: medir la línea base antes de construir, elegir el caso por impacto y viabilidad y no por atractivo, y montar los permisos, la trazabilidad y la suite de evaluación como parte del sistema y no como un anexo posterior.
Eso cuesta más al principio y menos al final. El primer flujo carga con integraciones, permisos y gobernanza que el segundo hereda completos, así que cada caso nuevo llega más rápido y más barato que el anterior.
Casi ningún piloto muere por la tecnología; muere porque nunca se diseñó para operar.
Si estás por decidir el primer caso de uso y quieres el criterio antes que la herramienta, el Diagnóstico de Oportunidad existe para eso: procesos, datos, riesgo y ROI esperado antes de construir nada.