La identidad de los agentes de IA ya es un problema de IAM: cómo gobernar cuentas, tokens y permisos antes de que lo haga el auditor

La mayoría de programas de IAM siguen obsesionados con el empleado humano. Alta, baja, MFA, revisión trimestral y a otra cosa. Mientras tanto, los agentes de IA, las service accounts, los tokens de acceso, los secretos embebidos en pipelines y las identidades de workload se han multiplicado sin pedir permiso al comité de riesgos. Luego llega la auditoría y hace la pregunta incómoda: ¿quién hizo exactamente esta acción crítica? Si la respuesta es “el sistema”, ya vas tarde.

Ese es el nuevo frente: la identidad no humana. Y dentro de ella, los agentes de IA añaden una capa especialmente incómoda porque no solo ejecutan tareas; encadenan herramientas, consumen datos, generan acciones y, en algunos casos, toman decisiones operativas con autonomía limitada o semiautónoma. Traducido a lenguaje de control interno: ya no basta con saber qué usuario lanzó un proceso. Hay que saber qué agente actuó, con qué credenciales, bajo qué política, contra qué sistemas, con qué datos y quién podía revocarlo en ese momento.

El NIST AI Risk Management Framework no te da una receta cerrada de IAM para agentes, pero sí deja claro el principio que importa: gobernanza, trazabilidad, medición y gestión de riesgo a lo largo del ciclo de vida del sistema de IA. Cruzado con NIST CSF 2.0, ahí aparece una conclusión bastante menos glamourosa que los demos de copilots: un agente de IA sin identidad gobernada es, en esencia, una cuenta privilegiada mal documentada con marketing encima.

Para CISOs y responsables de cumplimiento europeos, la cuestión ya no es teórica. DORA está plenamente aplicable desde el 17 de enero de 2025, NIS2 obliga a medidas de gestión del riesgo y control de accesos en su art. 21, e ISO/IEC 27001:2022 lleva años recordando en su Anexo A que el acceso debe limitarse, revisarse y trazarse. Si en 2026 tu organización está desplegando agentes que invocan ERP, CRM, repositorios de código, bases de datos o sistemas de pagos, necesitas tratarlos como identidades de alto impacto. No como “automatización”. Esa palabra suele ser la coartada favorita del desorden.

El error de diseño: tratar un agente de IA como si fuera una simple API key

El fallo más común no es técnico, sino conceptual. Un agente de IA no es solo un modelo ni solo una aplicación. Es una combinación de componentes: modelo, orquestador, memoria, conectores, herramientas, secretos, políticas de ejecución y registros. Cuando ese conjunto interactúa con sistemas corporativos, aparece una identidad operativa. Si esa identidad se implementa como una API key compartida, una service account genérica o un token de larga duración, acabas de convertir un problema moderno en una versión peor de un problema antiguo.

Peor por tres motivos.

Primero, porque la acción del agente suele ser encadenada. Un usuario pide algo en lenguaje natural, el orquestador interpreta, el agente consulta una base de conocimiento, luego llama a un sistema externo, después crea o modifica un registro. La trazabilidad se rompe si todos esos pasos comparten la misma credencial o si el sistema no registra el contexto completo de ejecución.

Segundo, porque el agente puede cambiar de comportamiento sin que cambie la identidad técnica. Basta alterar el prompt del sistema, el set de herramientas autorizadas, la política de decisión o el modelo subyacente. Eso significa que una misma service account puede representar riesgos distintos en momentos distintos. Tu revisión clásica de accesos cada tres meses no capta eso ni de lejos.

Tercero, porque el agente opera con una opacidad funcional que complica la rendición de cuentas. No basta con almacenar logs de autenticación. Necesitas enlazar identidad, instrucción recibida, herramienta invocada, datos accedidos, resultado devuelto y decisión posterior. Si no, tendrás trazabilidad del login, pero no de la conducta. Para investigar un incidente, eso vale bastante menos de lo que algunos proveedores sugieren en sus diapositivas.

El NIST CSF 2.0 encaja bien aquí. Su función Govern exige que la organización establezca políticas, roles y supervisión del riesgo de ciberseguridad; Identify obliga a conocer activos, dependencias y contexto; Protect cubre identidades, autenticación, control de acceso y gestión de credenciales. No es un mapa diseñado solo para IA, pero precisamente por eso sirve: baja el debate desde la fascinación por el modelo a la disciplina operativa. Y ahí se separan los programas maduros de los juguetes caros.

