La identidad de los agentes de IA ya es un problema de IAM. Y de auditoría

El problema no es que haya agentes de IA. El problema es que ya tienen identidad operativa y demasiadas organizaciones siguen gestionandolos como si fuesen un token con esteroides.

Un agente que consulta un CRM, lanza una orden en un ERP, abre un ticket, resume un correo sensible o decide que transaccion merece revision manual no es solo una funcion automatizada. Es un sujeto tecnico con permisos, contexto, memoria, credenciales y capacidad de accionar. En otras palabras: una identidad no humana con radio de impacto real. Si tu programa de IAM todavia distingue entre empleados, proveedores y “cuentas de servicio”, pero no sabe donde encajan los agentes de IA, ya tienes una brecha de gobierno aunque aun no tengas un incidente.

La cuestion se ha vuelto urgente este año por una razon bastante prosaica: la adopcion de agentes ha corrido mas rapido que la disciplina de control. Se despliegan copilotos internos, orquestadores RAG, bots con acceso a SaaS y asistentes de operaciones como si fuesen simples integraciones. Luego llega auditoria, o peor, llega un incidente, y aparece la pregunta que nadie queria contestar: quien autorizo exactamente a este agente a hacer esto, con que privilegios, usando que credencial, y donde esta la traza completa de sus decisiones y acciones.

Aqui NIST ha sido mas util que grandilocuente. El AI Risk Management Framework no impone obligaciones legales, pero si deja una idea que el mercado ya no puede esquivar: los sistemas de IA deben gobernarse como sistemas socio-tecnicos con funciones de gobierno, mapeo, medicion y gestion. Trasladado al terreno de identidad, eso significa que el agente no puede vivir fuera del perimetro de GOV, IDENTIFY y PROTECT del NIST CSF 2.0. Y en Europa, menos aun: DORA exige marcos de gestion del riesgo TIC y controles de seguridad, NIS2 eleva el liston de la gestion de accesos y el GDPR complica cualquier escenario en el que el agente trate datos personales sin necesidad, base de control o trazabilidad suficiente.

La ironia es evidente. Llevamos anos diciendo que hay demasiadas identidades no humanas: service accounts olvidadas, claves hardcodeadas, certificados sin inventario, tokens de API eternos. Ahora anadimos una capa nueva: identidades que no solo autentican peticiones, sino que encadenan decisiones, llaman herramientas, retienen contexto y actuan en nombre de alguien. Si eso no entra en IAM, PAM, logging y control interno, acabara entrando por la puerta de incident response.

No es automatizacion clasica: un agente combina identidad, contexto y capacidad de accion

Una cuenta de servicio tradicional ejecuta una tarea definida. Un agente de IA, en cambio, suele operar con cuatro rasgos que complican su gobierno.

Primero, usa varias credenciales de forma indirecta. Puede autenticarse con una identidad propia en el orquestador, consumir un secreto de vault para llamar a un CRM, apoyarse en OAuth para acceder a correo y usar un token temporal para invocar un modelo o una base vectorial. Si quieres reconstruir quien hizo que, la cadena de identidad no es lineal.

Segundo, su autorizacion cambia segun contexto. Un agente puede tener permiso para leer contratos, pero solo en un flujo de procurement; o para abrir tickets, pero no cerrarlos; o para recomendar un bloqueo de usuario, pero no ejecutarlo. El minimo privilegio ya no es una matriz estatica de roles. Requiere politicas granulares, condicionadas y, en algunos casos, efimeras.

Tercero, genera acciones derivadas que no siempre estaban previstas al disenar el acceso inicial. Un agente conectado a herramientas puede pasar de “consultar” a “actuar” por simple ampliacion de capacidades. Hoy lee Slack; manana crea un canal, invita externos y envia un resumen con datos sensibles. El desliz de permisos no siempre llega por mala fe. A veces llega por entusiasmo de producto.

Cuarto, produce resultados que afectan a decisiones de negocio y control. Si un agente clasifica alertas, prioriza pagos, sugiere bloqueos o redacta respuestas regulatorias, su actividad entra en el territorio de la evidencia y la responsabilidad. Ya no basta con saber que la API respondio 200 OK.

