Compañeros de IA en un proyecto: qué ejecutan y qué decide tu equipo

Puntos clave

• Las cinco formas en que se le puede dar trabajo a un agente, y cuál conviene para cada tipo de proceso.
• Qué contexto lee exactamente cuando recibe una tarea, y qué queda fuera de su alcance.
• El criterio con el que Asana decide cuándo pedir aprobación humana, que sirve para diseñar el tuyo.
• Dónde conviene poner el punto de control en tus propios proyectos, y quién debe fijarlo.

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

Los Compañeros de IA de Asana, llamados AI Teammates en inglés, son agentes preconfigurados que se asignan a una tarea igual que se asigna a una persona. Trabajan con el contexto del proyecto: qué depende de qué, contra qué objetivo corre, quién aprueba. Asana publica más de 30 listos para usar en marketing, operaciones y tecnología, además de otros por industria. Operan bajo los permisos que se les definen, no pueden ampliárselos solos y cada acción queda registrada. El diseño del trabajo no cambia porque un agente ejecute parte de él: cambia dónde se pone el punto de control.

La pregunta de fondo no es qué puede hacer un agente sino qué deja de pasar por una persona

En las reuniones donde se decide esto, la demostración suele responder la pregunta equivocada. Muestra capacidad, y lo que el comité necesita resolver es otra cosa: qué trabajo deja de pasar por un escritorio humano, y si alguien puede reconstruir después lo que ocurrió.

No es una preocupación exótica. KPMG, en su encuesta trimestral a líderes, encontró que más de la mitad ya espera un modelo donde las personas dirigen agentes en lugar de uno donde los agentes trabajen solos. La expectativa dominante no es la sustitución. Es la supervisión, y la supervisión hay que diseñarla.

Ahí está el trabajo real de dirección en esta decisión. No aprobar una herramienta, sino definir en qué puntos del proceso una persona sigue firmando. El mapa del proceso y las tres condiciones previas sirven para saber si la operación está lista; esta pieza se ocupa de lo que viene después, que es dónde poner la firma.

Cómo se asigna trabajo a un Compañero de IA

Hay cinco vías, y la elección no es un detalle de configuración: define quién queda a cargo de que el trabajo arranque. Para el trabajo de alto volumen que no pide criterio la vía correcta es otra.

Tres son manuales. Se le puede asignar una tarea directamente. Lee entonces su título, su descripción, su contexto. Empieza a trabajar: comenta, crea subtareas, ejecuta lo que sus instrucciones permitan. Se le puede mencionar en un comentario para pedirle algo o corregirle el rumbo, incluso mientras está trabajando, sin esperar a que termine. Responde cuando alguien con acceso a él comenta en una tarea donde es colaborador, si el comentario va dirigido a él.

Dos son automáticas, y son las que cambian la escala. Reglas y formularios: cuando una tarea entra a cierta sección se le asigna para triaje, o cuando un formulario genera una solicitud se le adjudica sola. También trabajo recurrente, que tiene una variante poco conocida: además de tomar cada ocurrencia de una tarea que se repite, el propio agente puede agendarse un seguimiento durante una ejecución, del tipo "vuelve a esto el viernes a las nueve".

Esa última capacidad es la que conviene mirar con más atención en un comité. Un agente que se agenda a sí mismo trabaja sin que nadie lo convoque, y eso es exactamente lo que se quiere para una revisión semanal de cartera y exactamente lo que no se quiere para un proceso todavía en diseño.

Mientras ejecuta se puede ver su actividad y detenerlo desde el hilo de la tarea con una indicación. No es un proceso en segundo plano al que solo se le ve el resultado.

Qué contexto lee y de dónde lo saca

El contexto no es un archivo que alguien le carga. Es la estructura del trabajo que ya existe en la plataforma, y por eso el resultado depende de qué tan completa esté.

Cuando recibe una tarea, lee su título y su descripción, y desde ahí recorre lo que la tarea declara: de qué depende, a qué proyecto pertenece, contra qué objetivo corre, quién más colabora. Los miembros autorizados pueden además subirle recursos de consulta permanente, como manuales, políticas o instrucciones internas, que es como se le transmite el criterio de la empresa en lugar de repetírselo en cada petición.

Fuera de Asana, puede trabajar con las herramientas que la organización conecte, entre ellas correo, calendario, almacenamiento de documentos, mensajería y algunos sistemas comerciales. Aquí hay un detalle de gobierno que conviene tener presente antes de autorizar la primera: las integraciones actúan en nombre de quien las conectó, sus acciones aparecen como si esa persona las hubiera hecho, y autorizar una integración para un Compañero la habilita para todos los Compañeros de esa persona.

