De piloto a producción, por qué se estancan los proyectos de IA
Las cinco razones por las que una prueba exitosa nunca llega a la operación diaria, y qué hay que definir desde el inicio para que el salto ocurra.
El patrón se repite en organizaciones de todos los tamaños. La prueba funciona, el equipo queda conforme, la presentación sale bien. Seis meses después, nadie lo usa y nadie sabe bien por qué se detuvo.
No es un problema de tecnología. Es que el piloto y la producción son dos cosas distintas, y se diseñan distinto.
Razón 1: el piloto se diseñó para impresionar
Muchas pruebas se construyen para demostrar que la tecnología funciona, con datos seleccionados y casos favorables. Eso responde una pregunta que casi nunca es la limitante: ¿esto es posible?
La pregunta que importa es otra: ¿esto encaja en cómo trabajamos? Un piloto bien diseñado usa casos reales, incluidos los difíciles, y mide tanto los aciertos como los errores.
Razón 2: nadie definió qué significaba avanzar
Si el criterio de éxito no se escribió antes de empezar, al terminar la discusión es interminable. Algunos ven un resultado prometedor, otros ven un porcentaje de error inaceptable, y sin un umbral acordado previamente la decisión se posterga.
El criterio tiene que ser un número y una condición: por ejemplo, "si el 70% de las salidas son usables sin corrección y el tiempo por caso baja al menos 40%, se escala".
Razón 3: la integración nunca se evaluó
El piloto corre en una herramienta aparte, con archivos cargados a mano. Funciona. Pero en producción hay que conectar con el ERP, respetar permisos, sincronizar datos y manejar errores.
Ese trabajo suele ser más grande que la prueba, y aparece recién cuando ya se consumió el presupuesto y el entusiasmo. La forma de evitarlo es simple: durante el piloto, alguien del área de sistemas tiene que responder por escrito si la integración es viable y qué implica.
Razón 4: no hay dueño en la operación
Un proyecto impulsado por innovación o por tecnología, sin un dueño en el área donde el proceso vive, se queda sin sostén cuando el equipo del piloto pasa a otra cosa.
El dueño tiene que ser la persona a quien le mejora el indicador. Si el proyecto no mejora el indicador de nadie, no hay dueño posible, y eso es información valiosa que conviene descubrir antes y no después.
Razón 5: las excepciones hunden el caso
Funciona en el 85% de los casos. El 15% restante son situaciones raras que el equipo resuelve con criterio. Si no se define qué pasa con esos casos, el equipo termina revisando el 100% por las dudas, y el ahorro desaparece.
Definir el circuito de excepciones es parte del diseño, no un detalle posterior: cómo se detectan, a quién van, con qué plazo se resuelven.
Lo que conviene definir antes de empezar
Cuatro respuestas por escrito, en media página:
- Qué número tiene que mover y cuál es su valor actual.
- Quién lo va a usar todos los días, con nombre.
- Con qué sistemas debería integrarse en producción y si eso es viable.
- Quién decide el paso a producción y con qué criterio.
Un piloto sin esas cuatro respuestas no es un piloto: es una demostración.
Cómo se ve un piloto bien hecho
- Dura entre cuatro y ocho semanas.
- Usa una muestra representativa de casos reales, incluidos los complicados.
- Lo opera el equipo que después lo va a usar, no solo el equipo técnico.
- Mide contra una línea de base conocida.
- Termina con una decisión escrita: escalar, ajustar o descartar.
Descartar también es un buen resultado. Un piloto que cuesta cinco semanas y evita una implementación de seis meses que no servía hizo exactamente lo que tenía que hacer.
El salto a producción
Cuando la decisión es avanzar, el trabajo que sigue es menos glamoroso: permisos, monitoreo, manejo de errores, capacitación, soporte. Suele ser el doble de esfuerzo que el piloto, y es lo que separa una prueba exitosa de un proceso que funciona todos los días a las nueve de la mañana.
Preguntas frecuentes
¿Por qué una prueba de concepto exitosa no se convierte en producción?
Porque la prueba se diseña para demostrar que la tecnología funciona, no para encajar en la operación. Cuando llega el momento de escalar aparecen la integración, los permisos, las excepciones y la gestión del cambio, que no se habían considerado.
¿Cuánto tiempo debería durar un piloto?
Entre cuatro y ocho semanas. Más que eso suele indicar que el alcance no estaba claro, y el proyecto entra en una zona donde se sigue probando sin decidir nada.
¿Qué hay que definir antes de empezar el piloto?
El criterio de éxito en un número, quién lo usará todos los días, con qué sistemas debería integrarse en producción y quién aprueba el paso siguiente. Sin esas cuatro respuestas, el piloto no tiene salida.