Uno de cada cinco organizaciones sufre incidentes de Shadow AI

Tu política de gobernanza de IA no sirve de nada si un empleado puede conceder acceso a una herramienta de IA a Microsoft 365 antes de que TI se entere. Ese es el incómodo centro de una nueva investigación de DNSFilter, que informa que el 20,1% de las organizaciones encuestadas ya han experimentado un incidente de seguridad vinculado a una conexión de IA no aprobada. Este hallazgo se acompaña de otro dato aún más difícil de justificar: más de la mitad de esas mismas organizaciones afirman tener controles de gobernanza o monitoreo de IA.

DNSFilter publicó los resultados el 3 de noviembre de 2026 en El costo de la IA en la sombra, como parte de su serie de encuestas Visibility Deficit 2026. La empresa encuestó a 400 profesionales de TI y ciberseguridad en cargos de gerente o superiores, en empresas de 150 a 5.000 empleados en Estados Unidos y Canadá, del 15 al 26 de junio de 2026, en colaboración con la firma de investigación Censuswide. Estas son respuestas autodeclaradas recogidas por un proveedor que vende filtrado DNS, por lo que describen lo que dicen los encuestados, no lo que encontraría una auditoría. Tómalas como una señal clara sobre las organizaciones medianas de Norteamérica, y no como algo más general.

Para un CISO o Chief Compliance Officer, la señal es contundente. El control que pedirán los reguladores y auditores no es el documento de política. Es la prueba de que cada sistema de IA que accede a contenido sensible fue autorizado, restringido y registrado, y que puedes presentar esa prueba en cuestión de días. El intercambio seguro de datos de Kiteworks está diseñado en torno a ese problema de evidencia, y el resto de este artículo explica por qué los números de DNSFilter lo hacen urgente.

Puntos clave

1. Una de cada cinco organizaciones ya ha tenido un incidente de IA en la sombra.

La encuesta de DNSFilter reveló que el 20,1% de los encuestados relacionaron un incidente de seguridad con una conexión de IA no aprobada.

2. Los controles de gobernanza y las conexiones no aprobadas coexisten.

El 54,0% de los encuestados usa controles de gobernanza o monitoreo de IA, pero el 46,1% tuvo un empleado que conectó una herramienta de IA no aprobada a Google Workspace, Microsoft 365 o single sign-on.

3. La notificación posterior es el modelo de aprobación dominante.

DNSFilter encontró que el 43% de las organizaciones se enteran del acceso de IA solo después de que se concede, o nunca.

4. La proliferación de agentes es la siguiente versión del mismo problema.

Los asesores de Morgan Stanley realizaron casi 50.000 intentos de crear agentes de IA, y los agentes que nadie adoptó no se revisan de forma integral.

5. La evidencia supera a la política.

Los reguladores regulan los datos, no los modelos, así que la posición defendible es un registro que muestre quién o qué accedió a qué contenido, bajo qué política y con qué resultado.

Qué midió realmente la encuesta de DNSFilter

El dato principal es ese 20,1%. Aproximadamente uno de cada cinco encuestados dijo que una conexión de IA no aprobada ya había provocado un incidente de seguridad. El comunicado no dice cómo definieron «incidente» los encuestados, así que no debe interpretarse como una tasa de brechas. Es la proporción de encuestados que vivieron algo que su organización clasificó como incidente de seguridad.

La segunda cifra explica cómo ocurren esos incidentes. En la encuesta, el 46,1% de las organizaciones tuvo un empleado que conectó una herramienta de IA no aprobada a Google Workspace, Microsoft 365 o su proveedor de single sign-on. Estas tres plataformas son donde vive el contenido empresarial sensible, lo que significa que una conexión de IA no aprobada ahí no es un simple experimento de navegador. Es un nuevo actor con una concesión OAuth sobre los sistemas que contienen contratos, registros de clientes y datos regulados.

Piénsalo en la práctica: un empleado hace clic en «Permitir» en una pantalla de consentimiento. La herramienta de IA ahora puede leer correos, archivos o datos de calendario bajo la identidad de ese empleado, indefinidamente, hasta que alguien revoque el acceso. No se generó un ticket ni se realizó una revisión de seguridad. El acceso es legítimo desde el punto de vista del proveedor de identidad, porque el usuario lo autorizó.

