Agentes en plantilla de Google: correo, calendario y entrada en el directorio. ¿Quién los da de baja?

En algún lugar del directorio de una empresa el año que viene, entre un analista nuevo y un contratista, habrá una entrada que termina en @agents.company.com. Tendrá un calendario, una carpeta de Drive y colegas que compartirán archivos con ella. Nadie de Recursos Humanos la habrá contratado, y puede que nadie sepa cómo dejarla marchar.

Esa es la imagen que Google dibujó el 8 de octubre. En su keynote de Gemini at Work, Thomas Kurian presentó a Gemini como “un agente único y universal para el trabajo” que se ejecuta en la nube, sigue trabajando “después de que cierre el portátil” y reparte los trabajos grandes entre subagentes. Dos tipos de agente de ese diseño llevan su propia identidad.

Los agentes en plantilla tienen “un rol persistente y definido y presencia operativa que abarca días, sesiones y múltiples responsabilidades cambiantes”. En Workspace, dice Google, ese agente “recibe su propia cuenta de Workspace, con dirección de correo, calendario, Drive y presencia en el directorio de su empresa”, y solo puede ver el contexto que las personas le dan.

Los subagentes son “agentes temporales y específicos de una tarea, cada uno con su propia identidad”, creados sobre la marcha para tareas de varios pasos que pueden durar horas o días.

Alrededor de ellos, Google describió los controles: identidades “atestiguadas criptográficamente y gobernadas como las de un empleado”, permisos basados en roles aprobados por los administradores de seguridad, propagación de OAuth cuando un agente llega a un sistema externo, un registro de auditoría “atribuido al agente y no a una persona”, un Agent Sandbox con su propia frontera de red y un Agent Gateway que inspecciona el tráfico que entra, sale y circula entre agentes.

Una advertencia antes de planificar nada en torno a esto. Aparte de las ediciones para sectores, que según Google están en preview, el keynote no da estado de disponibilidad, precios ni disponibilidad regional de estas piezas. Léalo como una dirección de arquitectura y consulte la documentación del producto antes de comprometer un roadmap con ello.

Dos tipos de agente, dos relojes de identidad

El diseño es más útil que su marketing porque separa dos problemas que los equipos de identidad empresarial ya conocen y ya gestionan en lugares distintos.

Un agente en plantilla se comporta como un empleado. Se incorpora, asume responsabilidades, cambia de rol y con el tiempo se va. En la mayoría de las empresas, ese ciclo de vida parte de los registros de Recursos Humanos y se gestiona a través de la gobernanza de identidades: quien se incorpora recibe un acceso base, quien cambia de puesto dispara una revisión de accesos y quien se va se desactiva el mismo día.

Un subagente se comporta como una carga de trabajo. Existe para una tarea, debería tener credenciales solo para esa tarea y debería desaparecer con ella. Ese ciclo de vida corresponde a los equipos de plataforma, a credenciales de vida corta y a la automatización, no a las revisiones trimestrales.

Google mete ambos en un solo producto. Su organización tiene que decidir igualmente qué proceso se ocupa de cada uno, porque el proveedor puede emitir la identidad, pero no puede decidir quién responde por ella.

Cuánto vive una identidad de agente

Una tareaMeses

1. SubagenteSe emite por tarea y debe expirar con ella
2. Tarea de larga duraciónSigue funcionando durante horas o días
3. Agente en plantillaCorreo, calendario, Drive, entrada en el directorio
4. Agente en plantilla inactivoAún conserva accesos que nadie usa

El cambio de puesto es el caso difícil

La frase de Google “múltiples responsabilidades cambiantes” es la parte que hay que leer dos veces. Cuando una persona cambia de rol, el traslado es un evento al que alguien puede asociar una revisión. Cuando las responsabilidades de un agente se desplazan porque sus colegas no dejan de asignarle trabajo nuevo, no hay ningún evento. Los permisos, las carpetas compartidas y los cuatro tipos de memoria que describe Google (de sesión, semántica, procedural, incluidas “las habilidades que escribe para sí mismo”, y episódica) se quedan todos, a menos que alguien los retire.

La acumulación de accesos tarda años con las personas. Un agente al que se le asignan tareas nuevas cada semana puede acumular la misma dispersión en un mes.

Hay un punto más silencioso en el diseño. Si un agente en plantilla solo puede ver “el contexto que usted o los miembros de su equipo le aportan”, compartir una carpeta con él es la forma en que se le aprovisiona. La mayoría de las empresas no revisa el uso compartido de Drive como una concesión de acceso. Con los agentes en plantilla, tendrán que hacerlo.

Qué significa retirar a un agente

La baja de una persona está bien ensayada: desactivar la cuenta, transferir los archivos, revocar los tokens. Un agente en plantilla añade elementos que ninguna lista de comprobación actual tiene:

• Memoria y habilidades escritas por él mismo. ¿Conservar, archivar o borrar? Las habilidades que un agente escribió para sí mismo pueden codificar cómo funciona realmente un equipo.
• Concesiones en otros sistemas. Cuando la identidad se propaga mediante OAuth, los tokens y los consentimientos viven en los sistemas externos, no solo en la consola de Google.
• El buzón. Es posible que proveedores y clientes sigan escribiendo a un agente que ya no existe, y alguien debería responsabilizarse de lo que llegue.

El propio equipo de TI de Microsoft ofrece un punto de referencia útil desde el otro lado del mercado. Su guía interna, publicada el mismo día, fija un umbral de inactividad de 60 días para los agentes creados en el Agent Builder de Microsoft 365 Copilot, con alertas y limpieza automatizada. Reglas de inactividad como esa son un suelo razonable también para los agentes en plantilla.

La atribución es la mitad de la responsabilidad

Registrar las acciones bajo la identidad del propio agente, y no la de una persona, resuelve un problema real: los auditores por fin pueden distinguir la acción de un empleado de la de un agente. Pero “lo hizo el agente” es solo la mitad de lo que necesita una investigación. La otra mitad es quién le dio el objetivo al agente y quién aprobó sus permisos. Por eso sostuvimos que los agentes necesitan lo que los empleados ya tienen: un ID, y también un jefe, un presupuesto y un archivo.

La misma lógica se aplica al Gateway. Una política como la del ejemplo de Google, “los agentes no pueden abrir documentos clasificados como Need to Know”, vale solo lo que valga el etiquetado que tiene detrás. Con los agentes en plantilla, la cobertura de etiquetas se convierte en cobertura de seguridad de los agentes.

Nada de esto va contra el diseño de Google. Identidades separadas y atestiguadas, con su propio registro de auditoría, son lo que pediríamos. El trabajo que crea recae en el lado del cliente: decidir qué ciclo de vida se ocupa de cada tipo de agente, definir qué dispara una revisión cuando el rol de un agente se desplaza y escribir la lista de comprobación de bajas antes de que el primer agente en plantilla reciba su dirección de correo.