Implementar agentes de IA: lo que la operación necesita tener ordenado

Puntos clave

• Qué lee exactamente un agente cuando entra a trabajar en una operación, y por qué eso decide su resultado antes que el proveedor.
• Las tres condiciones que puedes verificar en tu propia empresa antes de aprobar el piloto.
• Qué pasa con el piloto cuando falta cada una, para que la evaluación mida lo que corresponde.
• Cómo estimar el costo del contexto que hoy se arma a mano, con tus propios números.

Análisis elaborado por los consultores de Xmarts, mejor partner de Asana en Latinoamérica.

Implementar agentes de inteligencia artificial rinde cuando la operación ya tiene tres cosas definidas: un modelo de trabajo donde proyectos, responsables, dependencias y objetivos están conectados y actualizados; permisos que reflejen quién puede ver y decidir qué; y procesos con puntos de control explícitos. Las tres se pueden verificar hoy, antes de comprometer presupuesto, y ninguna depende del proveedor que se elija después. El orden previo no es un requisito de venta: es la condición que separa un piloto que escala de uno que se apaga.

La pregunta previa que conviene resolver antes de aprobar el piloto

La decisión que llega al comité casi siempre viene formulada como una elección de proveedor. Cuál plataforma, qué alcance, qué presupuesto. Hay una pregunta anterior que rara vez aparece en la carpeta, y es la que decide el resto: si la operación está hoy en condiciones de que un agente produzca algo medible. El modelo de trabajo entre personas y agentes describe qué promete esa forma de operar; esta pieza se ocupa de lo que hay que tener puesto para que la promesa aplique.

No es un requisito que ponga el vendedor, y tiene evidencia detrás. En una encuesta de EY a líderes de la industria tecnológica en Estados Unidos, que es donde la adopción de inteligencia artificial ha llegado más lejos, la mitad de las iniciativas a nivel departamental opera sin aprobación ni supervisión formal y casi ocho de cada diez líderes reconocen que la adopción va más rápido que su capacidad de gestionar el riesgo. Si así está el sector que más terreno ha recorrido, conviene asumir que fuera de él la situación no es mejor.

Lo que ese dato describe no es imprudencia: es adopción que corrió por delante de la estructura. Y tiene una consecuencia práctica para quien aprueba el presupuesto, porque esa estructura se puede inspeccionar antes de comprometerlo. Son tres cosas, se ven en el trabajo de esta semana, y cada una tiene una evidencia observable que alguien de tu equipo puede traer a la próxima reunión de comité.

Qué lee un agente cuando entra a una operación

Conviene ser preciso con la mecánica, porque la palabra agente admite demasiadas interpretaciones y la mayoría son de película.

Un agente de trabajo no consulta un cerebro central que sabe cómo funciona tu empresa. Consulta el registro de trabajo que tu empresa mantiene: qué proyectos existen, qué tareas cuelgan de cada uno, quién es responsable, de qué depende cada entrega, contra qué objetivo corre y en qué estado está hoy. Asana llama a ese registro Work Graph y lo describe como un mapa conectado y actualizado del trabajo de la organización. Otras plataformas lo llaman de otra forma y la consecuencia es la misma: lo que no está en ese registro, para el agente no existe.

Los Compañeros de IA de Asana se asignan como cualquier otro miembro del equipo y operan, en palabras de la propia compañía, bajo las pautas y permisos que tú defines, con cada acción auditable y reversible. Esa frase tiene dos mitades y la segunda suele leerse rápido. La primera dice que el agente no se inventa su alcance. La segunda dice que el alcance se lo das tú, con el mismo modelo de permisos que ya usas para personas.

Hay un detalle que lo vuelve muy concreto. El agente construye una memoria propia con lo que va aprendiendo del trabajo, y la visibilidad de esa memoria queda atada estrictamente a los permisos de la plataforma. Un agente que trabaja para el área de operaciones no puede recordar hacia el área de finanzas si los permisos nunca lo permitieron. Es una buena noticia de gobierno y, al mismo tiempo, la razón por la que un esquema de permisos heredado de una migración vieja se convierte en un techo silencioso para todo lo que venga después.

Las tres condiciones que hacen la diferencia

Un modelo de trabajo conectado. No basta con que el trabajo esté registrado: tiene que estar relacionado. Un proyecto que no cuelga de ningún objetivo, una entrega que no declara de qué depende, una tarea sin responsable nombrado. Cada una de esas ausencias es una relación que el agente no puede recorrer, y las relaciones son justamente lo que distingue un sistema de trabajo de una lista de pendientes compartida. Aquí es donde el mapa del proceso que ya levantaste se vuelve útil por segunda vez, porque dice qué relaciones importan de verdad en tu operación y cuáles son adorno.

Permisos que digan la verdad. El modelo de permisos de la mayoría de las empresas se armó una vez, durante una implantación, y creció por excepciones. Alguien necesitó acceso a un proyecto puntual y se le dio para siempre. Un área cambió de responsable y el anterior conservó todo. Nada de esto molesta mientras solo hay personas, porque las personas aplican criterio sobre lo que ven. Un agente no aplica criterio. Opera dentro del perímetro que le corresponde, y ese perímetro se vuelve visible el día que entra. En la práctica, revisar permisos antes de un piloto de inteligencia artificial suele ser el primer inventario honesto de accesos que la empresa hace en años.

