Cuando un proyecto de IA muere, casi nunca es por la IA

Cuando un proyecto de IA muere, la autopsia casi siempre culpa a la tecnología: el modelo, el proveedor, la IA que no estaba lista. Es una conclusión cómoda, porque deja la culpa fuera de la empresa. Y casi siempre es falsa.

Si ordenas las causas según su origen, aparecen tres grupos. Una es de problemas que la IA trajo de verdad. Otra es de problemas de integración que la RPA nos enseñó hace quince años. La tercera, la más grande, es de fallas de gestión que hunden proyectos de cambio desde mucho antes de que alguien dijera "agente".

El grupo de la IA es la más chica. Eso cambia la conversación: deja de tratarse de elegir un modelo mejor y pasa a tratarse de implementar mejor.

Lo que la IA sí trajo de nuevo

Son dos cosas: la confianza y la responsabilidad.

Un modelo público, solo, no alcanza la precisión que exige el trabajo transaccional, y no puede demostrar por dónde viajan tus datos ni cómo se protegen. Entonces cumplimiento, legal y seguridad lo frenan antes de producción, y hacen bien.

Ganarse esa confianza no pasa por convencer a nadie de que el modelo es inteligente. Pasa por prepararlo para tu contexto, con ejemplos históricos, reglas del negocio y pruebas antes de salir, y por operarlo después con registro y controles.

La otra es más silenciosa: después de salir a producción, nadie es dueño del resultado. El proveedor culpa al integrador, el integrador culpa a los datos, el rendimiento se va degradando y el gasto en el modelo sube sin que nadie lo mire. Los agentes lo empeoran, porque siguen funcionando y cambiando después del lanzamiento, así que la responsabilidad tiene que durar lo que dura la operación. Estas dos son el impuesto propio de la IA.

Lo que la RPA ya nos había enseñado

La integración y el volumen real. La IA cambió la tecnología, no las condiciones de terreno de una implementación.

La integración es la misma pared contra la que chocó la RPA. El ERP, el sistema de bodega, el de transporte y los portales antiguos tienen que leerse y escribirse en tiempo real y sin fallar, y la mayoría de las empresas nunca cruza esa línea. Es ingeniería, y ningún modelo la resuelve por ti.

El volumen real es su gemelo. El sistema funciona precioso con datos de prueba y se cae el día que llega el volumen de verdad, con escaneos malos, órdenes de compra a medias y cada proveedor con su formato un poco distinto. Por eso importan las muestras reales de producción, las pruebas ordenadas y los criterios de éxito claros, mucho antes de salir. Cambiar la automatización por un modelo no cambia la naturaleza del desorden. Solo sube lo que está en juego.

Lo que no tiene nada que ver con la IA

Ninguna de estas causas es propia de la IA, y son las más comunes, porque deciden todo antes de que la tecnología pueda probarse.

Nadie en la gerencia es dueño. Sin un ejecutivo que decida, las disyuntivas quedan abiertas, las decisiones se demoran y un equipo sin autoridad termina conduciendo un trabajo estratégico. Detrás de cada implementación rápida hay un ejecutivo que sigue presente después de aprobar: resuelve, saca obstáculos y empuja a simplificar el proceso antes de automatizarlo. El patrocinio hace partir un proyecto. La presencia del ejecutivo lo hace llegar.

Los requisitos se mueven. No hay un acuerdo cerrado ni datos de muestra reales. El negocio y los expertos no están alineados, los indicadores y las reglas se definen tarde y el alcance se desliza sin que nadie lo anuncie. La IA ejecuta con fidelidad el proceso que le das. Si el proceso está incompleto o mal entendido, la tecnología solo multiplica esos supuestos.

Los accesos tardan. Credenciales, ambientes y equipos de prueba se demoran semanas en vez de días, y el proyecto parte antes de poder correr. Los permisos se vuelven el camino crítico escondido, y la IA carga con atrasos que son de una organización que no estaba lista.

Se persigue el cien por ciento. En casi cualquier operación, unos pocos proveedores o tipos de caso concentran la mayor parte del volumen. Aun así, los equipos se agotan persiguiendo casos raros y confunden perfeccionismo con avance. Los que llegan más rápido tratan la salida a producción como el comienzo, automatizan primero lo que tiene más volumen y amplían de a poco, con control.

Relee esa lista. No aparece un modelo, ni un token, ni una prueba de rendimiento. Son las fallas de cualquier programa de cambio complejo, documentadas hace décadas. Casi todo lo que hace fracasar un proyecto de IA es un problema de disciplina en la organización disfrazado de problema tecnológico.

Dos proyectos, el mismo motor

Piensa en dos implementaciones con la misma tecnología.

La primera llega a producción antes de lo planeado porque el ejecutivo que la aprobó se queda. El alcance y las disyuntivas se acuerdan temprano, el equipo parte por el trabajo de más volumen, los obstáculos se sacan rápido y el proceso se simplifica antes de automatizarlo. La tecnología no cambia. Cambia la velocidad con que se decide.

La segunda hace el camino inverso. Los requisitos siguen cambiando, los datos representativos y los ambientes de prueba llegan tarde, y la atención se va a excepciones de poco volumen antes de probar el trabajo que más vale. Cuando el cronograma se corre, la IA es el blanco obvio, aunque el freno estuvo en otra parte.

Ninguno de los dos resultados lo decidió el modelo. Uno aceleró porque la organización sostuvo a la tecnología. El otro se frenó porque la organización esperaba que la tecnología tapara sus propias fallas de ejecución.

Cómo revisar tu propio proyecto

Si la IA explica una sola pila de tres, elegir un modelo más inteligente resuelve, en el mejor caso, una parte chica del riesgo. El resto se decide antes de que el primer colaborador digital trabaje: un ejecutivo que sigue presente, requisitos cerrados con datos reales, infraestructura lista y decisiones a tiempo. Y se decide después, según si la integración aguanta producción y si alguien es dueño del resultado.

Las cinco condiciones que le pedimos a cualquier colaborador digital antes de que trabaje sirven igual para revisar tu proyecto:

• Un cargo. Qué trabajo hace tiene que estar escrito, con reglas cerradas, datos reales y el volumen grande primero. Si falta, el problema es de requisitos y de foco.

• Un jefe. Una persona con nombre revisa, firma y resuelve disyuntivas. Si no existe, el problema es de patrocinio.

• Evidencia de todo. Queda escrito qué hizo, con qué dato y en qué sistema. Si no queda, legal y seguridad tienen razón en frenarlo.

• Evidencia que se puede auditar. Alguien de fuera del proyecto puede revisar ese registro sin pedir permiso. Si no puede, la confianza no llega.

• Alguien que responde. Hay un nombre para cuando falle, seis meses después del lanzamiento. Si la respuesta es "depende", el problema es de responsabilidad.

La integración y los accesos no están en esa lista porque son ingeniería, y la ingeniería se prueba antes de salir, con volumen real.

Si lo que falla está en la evidencia y en quién responde, tienes un desafío propio de la IA, y se resuelve con diseño, control y alguien que opere el resultado. Si lo que falla es el cargo o el jefe, la tecnología probablemente no es tu mayor obstáculo. Las mismas disciplinas que han decidido la suerte de los proyectos de cambio durante décadas van a decidir la del tuyo.

Antes de preguntarte si la IA está lista para tu empresa, pregúntate si tu empresa está lista para ponerla a trabajar.