Este cambio de naturaleza importa porque obliga a tratar al agente como una identidad no humana de alto riesgo, no como un accesorio de integracion. Y eso exige un modelo propio de ciclo de vida: alta, aprobacion, asignacion de permisos, vinculo a propietario, monitoreo, recertificacion y revocacion.

Lo que NIST si esta diciendo, aunque no use el lenguaje de tu auditor

El AI RMF de NIST gira sobre cuatro funciones: Govern, Map, Measure y Manage. No es un manual de IAM, pero si ofrece un marco util para aterrizar controles. La clave para CISOs y compliance officers europeos esta en leerlo con gafas de identidad y no solo de “riesgo de modelo”.

En Govern, NIST insiste en estructuras de responsabilidad, politicas, procesos y supervision. Traducido: cada agente debe tener propietario de negocio, propietario tecnico y criterio formal de aprobacion. Si una organizacion no puede asignar un owner claro a un agente con acceso a datos o sistemas productivos, ese agente no deberia pasar a produccion. No por purismo. Porque despues nadie firma la recertificacion ni asume la revocacion.

En Map, el marco pide entender contexto, finalidad, actores y flujos de impacto. Eso obliga a inventariar no solo el modelo, sino las herramientas conectadas, las fuentes de datos, los usuarios en cuyo nombre opera el agente y las decisiones que puede influir o ejecutar. El inventario de activos del NIST CSF 2.0 en ID.AM encaja aqui de forma natural: si el agente no aparece como activo, identidad y dependencia, sera invisible justo cuando haga falta medir su riesgo.

En Measure, el punto no es solo evaluar sesgo o precision. Tambien hay que medir comportamiento operacional: que permisos usa de verdad, cuantas llamadas privilegiadas realiza, a que datos accede, cuantas excepciones de politica provoca, cuantos secretos consume y con que frecuencia falla la trazabilidad. Lo que no se mide en telemetria acaba maquillado en presentaciones.

En Manage, NIST habla de tratamiento, respuesta y mejora continua. Llevado a IAM, eso significa rotacion de credenciales, reduccion de permisos, desactivacion automatica por inactividad, limitacion de herramientas, aislamiento por entorno y kill switch. Si un agente se comporta de forma anomala, la organizacion debe poder degradar sus permisos o apagarlo sin tener que abrir un war room para descubrir donde se desplego.

El NIST CSF 2.0, publicado en febrero de 2024, ayuda a convertir estas ideas en lenguaje de seguridad operativo. Su funcion Govern exige que el riesgo de ciberseguridad se incorpore al gobierno corporativo. Identify pide inventario y comprension del contexto organizativo. Protect cubre gestion de identidades, autenticacion, autorizacion y control de acceso. No menciona “agentes de IA” en cada subcategoria, claro. Tampoco hacia falta. El mensaje es bastante transparente: si una entidad introduce nuevos actores digitales con acceso a procesos y datos, debe meterlos dentro del mismo sistema de control, no fuera de balance.

El angulo europeo: DORA, NIS2 y GDPR no hablan de moda, hablan de control

En Europa la discusion deja de ser academica muy rapido. Un agente de IA con privilegios puede chocar a la vez con resiliencia operativa, seguridad de red y sistemas, y proteccion de datos. Tres departamentos. Tres marcos. El mismo dolor.

DORA, aplicable plenamente desde el 17 de enero de 2025, obliga a las entidades financieras a mantener un marco solido, integral y bien documentado de gestion del riesgo TIC. El articulo 6 exige ese marco; el articulo 8 se centra en identificacion, clasificacion y documentacion de funciones, activos TIC y dependencias; el articulo 9 trata la proteccion y prevencion, incluyendo politicas y procedimientos de seguridad TIC, control de acceso, gestion de identidades y mecanismos de autenticacion robustos; y el articulo 10 aborda deteccion. Si un agente con acceso a sistemas de una entidad financiera no esta identificado como activo y dependencia, no tiene un perfil de acceso formalizado y no deja huella suficiente para deteccion y respuesta, el problema no es teorico: es de cumplimiento.

Ademas, DORA endurece el foco sobre terceros TIC en los articulos 28 a 30. Eso importa porque muchos agentes se apoyan en modelos alojados por terceros, herramientas SaaS y brokers de API. No basta con revisar el proveedor del modelo. Hay que mapear toda la cadena: orquestador, vector store, sistema de observabilidad, plataforma de secretos, herramientas conectadas y cualquier subprocesador que pueda ver prompts, respuestas o metadatos. En el papel, muchos programas de third-party risk management todavia evalúan al “proveedor de IA” como si fuese una caja unica. En la practica, es una muneca rusa.

