El piloto de IA que funcionó no resuelve nada
Casi todos los pilotos de IA "funcionan". Casi ninguno llega a producción. El problema no es la tecnología, es que nadie hizo las preguntas que importan antes de construir.
En Jubili Labs hemos visto la misma escena repetirse en clientes de rubros completamente distintos: el piloto de IA sale bien, alguien lo aplaude en la reunión de directorio, y después nada. El proyecto no muere. Tampoco avanza. Se queda ahí, indefinido, mientras el entusiasmo inicial se enfría solo.
No es un caso aislado. Es un patrón tan repetido que tiene nombre entre quienes trabajan de cerca con estos procesos: el valle de la muerte de los pilotos de IA, aquella franja en la que un proyecto técnicamente válido muere por razones que no son técnicas. Y entenderlo empieza por una pregunta incómoda: ¿por qué algo que "funcionó" nunca llega a ninguna parte?
El piloto exitoso es la trampa, no el logro
Toda empresa que prueba IA tiene una historia parecida: armaron un piloto, funcionó mejor de lo esperado, llovieron elogios en la reunión de directorio, y seis meses después el proyecto sigue en el mismo estado. Ni cancelado ni en producción. Zombi.
El error empieza en la palabra "funcionó". Un piloto exitoso no significa que el problema esté resuelto. Significa que resolviste una versión miniaturizada y protegida del problema. Y esa versión casi nunca se parece a lo que tu negocio necesita operar todos los días.
Un piloto no valida un producto. Valida que la tecnología puede funcionar en condiciones ideales. Son preguntas distintas, y confundirlas es la causa número uno de proyectos de IA que nunca despegan.
Piloto y producción no son el mismo problema con más volumen
Se suele pensar la producción como "el piloto pero más grande". No es así. Son entornos con reglas distintas.
| Dimensión | En el piloto | En producción |
|---|---|---|
| Datos | Curados, limpios, seleccionados a mano | Crudos, incompletos, con excepciones que nadie documentó |
| Usuarios | Decenas, casi siempre internos y motivados | Miles, con niveles de paciencia y contexto muy distintos |
| Operación | Demo controlada, con el equipo presente | 24/7, sin nadie mirando cuando algo falla a las 3 a.m. |
| Tolerancia al error | Alta, se explica como "todavía estamos probando" | Baja, cada error tiene un costo real y un cliente real |
Un modelo que responde bien con datos curados por el propio equipo que lo construyó no dice nada sobre cómo se comporta con la data real de la operación, esa que tiene campos vacíos, formatos inconsistentes y casos límite que nadie anticipó porque nadie los buscó a propósito. Y un sistema que diez personas prueban con paciencia de piloto no es el mismo sistema que miles de usuarios van a exigir sin margen de error.
Por qué fracasan de verdad (spoiler: casi nunca es el modelo)
Cuando un proyecto de IA muere en el valle, casi siempre aparece la misma explicación: "la tecnología no estaba lista". Rara vez es la razón real. En la mayoría de los casos que vemos, el modelo funciona razonablemente bien. Lo que falta es todo lo demás:
No existen KPIs definidos antes de empezar. Si nadie decidió qué significa éxito en producción, nadie puede decidir cuándo dar el paso. El piloto termina, todos coinciden en que "salió bien" y ahí se acaba la conversación porque no hay un número que obligue al siguiente paso.
No existe una integración real con los sistemas de la empresa. Un piloto que vive en una pestaña aparte, alimentado a mano, no le está costando nada a nadie mantenerlo. Producción exige conectarlo con el CRM, el ERP, los sistemas legados que nadie quiere tocar. Ahí aparece el verdadero costo y ahí es donde muchos proyectos se frenan.
No se consignó un dueño del lado del negocio. Un piloto que impulsa el equipo de datos o de IA, sin que un área de negocio lo reclame como propio, no tiene quién pelee por el presupuesto de producción. Cuando toca priorizar, gana el proyecto que tiene un gerente de operaciones defendiéndolo, no el que tiene un informe técnico bien hecho.
El piloto responde una pregunta técnica: ¿se puede? La producción responde una pregunta de negocio: ¿vale la pena sostenerlo cuando nadie está mirando?
Esto no es un argumento contra los pilotos. Son necesarios y baratos comparados con construir a ciegas. El problema es tratar un piloto exitoso como el final del camino en vez de como el primer filtro de varios.
El filtro de cuatro preguntas antes de construir
Antes de llevar cualquier piloto a producción, en Jubili Labs pasamos el proyecto por cuatro preguntas. Si alguna no tiene respuesta clara, no se construye todavía.
- a)¿Qué métrica de negocio se mueve si esto funciona y quién la mide hoy sin IA?
- b)¿Con qué sistemas reales tiene que conectarse y quién en la empresa es dueño de esos sistemas?
- c)¿Quién en el negocio, no en tecnología, pierde algo si este proyecto se cancela?
- d)¿Qué pasa cuando falla con un caso que nadie probó? ¿Hay un plan o solo la esperanza de que no pase?
Si las cuatro tienen dueño y respuesta, el piloto tiene sentido de convertirse en inversión real. Si dos o tres quedan en blanco, lo que tienes no es un proyecto de IA en pausa. Es un experimento bien ejecutado que nunca estuvo diseñado para llegar a ningún lado.
La pregunta que reemplaza a "¿funciona?"
"¿Funciona?" es la pregunta que se responde en la demo, con el equipo que lo construyó presente para explicar por qué ese resultado raro no cuenta. La pregunta que de verdad importa es otra: ¿funciona con miles de casos reales, con datos sucios, sin que nadie del equipo original esté mirando por encima del hombro?
Esa es la que separa un piloto de un producto. La mayoría de los proyectos de IA no mueren porque la tecnología falle. Mueren porque nadie se hizo esa pregunta antes de empezar a construir.