El acceso de los agentes de IA supera la responsabilidad
Tus agentes de IA ya tienen acceso a registros de clientes, propiedad intelectual confidencial y archivos de RR. HH., y cuando uno de ellos se comporta de forma indebida, tu organización puede tener dificultades para determinar quién responde por ello.
Esa es la incómoda realidad que muestra la encuesta de adopción de agentes de IA de 1Password, que consultó a 1,000 empleados de tiempo completo en EE. UU. en empresas con 250 o más empleados, divididos equitativamente entre personal de TI y seguridad y desarrolladores. La encuesta se realizó del 26 de mayo al 3 de junio de 2026. El 71% de los encuestados afirmó que los agentes de IA tienen acceso a datos de clientes, propiedad intelectual confidencial o información de RR. HH. en sus empresas, y solo el 35% indicó que gestionan esos agentes bajo los procesos existentes de gestión de identidades y accesos.
El acceso es la parte visible. La pregunta más difícil es la que hace un regulador, un auditor o un abogado contrario después de un incidente. ¿Quién autorizó ese acceso, bajo qué política y dónde está el registro? El equipo de identidad puede decirte quién. Solo un control a nivel de datos puede decirte qué se tocó, cuándo y bajo qué política, y luego entregar esa información como evidencia. El intercambio seguro de datos de Kiteworks se basa en esa distinción, y es el enfoque que este artículo aplica a la encuesta.
Los números merecen una lectura cuidadosa, porque el hallazgo interesante no es cuántos agentes tienen acceso, sino cuán poco acuerdo existe sobre quién responde por ellos.
Conclusiones clave
1. El acceso ha superado a la responsabilidad.
El 71% de los empleados estadounidenses encuestados dice que los agentes de IA pueden acceder a datos de clientes, propiedad intelectual confidencial o información de RR. HH., pero la responsabilidad por esos agentes está dispersa entre equipos, usuarios y ejecutivos.
2. La responsabilidad sigue sin resolverse.
El 65% considera que otra persona distinta a la actualmente responsable debería serlo, lo que convierte la responsabilidad de los agentes en una decisión de gobernanza pendiente y no en un organigrama definido.
3. Los programas de identidad solo cubren parte del problema.
Solo el 35% gestiona los agentes bajo los procesos existentes de gestión de identidades y accesos, y el 21% no ha formalizado ningún enfoque para el acceso de agentes.
4. Las credenciales son el punto débil silencioso.
El 86% reporta problemas relacionados con credenciales en identidades no humanas, y el 27% ha experimentado un incidente de seguridad o filtración vinculado a agentes con privilegios excesivos.
5. Lo que importa a los reguladores es la evidencia, no la intención.
El control relevante demuestra qué humano delegó en qué agente, qué datos se tocaron y bajo qué política, y esa prueba debe poder presentarse cuando se solicite.
La encuesta midió empleados, no reportes de incidentes
Antes de construir un programa basándote en cualquier cifra, define qué mide. La encuesta de 1Password preguntó a 1,000 empleados estadounidenses qué observan dentro de sus propias empresas. Todas las cifras son autoinformadas, la muestra es solo de EE. UU., y 1Password vende soluciones de gestión de identidades y secretos, por lo que sus conclusiones apuntan hacia su propia categoría de producto. Un CISO escéptico debería leerla así.
Nada de esto hace que los datos sean inútiles. Los hace direccionales, y eso basta cuando el patrón se repite en investigaciones independientes, como sucede más adelante en este artículo. La encuesta también divide su muestra de forma clara, con 500 desarrolladores y 500 profesionales de TI y seguridad, y esa división produce la comparación más reveladora del informe. Los desarrolladores, quienes crean e implementan agentes, tienen más probabilidades de reportar brechas de seguridad en la gestión de agentes (67%) que los encuestados de TI y seguridad (57%).
Vuelve a leer eso. Las personas más cercanas a los agentes ven más brechas que quienes son responsables de protegerlos. Eso no es un problema tecnológico. Es un problema de visibilidad, y la visibilidad es lo primero que revisa un auditor.
Confías en que tu organización es segura. Pero ¿puedes comprobarlo?
Leer ahora
La gobernanza sigue en borrador mientras el acceso ya está en producción
Empecemos por la adopción. Casi la mitad de los desarrolladores (46%) dijo que ya usan agentes de IA en producción, y otro 45% espera hacerlo en los próximos dos años. Los agentes no son un piloto aislado en un entorno de pruebas. Ya están en el flujo de trabajo, y la encuesta indica que están accediendo a los datos que generan responsabilidad cuando hay filtraciones.
En el total de los 1,000 encuestados, el 62% reportó brechas de seguridad en la gestión de agentes en su empresa. Detrás de ese titular hay un dato más silencioso. El 33% de los profesionales de TI y seguridad dijo que no tiene idea de cuántas identidades no humanas o agentes están en uso en su empresa. No puedes gobernar un inventario que no puedes contar, ni generar un registro auditable de un actor que nunca registraste.
Luego viene la brecha de procesos. Solo el 35% gestiona los agentes de IA bajo los procesos existentes de gestión de identidades y accesos, y el 21% aún no ha formalizado ningún enfoque para gestionar el acceso de agentes.
Aquí es donde el enfoque importa. Los agentes son una segunda clase de identidad que opera junto a los usuarios humanos, y el modelo de gobernanza de la organización debe cubrir ambos bajo una sola política, no ejecutar un programa para humanos y otro, más débil, para agentes. Un modelo de control de acceso basado en roles diseñado para empleados asume una persona que toma decisiones. Un agente no toma ninguna. Accederá a todo lo que se le permita, a velocidad de máquina, por lo que el control de acceso basado en atributos evaluado en cada solicitud se adapta mejor a los agentes que un rol estático. Por la misma lógica, la gobernanza de datos de IA debe comenzar con los datos, no con el modelo. Los equipos de seguridad que tratan el problema como una cuestión de seguridad del modelo están preguntando a la persona equivocada la pregunta equivocada, un tema desarrollado en por qué los agentes de IA rompen los modelos de seguridad tradicionales.
La responsabilidad recae en quien está más cerca, no en quien debería tenerla
Los datos sobre responsabilidad son la parte de la encuesta que un Chief Compliance Officer debería imprimir. Se preguntó a los encuestados quién es responsable en la práctica por las acciones de los agentes. La respuesta más común fue el liderazgo del equipo o departamento con un 24%. El usuario que utiliza el agente siguió con un 19%, luego el liderazgo de la empresa con un 17% y el equipo de seguridad con un 13%. El 5% dijo que el propio agente es considerado responsable.
Detente un momento en esa última cifra. Aproximadamente uno de cada veinte encuestados trabaja en un lugar donde el responsable es un software. Ningún regulador, tribunal o junta acepta esa respuesta, porque el software no puede ser multado, sancionado ni citado.
La dispersión entre las otras cuatro respuestas cuenta la verdadera historia. No hay un único responsable claro. Y cuando 1Password preguntó si la persona actualmente responsable es la adecuada, el 65% dijo que debería ser otra. Eso es un vacío de responsabilidad, que surge fácilmente cuando una función otorga acceso y otra asume el riesgo. Refleja el argumento de la brecha de autoridad en los flujos de trabajo de IA, donde la autoridad delegada nunca se documenta.
Entre estos encuestados, la propiedad de la seguridad de IA está sin resolver, así que no esperes que un organigrama lo solucione. Trata la ambigüedad como el problema a cerrar, de forma deliberada, con un responsable asignado para cada agente.
El marco regulatorio es simple, y es el que debe guiar tus prioridades. Los reguladores regulan los datos, no los modelos. Por ejemplo, la Regla de Seguridad de HIPAA exige que las entidades cubiertas y los asociados comerciales asignen un nombre o número único para identificar y rastrear la identidad del usuario e implementen controles de auditoría que registren y examinen la actividad en sistemas que contienen información de salud protegida electrónica. La regla no tiene ninguna excepción para IA. Según mi interpretación, un agente que accede a un registro de paciente debe ser identificable y rastreable igual que una enfermera, y un programa de cumplimiento de HIPAA que no puede atribuir el acceso de un agente tiene una brecha de evidencia antes de que llegue la primera queja. La prueba práctica es la que se plantea en no puedes gobernar lo que no puedes atribuir.
Las credenciales son el punto débil silencioso
Los agentes se autentican con credenciales, y la encuesta sugiere que esas credenciales se gestionan como todo lo que un equipo saturado nunca planeó escalar. El 86% de todos los encuestados reportó problemas relacionados con credenciales en identidades no humanas, y el 27% reportó un incidente de seguridad o filtración por identidades no humanas con privilegios excesivos.
El dato de los desarrolladores es más duro. Entre los 500 desarrolladores, el 40% dijo que otorga a los agentes acceso persistente a sistemas o credenciales, el 24% codifica credenciales directamente en el código y el 20% comparte credenciales por Slack o correo electrónico. El 43% no utiliza un gestor de secretos o bóveda dedicado.
Ese último punto merece atención, porque expone la debilidad de la política sin aplicación. Muchos equipos tienen una bóveda. Muchos también usan atajos. Cuando un agente tiene una credencial persistente que alguien pegó en un mensaje hace meses, el control de acceso en papel y el control de acceso real divergen, y solo uno aparecerá en el registro de auditoría. Esta es la misma brecha descrita en los permisos no determinan lo que la IA debería poder usar, que señala que lo que un agente puede tocar y lo que debería poder usar son preguntas distintas.
Los líderes de cumplimiento deben prestar atención por una razón concreta. Una identidad no humana con privilegios excesivos puede socavar la minimización de datos en cuanto accede a más de lo necesario para su tarea, y lo hace en silencio, sin que ningún usuario lo reporte.
Investigaciones independientes muestran el mismo patrón
Una sola encuesta de un proveedor prueba poco. Sin embargo, otras tres fuentes apuntan en la misma dirección, aunque dos de ellas también son investigaciones de proveedores.
Empecemos con la visión del CISO. La encuesta de Vorlon a CISOs, cubierta por IT Brief UK, consultó a 500 CISOs estadounidenses en organizaciones de 500 o más empleados sobre el año 2025. De los CISOs encuestados, el 30.8% reportó exfiltración de datos no autorizada a través de integraciones SaaS-IA, y el 86.8% dijo que la visibilidad sobre qué datos intercambian las herramientas de IA con aplicaciones SaaS sigue siendo una limitación de sus herramientas actuales. Vorlon vende una plataforma de seguridad de ecosistemas, así que considera las cifras como investigación de proveedor. El dato relevante es el de visibilidad.
Esa conclusión sobre visibilidad apunta en la misma dirección que los datos de 1Password, pero desde otro rol dentro de la organización. Los CISOs reportan visibilidad limitada sobre los datos que intercambian las herramientas de IA con aplicaciones SaaS, y los encuestados de 1Password describen responsabilidad dispersa sobre los agentes. Ambos son señales de una brecha estructural, aunque midan cosas distintas.
Ahora la perspectiva de los profesionales según la investigación de Kiteworks. El Informe Anual de Seguridad de Datos y Riesgo de Cumplimiento de Kiteworks 2026 recopiló respuestas de 459 profesionales de seguridad, cumplimiento y tecnología en el segundo trimestre de 2026, y todos los resultados son autoinformados. El 65% descubrió empleados usando herramientas de IA no aprobadas con datos de la organización, y solo el 30% tenía implementado un mecanismo formal de apagado o terminación de agentes. La IA en la sombra y los agentes no gobernados son dos caras del mismo fallo: tanto las herramientas autorizadas como las no autorizadas acceden a datos que nadie ha mapeado.
Por último, considera la visión gubernamental. El 20 de agosto de 2026, el National Cyber Security Centre del Reino Unido publicó un artículo en su blog, Managing the cyber risk of agentic AI. Recomienda que cada agente tenga una identidad única, que las credenciales tengan la menor vida útil posible, que personas o grupos específicos sean responsables de la actividad de IA donde una acción no deseada tendría consecuencias importantes, que las organizaciones definan cuándo un agente debe detenerse y buscar aprobación humana, y que los registros sean inmutables siempre que sea posible. También indica que las organizaciones siempre deben poder detener la actividad de un agente de inmediato. Yo interpreto esa lista como una lista de verificación de evidencia. Cada punto corresponde a una pregunta que puede hacer un regulador.
Por qué la identidad por sí sola no genera la evidencia
La identidad responde bien a una pregunta: quién o qué está solicitando. Los auditores y reguladores hacen cuatro preguntas. ¿Quién delegó esto, qué datos se tocaron, bajo qué política y puedes demostrarlo? La primera es una cuestión de identidad. Las otras tres son preguntas a nivel de datos. Este es el punto que se desarrolla en la identidad sabe quién, los datos saben qué, y por eso una organización puede tener un programa de IAM impecable y aun así fallar ante una solicitud de evidencia.
La propia lista de deseos de la encuesta confirma la brecha. Cuando se preguntó qué necesitan para ampliar el uso de agentes, el 53% pidió responsabilidad clara por las acciones de cada agente, el 52% quería una vista centralizada de los accesos de humanos y agentes, y el 51% deseaba una pista de auditoría completa. Solo el 5% dijo que no necesita nada. Observa lo que tienen en común esos tres puntos. Ninguno es un mejor modelo. Los tres son controles de evidencia y atribución.
Esa es la razón arquitectónica para gobernar a nivel de datos. Kiteworks Compliant AI gobierna las interacciones de los agentes con datos regulados a nivel de datos, no a nivel de modelo, así que la aplicación de controles no depende de un prompt, un filtro de seguridad ni de un framework de agente específico. Cada interacción pasa por cuatro controles. El agente se autentica mediante OAuth 2.0 y se vincula al humano que delegó el flujo de trabajo. El acceso se evalúa según la identidad del agente, la clasificación de los datos y el contexto. Los datos se protegen con cifrado validado FIPS 140-3 en tránsito y en reposo. Y cada interacción queda registrada en una pista de auditoría a prueba de manipulaciones con atribución completa, transmitida al SIEM en tiempo real.
El Kiteworks Secure MCP Server aplica el mismo patrón a clientes de IA como Claude y Copilot. Evalúa cada solicitud con controles basados en roles y atributos, así que un cliente de IA solo recibe los datos que la política considera apropiados, y cada acceso a archivos, operación de carpeta y recuperación de datos es autorizado, aplicado y registrado. Como la autenticación OAuth 2.0 hace que cada operación de IA herede los permisos existentes del usuario, el humano y el agente que actúa en su nombre quedan bajo una sola política y una sola pista de auditoría. El motor de políticas de datos es lo que hace que esa política única sea aplicable en todos los canales, y los registros de auditoría son lo que la convierte en algo que un regulador puede revisar.
El principio de diseño es la paridad. Una gobernanza que cubre a las personas pero no a los agentes deja fuera de la pista de evidencia a una población de consumidores de datos en rápido crecimiento. Una gobernanza que cubre a los agentes pero ignora a los humanos que delegaron en ellos rompe la cadena de responsabilidad. Ambas fallan la misma auditoría.
Qué cambiar antes de la próxima solicitud de auditoría
Nada de esto requiere una nueva categoría de herramienta antes de requerir una decisión. Empieza por las decisiones, porque la tecnología solo aplica lo que alguien ha documentado.
Asigna un responsable a cada agente. El 65% que dice que otra persona debería ser responsable te está diciendo que nunca se hizo la asignación, así que hazla. El responsable puede ser un rol en vez de una persona, pero debe ser un rol nombrado al que un regulador pueda contactar. Aquí es donde comienza el zero trust para IA generativa: ningún agente es confiable por defecto y cada agente está vinculado a un humano que responde por él.
Haz un inventario de lo que tienes. Si un tercio de tu personal de TI y seguridad no puede decir cuántos agentes e identidades no humanas existen, el inventario es el primer entregable. Incluye las credenciales que tiene cada agente y dónde se almacenan.
Mueve los agentes bajo la misma gobernanza de gestión de identidades y accesos que los humanos, con credenciales de corta duración y sin secretos persistentes en herramientas de chat. Luego añade políticas a nivel de datos, para que la identidad controle el acceso y la política controle lo que sale.
Prueba el kill switch. Solo el 30% de los encuestados en la investigación de Kiteworks tenía uno implementado, y un control que nadie ha probado es solo una hipótesis, no un control real. Haz un simulacro que detenga a un agente y mide cuánto tiempo tardas en mostrar exactamente qué tocó.
Por último, practica la solicitud de evidencia. Elige un agente, una semana y una pregunta tipo regulador, y genera el registro. Si ese ejercicio toma semanas, has encontrado la brecha antes de que lo haga un examinador.
El patrón en la encuesta, la investigación de CISOs y las recomendaciones del NCSC es consistente. El acceso avanzó primero. La responsabilidad va detrás. Las organizaciones que cierren esa distancia serán las que traten el acceso de agentes como una actividad gobernada, atribuible y generadora de evidencia desde la primera solicitud.
Para saber más sobre cómo gobernar el acceso a datos de agentes de IA en entornos regulados, solicita una demo personalizada hoy.
Preguntas frecuentes
En general, no. Los reguladores imponen obligaciones sobre los datos y la organización que los gestiona, sin importar si una persona o un agente accedió al registro. Por ejemplo, los requisitos de la Regla de Seguridad de HIPAA para la identificación única de usuarios y controles de auditoría no hacen distinción para IA, así que un agente que accede a información de salud protegida electrónica debe ser rastreable. Trata a los agentes como una segunda clase de identidad bajo el mismo modelo de gobernanza y vincula su actividad a la misma evidencia de GRC que ya produces para usuarios humanos.
La encuesta muestra que las organizaciones no han resuelto esto. Los encuestados señalaron al liderazgo del equipo (24%), el usuario (19%), el liderazgo de la empresa (17%) y el equipo de seguridad (13%), y el 65% dijo que otra persona debería ser responsable. El enfoque más sólido es asignar un responsable nombrado a cada agente antes de la implementación y vincular el agente al humano que delegó su flujo de trabajo. Kiteworks Compliant AI vincula cada agente al humano que lo autorizó y registra las interacciones en una pista de auditoría con atribución completa, para que el responsable sea visible y no reconstruido después.
Úsala como orientación, no como prueba. La encuesta de 1Password es autoinformada, cubre solo empleados de EE. UU. y proviene de una empresa que vende gestión de identidades y secretos. Su valor es que otras fuentes, como la investigación de CISOs de Vorlon y el blog del NCSC del Reino Unido sobre IA agente, apuntan en la misma dirección. Construye el programa sobre tu propio inventario y pruebas de evidencia, y usa la encuesta para justificar su realización. Un enfoque de intercambio de datos de confianza cero se basa en la verificación, no en las promesas, lo que aplica tanto a la investigación como al acceso.
En parte. Solo el 35% de los encuestados gestiona agentes bajo procesos existentes de IAM, y la identidad responde quién solicita, pero no qué datos puede usar un agente ni para qué propósito. Extiende la gobernanza de identidad a los agentes y añade políticas evaluadas por solicitud según la clasificación de datos y el contexto, para que el agente reciba solo los datos mínimos necesarios. La Regla de Mínimo Necesario de HIPAA es un buen modelo de cómo funciona ese principio en la práctica. El Kiteworks Secure MCP Server muestra cómo la aplicación por solicitud puede estar delante de los clientes de IA.
Deberías poder mostrar qué humano delegó en el agente, qué datos accedió, qué política lo permitió, si los datos estaban cifrados y un registro a prueba de manipulaciones de cada operación. Practica la generación de ese paquete y mide el tiempo que toma. En la encuesta, el 51% dijo que una pista de auditoría completa es algo que desean para ampliar el uso de agentes, y ese es un estándar razonable. Comienza confirmando que tus registros de auditoría capturan la actividad de agentes con la misma atribución que la actividad humana, y luego practica la solicitud.
Recursos adicionales
- Artículo del Blog
Estrategias Zero‑Trust para una protección de privacidad de IA asequible - Artículo del Blog
Cómo el 77% de las organizaciones falla en la seguridad de datos de IA - eBook
Brecha de gobernanza de IA: Por qué el 91% de las pequeñas empresas juega a la ruleta rusa con la seguridad de datos en 2025 - Artículo del Blog
No existe un «–dangerously-skip-permissions» para tus datos - Artículo del Blog
Los reguladores ya no preguntan si tienes una política de IA. Quieren pruebas de que funciona.