Todo agente de IA ya tiene un ID. Ninguno tiene un puesto.

Los agentes se están volviendo empleados, al menos en el papel. Cada uno recibe una identidad, permisos, un registro de auditoría y una persona responsable. Es un avance, y es la mitad fácil. Un ID te dice quién es el agente. No te dice qué trabajo le pertenece, quién se lo entrega ni qué significa "terminado". Las empresas que se quedan en la credencial tendrán un directorio ordenado de agentes y la misma operación de antes.

Qué cambió Microsoft

Según la documentación de Copilot Studio de Microsoft, desde mayo de 2026 Copilot Studio crea automáticamente un Microsoft Entra Agent ID para cada agente nuevo, y los administradores ya no pueden desactivarlo. La identidad hace visibles para los administradores los permisos de conectores del agente, permite aplicar políticas de Acceso Condicional y lo integra al registro de auditoría y a la gestión de su ciclo de vida. El dueño del agente queda como patrocinador (sponsor), lo que Microsoft describe como trazabilidad de gobierno, responsabilidad sobre el ciclo de vida del agente y alineación con las políticas de propiedad de la organización.

Léelo como una declaración de diseño: un agente debe tener una persona responsable. Bien. Pero fíjate en lo que la capa de identidad no puede contener. Registra quién puede acceder a qué. No tiene un campo para de qué resultado responde este agente.

Una credencial no es una descripción de puesto

Cuando contratas a una persona, el acceso es el último paso de la incorporación, no el primero. Antes vienen las preguntas que hacen posible el trabajo:

• ¿Cuál es el rol? Qué etapa de qué flujo es suya y dónde termina.
• ¿Quién le pasa el trabajo y a quién se lo pasa después?
• ¿Cómo se mide? Un solo número, visible para quien es responsable.
• ¿Cuándo cambia o termina el rol?

Los agentes se saltan todo esto porque la plataforma se lo permite. Creas uno en una tarde, recibe su identidad solo y empieza a generar actividad. La actividad parece trabajo. En un sistema que nadie rediseñó, casi siempre es solo movimiento.

El problema del patrocinador

Un patrocinador es la idea correcta, y falla de una forma predecible. Si el patrocinador es quien construyó el agente, normalmente alguien de TI o de innovación, puede responder "¿a qué tiene acceso?", pero no "¿la fila es más corta?". Quien puede responder eso es quien dirige la operación: la jefa de atención al cliente, el responsable de reportes, la de logística.

El patrocinador de un agente debería ser el dueño del flujo donde trabaja, no quien lo configuró. Si esa persona no existe, el hallazgo no es sobre el agente. Es que el flujo no tiene dueño, y ningún agente puede arreglar eso.

Cómo se ve la evidencia

Los casos que podemos mostrar parten de la operación, y las partes autónomas llegan después. En Rodo, las consultas de WhatsApp, redes y web se integraron a una operación de servicio con una ruta de resolución medible. En la primera ventana medida, 82% de las consultas creadas en vivo llegaron a resuelto (cohorte del 31 de agosto al 24 de septiembre, según el reporte operativo de Rodo del 24 de septiembre de 2026; las cifras describen registros del pipeline, no todas las conversaciones). Fue una primera ventana medida, sin base de comparación anterior.

Lo importante no es la cifra. Es que cada consulta tenía un lugar, una etapa y un resultado antes de automatizar nada. Un agente que trabaja dentro de esa ruta tiene un puesto porque la ruta existe.

Una prueba para esta semana

Haz una lista de los agentes que corren en tu empresa, desde el piloto que nadie recuerda hasta el que el director mostró en una demo. Para cada uno escribe una línea: este agente es responsable de [etapa] de [flujo], su dueño es [nombre], y sabemos que funciona cuando [número] se mueve.

Todo agente para el que no puedas completar esa frase no tiene un puesto. Arregla la frase antes de revisar sus permisos.