Conviene empezar por lo que casi siempre es cierto: la herramienta funciona. La prueba salió bien, el modelo responde, la licencia está paga y el área de sistemas hizo su parte sin errores. Y aun así, tres meses después, el panel de uso está plano.
A partir de ahí el diagnóstico se desvía solo. Se habla de resistencia al cambio, de falta de capacitación, de que el equipo «todavía no le agarró la mano». Se contrata otra sesión de entrenamiento y se manda un correo recordando que existe. Ninguna de esas explicaciones es el problema. La adopción no se rompe el día en que alguien decide no abrir la aplicación: se rompió bastante antes, cuando se decidió comprarla.
Porque en general se compró por lo que hace, no por el trabajo concreto que le saca de encima a una persona concreta. Son dos preguntas distintas y solo una se responde en una demostración. «Resume cuentas, redacta correos, analiza llamadas» describe una capacidad. «El lunes, quien arma el reporte deja de pasar dos horas en eso» describe un cambio. Nadie se levanta con ganas de usar inteligencia artificial. Se levanta con ganas de no volver a hacer lo que detesta hacer.
Y ahí aparece el error más caro, que es el de proceso: nadie cambió nada alrededor de la herramienta. Se la apoyó encima de una forma de trabajar que quedó intacta. El vendedor sigue cargando los mismos campos, escribiendo el mismo resumen y mandando el mismo correo de siempre; solo que ahora, además, tiene que abrir una aplicación más, leer lo que devolvió y corregirlo. No le sacaste trabajo. Le agregaste un paso.
Una herramienta que se suma a un proceso que no cambió no es una herramienta. Es una tarea más, con mejor interfaz.
Después está la cuestión del dueño. Estos proyectos los suele pedir la dirección, los implementa sistemas y no los usa nadie —y ninguno de los tres se siente responsable de que se usen. Cuando pregunto quién es el dueño, la respuesta casi siempre es un área, no una persona. Un área no adopta nada. Adopta alguien que tiene un problema propio, un plazo y algo que ganar si esto funciona.
Con el criterio de éxito pasa lo mismo. Si al arrancar nadie escribió qué tenía que moverse y para cuándo, el proyecto no se puede sostener ni discontinuar: queda flotando, ni vivo ni muerto, hasta que vence la licencia. Y a falta de criterio se mide lo único que el sistema sabe contar: cuánta gente entró esta semana. Uso no es resultado. Un equipo puede abrir la herramienta todos los días y tener el mismo ciclo comercial que el trimestre pasado.
Queda lo que rara vez se dice en voz alta. Muchas de estas iniciativas se anuncian con la palabra «eficiencia» o con la promesa de ahorrar tiempo. Puertas adentro, un equipo que escucha «esto hace en un minuto lo que vos hacés en una hora» no escucha una buena noticia: escucha una conversación sobre su propio puesto. Nadie adopta con entusiasmo aquello que parece diseñado para volverlo prescindible, y si el tiempo que se ahorra no tiene un destino declarado, cada uno lo completa con la versión más incómoda.
La comparación que más me sirve es entre las herramientas que hay que imponer por decreto y las que se adoptan solas. Las segundas no son mejores técnicamente: le sacan a alguien una tarea que odiaba, y se nota la primera vez que la usan. A nadie hubo que capacitarlo para dejar de hacer manualmente algo que ya no quería hacer. Cuando hace falta una campaña interna para que un equipo use algo, ya está dicho todo: lo que se compró no resolvía un problema que el equipo tuviera.
Por eso las preguntas que importan antes de firmar no son sobre el modelo. Son de quién es el problema que esto resuelve, qué deja esa persona de hacer la semana que viene, quién responde si en noventa días nadie lo usó y qué número tendría que haberse movido para que renovar la licencia tenga sentido. Ninguna de las cuatro la contesta un proveedor. Se contestan adentro, y se contestan antes.
Lo incómodo es que responderlas obliga a tocar el proceso, y eso cuesta más que comprar la licencia. Es más rápido anunciar una herramienta que rediseñar cómo trabaja un equipo, y por eso suele hacerse en ese orden. Pero una implementación sin cambio de proceso no es una implementación a medias: es una compra.
La adopción no es la última etapa de un proyecto de inteligencia artificial. Es la primera decisión, tomada mucho antes de elegir la herramienta: qué trabajo, de quién, deja de hacerse.
Una herramienta que hay que imponer no resolvía el problema de nadie.