Qué cambia cuando la identidad no humana decide o actúa

Las identidades no humanas no son nuevas. Llevamos años conviviendo con cuentas de servicio, certificados, tokens OAuth, claves SSH, secretos de CI/CD, bots RPA y workloads en Kubernetes. Lo nuevo es la combinación de escala, dinamismo y capacidad de decisión contextual que traen los agentes de IA.

Un bot RPA normalmente sigue un flujo predefinido. Un agente de IA puede elegir entre varias herramientas, reintentar consultas, reformular instrucciones y producir acciones diferentes ante entradas parecidas. Eso eleva cuatro exigencias de control.

1. Autenticación fuerte ligada al workload, no a un secreto estático

Si el agente se autentica con una contraseña almacenada en un fichero de configuración o con una API key de larga duración, el control ya nace torcido. Lo sensato en 2026 es identidad de workload con credenciales efímeras, emisión just-in-time y atestación del entorno de ejecución cuando sea posible. En cloud, eso suele significar roles gestionados, tokens de corta vida, federación OIDC entre plataformas y secret managers con rotación automática. En entornos on-prem o híbridos, certificados de corta vigencia, cuentas dedicadas por servicio y vault centralizado.

La diferencia práctica es enorme. Un secreto robado con validez de 365 días es un regalo para un atacante y una pesadilla para forense. Un token de 15 minutos, emitido para un pod concreto o una función concreta, limita la ventana de abuso. Suena básico. Lo es. Y aun así sigue sin implantarse de forma homogénea porque demasiados despliegues de IA se hacen deprisa y con credenciales heredadas del equipo que montó la prueba de concepto.

2. Autorización granular y mínimo privilegio real

“Read/write” a un sistema entero no es una política de acceso; es pereza documentada. Un agente debe tener permisos por herramienta, por acción, por dataset y, cuando sea viable, por contexto transaccional. No todos los conectores merecen el mismo nivel de confianza. Un agente que resume tickets de soporte no necesita borrar usuarios en el directorio. Uno que redacta respuestas de compliance no necesita acceso directo a cuentas de producción. Parece obvio hasta que descubres que el agente corporativo usa la misma identidad para consultar SharePoint, Jira, GitHub y el CRM.

ISO/IEC 27001:2022 Anexo A es bastante menos tolerante con esa improvisación de lo que algunos creen. El control A.5.15 exige políticas y reglas de control de acceso; A.5.16 trata la gestión de identidades; A.5.17 habla de información de autenticación; A.8.2 se centra en el acceso privilegiado; A.8.3, en la restricción del acceso a la información. No hace falta que el texto diga “agente de IA” para que el auditor entienda el punto. Si una identidad técnica puede ejecutar acciones de alto impacto sin segmentación adecuada, el hallazgo cae por su propio peso.

3. Trazabilidad de acción, no solo de sesión

Un log de “token emitido” o “service account autenticada” no basta. Necesitas eventos que permitan reconstruir qué hizo el agente, por qué lo hizo y bajo qué autorización. Ahí conviene registrar, como mínimo, cinco piezas de evidencia por operación relevante: identidad del agente, identidad humana o de sistema que originó la solicitud, herramienta o API invocada, objeto afectado y resultado. Si además capturas versión del modelo, hash de prompt de sistema o policy bundle aplicado, mucho mejor. No por fetichismo técnico, sino porque cambia por completo tu capacidad de investigación.

GDPR ofrece un incentivo extra. El art. 5.1.f exige integridad y confidencialidad; el art. 24 obliga al responsable a aplicar medidas apropiadas; el art. 25 introduce protección de datos desde el diseño y por defecto; el art. 32 exige seguridad del tratamiento. Si un agente accede a datos personales o genera decisiones que afectan a individuos, la trazabilidad deja de ser una buena práctica de seguridad y pasa a ser un mecanismo defensivo de cumplimiento. Cuando llegue una reclamación o una brecha, necesitarás demostrar no solo que había control, sino que funcionó.

4. Revocación inmediata y kill switch operativo

Los usuarios humanos se desactivan. Los agentes también deberían. Y sin ceremonias. Cada agente con capacidad de actuar sobre sistemas críticos debería tener un mecanismo de revocación rápida: deshabilitar su identidad, retirar acceso a herramientas, invalidar tokens activos, bloquear su tráfico saliente o suspender el workflow. Si para apagar un agente tienes que abrir tres tickets y pedir ayuda a dos equipos, no tienes control operativo; tienes esperanza.

