Cyber IA
Identidad de agentes de IA: el nuevo frente de IAM para unas máquinas que ya actúan por su cuenta
Por Redacción CyberComplianceAI23 min lectura
Ultima revision
9 de julio de 2026
Imagen generada por IAUltima revision
9 de julio de 2026
Imagen generada por IALa discusión sobre IA en seguridad suele atascarse en sesgos, alucinaciones o uso aceptable. Todo eso importa. Pero hay un problema mucho más pedestre y bastante más urgente: ya hay agentes de IA actuando en sistemas corporativos con credenciales, permisos y capacidad de tocar datos, y muchas organizaciones siguen tratándolos como si fueran un script más con esteroides.
No lo son. Un agente de IA no es solo software. Es software con iniciativa operativa delegada: consulta sistemas, invoca herramientas, toma decisiones dentro de un margen, encadena acciones y, en demasiados casos, lo hace con secretos persistentes, service accounts sobredimensionadas y una trazabilidad mediocre. Si eso no te suena a crisis de IAM en cámara lenta, conviene revisar el programa de control de accesos antes de que lo haga un auditor. O un atacante.
La cuestión de fondo es sencilla: la identidad no humana se ha disparado y la IA acelera el problema. Ya no hablamos solo de cuentas de servicio, claves API y certificados máquina a máquina. Ahora hablamos también de agentes que leen un buzón, extraen datos de un CRM, consultan un repositorio, redactan una respuesta, abren un ticket y lanzan una transacción a través de una API. Cada uno de esos pasos exige autenticación, autorización, registro, supervisión y revocación. Si falta uno, no tienes automatización avanzada. Tienes riesgo operacional con marketing.
Aquí es donde varias piezas regulatorias y de buenas prácticas convergen de forma bastante menos abstracta de lo que parece. El NIST AI Risk Management Framework empuja a gobernar los sistemas de IA según contexto, impacto y ciclo de vida. NIST CSF 2.0 coloca el gobierno, la identificación de activos y la protección de identidades en el centro. ISO/IEC 27001:2022, en su Anexo A, aterriza controles de gestión de identidades, autenticación y derechos de acceso. DORA obliga a las entidades financieras a controlar el riesgo TIC con disciplina bastante menos poética y bastante más auditable. El mensaje combinado es incómodo, pero útil: si un agente puede actuar, debe tener una identidad gobernada como cualquier otro actor con acceso. Sin atajos.
La mayoría de los programas de IAM nacieron pensando en empleados, administradores, terceros y, en el mejor de los casos, en cuentas de servicio. El modelo mental era binario: humano o máquina. La IA revienta esa comodidad. Un agente no humano puede ejecutar acciones no deterministas dentro de una política determinada. Eso cambia tres cosas.
La primera es la superficie de riesgo. Una cuenta técnica clásica hace siempre lo mismo o algo muy acotado. Un agente orquestado con herramientas puede hacer varias cosas, en secuencia, según entradas cambiantes. Si el modelo recibe una instrucción manipulada, una recuperación de contexto contaminada o una herramienta mal delimitada, el problema no es solo el modelo. Es la identidad que le permite actuar.
La segunda es la atribución. Cuando un usuario pulsa un botón en un ERP, la responsabilidad es más fácil de reconstruir. Cuando un agente decide qué acción tomar a partir de un prompt, un set de políticas, una recuperación RAG y un catálogo de herramientas, la organización necesita conservar evidencia de qué identidad ejecutó qué, con qué autorización, en nombre de quién, sobre qué datos y con qué resultado. Si ese hilo se pierde, la auditoría deja de ser auditoría y se convierte en arqueología.
La tercera es la gobernanza del privilegio delegado. Muchos agentes operan “por cuenta de” un usuario o de una función de negocio. Esa delegación no puede resolverse con un token largo y una oración. Necesita límites: alcance, duración, contexto, datos permitidos, herramientas accesibles y condiciones de revocación. El principio de mínimo privilegio deja de ser una recomendación elegante y pasa a ser la diferencia entre una automatización útil y un incidente notificable.
NIST AI RMF no prescribe un control concreto de IAM, pero sí deja clara la necesidad de gobernanza, medición y gestión de riesgos en sistemas de IA a lo largo del ciclo de vida. En la práctica, eso obliga a responder preguntas muy prosaicas: ¿qué identidades usan tus agentes?, ¿quién las aprueba?, ¿qué secretos consumen?, ¿cuánto duran?, ¿cómo se revocan?, ¿qué logs dejan? Si no puedes responderlas sin reunir a cinco equipos y abrir veinte pestañas, el problema ya existe.
Conviene no esperar a que una norma enumere expresamente “AI agents” para empezar a gobernarlos. La regulación relevante ya cubre la sustancia del problema.
En NIST CSF 2.0, la función GOVERN obliga a definir políticas, roles, responsabilidades y apetito de riesgo de ciberseguridad; IDENTIFY exige inventariar activos y comprender su contexto; PROTECT cubre la gestión de identidades, autenticación y control de acceso. Si un agente de IA accede a datos, APIs o sistemas, es un activo con dependencias y una identidad que debe entrar en ese perímetro de control.
ISO/IEC 27001:2022 aterriza lo mismo de manera más operativa. En el Anexo A, el control A.5.15 exige control de acceso; A.5.16, gestión de identidades; A.5.17, información de autenticación; A.5.18, derechos de acceso. Si una organización certificada permite agentes con credenciales persistentes, sin owner claro o sin recertificación periódica, tiene un problema que no se arregla con una política bonita en SharePoint.
En el sector financiero europeo, DORA aprieta más. El Reglamento (UE) 2022/2554 obliga a contar con un marco de gestión del riesgo TIC robusto. El artículo 6 exige un marco interno de gestión del riesgo TIC sólido, integral y debidamente documentado. El artículo 9 entra en protección y prevención, incluyendo políticas, procedimientos, protocolos y herramientas para proteger los activos de información y TIC. Aunque DORA no hace fetichismo terminológico con las identidades no humanas, su lógica es inequívoca: los mecanismos de acceso y autenticación forman parte del núcleo de control preventivo. Si tu agente accede a un sistema crítico con una cuenta genérica compartida entre equipos, buena suerte explicando eso frente a supervisión, auditoría interna o segunda línea.
Hay además un ángulo de terceros que muchas entidades están subestimando. DORA, en sus artículos 28 y siguientes, impone disciplina sobre riesgo de terceros proveedores de servicios TIC. Si el agente de IA depende de un proveedor externo, de un modelo alojado, de una plataforma de automatización o de un vault gestionado por un tercero, la identidad del agente deja de ser solo una cuestión técnica: entra en evaluación contractual, derechos de auditoría, estrategias de salida y dependencia operativa.
NIS2 también suma presión, sobre todo para entidades esenciales e importantes. El artículo 21 obliga a medidas técnicas, operativas y organizativas apropiadas para gestionar riesgos de seguridad de redes y sistemas de información. Ahí caben control de accesos, gestión de incidentes, seguridad de la cadena de suministro y uso de autenticación multifactor o soluciones de autenticación continua cuando proceda. Un agente que opera sobre sistemas cubiertos por NIS2 no vive fuera de ese perímetro por el mero hecho de ser “interno”.
Y luego está GDPR, que no habla de agentes porque no necesita hacerlo. Si un agente trata datos personales, el responsable debe aplicar medidas técnicas y organizativas apropiadas conforme al artículo 32. Si se produce una brecha vinculada a abuso, exposición o uso indebido de credenciales del agente, el reloj del artículo 33 corre igual: notificación a la autoridad de control sin dilación indebida y, cuando sea posible, dentro de las 72 horas. La IA no suspende la normativa de protección de datos; solo la hace más fácil de incumplir a gran velocidad.
Hay una escena que se repite demasiado. El negocio quiere un copiloto para atención al cliente, operaciones o finanzas. Tecnología monta un agente con acceso a correo, CRM, base documental y un par de APIs internas. Seguridad pregunta por los permisos. Respuesta: “de momento le hemos dado acceso amplio para validar el caso de uso; luego lo afinamos”. Ese “luego” es el agujero de siempre, solo que ahora automatizado.
El patrón técnico suele incluir uno o varios de estos pecados veniales que acaban siendo capitales:
El argumento a favor suele ser operativo: si estrechas demasiado el perímetro, el agente falla y el proyecto pierde tracción. Es cierto. También es cierto que otorgar privilegios masivos para evitar errores funcionales es exactamente la clase de decisión que luego acaba en un informe de auditoría con adjetivos desagradables.
Aquí está el quid: un agente de IA debe diseñarse como un principal de seguridad con permisos extremadamente específicos, no como un superusuario de conveniencia. Si necesita consultar saldos, que consulte saldos. Si necesita redactar un correo, que no pueda extraer toda la base histórica de clientes. Si necesita abrir tickets, que no pueda cerrar incidentes críticos sin intervención humana. Parece obvio. No siempre se hace.
Autenticar a un agente no es “ponerle un secreto”. Es garantizar que la entidad que ejecuta acciones es la que dice ser, en el contexto correcto, con credenciales resistentes y trazables.
En la práctica, eso implica separar varios planos. El primero es la identidad del workload o del runtime. Un agente desplegado en Kubernetes, en un cloud function o en una plataforma de automatización debe autenticarse idealmente mediante identidad de workload federada o credenciales efímeras emitidas dinámicamente, no mediante secretos estáticos pegados al contenedor. Si todavía dependes de una clave API válida durante meses para un agente con acceso a datos sensibles, no tienes un problema de IA: tienes un problema de 2017 que ha aprendido a hablar.
El segundo plano es la identidad de la aplicación o herramienta a la que el agente llama. No todos los conectores merecen la misma confianza. Las credenciales para leer un índice documental no deberían servir para disparar acciones financieras, y mucho menos compartirse entre entornos de desarrollo y producción. La segregación por entorno no es burocracia; es control de daños.
El tercero es la identidad delegada, cuando el agente actúa en nombre de un usuario. Aquí conviene distinguir entre impersonation plena, delegación acotada y ejecución asistida. Para la mayoría de escenarios sensibles, la segunda es la opción razonable: el agente puede ejecutar acciones en el perímetro del usuario, pero bajo un subconjunto de permisos, con caducidad corta, propósito definido y registro explícito del mandante. Si adoptas una suplantación total y silenciosa, estás borrando justo la línea de responsabilidad que luego querrás demostrar.
Desde la óptica de evidencia, la autenticación adecuada deja rastros verificables: emisión del token o certificado, origen, duración, claims, identidad del agente, identidad del usuario delegante cuando exista, entorno, herramienta destino y resultado. Si alguno de estos elementos no está disponible, la investigación de incidentes queda coja.
El viejo mínimo privilegio sigue siendo necesario, pero se queda corto para agentes. Hace falta mínimo privilegio contextual. Un agente puede necesitar permisos distintos según tarea, momento, criticidad, sensibilidad del dato o canal de entrada.
Pongamos un ejemplo operativo. Un agente de soporte interno puede consultar tickets abiertos y sugerir respuestas. Eso requiere lectura en el sistema ITSM y acceso limitado a una base de conocimiento. No necesita acceso de escritura a directorio corporativo, ni capacidad para resetear contraseñas, ni lectura masiva de chats históricos. Si además puede lanzar una acción de “cerrar ticket”, esa acción debería exigir condiciones adicionales: ticket de baja criticidad, usuario autenticado, ausencia de indicadores de fraude, y quizá aprobación humana si afecta a acceso privilegiado.
Otro caso: un agente financiero que prepara conciliaciones o revisa anomalías. Puede leer extractos, comparar registros y proponer asientos. Debería tener bloqueada la ejecución final de pagos, cambios de beneficiario o modificaciones de límites sin un control adicional. Aquí convergen seguridad y segregación de funciones. El agente puede asistir. No debe convertirse en un bypass elegante de los controles que llevas una década intentando imponer a las personas.
En términos de diseño, esto suele traducirse en permisos por herramienta, por acción y por conjunto de datos; políticas basadas en atributos; scopes temporales; y separación explícita entre capacidad de lectura, recomendación y ejecución. Cuando la plataforma lo permita, conviene introducir policy enforcement points delante de herramientas críticas para validar contexto antes de cada invocación. Sí, añade fricción. También evita que un prompt malicioso convierta un asistente útil en un empleado imaginario con acceso excesivo.
El marco de NIST AI RMF ayuda aquí porque insiste en gestionar riesgos de IA de forma sociotécnica, no solo algorítmica. La decisión de autorizar a un agente no depende solo de si el modelo funciona bien, sino del impacto de sus acciones, la criticidad del proceso y la capacidad de supervisión. El control de acceso deja de ser una cuestión de infraestructura y pasa a ser parte del diseño de la función de negocio.
La forma más rápida de encontrar desorden en identidades no humanas es preguntar cuánto duran sus credenciales. Si la respuesta es “depende” y nadie puede demostrarlo con datos, ya tienes un indicador de madurez bastante honesto.
Las credenciales de agentes deberían ser efímeras siempre que sea técnicamente posible. Certificados de corta vida, tokens con tiempo de expiración medido en minutos u horas, secretos emitidos bajo demanda desde un vault, federación de identidad entre plataforma de ejecución y recursos objetivo. No siempre será viable en todos los sistemas heredados, pero debe ser el principio por defecto.
La rotación periódica sigue siendo necesaria cuando existen secretos persistentes. Lo crítico aquí no es solo fijar una frecuencia, sino demostrar tres cosas: que el secreto rota realmente, que la rotación no depende de memoria humana y que la revocación funciona sin dejar residuos operativos. El control útil no es la política que dice “rotaremos cada 90 días”, sino el registro que prueba que la clave del agente X fue emitida el 4 de junio de 2026, reemplazada el 3 de julio de 2026 y que la anterior quedó inválida en todos los entornos. Lo demás es literatura.
Este punto también importa para DORA por una razón muy concreta: la resiliencia operativa no consiste en evitar todos los incidentes, sino en contenerlos y recuperarse. Si una credencial de agente se filtra y no puedes revocarla rápido porque está embebida en tres integraciones, dos scripts y una plataforma SaaS de un tercero, el problema ya no es de higiene técnica. Es de continuidad operativa.
La auditoría de identidades no humanas solía centrarse en “qué cuenta hizo la llamada”. Con agentes de IA eso no basta. Necesitas un registro más rico, porque la cadena causal es más compleja.
Una traza útil debería permitir reconstruir, al menos, estos elementos: identidad única del agente; versión del agente o del flujo; modelo utilizado si influye en la decisión; identidad del usuario o proceso desencadenante; herramienta invocada; recurso accedido; política de autorización aplicada; secreto o token empleado de forma referenciable, sin exponerlo; hora exacta; resultado; y cualquier paso de aprobación humana cuando exista.
Si el agente usa recuperación aumentada, conviene registrar además la fuente documental o índice consultado, porque muchas decisiones problemáticas no nacen de una credencial comprometida sino de contexto erróneo o manipulado. Si el agente actúa con delegación, debe quedar constancia explícita de si ejecutó una recomendación propuesta al usuario o si actuó automáticamente bajo una política preaprobada.
Esto enlaza con GDPR y con investigación forense. Si un interesado ejerce derechos o si se produce una brecha de datos, la organización necesita saber no solo que hubo acceso, sino si el acceso fue provocado por una acción autónoma del agente, por una instrucción de un usuario autenticado o por un abuso de la cadena de herramientas. Sin esa distinción, las evaluaciones de riesgo y las notificaciones se vuelven peligrosamente especulativas.
También enlaza con el control interno financiero. En entornos sujetos a SOX o a controles equivalentes, cualquier automatización que toque procesos con impacto financiero exige evidencia suficiente para demostrar integridad, autorización y segregación. Un agente que propone ajustes contables o desencadena cambios en sistemas relevantes para reporting no puede operar con un log pobre y una identidad compartida. Eso es pedirle al auditor que cierre los ojos con amabilidad. Rara vez lo hacen.
La prueba de fuego de cualquier esquema de identidad no humana no es su diseño en PowerPoint, sino su revocación en una tarde mala. Un empleado se marcha, un proveedor pierde acceso, una clave se expone, un agente empieza a comportarse de forma anómala o una herramienta integrada muestra señales de compromiso. ¿Puedes cortar el acceso del agente en minutos, de forma selectiva y sin tumbar medio proceso?
La revocación efectiva tiene varias capas. La primera es deshabilitar la identidad principal del agente o invalidar sus credenciales activas. La segunda es cortar la delegación hacia herramientas concretas. La tercera es suspender o poner en cuarentena los flujos automáticos relacionados. La cuarta, más olvidada, es invalidar sesiones, cachés, tokens derivados o credenciales emitidas por terceros dependientes. Muchos equipos revocan la cuenta principal y descubren demasiado tarde que siguen vivas credenciales secundarias en integraciones satélite.
Desde el punto de vista de gobierno, cada agente debería tener un owner técnico, un owner de negocio y un procedimiento documentado de emergencia para revocación. Si nadie sabe quién puede apagarlo o qué impacto operativo tendrá hacerlo, la entidad no controla al agente; convive con él. Hay relaciones peores, pero para cumplimiento no es ideal.
El error opuesto al privilegio excesivo es diseñar un esquema tan rígido que nadie lo use y todos vuelvan al token compartido “solo mientras tanto”. La respuesta no es menos control. Es mejor diseño.
La arquitectura razonable para agentes de IA suele combinar cinco principios. Primero, identidad única por agente y por entorno. Nada de una sola cuenta para desarrollo, pruebas y producción, ni de varios agentes colgados de la misma service account. Segundo, credenciales efímeras o federadas como opción por defecto. Tercero, permisos por herramienta y por acción, no solo por aplicación. Cuarto, aprobación humana para acciones de impacto alto o irreversible. Quinto, telemetría suficiente para atribución y auditoría.
Un patrón útil es separar el “cerebro” del agente de las “manos” que ejecutan acciones. El motor que decide qué hacer no debería tener acceso directo universal; debería pasar por un plano de herramientas controlado, donde cada acción está encapsulada, autenticada, autorizada y registrada. Eso permite aplicar políticas coherentes sin rehacer cada caso de uso desde cero. También reduce el radio de explosión cuando una herramienta se comporta mal o una instrucción logra desviar al agente.
Otra buena práctica es imponer estados operativos diferenciados: modo observación, modo recomendación y modo ejecución. En observación, el agente solo lee y aprende el flujo. En recomendación, propone acciones pero no las ejecuta. En ejecución, actúa dentro de un perímetro definido y con controles reforzados. Esta graduación ayuda a introducir casos de uso sin regalar permisos plenos desde el primer día, que es una costumbre muy popular y muy cara.
Los auditores y supervisores no necesitan dominar la jerga para detectar un control flojo. Si una organización despliega agentes con acceso a sistemas relevantes, las preguntas previsibles ya están sobre la mesa.
Van a pedir inventario. Cuántos agentes existen, para qué sirven, en qué entornos corren, qué datos tocan, qué sistemas invocan, quién es su owner. Van a pedir evidencia de alta, cambios y baja. Quién aprobó la creación, quién autorizó los permisos, cuándo se revisaron por última vez. Van a pedir trazas. Qué acciones ejecutó el agente A entre el 1 de mayo de 2026 y el 30 de junio de 2026, con qué identidad, sobre qué recursos, en nombre de quién. Y van a pedir pruebas de revocación y de rotación.
Si la entidad está bajo DORA, ese paquete encaja directamente con el marco de gestión del riesgo TIC y con la documentación exigible sobre controles preventivos, detective y de respuesta. Si además aplica ISO 27001, la pregunta de auditoría sobre identidades no humanas no es un exotismo: es una extensión natural de A.5.16 a A.5.18. Si opera bajo NIS2, la conversación irá hacia medidas apropiadas, autenticación y cadena de suministro. Y si hay datos personales, GDPR introduce una dimensión adicional: minimización, necesidad, seguridad del tratamiento y capacidad de detectar y responder a incidentes.
Lo interesante es que la evidencia útil para todos estos marcos se parece bastante. No hace falta inventar un programa paralelo “solo para IA”. Hace falta extender el existente con disciplina.
Si quieres saber si el gobierno de identidades de agentes está listo para una revisión seria, estas evidencias deberían existir y poder extraerse sin drama:
Si parte de esta evidencia no existe, no hace falta dramatizar. Hace falta construirla antes de escalar el número de agentes. Porque los agentes crecen con una velocidad que los controles internos rara vez igualan.
En banca, seguros, pagos y mercados, el asunto adquiere una dimensión adicional: los agentes no solo pueden tocar datos, también pueden afectar a procesos regulados, continuidad de negocio, relación con clientes y riesgo de terceros. DORA convierte este debate en algo más que una recomendación de arquitectura.
Una entidad financiera española que use agentes para soporte, back office, fraude, onboarding o gestión documental debería plantearse cuatro preguntas inmediatas. Primera: ¿el agente accede a funciones críticas o importantes, en el sentido operativo de DORA? Si la respuesta es sí, el umbral de exigencia sobre autenticación, segregación y trazabilidad sube bastante. Segunda: ¿existe dependencia material de un proveedor TIC para la identidad, el runtime o las herramientas del agente? Si es así, la conversación entra de lleno en gestión de terceros y resiliencia contractual. Tercera: ¿el agente toca datos personales, financieros o de autenticación? Entonces GDPR y, en ciertos casos, normativa sectorial de seguridad y secreto bancario endurecen las condiciones. Cuarta: ¿podría una acción del agente desencadenar un incidente operativo o de seguridad con obligación de escalado interno o externo? Si nadie ha mapeado ese escenario, la preparación es insuficiente.
El punto con más ironía involuntaria es este: muchas entidades han invertido años en cerrar accesos privilegiados de administradores humanos, para luego abrir puertas bastante alegres a automatizaciones “inteligentes” que heredan credenciales amplias por razones de agilidad. Cambia el interfaz, no el riesgo. Y el supervisor, por desgracia para los optimistas, suele darse cuenta.
Hay una metáfora útil para ordenar decisiones. Piensa en cada agente como un empleado temporal muy rápido, muy obediente y completamente incapaz de entender la prudencia institucional salvo que se la impongas. No debe tener acceso porque “es del sistema”. Debe tenerlo porque una función concreta lo requiere, durante un tiempo concreto, bajo controles concretos.
Aplicado a gobierno, eso significa:
Primero, alta formal. Todo agente entra en inventario con propósito, sponsor de negocio, owner técnico, clasificación de criticidad y conjunto inicial de herramientas permitidas.
Segundo, perfilado de acceso por tareas. No se conceden permisos por afinidad tecnológica, sino por acciones necesarias y datos estrictamente requeridos.
Tercero, supervisión escalonada. Los agentes empiezan en modo lectura o recomendación y solo pasan a ejecución automatizada cuando existe evidencia de comportamiento estable, controles compensatorios y trazabilidad adecuada.
Cuarto, recertificación periódica. Igual que revisas accesos de usuarios, revisas si el agente sigue necesitando esos permisos. Si el caso de uso cambió, el acceso cambia. Si el agente ya no aporta valor, se retira. Cuesta menos que mantener un zombi con token activo.
Quinto, baja completa. Se revocan credenciales, se eliminan secretos, se retiran permisos a herramientas y se conserva la evidencia necesaria para auditoría e investigación posterior.
No es un modelo glamuroso. Tampoco lo es IAM. Esa es precisamente la razón por la que funciona cuando el entusiasmo por la IA empieza a producir más conectores que controles.
En 2026, el problema ya no es prever si habrá identidades no humanas complejas. Ya están aquí. El problema es que muchos programas de IAM aún no las ven con la granularidad adecuada. Ven cuentas técnicas, secretos, integraciones SaaS y pipelines. Pero no siempre ven agentes con capacidad de decisión operativa, delegación contextual y exposición transversal a datos, herramientas y terceros.
Ese punto ciego importa porque distorsiona prioridades. Se invierte en guardrails del modelo, filtrado de prompts y monitorización de contenido generado —todo razonable— mientras se deja para más adelante la cuestión bastante más estructural de quién puede hacer qué en nombre de quién. Es una asimetría curiosa: mucho debate sobre la inteligencia del agente y poca disciplina sobre sus llaves.
La pieza clave del NIST AI RMF no es que prometa una receta cerrada. Es que empuja a tratar la IA como un sistema gobernable, no como una caja mágica. Cuando cruzas esa idea con NIST CSF 2.0, ISO 27001, DORA, NIS2 y GDPR, la conclusión es bastante terrenal: la identidad del agente es control interno, seguridad operativa y compliance al mismo tiempo. No una nota al pie del proyecto de innovación.
Si eres CISO, la pregunta es directa: ¿puedes enumerar hoy qué agentes tienen acceso a sistemas críticos y con qué privilegios exactos? Si eres responsable de cumplimiento, la versión equivalente es igual de incómoda: ¿puedes demostrarlo con evidencia? Si la respuesta es no, no hace falta parar toda iniciativa de IA. Hace falta hacer lo que las organizaciones maduras llevan años haciendo con los humanos: saber quién entra, qué toca, cuánto tiempo puede hacerlo y cómo se le corta el acceso cuando haga falta.
La IA agentica no elimina los fundamentos de seguridad. Los pone a prueba. Y, como suele pasar, el problema no empieza cuando la máquina piensa. Empieza cuando actúa con una identidad que nadie gobierna de verdad.
Resumen semanal gratis
Suscríbete al resumen semanal de regulación, vulnerabilidades explotadas y acciones para tu equipo.
¿Quieres un plan a medida? Modela tu organización con Agentic Digital Twin.
Es el proceso de vigilar de forma continua los cambios normativos y las vulnerabilidades relevantes, y traducirlos en acciones concretas para los equipos de seguridad, riesgo y compliance.
Una vulnerabilidad explotada puede activar obligaciones de notificación o gestión de riesgo (por ejemplo en DORA, NIS2 o el CRA). Mapear la amenaza al marco aplicable permite priorizar la respuesta.
Un GAP Assessment evalúa tu madurez por control frente al marco elegido (DORA, NIS2, ISO 27001, etc.) y produce un plan de acción con brechas priorizadas.