Esa es la brecha de autorización, y por eso los permisos no determinan lo que la IA debería poder usar. Los sistemas de identidad responden a la pregunta «¿este usuario aprobó esta app?» pero no a «¿debería esta app, actuando por este usuario, leer este contenido?» La distancia entre esas dos preguntas es donde vive la IA en la sombra.

Por qué las políticas fallan en la pantalla de consentimiento

Los datos de DNSFilter sobre los flujos de aprobación son lo más útil del informe. De las organizaciones cuyos empleados usan herramientas de IA para trabajar, el 36,8% permite que los empleados concedan acceso OAuth o API y notifiquen a TI después. Otro 6,5% no envía ninguna notificación. En conjunto, la encuesta sitúa en el 43% la proporción que se entera del acceso de IA solo después de que se concede, o nunca.

Lee esos números como una arquitectura, no como una falta de disciplina. Una organización que permite la autoaprobación de empleados y avisa a TI después ha priorizado la velocidad sobre la revisión, normalmente por razones de negocio válidas. El problema es que el modelo de notificación produce un registro de la concesión, no una decisión sobre el contenido al que da acceso esa concesión.

La otra mitad del rompecabezas es el número de controles. Con el 54,0% de los encuestados ejecutando controles de gobernanza o monitoreo de IA, cabría esperar que las conexiones no aprobadas fueran raras. Sin embargo, casi la mitad sigue reportando una. La interpretación honesta es que el monitoreo te dice que existe una conexión, mientras que la gobernanza decide a qué puede acceder esa conexión. La mayoría de las organizaciones ha invertido en lo primero. Esa es la brecha entre detección y control que pocos programas han cerrado.

Esa distinción es clave para la exposición en auditoría. Un auditor no pregunta si puedes ver el tráfico de IA. Un auditor pregunta si puedes demostrar que el acceso a un registro regulado fue autorizado, que la autorización se aplicó en el momento del acceso y que quedó registrado en un log resistente a manipulaciones. Un panel que cuenta las herramientas de IA conectadas no responde a ninguna de esas preguntas.

La brecha de visibilidad es mayor de lo que creen los líderes

El CEO de DNSFilter, Ken Carnesi, hizo una afirmación que merece atención. Aproximadamente una de cada siete organizaciones en la red de DNSFilter ve más de 10 herramientas de IA en uso, mientras que menos de una de cada 100 líderes de TI cree que eso ocurre en su entorno. El informe completo respalda ambos lados. Sus datos de red cubren 3.400 millones de solicitudes a herramientas de IA generativa de más de 43.000 organizaciones norteamericanas en agosto de 2026. Contando proveedores de IA distintos en un día laboral estándar, la organización mediana ve cinco, y el 15,2% ve más de 10. En la encuesta, solo el 0,5% de los profesionales de TI dijo que sus empleados usan más de 10 herramientas de IA, lo que hace que la cifra de red sea 30 veces mayor que la autodeclarada.

Observa qué mide la cifra de red. Cuenta los proveedores de IA distintos que aparecen en el tráfico DNS, así que muestra uso, no necesariamente una integración aprobada o autorizada. Ambos datos provienen de DNSFilter, cuyos datos de red se extraen de sus propios clientes y cuyo informe termina invitando a probar su producto. Ninguno de los dos es independiente. Aun así, la tendencia coincide con lo que reportan los profesionales en otros lugares, por lo que merece atención en vez de ser descartada.

El lado del control se ve débil en el mismo informe. De todo ese tráfico, solo el 0,75% de las solicitudes a IA generativa fueron bloqueadas, y DNSFilter interpreta esto como que la mayoría de las organizaciones no ejerce el control que su gasto en gobernanza pretendía comprar. Por separado, el 61,5% de los encuestados no puede afirmar que todas las herramientas de seguridad en su entorno estén correctamente configuradas, y el 61,8% no puede decir que todas estén siendo monitoreadas activamente. Permitir la IA es una decisión de política válida. Permitirla por defecto, sin una decisión, es otra cosa.