NIS2, por su parte, obliga en su articulo 21 a adoptar medidas tecnicas, operativas y organizativas adecuadas y proporcionadas para gestionar los riesgos que amenazan la seguridad de las redes y sistemas de informacion. El propio articulo 21 enumera aspectos muy concretos: analisis de riesgos, gestion de incidentes, continuidad, seguridad de la cadena de suministro, politicas y procedimientos para evaluar la eficacia de las medidas, higiene cibernetica, criptografia y seguridad de recursos humanos, control de acceso y gestion de activos. Si tu organizacion es entidad esencial o importante y despliega agentes con acceso a procesos criticos, tratarlos como un experimento al margen de estos controles seria una forma bastante creativa de incumplir.

El GDPR tampoco se queda quieto. Si el agente trata datos personales, entran en juego varios articulos a la vez. El articulo 5.1.c impone minimizacion de datos. El articulo 5.1.f exige integridad y confidencialidad. El articulo 25 obliga a proteccion de datos desde el diseno y por defecto. El articulo 32 exige medidas tecnicas y organizativas apropiadas, entre ellas la capacidad de garantizar confidencialidad, integridad, disponibilidad y resiliencia. El articulo 30 complica la vida a quien no tenga claro en que tratamiento encaja el agente y que categorias de datos toca. Y si el agente provoca una violacion de seguridad de los datos personales, el reloj de 72 horas del articulo 33 no se detiene porque la causa haya sido una mala configuracion de permisos en una herramienta “innovadora”.

Hay un detalle que suele escaparse: la trazabilidad del agente no solo importa para seguridad, sino para demostrar licitud y responsabilidad proactiva. Si el agente resume correos de clientes, accede a historiales de soporte o prepara respuestas con datos de empleados, necesitas poder probar por que tuvo acceso, que datos podia ver, durante cuanto tiempo, con que restricciones y quien aprobo esa configuracion. Sin eso, la defensa habitual de “fue una automatizacion interna” vale poco.

La explosion de identidades no humanas no empezo con la IA, pero la IA la desordena

Las identidades no humanas llevan anos multiplicandose. Cuentas de servicio, certificados de workload, claves de API, secretos en pipelines, bots de RPA, conectores SaaS, funciones serverless, robots de test. La IA no inaugura el problema. Lo acelera y lo vuelve menos visible.

Antes, una cuenta de servicio solia tener una funcion relativamente acotada. Hoy un agente puede encadenar varias: consultar una base de conocimiento, leer una cola, buscar en CRM, pedir aprobacion en Teams, invocar una API de pagos sandbox y dejar un registro en GRC. Cada salto puede usar credenciales distintas, scopes distintos y mecanismos de autorizacion distintos. Resultado: mas superficie, mas complejidad y mas probabilidad de privilegios sobrantes.

Tambien cambia el patron de crecimiento. Las identidades humanas crecen con altas de personal. Las no humanas crecen con iniciativas, integraciones y pruebas. Y los agentes crecen, ademas, con la facilidad del prototipado. Un equipo de negocio monta un copiloto con herramientas conectadas en dias, no en meses. Si seguridad e IAM llegan al final, el acceso ya existe, el caso de uso ya es popular y el “no” llega con retraso. Mala combinacion para cualquier gobierno serio.

La consecuencia practica es que el inventario tradicional se queda corto. No basta con contar service accounts o secretos en un vault. Hay que modelar relaciones: que agente existe, que version del workflow ejecuta, sobre que modelo se apoya, a que herramientas llama, con que identidad base, en nombre de que usuario o sistema, y en que entorno. Sin ese grafo de dependencias, el control de acceso es una foto borrosa.

Los cinco controles que separan un agente util de un hallazgo de auditoria

La teoria regulatoria sirve de poco si no aterriza en controles verificables. Para identidades de agentes de IA, hay cinco bloques que marcan la diferencia.

1. Autenticacion fuerte y separacion de identidades

