Los agentes de IA ya están dentro de tus sistemas y tu estrategia de identidad aún no lo sabe
Para finales de 2026, el 40% de las aplicaciones empresariales incluirá agentes de IA con tareas específicas. Hace doce meses, esa cifra no llegaba al 5%. El salto no es solo estadístico: es estructural. Millones de identidades no humanas están operando ahora mismo en redes corporativas con acceso a datos, sistemas y decisiones, y la mayoría de los equipos de seguridad todavía está mirando el problema con los instrumentos equivocados.
La gestión de identidades y accesos —lo que la industria llama IAM por sus siglas en inglés— fue construida para un mundo donde los actores del sistema eran personas. Alguien entra, se le asigna un rol, se le revisa el acceso periodicamente y eventualmente se le desvincula. El ciclo tiene lógica humana porque fue diseñado para humanos. Los agentes de IA no entran por recursos humanos, no tienen manager que apruebe sus permisos y tampoco tienen fecha de baja programada. Pero sí tienen acceso. Y ese acceso, en la mayoría de las organizaciones, no está gobernado con el mismo rigor que el de cualquier empleado nuevo.
Esto no es un problema técnico menor. Es una grieta estructural en cómo las empresas entienden quién —o qué— opera dentro de sus sistemas.
El inventario que nadie tiene
Antes de hablar de controles, hay una pregunta más básica que pocas organizaciones pueden responder con precisión: cuántos agentes de IA están corriendo en sus entornos ahora mismo, quién los desplegó y qué pueden hacer.
La respuesta incómoda es que la mayoría no lo sabe. Según datos publicados por Gravitee, solo uno de cada siete agentes de IA que opera en entornos productivos recibió revisión formal del equipo de seguridad antes de ser desplegado. Los restantes fueron lanzados por equipos de negocio o desarrollo con urgencia operativa, sin pasar por los mismos filtros que se aplican a cualquier sistema nuevo. El resultado es un ecosistema de identidades no humanas que acumulan permisos sin auditoría, operan bajo credenciales compartidas y permanecen activas mucho después de que el flujo de trabajo que las originó haya cambiado o desaparecido.
El problema no es nuevo en términos de concepto. Las identidades no humanas —cuentas de servicio, claves de API, scripts de automatización— ya superaban en número a los usuarios humanos en la mayoría de las empresas grandes antes de que los agentes de IA entraran al panorama. Lo que cambió es la velocidad y la autonomía. Un clúster de Kubernetes puede aprovisionar miles de cuentas de servicio en minutos. Un agente de IA puede interactuar con múltiples sistemas simultáneamente, tomar decisiones en tiempo real y modificar su comportamiento según el contexto. Eso no es una cuenta de servicio pasiva esperando una instrucción. Es un actor con capacidad de juicio propio dentro de tus sistemas.
Sin un inventario claro de qué agentes existen, qué acceso tienen y quién responde por ellos, cualquier conversación sobre controles es posterior al problema. No puedes gobernar lo que no has catalogado.
Cómo se ve una brecha cuando el actor es una máquina
El caso de Salesloft y Drift, ocurrido el año pasado, ilustra con precisión el tipo de riesgo que emerge cuando los controles de identidad no alcanzan a las integraciones de IA. Atacantes comprometieron tokens OAuth vinculados al chatbot de Drift —una integración de IA usada por Salesloft— y accedieron a los entornos de Salesforce de más de 700 organizaciones. La brecha pasó desapercibida durante días.
El detalle que importa no es técnico sino operativo: el equipo de seguridad podía ver que el chatbot tenía acceso. Lo que no podía ver era qué estaba haciendo con ese acceso en tiempo real. Desde afuera, las consultas maliciosas eran indistinguibles del comportamiento legítimo del bot. Era una identidad no humana de confianza haciendo exactamente lo que parecía que debía hacer.
Ese patrón —acceso visible, comportamiento invisible— es el núcleo del problema. Los marcos de IAM tradicionales fueron construidos para responder a la pregunta de quién tiene acceso a qué. Frente a agentes de IA, la pregunta que importa es qué está haciendo ese acceso en cada momento, bajo qué contexto y con qué propósito. Son preguntas distintas y requieren instrumentos distintos.
El modelo de control estático basado en roles —asignas un rol, el rol define los permisos, los permisos se revisan cada trimestre— no fue diseñado para actores que operan a velocidad de máquina y modifican su comportamiento según el contexto. Necesitas evaluación continua de riesgo, no auditoría periódica. Necesitas que el acceso expire automáticamente cuando la tarea termina, no que persista indefinidamente porque nadie lo revocó.
Los principios existen desde hace tiempo. El mínimo privilegio, el acceso justo a tiempo, los tokens efímeros que expiran solos, la integración con plataformas de gestión de accesos privilegiados. Ninguno de estos mecanismos es nuevo. Lo que es nuevo es la urgencia de extenderlos a una clase de identidades para las que no fueron pensados originalmente, y hacerlo antes de que el incidente siguiente aparezca en el reporte trimestral.
Lo que las organizaciones están aplazando y por qué ese aplazamiento tiene costo
Hay una razón por la que los equipos de seguridad no han extendido sus marcos de IAM a los agentes de IA con la misma velocidad con que esos agentes se despliegan: el despliegue lo impulsan los equipos de negocio y los equipos de seguridad responden después.
La asimetría es estructural. Un equipo de producto o de operaciones que encuentra en un agente de IA una forma de automatizar un flujo de trabajo no tiene incentivos para detenerse y pedir una revisión de seguridad que puede tomar semanas. Su incentivo es el resultado operativo inmediato. El costo de no hacerlo —una brecha, un acceso no autorizado, un agente comprometido— lo paga otro equipo, más tarde, bajo otro presupuesto.
Esa distribución de incentivos produce exactamente el inventario caótico que describimos antes: decenas o cientos de agentes corriendo en producción, muchos sin dueño formal, con permisos que nunca fueron revisados y credenciales que nadie sabe cuándo expiran.
La solución no es ralentizar el despliegue de agentes. Las ganancias de productividad son reales y las organizaciones que se queden atrás pagarán ese costo de otra manera. La solución es integrar la gobernanza de identidades al proceso de despliegue, no como un paso posterior sino como una condición previa. Que ningún agente entre a producción sin que alguien haya respondido tres preguntas básicas: a qué tiene acceso, quién responde por ese acceso y bajo qué condiciones ese acceso expira.
Gartner identificó la falta de gobernanza sobre identidades de agentes de IA como una de las tendencias de ciberseguridad más críticas para 2026. No porque sea un problema nuevo en su lógica, sino porque la velocidad de adopción está superando la velocidad de los controles. La brecha entre ambas es donde viven los incidentes.
El gobernador que falta en la carrera hacia la IA operativa
La narrativa dominante sobre IA en las empresas está centrada en capacidad: qué puede hacer un agente, cuánto tiempo ahorra, cuántos procesos automatiza. Es una narrativa legítima. Los números de productividad son reales.
Lo que esa narrativa deja fuera es la pregunta sobre quién responde cuando algo sale mal. Y cuando el actor que falla no es un empleado sino un agente con acceso a múltiples sistemas, la pregunta se vuelve más difícil de responder.
La reducción de costos por brechas que los marcos de IA en IAM prometen —hasta un 80% según algunos estudios del sector— no llega sola. Llega cuando alguien decidió que los agentes de IA son decisiones de identidad antes de ser decisiones de ingeniería. Cuando el equipo de seguridad tiene visibilidad en tiempo real del comportamiento de cada agente, no solo de sus permisos estáticos. Cuando los accesos expirar automáticamente y los flujos de atestación son continuos, no anuales.
Las organizaciones que están desplegando agentes de IA sin ese nivel de gobernanza no están siendo temerarias por ignorancia. Están siendo temerarias porque la presión para moverse rápido es real y los controles correctos requieren inversión, coordinación y fricción deliberada en los procesos de despliegue.
Esa fricción, bien diseñada, no frena la adopción. La hace sostenible. La diferencia entre un programa de IA que escala de forma ordenada y uno que produce un incidente mayor en dieciocho meses no está en la calidad de los modelos ni en la ambición de los casos de uso. Está en si alguien tuvo la conversación sobre identidades antes de que el primer agente llegara a producción.