Puntos de control explícitos. Un proceso con control explícito declara cuatro cosas: quién aprueba, en qué momento del recorrido, con qué criterio, y qué pasa cuando el criterio no se cumple. La cuarta es la que casi siempre falta, y es la que convierte un control en una regla operable en lugar de un trámite.

Cuando esa declaración no existe, el control igual ocurre, solo que de manera informal: alguien lo revisa porque siempre lo ha revisado. Eso funciona entre personas que se conocen. Se rompe en cuanto entra un participante que no estaba en el acuerdo tácito.

La documentación de Asana lo plantea del lado del diseño: los agentes completan trabajo asignado manteniendo a las personas dentro de las decisiones, las revisiones y las entregas. Para que eso ocurra, alguien tiene que haber dicho antes cuáles son esas decisiones. Un agente puede esperar una aprobación, avisar a quien corresponde y detenerse hasta recibirla. Lo que no puede es deducir que existe una aprobación cuando nadie la declaró, porque ese conocimiento vive en la costumbre y no en la estructura.

Vale la pena notar en qué orden conviene atacarlas. El modelo de trabajo y los permisos son trabajo de configuración con un final claro. Los puntos de control son trabajo de acuerdo entre áreas, y por eso arrancan antes aunque terminen después.

Qué ocurre cuando falta alguna de las tres

El patrón es lo bastante regular como para anticiparlo, y anticiparlo es lo que permite evaluar un piloto con justicia.

Sin modelo conectado, el agente entrega un resumen de estado impecable de un proyecto cuya dependencia crítica vive en otro lado. La dirección detecta el hueco y concluye que la herramienta no es confiable. Sin permisos correctos, el piloto se frena por una razón administrativa que nadie previó, o no se frena y opera con un alcance mayor al que alguien habría autorizado por escrito. Sin puntos de control, el equipo hace lo razonable y revisa todo cada vez, con lo que el tiempo ahorrado vuelve a gastarse en verificación.

Ninguno de los tres es un fallo de la plataforma. Son fallos de lectura, y la configuración inicial de una empresa completa ya obliga a resolverlos, con agentes o sin ellos.

En los diagnósticos de Xmarts con empresas que agregaron áreas más rápido que procedimientos, uno de los patrones que más se repite es el tercero. El modelo de trabajo suele estar a medio camino y los permisos se pueden ordenar, pero la revisión informal es cultura. La cultura no se corrige con una configuración.

Cómo medir hoy en qué punto está tu operación

Las tres se miden sobre el terreno, no sobre el organigrama. Ninguna necesita una herramienta.

La del modelo de trabajo tiene una aproximación rápida. Toma las últimas diez decisiones del comité. Cuenta en cuántas alguien tuvo que reunir el contexto a mano: pedir el estado por mensaje, abrir tres archivos, preguntar a dos personas quién era responsable de qué. Multiplica esas horas por el costo hora cargado de quien las dedicó, y eso por las veces que ese tipo de decisión se repite en el año. Lo que sale es lo que hoy cuesta sostener el contexto a mano, que es justamente el trabajo que un agente no puede asumir mientras ese contexto no viva en una estructura que se pueda recorrer. La cifra la pone tu operación.

Para los permisos, la verificación es más corta: pide la lista de quién tiene acceso a los tres proyectos más sensibles y compárala con quién debería tenerlo hoy. Esa distancia es el trabajo pendiente.

Para los puntos de control, la prueba es una pregunta a quien ejecuta: en el último entregable, cómo supiste que ya estaba aprobado. Si la respuesta describe un mensaje, una conversación de pasillo o un silencio interpretado, el control existe pero no está declarado.

Los procesos con los que Xmarts trabaja estos diagnósticos son estándar, y el calendario no lo es. Una empresa con un proceso crítico y un área dueña no recibe el mismo plan que una donde tres áreas comparten el mismo proceso y ninguna lo declara propio: la segunda necesita una conversación de gobierno antes que cualquier configuración. Esa parte del alcance se dimensiona con el caso enfrente, no antes.

Tres preguntas para llevar a tu comité de dirección:

1. De las últimas diez decisiones que tomamos, ¿en cuántas alguien tuvo que reunir el contexto a mano? Si son la mayoría, el contexto no está en el sistema y ningún agente puede leerlo.
2. ¿Cuándo se revisó por última vez quién tiene acceso a qué, y con qué criterio? Si la respuesta apunta a la implantación original, el modelo de permisos refleja una empresa que ya no existe.
3. En nuestro proceso más crítico, ¿está escrito quién aprueba y con qué criterio, o se sabe? Si se sabe, funciona entre las personas actuales y no sobrevive a un cambio de equipo.

Antes de decidir si tu empresa está lista para sumar agentes a su operación conviene medir las tres condiciones sobre el terreno, no sobre el organigrama. Un diagnóstico con un consultor de Xmarts Enterprise lo hace con tu equipo y tus procesos. Agenda el tuyo.

Preguntas frecuentes