El Informe de Investigaciones de Brechas de Datos 2026 de Verizon ofrece una perspectiva más sólida sobre el mismo comportamiento. Basándose en registros de prevención de pérdida de datos en vez de encuestas, encontró que el 67% de los usuarios accede a servicios de IA mediante cuentas no corporativas en dispositivos corporativos, y que el 45% de los empleados ahora son usuarios habituales de IA en dispositivos corporativos, frente al 15% del año anterior. La IA en la sombra se convirtió en la tercera acción interna no maliciosa más común del conjunto de datos, cuadruplicando su frecuencia.

Pon las dos fuentes lado a lado y aparece un patrón. El uso de IA en el trabajo ya no es un caso aislado, y una gran parte ocurre mediante cuentas que la organización no puede ver ni gobernar, una deriva que los equipos de seguridad ahora describen como la IA en la sombra moviéndose al navegador. Las cifras de Verizon cubren de octubre de 2024 a noviembre de 2025, y provienen de incidentes y datos DLP que los contribuyentes eligieron compartir, así que no son un censo. Sin embargo, es un método diferente que llega a una conclusión compatible.

La consecuencia práctica para un Chief Compliance Officer es que «tenemos una política de IA» y «sabemos dónde la IA accede a datos regulados» son afirmaciones distintas. Solo la segunda resiste la repregunta de un regulador.

La proliferación de agentes en Morgan Stanley es el anticipo

La IA en la sombra no es solo empleados pegando texto en un chatbot. El siguiente nivel es empleados creando agentes. American Banker informó el 2 de noviembre de 2026 que los asesores de Morgan Stanley han realizado casi 50.000 intentos de construir agentes de IA mediante prompts en lenguaje natural, principalmente para automatizar tareas rutinarias.

El detalle relevante está en lo que ocurre después. Koren Maranca, responsable de IA para la división de gestión patrimonial de la firma, dijo a la publicación: «A veces la gente crea un agente, lo usa dos veces y luego nunca lo vuelve a tocar». Los agentes que adopta el equipo de un asesor pasan por revisión y aprobación después de su uso, según el artículo, mientras que los agentes huérfanos no se revisan de forma integral.

Morgan Stanley es una firma con muchos recursos y fuertemente regulada, y describe que tiene controles en vigor. También lleva a cabo un gran esfuerzo de revisión, con más de 1.000 personas revisando resultados de modelos antes de pasar a producción, y reporta que aproximadamente la mitad de las consultas de los asesores ahora son atendidas primero por un agente de IA. Es una empresa que se toma el trabajo en serio. Aun así, el modelo de revisión posterior deja una población de agentes abandonados cuyo acceso fue concedido y nunca se revisó.

Observa el paralelismo con el hallazgo de DNSFilter. En ambos casos, el acceso se concede primero y se revisa después. En ambos, lo que queda es un permiso permanente vinculado a una identidad humana. Un agente olvidado conserva credenciales igual que una concesión OAuth olvidada.

Por eso los agentes deben gobernarse junto con los humanos que los crean, bajo el mismo motor de políticas y el mismo registro de auditoría. Un agente no es una especie de riesgo aparte que requiera un programa separado. Actúa en nombre de una persona, hereda su alcance y debe estar limitado a su autorización y nada más. El problema de fondo es la autoridad delegada en los flujos de trabajo de IA, y necesita un responsable asignado. Cualquier enfoque que trate a los agentes como no gobernados hasta que llegue una nueva herramienta describe mal el problema, porque los controles de acceso ya existen y solo deben aplicarse.

Los profesionales lo ven, y la política por sí sola no lo soluciona

Una cuarta fuente aporta la perspectiva de los profesionales. La encuesta de O’Reilly a 209 profesionales de seguridad, realizada en septiembre de 2026, encontró que el 49% señaló como principal preocupación que los empleados filtren datos sensibles mediante herramientas de IA comerciales, empatado con la excesiva confianza en resultados de IA no verificados. La muestra es pequeña y autoseleccionada, sin margen de error declarado, así que sirve para marcar tendencia, no precisión.

Dentro de esa muestra, la IA en la sombra se reportó como generalizada por el 17% de los encuestados cuyas organizaciones tenían una política de IA integral, frente al 35% donde la política era básica y al 37% donde no había ninguna. Los subgrupos son pequeños y no se informa su tamaño, y la relación es una asociación, no una prueba de que la política cause menos IA en la sombra. Aun así, la diferencia sugiere que la calidad de la política importa, y que una política débil funciona tan mal como no tener ninguna.