Un agente no debe reutilizar credenciales humanas ni compartir una identidad generica con otros agentes. Cada agente productivo necesita una identidad unica, vinculada a un repositorio, un flujo o una aplicacion concreta y a un propietario claro. Si el proveedor soporta workload identity federation, mejor que secretos estaticos. Si no, la alternativa razonable es secreto en vault con rotacion automatizada y alcance minimo.

Esto parece obvio, pero aun se ven despliegues donde el agente usa la cuenta OAuth del desarrollador que lo configuro, o una API key compartida entre entorno de desarrollo y produccion. El primer incidente convierte esa comodidad en prueba documental de que el control no existia.

La autenticacion fuerte aqui no es solo MFA, que a menudo ni aplica a un workload. Es usar mecanismos adecuados para identidades de maquina: certificados, tokens de corta duracion, federacion de identidad de workloads, managed identities y validacion mutua entre servicios. Lo relevante es eliminar credenciales persistentes que sobreviven mas que el caso de uso.

2. Autorizacion de minimo privilegio, de verdad, no en PowerPoint

El minimo privilegio para agentes exige bajar al nivel de accion. “Acceso al CRM” no significa nada. Hay que decidir si el agente puede leer contactos, actualizar casos, crear tareas, descargar adjuntos o ejecutar consultas amplias. Y si un agente actua en nombre de un usuario, conviene separar dos capas: lo que el usuario puede hacer y lo que el agente puede hacer por delegacion.

Una practica sensata es definir permisos por herramienta y verbo: leer, crear, modificar, borrar, aprobar, exportar. Otra, imponer aprobacion humana para acciones irreversibles o financieramente relevantes. Si el agente puede preparar un pago, pero no ejecutarlo; o redactar una respuesta al regulador, pero no enviarla; ya has reducido bastante el radio de desastre sin matar el caso de uso.

En entornos maduros, esto se implementa con policy-as-code y scopes efimeros emitidos por flujo. En entornos menos sofisticados, al menos con roles separados por entorno y capacidades capadas en produccion. Lo que no funciona es asignar permisos amplios “para que el piloto no falle” y prometer que se endureceran despues. Despues suele ser nunca.

3. Rotacion y gestion de credenciales con caducidad real

Los agentes acumulan secretos como los cajones acumulan cargadores viejos. API keys para el LLM, tokens del buscador empresarial, credenciales del ticketing, certificado del webhook, secreto del conector de correo. Si esa coleccion no rota de forma automatizada y trazable, el riesgo no es hipotetico.

La regla operativa deberia ser simple: ningun secreto estatico sin fecha de expiracion y sin owner. Si la plataforma permite tokens de vida corta, usalos. Si exige claves largas, metelas en un gestor de secretos con rotacion programada y alertas de expiracion. Y no mezcles secretos entre entornos. Un fallo de desarrollo no deberia abrir una puerta lateral a produccion.

Para auditoria, la evidencia util no es un PDF con una politica preciosa. Son logs de rotacion, inventario de secretos por agente, excepciones aprobadas con fecha de caducidad y pruebas de que una credencial revocada deja al agente sin capacidad de accion. Sin esa ultima prueba, la revocacion es una declaracion de intenciones.

4. Trazabilidad completa: quien invoco, que decidio, que herramientas uso y que cambio

Este es el control mas infravalorado. Muchas organizaciones registran prompts y respuestas, pero no la cadena de decisiones ni las acciones ejecutadas. Para gobernar agentes hace falta enlazar, al menos, estos elementos: identidad del agente, usuario o sistema solicitante, herramientas invocadas, credenciales o scopes utilizados, datasets consultados, accion realizada, resultado, marca temporal sincronizada y decision humana si existio aprobacion.

Si falta uno de esos eslabones, el analisis forense se vuelve una novela experimental. Sabras que algo paso, pero no como ni con que permisos exactos.

La trazabilidad ademas cumple tres funciones distintas. Sirve para seguridad, porque permite detectar abuso o comportamiento anomalo. Sirve para cumplimiento, porque demuestra control y responsabilizacion. Y sirve para operaciones, porque ayuda a depurar por que un agente hizo algo inesperado. Quien trate esto solo como logging tecnico se esta perdiendo dos tercios del valor.

