En los últimos meses se repite una escena que ya no sorprende a nadie que trabaje cerca de proyectos de IA en empresas: un piloto arranca, funciona mejor de lo esperado, genera entusiasmo en el equipo que lo impulsó, y unos meses después simplemente deja de estar. No lo cancelaron en una reunión ni hubo un correo anunciando el cierre. Alguien un día se da cuenta de que nadie lo usa, de que el dashboard no se revisa hace semanas, o de que el proceso volvió silenciosamente a hacerse como antes.
Varios reportes recientes sobre adopción de IA en el mundo corporativo describen este mismo patrón: buena parte de los pilotos que sí mostraron resultados terminan cayendo entre el tercer y el noveno mes de vida. Lo llamativo no es que fracasen los pilotos malos, eso es esperable y hasta sano. Lo llamativo es que caigan los que funcionaron.
La tesis es simple y, a esta altura, bastante incómoda: el problema no es el modelo. El problema es que nadie definió, desde el día uno, quién es el dueño operacional de esa solución ni qué métrica de negocio iba a justificar que siguiera viva.
Cuando un piloto de IA se arma, casi siempre lo hace un equipo motivado, con buen criterio técnico y ganas reales de resolver algo. Se elige una herramienta, se prueba sobre un caso acotado, se mide el resultado inicial y se presenta con orgullo. Todo eso está bien. El problema aparece después, cuando ese piloto necesita dejar de ser un experimento y convertirse en parte de la operación normal de la empresa. Ahí es donde casi nunca hay claridad sobre quién lo sostiene cuando el entusiasmo inicial se apaga, quién responde si algo falla, quién decide si vale la pena seguir invirtiendo en mejorarlo, y sobre todo, qué número concreto del negocio se supone que ese piloto debía mover.
Sin ownership operacional, cualquier iniciativa de IA queda flotando entre áreas. El equipo que la construyó no tiene mandato para mantenerla en producción indefinidamente, porque ese no es su trabajo. El área de negocio que se benefició del piloto no se siente dueña de la herramienta, porque nunca participó en decidirla ni en definir cómo medirla. Y sin métricas acordadas desde el inicio, no hay forma de defender la continuidad del proyecto cuando llega el momento en que alguien pregunta si vale la pena seguir pagando por eso. La conversación se vuelve subjetiva, basada en percepciones ("parecía que ayudaba") en lugar de datos, y en esa conversación, casi siempre pierde la herramienta nueva frente a la forma antigua de hacer las cosas.
Esto tiene una implicancia directa para quienes lideran estas iniciativas dentro de una empresa: la pregunta correcta no es solo qué caso de uso probar, sino quién va a ser responsable de esa solución dentro de seis meses y con qué número se va a evaluar si siguió generando valor. Si esas dos preguntas no tienen respuesta antes de arrancar el piloto, ya se está construyendo algo con fecha de vencimiento, aunque el resultado inicial sea excelente.
Definir ownership no significa burocratizar cada experimento con IA ni exigir un comité antes de probar algo. Significa algo más simple: que alguien en el negocio, no solo en tecnología, se haga cargo de sostener la solución cuando deje de ser novedad. Y que desde el primer día exista una métrica de negocio, no solo una métrica de uso, que permita decidir con criterio si conviene seguir, ajustar o cerrar.
El verdadero riesgo de estos meses no es que las empresas prueben demasiadas herramientas de IA. Es que sigan tratando cada piloto exitoso como un logro cerrado, cuando en realidad es apenas el punto de partida de una decisión operacional que todavía nadie tomó.