Los agentes también aparecen en la misma encuesta. Cuando se preguntó por el mayor riesgo relacionado con agentes, el 28% eligió permisos excesivos o propiedad poco clara, la mayor proporción de todas las opciones. La propiedad poco clara es el vacío de responsabilidad que ilustran los agentes huérfanos de Morgan Stanley. Alguien creó el agente, nadie lo asume y sus permisos permanecen.

Aquí cabe una nota de precaución, en el espíritu de leer con cuidado los datos de los proveedores. El Informe CISO 2026 de Vorlon, una encuesta patrocinada por un proveedor a 500 CISOs estadounidenses realizada en enero y febrero de 2026, encontró que el 30,4% experimentó actividad sospechosa de agentes de IA en 2025, y el 86,8% dijo que no puede ver qué datos intercambian las herramientas de IA con aplicaciones SaaS. La muestra es solo de EE. UU. y el proveedor vende en esta categoría. La consistencia entre cuatro muestras, métodos y patrocinadores diferentes es más persuasiva que cualquier cifra individual.

El dinero se mueve hacia la gobernanza, y la prueba es el criterio

Los presupuestos confirman que los líderes sienten la presión. DNSFilter informa que el 74,5% de los encuestados tiene un presupuesto de ciberseguridad mayor que hace 12 meses, el 18,8% lo aumentó en más de un 10% y el 40,3% señaló la seguridad y gobernanza de IA como el destino del próximo dólar incremental de seguridad, frente al 25,5% para la seguridad en la nube. La intención de gastar no es lo mismo que gastar bien, y la encuesta no puede decirnos qué compras cerrarán la brecha.

El gasto en IA dentro de las funciones de cumplimiento también está aumentando. Compliance Week informó sobre la investigación de S-RM que el 78% de 225 profesionales de cumplimiento espera que el gasto en herramientas de cumplimiento y debida diligencia habilitadas por IA aumente alrededor del 24% en los próximos uno o dos años, de unos $337.000 a $416.000. El artículo completo está detrás de un muro de pago, así que solo se citan las cifras iniciales, y miden expectativas, no resultados.

Junta esas dos señales presupuestarias y la imagen es clara. Los líderes de seguridad financiarán la gobernanza de IA, y los equipos de cumplimiento pondrán más documentos sensibles frente a sistemas de IA. Ambos movimientos aumentan las veces que la IA accede a contenido regulado, lo que eleva el valor de la prueba de que cada acceso fue autorizado.

Aquí tienes el criterio para cualquier inversión: imagina que un regulador, un auditor o un abogado contrario pregunta cómo un sistema de IA accedió a un registro específico en un día concreto. ¿Podrías mostrar, en pocos días, la identidad que lo solicitó, la política que lo permitió, el contenido devuelto y el registro que lo documentó? Si la respuesta requiere semanas correlacionando logs de herramientas distintas, el dinero se destinó a visibilidad, no a gobernanza.

Los reguladores regulan los datos, no los modelos. HIPAA no distingue si un registro lo leyó un humano o un agente de IA, y tampoco lo hacen los demás marcos que rigen datos financieros, de defensa y de privacidad. La obligación de controlar y evidenciar el acceso sigue a los datos dondequiera que la IA los lleve.

Gobernar la capa de datos, no solo la herramienta de IA

Si el problema es la distancia entre «el usuario aprobó esta app» y «esta app debería leer este contenido», la solución debe estar donde se accede al contenido. Eso significa aplicar la política en la capa de datos, a cada solicitud, de acuerdo con los principios de seguridad de confianza cero, ya sea que el solicitante sea una persona, un asistente que trabaja para una persona o un agente creado por una persona.

Este es el principio de diseño detrás de Kiteworks Compliant AI y el Secure MCP Server. El MCP Server permite que asistentes de IA como Claude y Copilot trabajen con contenido en Kiteworks mediante el Model Context Protocol. La autenticación utiliza OAuth 2.0, y cada operación se evalúa según políticas de acceso basadas en roles y atributos en el Motor de Políticas de Datos de Kiteworks, así que una IA hereda los permisos del usuario para el que actúa y no puede superarlos. Cada acceso queda registrado en un log de auditoría unificado, que es el registro que pide un auditor.