Esta exigencia conecta con DORA de forma bastante directa. El Reglamento (UE) 2022/2554 obliga a las entidades financieras a contar con un marco sólido de gestión del riesgo TIC y capacidades de respuesta y recuperación. El art. 6 establece el marco de gestión del riesgo TIC; el art. 9 trata protección y prevención, incluyendo políticas, procedimientos, protocolos y herramientas para minimizar el impacto de incidentes TIC; el art. 10 cubre detección. Si un agente con acceso privilegiado se comporta de forma anómala, la capacidad de revocación no es cosmética: es una medida de contención.

Por qué NIST AI RMF importa aunque no sea una norma de IAM

Quien lea el NIST AI RMF esperando un catálogo detallado de controles de gestión de identidades saldrá decepcionado. Quien lo lea bien entenderá algo más útil: los riesgos de IA no se gestionan solo en el modelo, sino en el sistema sociotécnico que lo rodea. Y la identidad forma parte de ese sistema.

El AI RMF gira alrededor de cuatro funciones: Govern, Map, Measure y Manage. Para el problema de identidades no humanas, las dos primeras son especialmente incisivas.

Govern obliga a definir accountability, procesos, políticas y cultura de riesgo. Si nadie es dueño del inventario de agentes, de su proceso de alta, de sus permisos o de su retirada, ya tienes un fallo de gobernanza. Y no, “eso lo lleva plataforma” no es una respuesta suficiente cuando el agente toca datos personales, sistemas financieros o procesos regulados.

Map exige contextualizar el sistema de IA: propósito, usuarios, impacto, dependencias, flujo de datos, interfaces y riesgos previsibles. Ese ejercicio debería desembocar en una decisión de IAM explícita. ¿El agente necesita identidad propia? Casi siempre sí. ¿Puede reutilizar una cuenta de servicio existente? Casi nunca debería. ¿Qué datos toca? ¿Qué herramientas puede invocar? ¿Qué nivel de supervisión humana exige? ¿Qué eventos deben registrarse? Si esas preguntas no se responden antes del despliegue, luego se responderán durante el incidente. Suele salir más caro.

NIST AI RMF también es útil porque evita un error frecuente: confiar en el control de acceso de la aplicación y olvidar el plano de orquestación. Muchos agentes se montan con frameworks que facilitan el uso de tools, plug-ins o function calling. Es práctico. También abre una superficie de abuso si el sistema no distingue entre permiso del usuario solicitante, permiso del agente ejecutor y permiso efectivo de cada herramienta. Esa separación debería modelarse desde diseño. Si no, el agente termina actuando con más privilegios que el usuario que originó la tarea. Un clásico del desastre moderno.

La intersección regulatoria europea: DORA, NIS2 y GDPR convergen más de lo que parece

No existe hoy una regulación europea que diga con esas palabras “todo agente de IA debe tener identidad propia con trazabilidad por acción”. Pero eso no significa vacío regulatorio. Significa algo más serio: varias normas ya imponen el resultado, aunque no usen esa etiqueta.

DORA: riesgo TIC, terceros y control operativo

Para entidades financieras, DORA ya no es horizonte; es presente desde enero de 2025. Si un agente de IA participa en procesos de negocio, atención al cliente, detección de fraude, desarrollo de software, operaciones internas o soporte, entra en el perímetro de gestión del riesgo TIC de la entidad en la medida en que afecte a funciones y activos TIC.

El art. 6 exige un marco interno sólido y documentado para gestionar el riesgo TIC. El art. 8 obliga a identificar, clasificar y documentar adecuadamente funciones, activos, roles y dependencias TIC. Ese verbo, documentar, es el que pincha la burbuja de muchas implementaciones de IA: un agente sin inventario, sin owner, sin clasificación por criticidad y sin mapa de dependencias incumple el espíritu y probablemente la letra del control. El art. 9 exige medidas de protección y prevención, entre ellas políticas de seguridad, control de acceso y gestión de identidades. DORA no enumera “IAM para agentes” como subcategoría autónoma, pero su lógica es inequívoca.

