Por qué los pilotos de IA no llegan a producción
La estadística circula en todas las presentaciones: la enorme mayoría de los pilotos de IA nunca llega a producción. Se cita mucho y se explica poco. Lo que sigue es lo que efectivamente vemos cuando entramos a rescatar un proyecto detenido.
Causa 1: el piloto se eligió para impresionar, no para resolver
El patrón es reconocible. Alguien de la organización vuelve de una conferencia, se arma un comité de innovación y se elige el caso de uso más vistoso: un asistente conversacional para toda la empresa, un generador de contenido, algo que se pueda mostrar en una lámina.
El piloto funciona. La demo sale bien. Y después no pasa nada, porque nadie en la operación tenía ese problema. La pregunta que no se hizo al inicio es cuál proceso está costando plata o tiempo hoy, de forma medible.
Señal de alerta: si no puedes nombrar a la persona específica cuyo trabajo mejora con el piloto, no tienes un caso de uso.
Causa 2: nunca hubo línea base
Sin medir el estado previo, no hay forma de demostrar mejora. El proyecto llega a la instancia de decisión con testimonios en vez de números, y compite por presupuesto contra iniciativas que sí traen números.
Lo que se necesita medir antes de empezar es poco y es simple: volumen, tiempo de resolución, costo por unidad procesada y tasa de error. Cuatro datos. Casi nunca están.
Señal de alerta: si el equipo no puede responder «cuánto nos cuesta hoy» en una reunión, el piloto va a morir aunque funcione.
Causa 3: nadie era dueño del resultado
Los pilotos suelen vivir en innovación, TI o transformación digital. La operación es «cliente interno». Cuando llega el momento de pasar a producción, el área operativa tiene que absorber un sistema que no pidió, no diseñó y no entiende del todo.
El resultado no es un rechazo explícito. Es algo más lento: el sistema se usa menos cada semana, se reportan fricciones menores, y en algún momento alguien pregunta si todavía está activo.
Señal de alerta: si el área que va a operar el sistema no participó en definir el alcance, la adopción va a ser el problema, no la tecnología.
Causa 4: el piloto no fue diseñado para escalar
Un piloto que funciona con cien casos al mes puede colapsar con diez mil. No solo técnicamente: también en costo de inferencia, en carga de revisión humana y en manejo de excepciones.
El error clásico es diseñar el piloto optimizando velocidad de demo en vez de arquitectura. Después escalar significa reconstruir, y reconstruir requiere un segundo presupuesto que ya nadie quiere pedir.
Causa 5: el caso de uso se eligió antes de mirar los datos
Muchos casos de uso valiosos son inviables hoy porque los datos que necesitan están incompletos, dispersos o no existen. Descubrirlo en el mes tres del piloto es caro. Descubrirlo en la semana dos del diagnóstico es gratis.
Qué hace distinto a un piloto que sí llega a producción
- Nace de un dolor operativo medible, no de una oportunidad tecnológica.
- Tiene línea base documentada antes de la primera línea de código.
- El área operativa es dueña del alcance y del criterio de éxito.
- Tiene criterio de corte explícito. Se define de antemano qué resultado justifica seguir y cuál justifica detener.
- Se diseña con el volumen real en mente, incluyendo costo de operación proyectado.
- Incluye plan de transferencia al equipo interno desde el inicio, no como fase final opcional.
Si ya tienes un piloto detenido
No siempre hay que partir de cero. En bastantes casos el trabajo técnico es rescatable y lo que falta es lo otro: la línea base, el dueño operativo y el caso de negocio. Vale la pena hacer ese diagnóstico antes de descartar la inversión ya hecha.
Si quieres una segunda opinión sobre un proyecto que no despega, escríbenos. También puedes revisar cómo estructuramos un proyecto de IA de punta a punta.
Seguir leyendo
Para profundizar en las decisiones que evitan que un piloto se detenga: