Un agente es una integración. Cien son un problema de gobernanza.
Los agentes obtuvieron identidad de producción antes de tener una forma estable de registrar lo que hicieron. Microsoft Entra Agent ID ya está disponible, con patrocinadores y fechas de caducidad. Las convenciones de OpenTelemetry para las trazas de los agentes siguen siendo experimentales. Esa diferencia no es un detalle: decide qué se puede poner en producción este año, y convierte una cuestión de IA en una cuestión de gobernanza.
La pregunta interesante sobre los agentes dejó de ser si funcionan. En los proyectos que vemos, un agente que lee el correo de un proveedor y propone el pedido correspondiente funciona lo bastante bien como para conservarlo. La pregunta interesante es qué ocurre el día en que hay cuarenta, construidos por cuatro equipos, tres de los cuales ya pasaron a otra cosa.
Eso no es un problema de IA. Cada una de sus partes es un problema que la industria ya conoce por su nombre: identidad, asignación de accesos, auditoría, imputación de costes, alcance de un fallo, control de cambios. La dificultad es que llegan todos a la vez, pegados a algo que decide por sí mismo.
Tres olas, y solo la tercera es difícil
La primera ola fue sobre modelos. Cuál, de qué tamaño, a qué precio por millón de tokens. Parecía decisiva entonces y resultó ser la menos duradera: el modelo que hoy está en producción será sustituido dos veces antes de que este artículo envejezca.
La segunda ola fue sobre agentes. Cómo conectar uno a un sistema real, dónde cae la línea entre lo que decide y lo que ejecuta el código. Escribimos sobre esa línea en los agentes deciden, el código ejecuta, y la respuesta se mantiene: criterio de un lado, garantías del otro.
La tercera ola no es sobre agentes mejores. Es sobre un conjunto de ellos. Y un conjunto se comporta de forma completamente distinta a una integración, porque cambia el modo de fallo. Un agente que se equivoca en un permiso es un defecto. Cuarenta agentes compartiendo un service principal es un incidente sin forma de saber cuál de ellos actuó.
Qué cambió de verdad en el último año
Ocurrieron dos cosas que conviene enunciar con precisión, porque la precisión es el argumento.
Los agentes pasaron a tener identidad de verdad. Microsoft Entra Agent ID introduce cuatro tipos de objeto nuevos: un agent identity blueprint, un blueprint principal, una agent identity y un agent user. Una agent identity es una cuenta en Entra ID, gobernada con la misma maquinaria de ciclo de vida que una persona: paquetes de acceso, gestión de derechos, Acceso Condicional aplicado al nivel del blueprint para que todos los agentes creados a partir de él hereden la política, y señales de riesgo procedentes de Identity Protection.
La parte de ese diseño que merece una pausa es el patrocinador. Cada agent identity tiene una persona responsable de su acceso y de su ciclo de vida. Si esa persona sale de la organización, el patrocinio se transfiere automáticamente a su responsable. Siempre hay alguien que responde por el agente, por construcción, y el sistema se niega a que ese alguien sea nadie.
Los agentes no obtuvieron una forma estable de registrar lo que hicieron. Las convenciones semánticas GenAI de OpenTelemetry, el vocabulario neutral para las trazas de los agentes, pasaron a un repositorio propio en la versión v1.42.0, del 12 de junio de 2026, y siguen siendo preestables. No hay 1.0. El formato ya es bueno y se emite ampliamente, y sigue estando explícitamente sujeto a cambios.
Puestas una al lado de la otra, la asimetría es toda la historia:
| Materia | En qué estado está | Qué significa en la práctica |
|---|---|---|
| Identidad | Disponible, con gobernanza | Se da al agente un nombre, un responsable y una caducidad |
| Derechos de acceso | Disponible | El acceso llega en un paquete, con aprobador y fecha de fin |
| Condiciones de acceso | Disponible | El Acceso Condicional evalúa el riesgo del agente antes de conceder |
| Traza y auditoría | Preestable, sin 1.0 | Se instrumenta, se fija la versión y se cuenta con cambios |
| Calidad de la evaluación | Preestable | Saber si el agente acertó sigue correspondiendo a quien lo opera |
Ya se puede decir quién es un agente, qué puede tocar y quién responde por él. Decir exactamente qué hizo, en un formato que siga leyéndose el año que viene, es la parte que no ha llegado. Quien planifica un conjunto de agentes este año planifica alrededor de esa falta, se haya dado cuenta o no.
El protocolo creó una estructura de gobernanza
Hay una segunda prueba, y no es una analogía.
El Model Context Protocol pasó su primer año siendo una capa de descripción: esta herramienta existe, se llama así. Las revisiones siguientes fueron casi todas sobre control. La revisión de junio de 2025 clasificó los servidores MCP como Resource Servers de OAuth 2.0, hizo obligatorios los metadatos de recurso protegido del RFC 9728, y pasó a exigir que el cliente vincule cada token a un servidor concreto mediante el parámetro de recurso del RFC 8707. La revisión de noviembre de 2025 añadió consentimiento incremental de ámbitos por la cabecera WWW-Authenticate, documentos de metadatos de client ID para el registro, y un mecanismo experimental de tasks para peticiones duraderas, con sondeo y recogida diferida del resultado.
Este último importa más de lo que parece. Las tasks existen porque los agentes empezaron a hacer trabajo que dura más que una petición. Trabajo que dura más que una petición es trabajo que necesita estado, dueño y forma de ser cancelado, que es la definición de algo que hay que gobernar.
Y después el protocolo hizo lo que hace la infraestructura cuando pasa a soportar peso: formalizó su propia gobernanza. Grupos de trabajo, grupos de interés, una estructura documentada, un sistema de niveles para los SDK con compromisos de mantenimiento. Los protocolos que se quedan en juguetes no crean comisiones.
Qué exige un conjunto de agentes, y a quién pertenece cada parte
Las nueve materias siguientes son las que hemos visto salir mal. Agruparlas así es útil porque muestra que casi ninguna pertenece al equipo de IA.
| Materia | La pregunta que falla | A quién pertenece |
|---|---|---|
| Identidad | ¿Cuál de los agentes hizo esto? | Identidad |
| Derechos de acceso | ¿Quién aprobó ese acceso, y cuándo termina? | Identidad y el dueño del negocio |
| Aislamiento | ¿A qué más podía llegar cuando salió mal? | Plataforma |
| Auditoría | ¿Se puede reconstruir la decisión seis meses después? | Plataforma y cumplimiento |
| Observabilidad | ¿Está fallando ahora, y cómo lo sabríamos? | Plataforma |
| Coste | ¿Qué equipo paga aquel ciclo? | Finanzas y plataforma |
| Política | ¿Qué no puede hacer nunca, sea cual sea el prompt? | Seguridad |
| Aprobación | ¿Qué acciones necesitan una persona antes de concretarse? | El dueño del negocio |
| Responsabilidad | ¿Quién firma cuando sale mal? | Una persona con nombre |
Solo la última fila es nueva, y lo es únicamente en el sentido de que la industria aún no ha creado el hábito.
Una identidad por agente, y por qué el atajo sale caro
El atajo más común que vemos es un service principal compartido por todos los agentes que publica un equipo. Es fácil, funciona el primer día, y destruye tres propiedades a la vez.
Se pierde la imputación: el registro de auditoría guarda el principal, no cuál de los agentes lo usó, y la respuesta a "cuál de ellos hizo esto" pasa a ser un ejercicio de reconstrucción a partir de registros de aplicación que pueden no existir. Se pierde el mínimo privilegio: el principal compartido acumula la unión de todos los permisos que algún agente necesitó, de modo que el agente más reciente y menos revisado hereda los derechos del más antiguo y de mayor confianza. Y se pierde la capacidad de revocar: apagar el agente comprometido los apaga todos.
El diseño que sobrevive es aburrido y conocido:
Un blueprint transporta la política. Cada agente recibe de él su identidad. El acceso llega en un paquete con aprobador y fecha de fin, en lugar de ser una concesión permanente que sobrevive al proyecto que la necesitó.
El detalle que merece una decisión, no un valor por defecto
Entra Agent ID permite que una agent identity solicite un paquete de acceso por vía programática, en su propio nombre, creando una petición de asignación. El patrocinador también puede pedir en nombre del agente, y un administrador puede asignar directamente.
Vale la pena releer la primera vía. Un agente puede pedir más acceso.
Esto no es un defecto. Es la primitiva correcta para un sistema donde el trabajo se descubre en ejecución, y la petición sigue cayendo en un flujo de aprobación con un aprobador humano. Pero es una bifurcación de arquitectura de verdad, y debe ser una decisión que la organización tome a propósito, en lugar de algo que descubre en una auditoría.
Nuestra posición, por el mismo razonamiento que aplicamos a cualquier camino de elevación de privilegios: poder pedir es aceptable, la aprobación nunca puede ser automática, y el aprobador tiene que ser alguien que entienda qué es aquel recurso. Un flujo de aprobación que dirige a quien no puede evaluar la petición es un sello con mejor registro.
La aprobación pertenece al paso irreversible
El instinto, cuando un equipo comprende cuánto puede hacer un agente, es poner a una persona delante de todo. Eso falla en quince días: quien revisa deja de leer, y se ha añadido latencia sin añadir criterio.
La línea que aguanta es la misma que gobierna el resto del sistema. Pida una persona donde la acción sea irreversible o visible hacia fuera, y en ningún otro sitio.
| Aprobar | No aprobar |
|---|---|
| Dinero que sale de la organización | Leer datos que quien pregunta ya puede leer |
| Todo lo que va hacia un cliente | Resumir, ordenar, redactar una propuesta |
| Cambios de permisos y roles | Consultar sistemas de registro |
| Borrar o sobrescribir registros | Proponer una acción para revisión |
| Publicar en una superficie pública | Todo lo que se deshace sin coste |
El criterio no es la importancia que parece tener la acción. Es si un error que pase desapercibido todavía se corrige el lunes.
El coste es un control, no un informe
El consumo de tokens se suele tratar como asunto financiero descubierto a fin de mes. En un conjunto de agentes es un mecanismo de seguridad, porque coste descontrolado y comportamiento descontrolado son el mismo suceso visto desde dos ángulos. Un agente atrapado en un ciclo de reintentos contra una herramienta que falla produce exactamente un síntoma visible antes de que alguien repare en el comportamiento: la factura.
Lo que significa que el presupuesto pertenece a la identidad, y no a un panel:
# El límite pertenece a la identidad del agente, no a una revisión mensual.
# Un agente atrapado en un ciclo gasta su propio presupuesto y para. No
# gasta el del equipo, ni el del agente de al lado.
def llamar_modelo(agente: AgentIdentity, peticion: Peticion) -> Respuesta:
if presupuesto.gastado(agente.id, hoy()) >= agente.limite_diario:
raise PresupuestoAgotado(agente.id) # falla cerrado, y avisa
respuesta = modelo.invocar(peticion)
presupuesto.registrar(agente.id, respuesta.tokens, respuesta.coste)
return respuesta
Los límites por agente dan tres cosas que un informe mensual no da: el ciclo se frena solo, el fallo se imputa a un agente en lugar de a un equipo, y la alerta salta mientras la causa sigue en pantalla.
Auditoría, cuando la razón es una probabilidad
La auditoría tradicional responde a qué ocurrió y bajo qué autoridad. Con agentes hay una tercera pregunta, y es la que se hace en la sala justo después de un incidente: por qué eligió aquello.
Esa respuesta no puede ser una explicación del modelo, porque una explicación dada después del hecho es una narrativa plausible, no un registro. Lo que sí se puede registrar es todo lo que rodea a la decisión, y resulta que basta:
- la identidad del agente, no el principal compartido;
- las herramientas disponibles en aquel momento, y sus versiones;
- las entradas que el agente recibió de hecho, incluido lo que devolvió un paso de búsqueda;
- las llamadas a herramientas, en orden, con los parámetros;
- las aprobaciones concedidas, por quién y cuándo;
- el modelo y la versión, porque el comportamiento cambia entre ellas.
Recreando eso se reproduce la decisión, que es lo que quiere un auditor. Es también exactamente la superficie que describen las convenciones GenAI de OpenTelemetry, y exactamente por eso su estado preestable es una restricción de planificación y no una nota al pie. Instrumentar ahora, fijar la versión de la convención, y contar con migrar.
La conclusión incómoda
Una organización con la identidad ordenada, gestión de derechos que funciona, auditoría de verdad e imputación honesta de costes pone un conjunto de agentes en producción este año. Una organización sin eso no está lenta por faltarle agentes. Está lenta porque ese cimiento nunca se construyó, y los agentes vuelven la falta medible de una forma que nada antes de ellos consiguió.
Escribimos algo parecido sobre el asistente que solo lee lo que el usuario puede leer y sobre qué ordenar antes de encender Copilot. El patrón se repite porque en el fondo no va de IA. Cada ola de automatización hace la misma pregunta a una organización, y la hace cada vez más alto: ¿sabe quién puede hacer qué, y puede probar qué se hizo?
Los agentes son la versión más alta de esa pregunta hasta hoy. Son también la primera que la va a repetir varios cientos de veces al día, sin cansarse, hasta que alguien responda.