Hay otro ángulo menos comentado: terceros TIC. Si el agente consume LLMs externos, vector databases gestionadas, plataformas de automatización, navegadores remotos o conectores SaaS, la entidad debe mirar el art. 28 y siguientes sobre gestión del riesgo de terceros prestadores de servicios TIC. La identidad del agente no termina en tu directorio: también se materializa en tokens emitidos a proveedores, scopes API negociados en integraciones y permisos delegados fuera del perímetro directo. Si no puedes listar qué proveedores reciben credenciales o tokens del agente y con qué alcance, tu mapa de terceros está incompleto.

NIS2: medidas mínimas y responsabilidad de la dirección

NIS2, Directiva (UE) 2022/2555, eleva el listón para entidades esenciales e importantes. El art. 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas. Entre ellas figuran políticas de análisis de riesgos y seguridad de los sistemas de información, gestión de incidentes, continuidad, seguridad de la cadena de suministro y uso de criptografía y, de forma muy relevante aquí, seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas, incluida la gestión y divulgación de vulnerabilidades.

¿Dónde entra la identidad de agentes? En varios puntos. Un agente es software desplegado con dependencias, credenciales y acceso a sistemas; por tanto, forma parte del mantenimiento seguro y del control de acceso. También toca cadena de suministro cuando integra servicios de terceros o librerías open source. Además, NIS2 hace algo que a muchos consejos de administración todavía les cuesta digerir: en su art. 20 impone responsabilidades a los órganos de dirección en la aprobación y supervisión de las medidas de ciberseguridad. Eso significa que no basta con dejar la identidad no humana en manos de equipos técnicos sin un marco de gobierno. Si el riesgo es material, el board tiene que entenderlo, aprobar enfoque y supervisar ejecución. Sí, aunque “solo” sea un agente interno que automatiza aprobaciones de baja cuantía. Así empiezan muchas sorpresas desagradables.

GDPR: cuando el agente toca datos personales, el listón sube

En cuanto un agente accede a correos, expedientes, historiales de soporte, grabaciones transcritas o perfiles de clientes, GDPR entra en la habitación sin llamar. Los artículos más obvios son el 5, 24, 25 y 32, pero hay más derivadas.

Si el agente decide cómo priorizar casos o propone acciones sobre personas, puede aparecer el art. 22 sobre decisiones automatizadas, según el caso de uso y el grado real de intervención humana. Si hay una brecha derivada del uso indebido de credenciales del agente, el art. 33 obliga a notificarla a la autoridad de control en 72 horas si es probable que suponga un riesgo para los derechos y libertades de las personas físicas. Y para decidir eso no te ayudará mucho un log pobre que solo diga que una cuenta técnica accedió a 40.000 registros a las 03:12.

Aquí la identidad granular y la trazabilidad contextual reducen dos riesgos a la vez: el riesgo material de acceso indebido y el riesgo jurídico de no poder demostrar diligencia. A las autoridades les interesa el daño. También les interesa la gobernanza. Un entorno donde varios agentes comparten secretos, no hay separación entre entornos y nadie puede explicar qué modelo o conector accedió a qué dato tiene mala defensa, incluso aunque el incidente acabe siendo menor.

El inventario que casi nadie tiene: registrar agentes como activos con identidad, propósito y dueño

La primera señal de madurez no es una herramienta nueva. Es un inventario decente. Muchas organizaciones tienen CMDB, inventario de aplicaciones e incluso catálogo de APIs. Lo que no tienen es un registro fiable de identidades no humanas y, dentro de él, una clase específica para agentes de IA.

Ese inventario debería incluir, como mínimo, doce campos útiles de verdad: nombre único del agente; propietario de negocio; propietario técnico; entorno de ejecución; proveedor o modelo usado; herramientas o conectores autorizados; sistemas destino; tipo de credencial; método de emisión; alcance de permisos; clasificación de criticidad; y mecanismo de revocación. Si no puedes completar esos campos, el despliegue no está listo para producción, por mucho que el demo haya encantado al comité de innovación.

Hay una razón práctica para formalizarlo así: la mayoría de incidentes con identidades no humanas no nacen de un ataque sofisticado, sino de una combinación de permisos excesivos, secretos mal guardados y falta de owner claro. En una auditoría, eso aparece enseguida. En un incidente, aparece cuando ya es tarde.

