Cuando el acceso supera a la gobernanza: el riesgo interno de la IA

Las empresas están dando a los agentes de IA las llaves de su contenido más sensible más deprisa de lo que nadie escribe las reglas sobre cómo se usan esas llaves. Esa brecha entre la velocidad de implantación y la madurez de la gobernanza se está convirtiendo, sin hacer ruido, en el problema de seguridad que definirá 2026, y ya lo dicen los propios responsables de seguridad.

El acceso de los agentes ya es la amenaza número uno

En un estudio realizado por Sapio Research para Exabeam en junio de 2026 y publicado el 16 de septiembre de 2026 —The Agentic Insider: From Monitoring to Understanding, una encuesta a 600 responsables de decisiones de seguridad y finanzas de siete países—, el 48 % de los responsables de seguridad señaló a los agentes de IA que operan con accesos excesivos, comprometidos o no previstos como la mayor amenaza a la que se enfrenta hoy su organización. Eso sitúa el acceso de los agentes por delante de los actores de amenazas externos (28 %) y muy por delante de los empleados comprometidos y los malintencionados (12 % cada uno). Por primera vez en una categoría de amenazas que los equipos de seguridad llevan años siguiendo, un problema de infraestructura supera a un adversario.

Qué cuenta realmente como «agente»

Importa cómo define el estudio su objeto. Sus autores separan con cuidado los «sistemas autónomos orientados a objetivos que pueden acceder a recursos de la empresa y actuar con una intervención humana limitada» de los «chatbots conversacionales». Esa distinción es todo el problema en miniatura. Un chatbot responde dentro de una ventana de chat; un agente actúa —lee un repositorio de contratos, extrae el registro de un cliente, redacta y envía un mensaje, actualiza un sistema de registro— y lo hace, por diseño, con una intervención humana limitada. Como señaló Gabrielle Hempel, de Exabeam, en un análisis relacionado, un agente puede tener «identidad válida, acceso autorizado, herramientas esperadas, ningún atacante» y aun así provocar un incidente. Cuanta más autonomía concede una organización a un agente —que es precisamente el argumento económico para implantarlo—, menos realista resulta controlarlo decidiendo de antemano, para cada tarea, exactamente qué puede tocar.

Por qué no funciona acotar el acceso a mano

Esa es la trampa en la que están cayendo la mayoría de las organizaciones. La respuesta instintiva a «el agente tiene demasiado acceso» es reducir su alcance: roles más estrechos, cuentas de servicio más restringidas, revisiones de permisos por agente. Eso funciona con el primer agente. No funciona con el quincuagésimo, y menos aún cuando la tarea del mismo agente cambia de una hora a otra, o cuando el contenido al que necesita llegar abarca correo electrónico, recursos compartidos de archivos, registros de CRM y datos estructurados que nadie inventarió pensando en agentes. Acotar a mano presupone un conjunto estático y enumerable de recursos y un conjunto estático y enumerable de tareas. La IA agéntica contradice ambas suposiciones continuamente.

Supervisar no es lo mismo que entender

Los datos de Exabeam muestran la tensión que esto crea incluso donde no se ha descuidado la gobernanza. El 60 % de los responsables de seguridad ha puesto en marcha herramientas específicas de seguridad o gobernanza de la IA, y el 56 % ha ampliado sus plataformas SIEM y de detección para cubrir a los agentes. Pero el 27 % sigue señalando la falta de contexto de comportamiento y de correlación como su mayor carencia de supervisión y, como observó Steve Wilson, director de IA y de producto de Exabeam, «las organizaciones están avanzando de forma significativa en la supervisión de los agentes de IA, pero supervisar la actividad no es lo mismo que entender el comportamiento». La supervisión te dice lo que hizo un agente después de hacerlo. No te dice, de antemano, si se le debería haber permitido.

El problema de presupuesto que se esconde tras el de seguridad

Una segunda restricción agrava la primera: el dinero. El 55 % de los responsables de seguridad afirma haber retrasado o reducido una iniciativa de seguridad porque no pudo plantear el riesgo en términos financieros que su director financiero aceptara, aunque el 93 % informa de que seguridad y finanzas están, en general, alineadas en la tolerancia al riesgo, y el 81 % dice que su director financiero entiende el riesgo de ciberseguridad en términos generales. La brecha no es de confianza; es de traducción. «Los directores financieros rara vez cuestionan si un riesgo de ciberseguridad es real», señaló Mike Byron, director financiero de Exabeam; lo difícil es «entender cómo la inversión reduce el riesgo en términos de negocio medibles». Un modelo de gobernanza capaz de señalar decisiones concretas y registradas —a esta identidad se le denegaron estos datos para esta finalidad en esta fecha— se traduce en una conversación de presupuesto mucho más fácilmente que un panel de supervisión.

La capa que falta: la política decidida en el momento de la solicitud

Si se juntan esas piezas, empieza a verse la forma de una respuesta viable. No es una mejor supervisión de los agentes después de que actúen, ni una hoja de cálculo más grande con permisos por agente decididos antes de que actúen. Es una capa de políticas situada en el propio punto de acceso que evalúa, en cada solicitud, si estos datos pueden usarse para esta finalidad por esta identidad —humana o agente— antes de que se mueva nada. Esa decisión debe tomarse de forma dinámica, a partir de los atributos de los datos, de la identidad y de la acción solicitada, en lugar de fijarse una vez por adelantado para un rol que inevitablemente quedará obsoleto. Y cada decisión, de permiso o de denegación, debe registrarse, para que el registro de aplicación sirva también como la evidencia que necesitan tanto los auditores como los directores financieros.

Esta es la dirección hacia la que ha trabajado Kiteworks con su Data Policy Engine, que evalúa en tiempo real los datos, la identidad y la acción solicitada frente a la política, aplica una directiva —bloquear, solo visualización, justificación obligatoria o permitir— y registra cada decisión en un registro de auditoría inmutable. En su extensión específica a los agentes, Kiteworks describe cómo el mismo punto de control se aplica antes de que cualquier solicitud de IA toque los datos: verificación de identidad, evaluación de políticas basada en atributos y registro de auditoría, con la identidad del agente vinculada a la persona que lo autorizó. La propia empresa plantea lo que está en juego sin rodeos: los agentes de IA «no ejercen ningún juicio ético independiente. Accederán a cualquier dato al que no se les impida explícitamente acceder».

Eso no es motivo para frenar la implantación de agentes. Es motivo para dejar de tratar el acceso como algo que se decide una vez y empezar a tratarlo como algo que se decide cada vez.

Si estás pensando en cómo debería ser un límite de políticas para los agentes en tu propio entorno, escribe a sales@kiteworks.com o inicia una conversación. No necesitas configurar Claude ni MCP para preguntar. Consulta el catálogo de agentes y la compatibilidad de asistentes.