Hay un matiz delicado con privacidad: registrar demasiado tambien puede generar riesgo. Los logs del agente no deberian convertirse en un lago de datos personales innecesarios. Conviene separar telemetria de acceso y accion de contenido sensible, aplicar minimizacion y definir periodos de retencion. Gobernar identidades de agentes sin gobernar sus logs seria media solucion.

5. Revocacion y kill switch sin teatro

Todo agente con acceso a sistemas o datos relevantes necesita un mecanismo de revocacion inmediata. No solo para when things go sideways, tambien para fin de proyecto, cambio de proveedor, baja de herramienta o rotacion de ownership. Si el agente depende de cinco integraciones, la revocacion debe cubrir las cinco, no solo la identidad principal.

La prueba de fuego es sencilla: si el responsable de seguridad pidiera desactivar ahora mismo el agente, cuanto tardarias en dejarlo sin acceso efectivo a todas sus herramientas? Cinco minutos, dos horas o una semana de mensajes cruzados entre platform, IAM y negocio? La respuesta real dice mas de tu control que cualquier politica.

Un kill switch serio combina desactivacion de la identidad principal, revocacion de secretos derivados, anulacion de scopes, despublicacion de conectores y bloqueo de rutas de red o de egress si hace falta. Si solo deshabilitas la interfaz, pero la automatizacion de fondo sigue pudiendo llamar APIs, no has apagado el agente; has apagado la pantalla.

Lo que deberia pedir un auditor, y lo que deberias tener listo antes de que lo pida

Cuando un auditor interno, un equipo de segunda linea o un supervisor sectorial pregunte por agentes de IA, no buscara poesia. Buscara evidencia. Y la evidencia tiene que sobrevivir a preguntas bastante concretas.

Primera: inventario. Cuantos agentes existen en desarrollo, pruebas y produccion; quien es su owner; que sistemas y datos tocan; que terceros intervienen; y que clasificacion de criticidad tienen. En una entidad bajo DORA, esta pregunta enlaza con el articulo 8 sobre identificacion y clasificacion de activos y funciones.

Segunda: alta y aprobacion. Existe un flujo documentado para crear un agente con acceso? Quien valida la necesidad de negocio, los permisos, la base legal de datos si aplica y la arquitectura tecnica? Si el agente cambia de alcance, hace falta reaprobacion? Sin ese gate de cambio, el scope creep queda institucionalizado.

Tercera: autorizacion granular. Puede demostrarse que el agente solo dispone de los permisos necesarios? Hay segregacion entre lectura y escritura, entre recomendacion y ejecucion, entre sandbox y produccion? Bajo ISO/IEC 27001:2022, el Anexo A incluye controles directamente conectados con esto, como A.5.15 sobre control de acceso, A.5.16 sobre gestion de identidades y A.5.18 sobre derechos de acceso.

Cuarta: monitoreo y logging. Donde se registran sus acciones? Cuanto tiempo se conservan los logs? Pueden correlacionarse con SIEM o con registros de aplicacion y API gateway? En terminos de NIS2 art. 21, esto toca tanto gestion de incidentes como evaluacion de la eficacia de las medidas de ciberseguridad.

Quinta: revocacion. Puede probarse con evidencia que al retirar acceso o eliminar la identidad el agente deja de operar? Hay registros de recertificacion periodica de permisos? Tienes agentes “huerfanos” cuyo owner ya no esta o cuyo caso de uso murio hace seis meses? Si la respuesta es si, el hallazgo ya se esta redactando solo.

Ejemplos operativos: donde suelen romperse las cosas

Veamos tres escenarios realistas, porque los principios sin friccion operativa suelen sonar mejor de lo que funcionan.

Copiloto interno de soporte con acceso a correo y CRM

El equipo de experiencia de cliente despliega un asistente que resume hilos de correo, busca incidencias previas y propone respuestas. Parece inocuo hasta que se conecta al buzón compartido y al CRM con permisos de lectura amplia. El agente empieza a procesar datos personales, historiales de reclamaciones y, a veces, documentos adjuntos con datos financieros.

Los controles minimos aqui son bastante concretos: acceso read-only salvo necesidad justificada, exclusiones de buzones sensibles, filtros por etiquetas o colas, tokenizacion o enmascarado cuando el prompt no necesite datos completos, y registro de cada consulta al CRM con identificador de agente y de usuario solicitante. GDPR art. 25 y 32 entran de lleno. Tambien la minimizacion del art. 5.1.c. Si el agente lee mas de lo que necesita para responder, ya vas tarde.