NIST CSF 2.0 encaja otra vez por la vía de Identify: activos, dependencias, roles y criticidad. DORA art. 8 también: identificación y documentación de funciones, roles y activos TIC. ISO 27001 lo refuerza desde los controles organizativos y técnicos. No hace falta inventar una nueva doctrina. Hace falta aplicar la existente a objetos que demasiadas empresas todavía consideran “automatizaciones” y no identidades operativas con riesgo propio.

Controles de diseño que separan un despliegue serio de una demo peligrosa

Cuando se baja al terreno, el gobierno de identidades de agentes se puede resumir en una pregunta: ¿qué impediría que este agente haga algo que no debería, y qué evidencia tendríamos si lo intenta? Si la respuesta depende de que “el prompt lo desaconseja”, estás confiando en el lugar equivocado.

Identidad única por agente y por entorno

Nunca reutilices la misma identidad para desarrollo, preproducción y producción. Tampoco para varios agentes con finalidades distintas. Un agente de conciliación financiera y uno de soporte interno no deberían compartir service account ni secretos. Parece burocracia; en realidad es la base para segmentar permisos, limitar blast radius y obtener logs útiles.

Delegación acotada al usuario solicitante

Si el agente actúa en nombre de un empleado, conviene distinguir tres capas: el usuario origen, el agente ejecutor y el sistema destino. La autorización final debería respetar la intersección entre lo que el usuario puede hacer y lo que el agente está autorizado a automatizar. Si el usuario no puede aprobar una transferencia, el agente no debería poder hacerlo “por eficiencia”. Si el agente tiene permiso técnico superior al del usuario, necesitas una justificación formal, controles compensatorios y registros reforzados. Si no, estás creando privilegio lateral con una sonrisa de UX.

Tool gating y allowlisting

El agente no debería descubrir herramientas disponibles por accidente ni por conveniencia del framework. Define una allowlist explícita de tools por caso de uso. Para cada una, determina métodos permitidos, parámetros restringidos, límites de frecuencia y tipos de dato aceptables. Un conector a correo, por ejemplo, puede permitir lectura de mensajes de una cola específica, pero no envío libre a dominios externos. Un conector a base de datos puede exponer procedimientos almacenados controlados en lugar de SQL arbitrario. Esto es seguridad de aplicación, sí, pero también IAM práctico: reduces el permiso efectivo del agente aunque su autenticación sea válida.

Credenciales efímeras y rotación obligatoria

Las credenciales persistentes son deuda técnica con fecha de incidente pendiente. Para agentes, el estándar razonable en 2026 es: secretos almacenados en vault, emisión temporal cuando se pueda, rotación automática con cadencias definidas y revocación centralizada. Si un proveedor externo no soporta tokens cortos o rotación sencilla, anótalo como riesgo de tercero. DORA te pedirá justificar bastante más que una preferencia comercial.

Aprobación humana para acciones irreversibles o de alto impacto

No todas las tareas requieren humano en el bucle, pero algunas lo exigen por simple sentido de control. Cambios contables, pagos, modificación masiva de datos personales, alta de privilegios, borrado de repositorios, publicación de código en producción o respuesta regulatoria externa no deberían ejecutarse sin una segunda barrera. Esa barrera puede ser workflow de aprobación, step-up authentication o segregación funcional. Lo relevante es que el agente no tenga autonomía plena donde el error o abuso sea material.

Logs enlazables y resistentes a manipulación

Los registros deben permitir correlación entre petición, decisión y acción. Idealmente con IDs de transacción, sincronización temporal consistente, retención definida y protección frente a alteración. Si el agente utiliza varios servicios, centraliza logs o al menos normalízalos. La investigación de un incidente se hunde rápido cuando cada proveedor registra en un formato distinto, con zonas horarias distintas y sin un identificador común.

Escenarios operativos: dónde se rompe de verdad

Hablar de “agentes de IA” en abstracto sirve poco. El riesgo cambia mucho según el caso de uso.

Banca y pagos: el agente que reconcilia, clasifica o prepara acciones

Un agente que analiza excepciones en pagos, prepara expedientes KYC o redacta respuestas a alertas AML puede tocar datos sensibles, documentación regulatoria y sistemas de core banking. Aquí el mínimo privilegio debe ser quirúrgico. Lectura selectiva, escritura muy acotada, segregación por proceso y logs con conservación suficiente para revisiones internas y regulatorias. Bajo DORA, la entidad necesita poder demostrar que el riesgo TIC del agente está identificado, documentado y controlado. Si además hay proveedores de IA o plataformas de automatización externas, la gestión de terceros entra de lleno.