Hay además una advertencia que la propia documentación de Asana hace y que casi nadie anticipa. Los comentarios de un Compañero son visibles para todos los que tienen acceso a la tarea. El lugar donde se le pide algo decide quién va a leer la respuesta, así que pedirle un análisis delicado en una tarea de proyecto abierto es una decisión de audiencia, no solo de productividad.

Permisos, memoria y registro: por qué esto es una decisión de dirección

Un Compañero recién creado ve lo público del dominio, como cualquier persona que entra. A lo privado hay que invitarlo. Dentro de cada espacio opera con uno de los tres niveles estándar de la plataforma. Editor, que crea tareas, las completa y actualiza campos; comentarista, que solo comenta; lector, que solo lee. Si se le agrega a un equipo, hereda los niveles de ese equipo. No puede ampliárselos por su cuenta.

La memoria es la parte que suele sorprender, y su diseño es más conservador de lo que la gente supone. El principio es el mismo que rige qué información alcanza un asistente de inteligencia artificial en cualquier plataforma: el permiso de la persona, no el del agente. El Compañero guarda recuerdos de lo que hizo, pero esos recuerdos viven sobre la tarea, no en un archivo central. Quien pierde acceso a una tarea pierde acceso a sus memorias. Cuando el Compañero se retira de un proyecto, olvida las memorias asociadas. La memoria nunca amplía el acceso de nadie.

Lo más útil para una conversación de comité, sin embargo, es la lógica con la que Asana decide cuándo detenerse a pedir permiso. No es una lista arbitraria de acciones sensibles. La aprobación humana se exige cuando la acción cambiaría quién puede ver qué.

Asignar una tarea pasa sin aprobación si quien la recibe ya tenía acceso a ella, y la exige si ese acceso sería nuevo. Agregar colaboradores funciona igual. Agregar miembros a un proyecto público pasa; a uno privado, no. Eliminar una tarea que el propio agente creó pasa; eliminar la de otra persona, no. Hay dos acciones que exigen aprobación siempre, sin condición: quitar colaboradores de una tarea y quitar miembros de un proyecto.

Ese criterio se puede llevar tal cual al diseño interno, y es lo que convierte una pregunta difusa en una regla. Deja de discutirse hasta dónde dejamos que llegue el agente, y pasa a discutirse qué acciones de nuestro proceso cambian quién ve qué.

Dónde conviene poner el punto de control en tus proyectos

Con los permisos resueltos queda lo que ninguna plataforma decide por la empresa: en qué momento del entregable una persona pone su firma. Ahí es donde el recorrido real del proceso vale por tercera vez, porque la firma se ubica donde el trabajo se detiene, no donde el organigrama lo sugiere.

Hay una forma de estimar lo que está en juego sin inventar cifras. Cuenta, en una semana normal, cuántas veces alguien de tu equipo pide un estado, arma un borrador desde cero o gestiona una aprobación pendiente. Multiplica por el tiempo que toma cada una y por el costo hora cargado de quien las hace. Ese es el trabajo de coordinación que hoy se ejecuta a mano y que un agente puede tomar. La cifra la pone tu operación.

Lo que no conviene mover con la misma ligereza es la firma. Tres criterios ayudan a ubicarla, y ninguno es técnico.

El primero es la reversibilidad. Una acción que se deshace sola no necesita aprobación previa; una que compromete a un tercero, sí. El segundo es la audiencia: si el resultado va a ser leído por alguien fuera del equipo, la revisión ocurre antes y no después. El tercero es la responsabilidad declarada. Cuando algo sale mal, alguien responde por ello, y esa persona es la que tiene que haber firmado.

En los diagnósticos de Xmarts con empresas que ya operan con procesos documentados, uno de los patrones que más se repite es que los dos primeros criterios se aplican bien y el tercero no está escrito en ninguna parte. El trabajo se supervisa, pero nadie declaró quién responde.

Los procesos con los que Xmarts trabaja estos diseños son estándar y el calendario no lo es. Una empresa de servicios con un proceso crítico y un área dueña no recibe el mismo plan que una industrial donde tres áreas comparten el mismo entregable y ninguna lo declara propio: la segunda necesita resolver la responsabilidad antes de tocar una configuración.

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

1. En nuestro proceso más crítico, ¿qué acciones cambiarían quién puede ver qué? Si nadie las puede enumerar, todavía no hay con qué diseñar el punto de control.
2. ¿Quién responde cuando un entregable sale mal? Si la respuesta tarda o admite dos nombres, el punto de control no tiene dueño y ninguna herramienta lo resuelve.
3. ¿Cuántas veces por semana alguien de dirección pide un estado que el sistema ya tiene? Es la medida más directa del trabajo de coordinación que hoy se hace a mano.

Decidir en qué punto de cada proyecto sigue aprobando una persona es trabajo de diseño, no de configuración. Un diagnóstico con un consultor de Xmarts Enterprise lo define sobre tus procesos reales. Agenda el tuyo.

Preguntas frecuentes