Agente de finanzas que reconcilia facturas y crea asientos preliminares

Aqui el riesgo ya no es solo de privacidad o seguridad. Es tambien de control financiero. El agente extrae datos, compara importes y propone asientos. Si ademas puede crear registros en el ERP, la segregacion de funciones se vuelve critica. Que el agente prepare no significa que deba contabilizar sin aprobacion.

Para una empresa cotizada o con controles internos exigentes, este escenario toca SOX de forma indirecta aunque la pieza no sea “de SOX”. La evidencia relevante incluye workflow de aprobacion, logs de cambios, limitacion de permisos a operaciones preliminares, y prueba de que el agente no puede modificar parametros maestros ni anular controles compensatorios. Si el agente tiene mas privilegios que un analista junior, alguien se ha saltado una conversacion incomoda.

Agente de ciberseguridad que investiga alertas y ejecuta contencion

Este es el caso favorito del mercado porque promete ahorrar tiempo al SOC. Y puede hacerlo. Pero es tambien el mas peligroso si se despliega con exceso de confianza. Un agente que consulta SIEM, EDR, inteligencia de amenazas y directorio corporativo, y que ademas puede aislar endpoints o bloquear cuentas, necesita una disciplina de PAM casi quirurgica.

Una arquitectura razonable separa investigacion de accion. El agente puede enriquecer alertas y recomendar contencion, pero las acciones disruptivas exigen aprobacion humana o reglas muy acotadas para casos definidos. Tambien conviene registrar la justificacion de la accion y el contexto de evidencia. Si bloqueas una cuenta por decision automatizada mal trazada, el incidente tecnico se convierte en incidente operativo y de gobernanza. Doble premio.

Tabla util: control, responsable, evidencia y urgencia

Checklist de evidencias para auditoria

Si el articulo toca un nervio auditado, mas vale ser practico. Estas son las evidencias que suelen resistir mejor una revision seria:

• Registro centralizado de agentes de IA con identificador unico, owner, entorno, finalidad, fecha de alta y fecha de ultima revision.
• Diagrama de arquitectura con herramientas conectadas, secretos consumidos, proveedores externos y flujos de datos.
• Matriz de permisos por agente y por herramienta, con justificacion de negocio y aprobador.
• Configuracion de autenticacion de workload o, en su defecto, inventario de secretos en vault con politica de rotacion y fecha de expiracion.
• Logs que enlacen solicitud, identidad del agente, usuario solicitante, accion ejecutada, sistema destino y resultado.
• Pruebas de recertificacion de accesos al menos anual, o con mayor frecuencia para agentes criticos.
• Prueba de revocacion efectiva: desactivacion de identidad, invalidez de tokens y bloqueo de llamadas posteriores.
• Evaluacion de impacto de proteccion de datos si el caso de uso lo requiere, o al menos analisis documentado de necesidad y minimizacion.
• Due diligence de terceros: proveedor del modelo, del orquestador, del vector store y de las herramientas conectadas, con clausulas de seguridad y tratamiento de datos.
• Registro de excepciones temporales con fecha de caducidad. Si una excepcion no caduca, no es una excepcion; es politica encubierta.

Implicaciones para entidades financieras europeas: DORA convierte este debate en control de primera linea

Para banca, seguros, pagos y otras entidades bajo DORA, la gobernanza de agentes de IA no puede quedarse en una iniciativa del laboratorio de innovacion. Debe entrar en el marco de riesgo TIC y en la documentacion de control interno.

Primero, porque los agentes suelen tocar funciones importantes o criticas antes de que nadie los llame asi. Un asistente que apoya onboarding, KYC, atencion al cliente, fraude o conciliacion ya esta cerca de procesos que impactan continuidad, integridad de informacion o cumplimiento regulatorio. DORA art. 8 obliga a identificar y clasificar activos y dependencias. Los agentes y sus conectores forman parte de ese mapa.

Segundo, porque la dependencia de terceros TIC se multiplica. Una entidad puede creer que usa “un modelo”, cuando en realidad depende de un proveedor cloud, un servicio de embeddings, un repositorio vectorial, una pasarela de herramientas y varios SaaS con OAuth. DORA art. 28 y siguientes obligan a gestionar ese riesgo de terceros con bastante mas rigor del que se ve en muchos pilotos.