Escenario típico de fallo: service account compartida entre varios bots de operaciones, token API de seis meses, acceso amplio a un repositorio documental y ausencia de trazabilidad por expediente. Cuando salta una consulta del auditor sobre una decisión concreta, nadie puede distinguir si actuó el analista, el bot clásico o el nuevo agente con LLM. La tecnología del futuro, gestionada con disciplina de 2014.

Seguros: siniestros, fraude y atención al cliente

En seguros aparecen agentes que resumen documentación, proponen clasificaciones de siniestro, extraen datos de pólizas y redactan comunicaciones. Tocan datos personales y, a menudo, categorías especialmente delicadas según el ramo. GDPR exige diseño cuidadoso: acceso solo a los datos necesarios, segregación por función, mascarado cuando proceda y trazabilidad de consultas y modificaciones. Si el agente puede recomendar una acción con efecto relevante sobre el cliente, conviene revisar además el grado de automatización real y la supervisión humana efectiva.

Sanidad y salud digital: donde un secreto expuesto es algo más que un incidente de TI

Aunque la pieza esté orientada a responsables europeos y no a HIPAA como norma principal, el paralelismo es útil. En entornos clínicos o de salud digital, un agente que ayuda a clasificar documentación, resumir historiales o coordinar flujos administrativos debe operar con identidades extremadamente acotadas. El daño de una credencial expuesta no es solo reputacional o regulatorio; puede afectar asistencia, confidencialidad clínica y seguridad del paciente. Si el despliegue mezcla herramientas SaaS, modelos externos y conectores internos, la gobernanza de identidad deja de ser soporte y se convierte en control crítico.

Desarrollo de software y DevSecOps: el agente con acceso al repositorio, al pipeline y al secreto equivocado

Este es uno de los escenarios más traicioneros. El agente revisa pull requests, abre issues, genera tests, propone cambios de infraestructura o interactúa con runners de CI/CD. Si su identidad tiene acceso de escritura a repositorios, artefactos o secretos del pipeline, una mala configuración puede convertirse en vector de supply chain interno. NIS2 art. 21 toca aquí de lleno por desarrollo y mantenimiento seguro. El control clave es separar lectura, propuesta y ejecución, evitando que el agente una en una sola identidad lo que debería estar segmentado entre revisión, aprobación y despliegue.

Checklist de evidencias para auditoría

Esta es una de las pocas listas que sí merece existir, porque el problema es auditable y las evidencias no se improvisan la semana antes de la revisión.

• Inventario actualizado de agentes de IA e identidades no humanas asociadas, con owner de negocio y owner técnico.
• Matriz de permisos por agente, herramienta, sistema destino y tipo de acción permitida.
• Política de emisión, almacenamiento, rotación y revocación de credenciales para service accounts, tokens y certificados.
• Pruebas de segregación entre entornos de desarrollo, preproducción y producción.
• Registros de aprobación para accesos privilegiados o excepciones al mínimo privilegio.
• Evidencia de revisiones periódicas de acceso, con fecha, responsables y remediación de hallazgos.
• Logs de actividad enlazables que muestren identidad del agente, originador de la solicitud, herramienta invocada, recurso afectado y resultado.
• Procedimiento de respuesta para deshabilitar un agente o revocar credenciales en caso de incidente.
• Evaluación de proveedores y terceros TIC que reciben o gestionan credenciales del agente, alineada con DORA art. 28 y siguientes cuando aplique.
• Documentación de privacy by design y evaluación de riesgo si el agente trata datos personales, conectable con GDPR arts. 24, 25 y 32.

Si tu organización no puede producir al menos la mitad de estas evidencias en 48 horas, el problema no es el auditor. El problema es que no gobierna de verdad sus identidades no humanas.

Implicaciones para entidades financieras españolas

En España, el mensaje es especialmente incómodo para banca, seguros, EDEs, EAFs, gestoras y proveedores fintech que viven ya bajo una combinación de supervisión prudencial, DORA, GDPR y, según el caso, NIS2 vía transposición nacional. El patrón que se observa este año es claro: el negocio quiere agentes que hagan más cosas, más rápido y en más sistemas. Cumplimiento y seguridad, en cambio, siguen midiendo controles con taxonomías pensadas para usuarios humanos y aplicaciones tradicionales.

