Solo el 14,4% de las organizaciones aprueba cada agente de IA antes de que entre en funcionamiento
Los ejecutivos confían en la seguridad, pero la telemetría no lo respalda. En una encuesta a más de 900 ejecutivos y profesionales técnicos, el 82% de los ejecutivos afirmó estar seguro de que sus políticas actuales los protegen de acciones no autorizadas de agentes de IA, mientras que la misma investigación reveló que menos de uno de cada seis organizaciones pone en marcha cada agente con la aprobación completa de seguridad e IT. Ambas afirmaciones no pueden ser ciertas por mucho tiempo, y la distancia entre ellas es donde se está gestando el próximo hallazgo de auditoría.
Esa brecha no es un problema tecnológico que espera una mejor herramienta. Es un problema de evidencia. Cuando un agente accede a datos regulados, un regulador, un evaluador o un abogado contrario preguntará quién autorizó al agente, a qué datos accedió y bajo qué norma. Una política escrita no responde ninguna de esas preguntas. Un registro a prueba de manipulaciones que vincule cada acción con una identidad y una decisión de política responde las tres.
Este artículo utiliza los resultados de la encuesta para mostrar dónde la gobernanza de agentes funciona y dónde falla, dirigido al CISO y al Chief Compliance Officer que deben respaldar la respuesta. El intercambio seguro de datos de Kiteworks está diseñado en torno a esa pregunta de evidencia, y el argumento a continuación aplica las mismas reglas tanto a los agentes como a las personas que les delegan tareas.
Conclusiones clave
1. La aprobación va por detrás de la implementación.
Los agentes llegan a producción antes de que seguridad e IT den el visto bueno, lo que significa que la revisión que la mayoría de las políticas asume no ocurre para la mayoría de los agentes.
2. La confianza no es control.
Una política escrita que ningún sistema aplica en el punto de acceso a los datos es solo una declaración de intenciones, y un auditor la leerá como tal.
3. Un agente sin identidad no deja evidencia.
Las credenciales compartidas y los agentes no supervisados eliminan el vínculo entre una acción y una persona responsable, y un investigador necesita cada eslabón.
4. Los reguladores regulan datos, no modelos.
Las mismas expectativas de divulgación y protección aplican tanto si una persona como un agente accedió al registro.
5. La propiedad es la brecha más fácil de cerrar.
Nombrar a una persona responsable de lo que los agentes pueden leer, escribir y compartir cuesta poco y hace que cualquier control posterior sea defendible.
Las cifras detrás de la brecha de aprobación
El informe State of AI Agent Security 2026 de Gravitee, publicado en febrero de 2026 y basado en más de 900 ejecutivos y profesionales técnicos, encontró que el 80,9% de los equipos técnicos ya pasaron de la planificación a las pruebas activas o producción. Solo el 14,4% informó que todos sus agentes de IA entraron en funcionamiento con la aprobación total de seguridad e IT. Si pones esas dos cifras lado a lado, la secuencia es clara. Los agentes se lanzan primero y la conversación de aprobación viene después, si es que llega.
Lee la fuente antes de confiar en los números. Gravitee vende gestión de APIs, y una encuesta de un proveedor no es una muestra aleatoria de la economía. Las cifras deben tratarse como orientativas. Aun así, son útiles aquí porque la tendencia coincide con lo que los líderes de seguridad describen en privado. Nadie reporta que los agentes esperan pacientemente a un comité de revisión.
El mismo informe encontró que el 88% de las organizaciones confirmaron o sospecharon un incidente de seguridad relacionado con agentes de IA. Esa cifra debe interpretarse con cuidado. El número de incidentes indica cuántas veces algo salió mal. No dice si la organización pudo explicar qué pasó, a quién, con qué datos y bajo la autoridad de quién. Al CISO y al Chief Compliance Officer se les mide por la explicación, no por el conteo.
La consecuencia es una población de agentes que los equipos de seguridad y cumplimiento no conocieron antes de su lanzamiento. No saben a qué podía acceder cada agente, qué credenciales utiliza ni si puede iniciar otros agentes. Cada agente no revisado es una pregunta sin respuesta esperando a un examinador, y las preguntas se multiplican con cada equipo que lanza uno.
Confías en que tu organización es segura. Pero ¿puedes comprobarlo?
Leer ahora
La confianza no es un control
El hallazgo más incómodo de la encuesta es el de la percepción. Gravitee informó que el 82% de los ejecutivos se siente seguro de que sus políticas los protegen de acciones no autorizadas de agentes, mientras que en promedio solo el 47,1% de los agentes de una organización están realmente monitoreados o protegidos. Los ejecutivos no mienten. Razonan a partir de la mejor información que tienen, que es una política escrita.
Eso es teatro de gobernanza, y vale la pena nombrarlo sin desprecio. Una política describe lo que la organización pretende. Un control es un mecanismo que detiene o registra lo que ocurre, independientemente de que alguien recuerde la política. Entre ambos está el punto en el que un agente accede a los datos, y a la mayoría de los ejecutivos nadie les ha mostrado qué ocurre en ese momento.
Un evaluador los trata de forma distinta. Si pide evidencia de que una política se cumple, el evaluador quiere ver el sistema que la aplica y el registro que demuestra que funcionó. Un archivador de políticas demuestra que alguien escribió una regla. No demuestra que alguna solicitud haya sido evaluada contra esa regla, que es lo único que un examinador puede comprobar.
Como argumenta Bonfy.AI, los agentes de IA no se descontrolaron, simplemente fueron donde nadie miraba, y la ausencia de un observador es una condición de gobernanza más que un fallo del agente. Cerrar la brecha de confianza implica poner un observador, y un aplicador, en el punto de acceso, y luego guardar el registro en un lugar donde el agente no pueda alterarlo.
Un prompt de sistema no llena esa brecha. Una instrucción que le diga a un modelo que no acceda a ciertos registros puede ser ignorada por inyección de prompts o alterada por una actualización del modelo, y un evaluador no aceptará «se le dijo al modelo que no lo hiciera» como prueba de control de acceso. La aplicación debe estar con los datos, independiente del modelo, y debe dejar un registro que sobreviva a la sesión.
Agentes sin identidad no dejan evidencia
La identidad es donde la cadena de evidencia se rompe primero. Gravitee encontró que solo el 21,9% de los equipos trata a los agentes como entidades independientes con identidad propia. El resto permite que los agentes actúen con credenciales prestadas, lo que significa que un registro de acceso muestra que algo accedió a un registro, pero no puede decir qué agente lo hizo ni quién lo envió.
Pasa eso por una auditoría. Una credencial compartida no puede identificar al actor. Un actor sin identidad no puede vincularse con la persona que delegó el trabajo. Un flujo de trabajo que nadie monitorea no deja ningún registro. Cada una de esas brechas elimina un eslabón entre una acción y una persona responsable, y una investigación defendible necesita la cadena completa desde la autorización hasta la acción y el resultado.
La práctica de autenticación muestra cómo se forma el hábito. El mismo informe encontró que el 45,6% de los equipos aún depende de claves API compartidas para la autenticación entre agentes. Las claves compartidas son convenientes, y la conveniencia es cómo una brecha de gobernanza se convierte en norma. Nadie decidió hacer anónimos a los agentes. Los equipos reutilizaron lo que ya funcionaba para servicios.
La capacidad agrava el problema. Los agentes que pueden crear y asignar tareas a otros agentes extienden la cadena de delegación con un eslabón que nadie autorizó, y un agente que genera otro agente transmite el acceso que tiene, así que el nuevo agente hereda el alcance de su «padre». No puedes gobernar lo que no puedes atribuir, y un árbol de agentes sin identidad en cada nodo es casi imposible de reconstruir.
La solución es fácil de decir y difícil de implementar. Trata a los agentes y a las personas como dos clases de identidad bajo un mismo modelo de gobernanza. Cada agente actúa en nombre de una persona identificada, dentro de los límites que marca la política, con un registro que vincula cada acción con la persona que la delegó. Eso es atribución, no independencia, y es lo que busca un investigador.
Los reguladores regulan datos, no modelos
Piensa en un sistema de salud cuyo agente lee el registro de un paciente para redactar un resumen y almacena el resultado donde no debería. Nada cambia en el análisis regulatorio porque el actor sea software. La obligación recae sobre la información de salud protegida y las protecciones que la organización dijo tener, y la Ley HIPAA no pregunta si un médico o un programa leyó el registro. Lo mismo aplica para datos de titulares de tarjetas bajo PCI DSS y para datos financieros de clientes bajo GLBA y las expectativas de control de SOX. El asesor legal decide qué es reportable en cada caso concreto, y este artículo ofrece solo información general.
Lo que necesita el Chief Compliance Officer es evidencia que llegue más rápido que el reloj. El Informe Anual de Riesgo de Seguridad y Cumplimiento de Datos de Kiteworks 2026 encontró que el 50% de las organizaciones no puede generar un registro completo de auditoría de acceso a datos de IA en un día hábil, y el 63% reportó una consecuencia de cumplimiento en los últimos doce meses, como un hallazgo de auditoría, un plan de remediación requerido, una escalada a la junta, una penalización contractual o una investigación regulatoria formal. Los plazos de notificación y las líneas de tiempo de los evaluadores se miden en días, y un paquete de evidencia que tarda semanas es un riesgo en sí mismo.
La brecha de evidencia es la versión del problema para el CCO. Los registros suelen existir, pero un registro no es evidencia hasta que vincula una acción con una identidad, una decisión de política y una marca de tiempo que no pueda alterarse después. Una pista de auditoría sólida marca la diferencia entre decirle a un examinador lo que probablemente ocurrió y mostrarle lo que realmente pasó.
El sector financiero ilustra bien lo que está en juego. Los supervisores esperan que las empresas protejan datos de liquidación, tesorería y clientes sin importar quién los haya tocado, y las organizaciones de servicios financieros que adoptan agentes para productividad deben ahora extender esas expectativas a toda identidad que pueda acceder a contenido regulado. El mismo razonamiento aplica para salud, legal y la Base Industrial de Defensa.
Cómo se ve un incidente cuando nadie aprobó el camino
Un caso reciente y concreto muestra cómo se manifiesta la brecha. Cybernews informó que agentes de codificación de IA expusieron más de 13.000 capturas de pantalla internas de 343 empresas tecnológicas en repositorios públicos de GitHub, incluyendo registros de clientes, datos de facturación, pantallas de sistemas de pago y características de productos no lanzados. Los agentes no podían adjuntar imágenes a pull requests privados, así que las publicaron como solución alternativa.
Nada en esa secuencia requirió un atacante. Los agentes estaban completando una tarea con permisos que ya tenían, y ninguna política prohibía la solución alternativa en una forma que el software pudiera aplicar. Es la brecha de aprobación en miniatura: una acción realizada sin una decisión a la que alguien pudiera apuntar, sobre datos que los reguladores protegen, sin un registro que el equipo de cumplimiento pudiera entregar.
La lección para el CISO no es que los agentes de codificación sean peligrosos. Es que autoridad y permiso no son lo mismo. Tener el permiso para crear un repositorio público no es igual que tener la autoridad para publicar datos internos en él, y los permisos no determinan qué puede usar la IA. La mayoría de los entornos aún no puede distinguir entre ambos.
La lección para el Chief Compliance Officer es la cuestión de la evidencia. Tras un incidente como este, la organización debe mostrar quién autorizó la salida de los datos, qué norma gobernó la decisión y dónde está el registro. Si la respuesta es «tendríamos que reconstruirlo», la organización ya va por detrás del reloj del regulador.
La IA en la sombra amplía la brecha más rápido de lo que la política la cierra
El Informe de IBM sobre el costo de una filtración de datos 2026 pone cifras al costo. Los incidentes de IA en la sombra representaron el 43% de las filtraciones en su muestra, frente al 20% del año anterior, y costaron más, con un promedio de 5,39 millones de dólares. El 68% de las organizaciones afectadas carecía de gobernanza para gestionar la IA o detectar IA en la sombra, y el 92% de las que sufrieron una filtración relacionada con IA carecían de controles de acceso adecuados para IA.
Esas cifras describen organizaciones que adoptaron IA más rápido de lo que construyeron los controles para verla. La brecha de aprobación en los datos de Gravitee es la misma historia a nivel de una sola canalización de implementación. Un agente que llega a producción sin revisión es IA en la sombra con otro nombre, aunque el equipo que lo creó no lo vea así.
Los datos de uso muestran por qué la brecha se amplía. El Informe de Investigaciones de Filtración de Datos 2026 de Verizon encontró que el 45% de los empleados ahora usan IA regularmente en dispositivos corporativos, frente al 15% del año anterior. El porcentaje que lo hace a través de cuentas no corporativas, con un 67%, bajó ligeramente, así que no se trata de un uso en la sombra descontrolado. Es una triplicación del uso general, con una mayoría persistente fuera de la capa de identidad que el equipo de seguridad puede ver.
La adopción también se fomenta desde arriba. El Informe de Gobernanza AI-Ready 2026 de OneTrust, basado en 1.200 altos directivos de ocho mercados, encontró que el 87% de las organizaciones fomenta el uso de agentes de IA, mientras que solo el 47% tiene gobernanza, supervisión y controles claros para los agentes. Es una encuesta patrocinada por un proveedor y debe leerse como orientativa, pero una brecha de cuarenta puntos entre fomento y control es una brecha de responsabilidad antes que una tecnológica.
Qué cambiaría la gobernanza en la capa de datos y qué no
Kiteworks Compliant AI gobierna la interacción de los agentes con datos regulados en la capa de datos, independiente del modelo, el prompt o el framework del agente. Cada interacción pasa por cuatro puntos de control. El agente se autentica mediante OAuth 2.0 y se vincula con la persona que delegó el flujo de trabajo. Una política basada en atributos evalúa la solicitud en tiempo real según la identidad del agente, la clasificación de los datos y el contexto, aplicando el acceso mínimo necesario a nivel de operación. El cifrado validado FIPS 140-3 está disponible para proteger los datos en tránsito y en reposo. Una pista de auditoría a prueba de manipulaciones registra la interacción con atribución completa y la envía al SIEM del equipo de seguridad.
El Servidor MCP Seguro de Kiteworks pone ese modelo delante de clientes de IA como Claude y Copilot. Cada solicitud se evalúa contra controles de acceso basados en roles y atributos a través del Data Policy Engine, por lo que un cliente de IA solo recibe los datos que la política considera apropiados. Los tokens OAuth se guardan en el almacén de claves del sistema operativo y nunca se exponen al modelo de lenguaje, y el contenido de los archivos que transfiere el servidor no se añade al contexto del modelo sin una acción explícita del usuario. Antes de una descarga, el servidor verifica el estado de los análisis de antivirus y prevención de pérdida de datos, y los administradores pueden desactivar herramientas destructivas o restringir qué herramientas se exponen a los agentes.
Imagina qué pasaría si los agentes accedieran a sistemas y datos internos solo a través de una ruta gobernada de este tipo. Cada solicitud estaría vinculada a un responsable humano, evaluada según la política y registrada, así que la organización tendría un registro que responde quién, qué y bajo qué norma. El CCO tendría evidencia para entregar a un examinador, y el CISO tendría un punto de control que no depende de que el agente actúe bien. Un enfoque de confianza cero para IA generativa aplica el mismo principio, sin confianza implícita en la identidad o intención del agente.
El alcance de esa afirmación importa. Una capa de datos gobernada controla a qué pueden acceder los agentes a través de ella y registra lo que hacen. No controla una captura de pantalla que un agente toma de la pantalla de un desarrollador, ni impide la creación de un repositorio público en una cuenta personal. Los controles que limitan esos destinos deben estar junto a la gobernanza de la capa de datos, no en su lugar. Juntos, cubren tanto los datos que un agente puede solicitar como los destinos que puede usar.
Guía de gobernanza para CISOs y responsables de cumplimiento
Empieza por la propiedad. Nombra a un ejecutivo responsable de lo que los agentes pueden leer, escribir, publicar y compartir, y dale autoridad sobre ingeniería, seguridad y cumplimiento. La propiedad de la seguridad de IA está indefinida en la mayoría de las organizaciones, con distintos líderes reclamando el puesto según a quién se pregunte, y ningún control técnico compensa una silla vacía.
Luego, crea un inventario de todos los agentes en producción y en pruebas. Registra quién lo creó, quién delegó su trabajo, qué credenciales usa, a qué datos puede acceder y si puede iniciar otros agentes. Las cifras de Gravitee sugieren que la mayoría de las organizaciones no puede generar esa lista hoy, así que el primer entregable es una lista, no una herramienta.
En tercer lugar, da a cada agente una identidad vinculada a la persona que lo autorizó y elimina las claves compartidas para la autenticación entre agentes. Aplica las mismas reglas de clasificación y manejo de datos a lo que los agentes leen y producen que aplicas a las personas, incluyendo imágenes y grabaciones que escapan a controles orientados a texto.
En cuarto lugar, aplica la política donde el agente accede a los datos, no donde la política está escrita. Una regla que está en un manual y que nadie revisa es una regla que un evaluador descartará. Combina la aplicación con un proceso de respuesta a incidentes documentado que ya cubra eventos causados por agentes.
Por último, ensaya la evidencia. Elige un flujo de trabajo de agente, pide al equipo que genere el registro completo de lo que accedió el agente y quién lo autorizó, y cronometra el resultado. Un dashboard de CISO que muestre la actividad de agentes junto a la de personas da la respuesta en minutos. Si el ejercicio tarda una semana, la organización ha encontrado su exposición real antes que el regulador.
La pregunta de responsabilidad que toda junta hará a continuación
La brecha de aprobación no se cerrará sola, porque toda la presión va en una sola dirección. Los equipos de negocio son recompensados por lanzar agentes, y la revisión se recompensa solo cuando algo sale mal. Los agentes de IA rompen los modelos tradicionales de seguridad precisamente porque esos modelos asumían que una persona se detendría en el momento de decidir.
Las juntas harán dos preguntas en el próximo ciclo. ¿Quién es responsable de lo que hacen nuestros agentes y podemos demostrarlo? Los líderes que puedan responder ambas con un responsable identificado, un inventario de agentes y un paquete de evidencia tratarán las cifras de la encuesta como una referencia que superan. Los que no puedan, verán que esas cifras describen su propia organización.
Para saber más sobre cómo gobernar el acceso a datos de agentes de IA con evidencia lista para auditoría, solicita una demo personalizada hoy.
Preguntas frecuentes
La brecha de aprobación es la distancia entre cuántos agentes de IA están en funcionamiento y cuántos pasaron por una revisión completa de seguridad e IT antes de su lanzamiento. La investigación de encuestas en 2026 encontró que solo el 14,4% de las organizaciones reportó que todos sus agentes entraron en funcionamiento con aprobación total, lo que significa que la mayoría tiene agentes en producción que ningún equipo de seguridad o cumplimiento evaluó, haciendo que la brecha sea una condición base y no una excepción. La brecha importa porque elimina la evidencia que un examinador espera, como quién autorizó al agente y a qué datos puede acceder. Un programa documentado de gobierno, riesgo y cumplimiento que nombre explícitamente a los agentes empieza a cerrarla.
Los ejecutivos razonan a partir de la política escrita, y en papel la política parece completa. Los datos de la encuesta muestran que el 82% de los ejecutivos se siente seguro de que sus políticas los protegen, mientras que en promedio menos de la mitad de los agentes están realmente monitoreados o protegidos. La confianza no es deshonesta, simplemente no está informada sobre la aplicación en el punto de acceso a los datos, y cerrar esa distancia implica mostrar a la dirección cómo es la aplicación solicitud por solicitud en vez de pedirles que confíen en un documento. Un informe que muestre la actividad de agentes junto a la de personas, como un dashboard de CISO, reemplaza la confianza por evidencia.
Un regulador o evaluador buscará un registro que vincule cada acción de un agente con una identidad, una decisión de política y una marca de tiempo inalterable. El registro debe mostrar la persona que delegó el flujo de trabajo, los datos accedidos y la norma que permitió o bloqueó la solicitud. El Informe Anual de Riesgo de Seguridad y Cumplimiento de Datos de Kiteworks 2026 encontró que el 50% de las organizaciones no puede generar un registro completo de auditoría de acceso a datos de IA en un día hábil, así que ensaya la recuperación antes de que llegue la solicitud. Registros de auditoría centralizados que cubran personas y agentes en un solo lugar hacen que la recuperación sea repetible.
Sí, porque las obligaciones se aplican a los datos. HIPAA, PCI DSS, las expectativas de control de SOX y marcos similares requieren controles de acceso, cifrado y pistas de auditoría para datos regulados, y esas expectativas aplican igual cuando un agente accede a ellos. Esperar reglas específicas para agentes deja a la organización expuesta mientras tanto, porque los reguladores esperan desde hace tiempo que los controles de acceso cubran toda identidad que pueda acceder a datos regulados. Una revisión contra HIPAA y los demás marcos que rigen tus datos, con los agentes nombrados explícitamente, cierra la brecha.
La respuesta honesta es que muchas organizaciones no lo han decidido, y eso ya es un hallazgo en sí. Distintas encuestas ponen a diferentes ejecutivos en el puesto de responsable, y una gran parte de las organizaciones reporta que no hay una responsabilidad clara en todo el ciclo de vida de la IA. La solución es organizacional antes que técnica. Nombra a un ejecutivo responsable, documenta la cadena de delegación de persona a agente y ancla ambos en tu programa de gobernanza de datos de IA, con Kiteworks Compliant AI cubriendo los controles en la capa de datos.
Recursos adicionales
- Artículo del Blog
Estrategias de confianza cero para una protección asequible de la privacidad en IA - 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 «–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.