Dos características de ese diseño responden directamente a los hallazgos de DNSFilter. Primero, la autorización se verifica por solicitud, no solo al conectar, así que una concesión OAuth permanente no se convierte en un permiso permanente a todo lo que el usuario puede ver. Segundo, la entrada de auditoría atribuye el acceso a un sistema de IA específico actuando para un usuario concreto, lo que elimina la ambigüedad de «la IA accedió» que dificulta la respuesta a incidentes y las consultas regulatorias. La gobernanza depende de ese registro, porque no puedes gobernar lo que no puedes atribuir.

Kiteworks no estaba en la ruta de datos de ninguna encuesta o empresa mencionada en este artículo, y la arquitectura no reemplaza las herramientas de descubrimiento que detectan conexiones no autorizadas. La detección de IA en la sombra y la aplicación de políticas en la capa de contenido son tareas distintas. Las organizaciones necesitan ambas, y la segunda es la que genera la evidencia que piden los reguladores.

Para quienes estén construyendo un programa, la arquitectura se basa en unas prácticas concretas que pueden implementarse en orden.

1. Haz un inventario de las concesiones OAuth y API que ya existen contra Google Workspace, Microsoft 365 y tu proveedor de identidad, y revoca las que ningún responsable de negocio reclame.
2. Sustituye la notificación posterior por la aprobación previa para integraciones de IA que puedan acceder a contenido regulado, y limita temporalmente las aprobaciones.
3. Asigna un responsable con nombre a cada agente de IA y expira los agentes que no se hayan usado en un periodo determinado, para que los agentes huérfanos pierdan sus permisos.
4. Aplica políticas a nivel de contenido en las solicitudes de IA como parte de la protección de datos de IA, para que el acceso dependa de la clasificación de los datos y los atributos del usuario, no del consentimiento de la app.
5. Prueba la evidencia. Elige un evento de acceso de IA al azar y mide cuánto tiempo tardas en presentar la identidad, la política, el contenido y el registro correspondiente.

Descubre más sobre la protección de datos de confianza cero para entender por qué cada solicitud, y no solo la conexión inicial, debe ser verificada.

Qué hacer antes de la próxima solicitud de auditoría

Los hallazgos de DNSFilter deben leerse como una invitación a medir tu propia organización. No asumas que estás en el 80% sin incidentes, y una breve revisión del riesgo de IA en tu entorno es la forma más rápida de averiguarlo. Aproximadamente uno de cada cinco encuestados en esta encuesta tampoco lo sabía hasta que ocurrió algo.

Empieza por el dato más fácil de obtener. Cuenta las aplicaciones de IA de terceros que tienen concesiones OAuth sobre tu suite de productividad. Las plataformas de identidad suelen listarlas en una consola de administración, así que el dato se obtiene rápido.

Luego, decide quién es responsable. La responsabilidad de la seguridad de IA está poco definida en la industria, con CIOs, CTOs y CISOs reclamando el puesto según quién haga la encuesta. Esa ambigüedad es el problema a resolver, no un hecho a aceptar. Nombra a un ejecutivo responsable del acceso a datos de IA bajo tu programa de gobernanza de datos y entrega al Chief Compliance Officer y a tu equipo de GRC un informe periódico sobre el registro de evidencia.

Después, cierra el círculo con el área legal y de privacidad. Un Responsable de Protección de Datos o un Consejero General querrán saber, antes de que llegue una consulta, qué sistemas de IA procesaron qué registros regulados. Construir ese registro de auditoría ahora cuesta mucho menos que reconstruirlo bajo la presión de un regulador.

Por último, revisa la suposición detrás de la IA autoservicio. La velocidad es un objetivo válido, y prohibir la IA solo la empuja más a la sombra. El camino viable es la habilitación gobernada, donde los empleados obtienen herramientas aprobadas rápidamente y la aprobación se aplica por política en la capa de datos, no se deja a una pantalla de consentimiento. Los equipos que exploran la gobernanza de datos de IA pueden usar este principio como punto de partida para su programa.

Para saber más sobre cómo generar evidencia lista para auditoría del acceso de IA a contenido sensible, agenda una demo personalizada hoy mismo.

Recursos adicionales

• Artículo del Blog
  Estrategias de confianza cero para proteger la privacidad de IA de forma asequible
• Artículo del Blog
  Cómo el 77% de las organizaciones está fallando 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.