Ahí hay un desfase. Y ese desfase no se resuelve renombrando service accounts como “AI workers”. Se resuelve metiendo los agentes en los procesos formales que sí pasan auditoría: alta de identidad, clasificación de criticidad, aprobación de accesos, registro de excepciones, revisión periódica, control de terceros, pruebas de revocación y trazabilidad operativa. Para una entidad española, además, hay una derivada práctica: la interlocución con supervisores y auditoría interna será mucho más sencilla si el lenguaje de control se alinea con marcos reconocibles. NIST AI RMF sirve para estructurar el riesgo; NIST CSF 2.0 para organizar funciones; DORA y GDPR para justificar exigencias concretas; ISO 27001 para aterrizar controles. Eso es mucho más defendible que un “nuestro proveedor dice que el agente es seguro por diseño”.

Otro punto clave: los agentes que operan sobre procesos externalizados o sobre proveedores cloud no eliminan responsabilidad. La redistribuyen mal si no se gestiona. DORA no permite una amnesia selectiva porque el token se emita fuera de tu centro de datos. Si el agente usa credenciales contra servicios de terceros, esa cadena debe estar mapeada, contractualizada y sujeta a monitorización. El regulador financiero europeo lleva años repitiendo que externalizar no equivale a externalizar la responsabilidad. Y, por una vez, no está repitiendo por inercia.

Lo que deberían hacer CISO y compliance ahora mismo, sin esperar a la siguiente moda

La prioridad no es comprar otra plataforma. Es poner orden en cuatro decisiones de gobierno.

La primera: decidir quién aprueba la creación de agentes con acceso corporativo y bajo qué criterios. Si cualquier equipo puede desplegar uno con una API key y un conector a sistemas internos, el problema ya existe aunque todavía no haya estallado.

La segunda: fijar una política de identidad para agentes. Debe cubrir naming, ownership, autenticación permitida, duración máxima de credenciales, segregación de entornos, mínimos de logging, revisión de permisos y mecanismos de revocación. Una política breve y aplicable vale más que una enciclopedia que nadie usa.

La tercera: integrar a los agentes en IAM/PAM y en el inventario de activos. No como nota al pie, sino como objeto gobernado. Eso implica revisiones de acceso, monitorización de privilegios, alertas por comportamiento anómalo y retirada formal cuando el agente deja de operar. Si tu PAM solo mira administradores humanos y tu IAM solo mira empleados, te faltan precisamente las identidades que más están creciendo.

La cuarta: exigir evidencia a producto, datos y arquitectura. Antes de pasar un agente a producción, pide inventario de herramientas, matriz de permisos, esquema de trazabilidad, fuente de credenciales, flujo de aprobación y kill switch. Si el equipo no puede entregarlo, el despliegue no está maduro. No es freno a la innovación. Es evitar que la innovación aterrice con privilegios de superusuario y memoria de pez.

La tesis incómoda: el verdadero riesgo no es que la IA piense demasiado, sino que acceda demasiado

Buena parte del debate público sobre IA sigue girando alrededor de sesgos, alucinaciones o seguridad del modelo. Todo eso importa. Pero para un CISO o un responsable de cumplimiento, el riesgo más inmediato y explotable suele ser más prosaico: una identidad no humana mal gobernada con acceso amplio a sistemas valiosos.

Eso explica por qué el problema merece atención ahora, en 2026. Porque la adopción de agentes avanza más rápido que la adaptación de los controles de IAM. Porque los marcos relevantes ya existen, aunque no pronuncien la palabra mágica en cada párrafo. Porque DORA, NIS2, GDPR, ISO 27001 y NIST CSF 2.0 convergen en algo muy sencillo: conocer quién accede a qué, con qué permiso, bajo qué supervisión y con qué evidencia.

Los agentes de IA no necesitan trato especial por capricho. Lo necesitan porque combinan autonomía operativa, escala y opacidad suficiente como para agravar fallos clásicos de identidad. Si tu organización los sigue administrando como credenciales sueltas conectadas a herramientas vistosas, la pregunta no es si tendrás un hallazgo de auditoría o un incidente. La pregunta es cuál llegará primero.

Aquí está el quid. La identidad de un agente de IA no es un detalle de implementación. Es control interno, es seguridad operativa y, cada vez más, es cumplimiento demostrable. Gobernarla bien no hará titulares. Gobernarla mal, en cambio, tiene un talento especial para producirlos.