Tercero, porque el reporting de incidentes puede complicarse. Si un agente con permisos excesivos provoca acceso indebido, alteracion de datos o indisponibilidad operacional, la organizacion necesitara reconstruir el incidente con rapidez. Sin trazabilidad, la clasificacion del incidente y la notificacion se vuelven mucho mas dolorosas. El supervisor no suele emocionarse con la frase “estamos investigando un comportamiento inesperado del agente”.

Cuarto, porque las funciones de control interno tendran que entender tecnicamente estas arquitecturas. Riesgo operacional, cumplimiento y auditoria interna no pueden limitarse a pedir una politica de IA y una demo del producto. Deben revisar identidades, permisos, secretos, logs y revocacion. Menos storytelling. Mas evidencia.

La objecion habitual: “pero si el agente actua siempre en nombre del usuario”

Es una objecion frecuente y, en parte, razonable. Si el agente opera con los permisos del usuario, podria pensarse que no hace falta tratarlo como identidad separada. Error a medias.

Incluso con delegacion, el agente sigue necesitando una identidad de ejecucion y un marco de control propio. Por tres razones. Una, porque puede actuar de forma asincrona o continuada cuando el usuario ya no esta presente. Dos, porque suele agregar herramientas y contexto que el usuario no opera manualmente de ese modo. Tres, porque la evidencia debe distinguir entre la voluntad del usuario y la accion automatizada concreta. “Lo pidio Ana” no explica por que el agente consulto cuatro sistemas, descargo dos adjuntos y escribio en un tercero.

La delegacion bien gobernada requiere, al menos, identidad separada del agente, vinculo fuerte con el usuario solicitante, scopes limitados, expiracion de sesion, y registro de consentimiento o accion de disparo. Si no, la trazabilidad se diluye y el control se vuelve nominal.

Lo que deberian hacer ya los CISOs y compliance officers en 2026

No hace falta montar un programa paralelo de “IAM para IA” como si fuese una religion nueva. Hace falta extender con disciplina los controles de identidad ya conocidos al nuevo tipo de actor.

Empieza por el inventario. No de modelos, sino de agentes con capacidad de accion y acceso. Si un agente toca datos personales, sistemas productivos o procesos de negocio relevantes, clasificalo como identidad no humana sujeta a control reforzado. Vinculalo a un owner y a un expediente de aprobacion.

Despues, revisa permisos reales, no permisos declarados. Que herramientas puede invocar? Que verbos puede ejecutar? Que secretos consume? Que acciones quedan bloqueadas sin aprobacion humana? Si no puedes responder a eso por cada agente productivo, la prioridad no es desplegar otro. Es arreglar el primero.

Luego mete telemetria donde duele. Correlaciona logs de agente, API gateway, IAM, vault, SIEM y sistemas destino. Define casos de uso de deteccion: uso fuera de horario esperado, expansion brusca de herramientas, picos de exportacion, llamadas fallidas repetidas, intentos de accion fuera de politica, uso de secretos proximos a expirar. La observabilidad de agentes no es un lujo de plataforma. Es control basico.

Y por ultimo, ensaya la revocacion. No la redactes. Pruebala. El dia que tengas que desactivar un agente por exposicion de credenciales, error de configuracion o salida de un proveedor, no querras descubrir dependencias ocultas en pleno incidente.

La tentacion en 2026 sigue siendo la misma: tratar la identidad de agentes de IA como un subtema tecnico del equipo que los construye. Seria comodo. Tambien seria un error. La identidad del agente ya es un asunto de IAM, de arquitectura, de cumplimiento, de riesgo operacional y de auditoria. En algunas entidades, incluso de consejo si el caso de uso toca procesos criticos.

La buena noticia es que los controles base no son exoticos. Autenticacion fuerte para workloads, minimo privilegio, secretos efimeros, trazabilidad, recertificacion y revocacion. Nada revolucionario. Lo revolucionario, si acaso, es aplicar esas viejas disciplinas antes de que el agente se convierta en tu empleado mas diligente, mas rapido y menos supervisado. Ya sabes como suele acabar esa combinacion.