Informe de investigación
Shadow AI y el nuevo problema de la autoridad delegada
Del uso invisible de la IA a la actuación autónoma dentro de la empresa
Resumen ejecutivo
- Shadow AI empieza como un problema de adopción no gestionada, pero los sistemas agénticos lo convierten en una cuestión de autoridad delegada.
- El Shadow AI convencional exige visibilidad sobre herramientas, cuentas, movimiento de datos y retención.
- El Shadow AI agéntico también requiere gobierno de identidad, mínimo privilegio, telemetría de acciones, puertas de aprobación y desaprovisionamiento rápido.
- Los fabricantes describen el problema desde sus planos de control existentes, por lo que hace falta un modelo integrado de evidencias.
Índice
La IA generativa ha entrado en las organizaciones con mayor rapidez que las políticas, los controles y los modelos de responsabilidad necesarios para gobernarla. Los empleados utilizan asistentes públicos para resumir documentos, mejorar mensajes, analizar hojas de cálculo y generar código. Los equipos de desarrollo conectan modelos mediante API y cuadernos de trabajo. Las plataformas SaaS activan funciones de IA dentro de aplicaciones que ya contienen información corporativa sensible.
Gran parte de esta actividad parte de una necesidad legítima de productividad. Un agente de soporte quiere redactar mejor una respuesta. Un desarrollador busca ayuda para interpretar una traza de error. Un profesional financiero necesita resumir un informe extenso. Un equipo jurídico quiere comparar cláusulas contractuales.
El riesgo aparece cuando estas acciones tienen lugar fuera de la visibilidad, la arquitectura aprobada y el marco de control de la organización.
Ese es el ámbito de Shadow AI.
Shadow AI comprende el uso de sistemas, modelos, asistentes y funciones de inteligencia artificial sin un nivel adecuado de conocimiento, gobierno o protección corporativa. Amplía el problema tradicional de Shadow IT hacia un entorno donde los datos pueden ser procesados por modelos externos, los prompts pueden convertirse en instrucciones operativas y los agentes de software pueden recibir autoridad delegada sobre sistemas empresariales.
El objetivo de seguridad debe centrarse en hacer visible, gobernable y protegible el uso de la IA. Las organizaciones necesitan alternativas aprobadas, controles aplicables y procedimientos de respuesta que permitan conservar la productividad y reducir la exposición no gestionada.
La evolución desde Shadow IT hasta Shadow AI
Shadow IT describe tradicionalmente la adopción de aplicaciones, almacenamiento en la nube, mensajería y servicios para compartir archivos sin aprobación formal. El problema central es conocido. Los empleados trasladan información empresarial a sistemas que los equipos de seguridad no pueden evaluar, monitorizar ni controlar adecuadamente.
Shadow AI hereda este problema de visibilidad y añade nuevos canales de exposición.
Un empleado puede copiar información confidencial en un chatbot público. Un desarrollador puede enviar código propietario, credenciales o registros de producción a un asistente de programación. Un usuario de negocio puede cargar informes financieros, contratos, expedientes de clientes o documentos estratégicos en una cuenta personal. Una función de IA integrada en una aplicación SaaS puede recuperar contenidos desde repositorios con permisos excesivos. Un modelo local puede almacenar prompts, respuestas, embeddings y trazas fuera de los sistemas habituales de monitorización y retención.
La IA agéntica introduce una transición adicional.
Un agente puede recibir credenciales, conectarse a plataformas SaaS, invocar herramientas, llamar a API, mantener memoria persistente y ejecutar acciones. Puede enviar mensajes, actualizar tickets, modificar registros, mover archivos, lanzar procesos o comunicarse con sistemas externos.
La pregunta de seguridad cambia.
En el Shadow AI convencional, la preocupación principal consiste en determinar qué datos se envían a un servicio de IA. En los sistemas agénticos, también es necesario saber a qué puede acceder el agente, qué autoridad se le ha delegado y qué acciones puede ejecutar.
El primer problema está relacionado principalmente con la visibilidad y el flujo de datos. El segundo incorpora identidad, permisos y autoridad delegada.
Esta distinción es crítica porque un agente autónomo se comporta como un nuevo actor empresarial. Puede operar de forma continua, utilizar permisos heredados de un patrocinador humano y conservar acceso después de que haya desaparecido la necesidad que justificó su creación. Los controles tradicionales siguen siendo válidos, aunque deben extenderse a identidades no humanas y acciones iniciadas por máquinas.
Los principales patrones empresariales de Shadow AI
Shadow AI no aparece a través de un único canal. Existen varios patrones empresariales, cada uno con mecanismos de exposición y necesidades de evidencia diferentes.
Servicios personales de IA generativa
El patrón más visible consiste en el uso de cuentas personales o servicios públicos de IA generativa. La información se introduce mediante prompts copiados o archivos cargados.
El contenido expuesto puede incluir tickets de clientes, datos personales, información financiera, documentos de recursos humanos, contratos, transcripciones de reuniones, notas estratégicas o registros de seguridad. El usuario puede percibir la interacción como algo temporal, mientras la organización dispone de poca información sobre cómo el proveedor almacena, registra, procesa o reutiliza esos datos.
La exposición suele ser accidental y estar motivada por la comodidad.
IA integrada en plataformas SaaS aprobadas
Un producto SaaS aprobado puede incorporar un copiloto, asistente o agente después de la revisión de seguridad original. Esto crea una forma más sutil de Shadow AI porque la aplicación de base sí está autorizada.
La función de IA puede recuperar contenido desde repositorios, mensajes, documentos y plataformas de colaboración a los que el usuario tiene acceso técnico. Los permisos excesivos y los repositorios compartidos de forma demasiado amplia adquieren mayor importancia cuando una IA puede buscarlos, relacionarlos y resumirlos a escala.
En estos casos, el origen del problema puede encontrarse en el modelo de acceso subyacente.
Asistentes de desarrollo, API y cuadernos de trabajo
La ingeniería de software incorpora riesgos específicos. Los desarrolladores pueden compartir código fuente, trazas, detalles de arquitectura, claves de API, registros de bases de datos o logs de producción con un asistente o una API externa.
Una interacción de programación puede revelar propiedad intelectual e información de infraestructura, además de provocar una exposición inmediata de credenciales. Toda clave incluida en un prompt externo debería tratarse como potencialmente comprometida y rotarse.
Modelos locales y de código abierto
La ejecución local de un modelo puede reducir parte de la exposición a terceros, aunque no establece por sí sola un marco de gobierno.
Los prompts, resultados, embeddings, archivos del modelo y trazas pueden almacenarse fuera de los controles aprobados de monitorización, copia de seguridad y retención. Las instalaciones locales también pueden quedar fuera del inventario de software, la gestión de vulnerabilidades o las políticas de endpoint.
La ubicación del modelo modifica el canal de exposición. La necesidad de gobierno permanece.
La IA agéntica necesita gobierno de identidad
Un agente de IA debe tratarse como un principal empresarial.
Este principio tiene consecuencias directas. Cada agente necesita un propietario identificable, un propósito documentado, un entorno operativo definido y un patrocinador humano responsable de su uso. Sus credenciales, tokens, conectores y permisos deben asociarse a un proceso concreto, evitando accesos generales de carácter permanente.
El ciclo de vida debería cubrir cuatro grandes etapas.
Aprovisionamiento y registro
Antes de entrar en funcionamiento, la organización debe registrar la identidad del agente, su propietario, su finalidad empresarial, el entorno y el principal de servicio asociado. También debe documentar el flujo aprobado y los dominios de datos previstos.
El acceso a herramientas debe ser explícito. Las autorizaciones OAuth, las API y los conectores han de corresponder con las tareas que el agente necesita realizar.
Las acciones sensibles, como enviar mensajes, exportar información, modificar registros o activar procesos, deben disponer de salvaguardas y requisitos de aprobación definidos de antemano.
Revisión de permisos
El patrocinador, la finalidad y la cadencia de revisión del agente deben certificarse de forma semejante a cualquier otra identidad.
La revisión debe incluir autorizaciones OAuth, claves de API, conjuntos de permisos, repositorios conectados, dominios de datos y memoria persistente. Este control adquiere especial importancia cuando las capacidades del agente evolucionan o se incorporan nuevos conectores después de su despliegue.
Mínimo privilegio y control del comportamiento
Los bots genéricos con acceso amplio generan problemas relevantes de responsabilidad y contención. Los agentes deberían vincularse a una tarea definida y utilizar los permisos más limitados posibles.
La memoria persistente no debe convertirse en una forma indirecta de acceso permanente. La organización debe saber qué información se conserva, dónde se almacena y cómo condiciona las acciones futuras.
También hacen falta controles sobre el comportamiento. Las decisiones con baja confianza, los datos sensibles y las acciones de alto impacto deben requerir aprobación humana. Las desviaciones repetidas deberían dar lugar a una reducción de permisos o a la suspensión del agente.
Desaprovisionamiento
El acceso debe finalizar cuando se retire el flujo, abandone la organización su propietario, termine el proyecto o expire la finalidad empresarial.
Los tokens, conectores, permisos y memorias deben revocarse o eliminarse. La organización también necesita un mecanismo de contención rápida capaz de suspender el agente, desactivar el flujo y preservar las evidencias relevantes.
Un agente resulta gobernable cuando la organización puede responder con evidencias a tres preguntas.
¿Quién es su propietario?
¿A qué tiene permitido acceder?
¿Qué acciones ha realizado?
Dos dominios de riesgo y dos modelos de control
Shadow AI convencional y Shadow AI agéntica comparten un origen relacionado con la adopción no gestionada, aunque plantean problemas de seguridad diferentes.
Shadow AI como problema de visibilidad y flujo de datos
La pregunta principal consiste en determinar qué información se está enviando a qué servicio de IA.
Los casos representativos incluyen empleados que utilizan cuentas personales, desarrolladores que envían código o logs a asistentes y plataformas SaaS que incorporan funciones de IA sin una revisión suficiente.
Los controles principales tienen un nivel de madurez considerable.
Las organizaciones pueden utilizar descubrimiento de aplicaciones de IA, identificación de cuentas personales y empresariales, DLP, clasificación de contenido, controles de navegador, restricciones de carga, telemetría de endpoint y entornos corporativos aprobados.
La respuesta habitual puede advertir al usuario, bloquear la interacción, redactar la información sensible o redirigir la actividad hacia un tenant autorizado.
Shadow AI agéntica como problema de identidad y autoridad
La pregunta principal consiste en saber a qué puede acceder el agente, qué puede decidir y qué puede ejecutar.
Entre los casos representativos se encuentran los agentes conectados a aplicaciones SaaS, los copilotos que recuperan contenido desde repositorios con permisos excesivos y los flujos abandonados que mantienen tokens activos después de perder su finalidad.
Los controles correspondientes incluyen inventarios de identidades no humanas, gestión del ciclo de vida de tokens y OAuth, mínimo privilegio, revisión de permisos, puertas de aprobación, registro de acciones, mecanismos de parada y desaprovisionamiento.
La respuesta puede requerir la suspensión del agente, la revocación de tokens, la reducción de permisos o la exigencia de aprobación humana antes de ejecutar acciones sensibles.
Las plataformas actuales ofrecen una cobertura significativa del dominio de flujo de datos. La responsabilidad sobre la autoridad de los agentes sigue más fragmentada. Los equipos de identidad, seguridad SaaS, aplicaciones, cloud y operaciones de seguridad pueden controlar partes diferentes del problema.
Esta fragmentación hace necesario un modelo central de gobierno que evite vacíos entre dominios.
Los casos de uso deben conectarse con evidencias y respuestas
Un caso de uso adquiere valor operativo cuando la organización define qué ha ocurrido, qué evidencias debe recopilar y qué respuesta corresponde aplicar.
Atención al cliente
Un empleado de soporte copia un ticket con datos personales en una cuenta de IA para redactar una respuesta.
Las evidencias útiles incluyen telemetría de copia y pegado, cargas de archivos, indicadores de cuenta personal, clasificación de PII y postura del dispositivo.
La respuesta preferente combina formación y redirección hacia un flujo aprobado. El contexto del cliente debería mantenerse dentro del CRM o de otro sistema corporativo gobernado.
Ingeniería de software
Un desarrollador comparte código, registros de producción, trazas o credenciales con un asistente, una API o un cuaderno de trabajo.
La evidencia debería incluir huellas de código, patrones de tokens, rutas de repositorio, identidad del desarrollador y servicio de destino.
Puede ser necesario bloquear la carga. Los secretos expuestos deben rotarse. El proceso de seguridad debería asumir que una clave externalizada puede haber sido registrada o conservada.
Finanzas y servicios jurídicos
Un usuario carga un contrato, documentación de una adquisición o un informe financiero para resumirlo o reescribirlo.
Las etiquetas de sensibilidad, huellas documentales, vocabulario asociado a la operación, propiedad del archivo y tenant externo constituyen evidencias relevantes.
La organización puede poner en cuarentena la carga, avisar al propietario e involucrar a privacidad o al área jurídica cuando la exposición potencial justifique la escalada.
Copilotos empresariales e IA integrada en SaaS
Un asistente aprobado recupera contenido al que los usuarios pueden acceder técnicamente, aunque su difusión amplia no resulte adecuada.
La investigación necesita registros de consultas, contexto de recuperación, rutas de origen, permisos de repositorio, herencia de acceso y etiquetas de sensibilidad.
La solución duradera consiste en corregir la capa de permisos. Un entorno de IA autorizado sigue dependiendo de un gobierno de acceso limpio.
Agentes conectados a plataformas SaaS
Un agente lee archivos, envía correos, actualiza tickets o publica contenidos utilizando credenciales delegadas.
La investigación necesita identificar el agente, el propietario, la autorización OAuth, los registros del conector, las llamadas a herramientas, los eventos de envío o actualización y los destinos externos.
La contención puede incluir la pausa del agente, la revocación del token y la exigencia de aprobación para operaciones de escritura o envío.
Flujos abandonados
Un flujo automatizado continúa activo después de finalizar el proyecto, desaparecer el propietario o expirar la necesidad empresarial.
La investigación debería revisar la última ejecución, antigüedad del token, permisos, propietario, desencadenantes, actividad del principal de servicio y autorizaciones sin uso.
Los tokens obsoletos deben revocarse y los flujos huérfanos deben desactivarse. Las certificaciones periódicas y las fechas automáticas de caducidad reducen la probabilidad de repetición.
La capacidad de respuesta depende de las evidencias capturadas en el momento de la exposición. Una alerta genérica que indique únicamente el uso de un servicio de IA resultará insuficiente en muchos casos. Los equipos de seguridad necesitan contexto sobre el usuario o agente, tipo de cuenta, clasificación de datos, dispositivo, destino, acción e impacto posterior.
Un modelo operativo de gobierno escalable
Las grandes empresas y los proveedores de servicios gestionados necesitan un modelo que combine salvaguardas centrales con ejecución local.
Los equipos centrales deberían definir principios obligatorios, niveles de riesgo, responsabilidades y reglas de tratamiento de datos. Las unidades de negocio, regiones y tenants pueden aplicar esas bases según sus herramientas aprobadas, obligaciones locales y apetito de riesgo.
Un modelo práctico puede estructurarse en ocho componentes.
El primero es un gobierno central con responsables definidos y adaptaciones locales.
El segundo es un catálogo de IA aprobada que identifique herramientas autorizadas, tenants empresariales, casos de uso adecuados, procesos de incorporación y actividades prohibidas.
El tercero es un modelo de clasificación que relacione la información pública, interna, confidencial y regulada con los destinos y acciones de IA permitidos.
El cuarto es un proceso de excepciones en el que intervengan el propietario del dato, seguridad y los responsables de privacidad o asesoría jurídica. Cada autorización debe contar con una fecha de expiración.
El quinto componente son las métricas sobre descubrimiento, formación, bloqueos, cargas sensibles, excepciones y antigüedad de las remediaciones.
El sexto es la gestión de políticas multitenant, con versiones, líneas base heredadas y excepciones locales controladas.
El séptimo es la integración con el SOC o la capa XDR, enviando eventos de alta confianza acompañados del contexto del dato, la cuenta, la identidad y la acción del agente.
El octavo es la mejora continua a partir de incidentes, excepciones y falsos positivos.
El objetivo es ofrecer una vía práctica hacia el uso autorizado. Cuando los empleados encuentran únicamente prohibiciones, tienden a buscar alternativas menos visibles. El gobierno resulta más eficaz cuando las capacidades aprobadas son fáciles de localizar y encajan en el trabajo real.
Detección y respuesta como un único ciclo basado en evidencias
La detección de Shadow AI debe conectarse directamente con el triaje, la contención y la mejora de controles.
La telemetría relevante se distribuye entre varias capas.
Las plataformas de red y SSE pueden identificar categorías de IA, cargas e indicadores de cuentas personales. Los navegadores y agentes de endpoint pueden observar operaciones de copia y pegado, extensiones, cargas de archivos y aplicaciones locales. Los entornos SaaS y Microsoft 365 aportan registros de uso, etiquetas, auditoría y autorizaciones OAuth. Las herramientas de seguridad de datos añaden clasificación, huellas y detección de credenciales. Las plataformas de identidad aportan contexto sobre usuarios, grupos, dispositivos, accesos de riesgo y alcance de tokens. Los runtimes de IA pueden proporcionar prompts, llamadas al modelo, invocaciones de herramientas, trazas y actividad de memoria.
Estas fuentes deben correlacionarse alrededor de un conjunto limitado de preguntas.
¿Qué datos se compartieron?
¿Qué usuario o agente realizó la acción?
¿Qué cuenta, dispositivo y herramienta intervinieron?
¿La información quedó almacenada, registrada, indexada o utilizada para entrenamiento?
¿Qué acción ejecutó la IA?
¿Se produjo una exposición posterior?
El proceso de respuesta puede avanzar mediante cinco etapas.
La clasificación determina el tipo de dato, sensibilidad, herramienta, cuenta, intención y canal de exposición.
La contención bloquea la sesión, pone en cuarentena la carga, revoca un token o suspende un agente.
La evaluación determina si la información quedó almacenada, fue utilizada para entrenamiento, compartida, indexada, registrada o transferida a otros terceros.
La remediación puede exigir eliminación, retirada, rotación de credenciales, reducción de permisos y notificación al propietario correspondiente.
La mejora actualiza políticas, reglas DLP, herramientas aprobadas, formación y procesos de excepción.
El nivel de automatización debe depender de la gravedad y de la confianza en la detección.
Un evento de baja gravedad con una herramienta aprobada y datos no sensibles puede requerir registro y orientación al usuario.
Un servicio no autorizado que recibe información interna puede generar una advertencia, un bloqueo, una redirección o un ticket.
La presencia de PII, código propietario o credenciales justifica una contención más intensa, rotación de secretos y revisión especializada.
Los datos regulados, las cargas masivas o una posible exfiltración deberían entrar en el proceso formal de respuesta ante incidentes.
Cómo definen Shadow AI los fabricantes de seguridad
El mercado de seguridad no define Shadow AI desde una posición neutral. Cada fabricante tiende a describirlo mediante el plano de control que ya posee.
Esto no invalida sus capacidades. Sí obliga a los compradores a diferenciar el riesgo real de la interpretación comercial de cada proveedor.
Netskope
Netskope aborda Shadow AI principalmente como un problema de uso de SaaS y movimiento de datos sensibles.
Sus puntos fuertes naturales incluyen el descubrimiento de aplicaciones de IA, la diferenciación entre cuentas personales y corporativas, la inspección de prompts y archivos, DLP contextual y acciones de permitir, bloquear, redactar o formar al usuario.
Este enfoque resulta especialmente relevante para servicios públicos de IA generativa y exposiciones iniciadas por empleados. Su extensión hacia IA privada y agéntica mantiene el énfasis en la visibilidad, los conectores y el gobierno del dato.
El ciclo de vida del agente y los controles de autoridad suelen requerir integración con plataformas de identidad y runtime.
Zscaler
Zscaler sitúa la ruta de acceso en el centro de su enfoque.
Su propuesta consiste en observar y controlar las interacciones cuando usuarios, aplicaciones o cargas se conectan a servicios de IA. Esto permite decisiones de acceso basadas en identidad, inspección de prompts, control de cargas y aplicación de políticas en tiempo real.
Su propuesta agéntica amplía esta lógica hacia activos de IA, servicios, cargas y tráfico de agentes.
El modelo ofrece mayor cobertura cuando la actividad relevante atraviesa la capa de aplicación de políticas. Las acciones ejecutadas dentro de SaaS, el funcionamiento local y los permisos delegados persistentes pueden exigir otras fuentes de telemetría.
Palo Alto Networks
Palo Alto Networks utiliza una interpretación más amplia basada en la superficie de ataque y el ciclo de vida de la IA.
Su enfoque puede conectar acceso de empleados, aplicaciones, modelos, agentes, plugins, cargas cloud, infraestructura y comportamiento de runtime mediante varias familias de producto.
La amplitud constituye su principal ventaja. Permite presentar Shadow AI como parte de una arquitectura de seguridad de IA que cubre desarrollo, producción y operaciones de seguridad.
Esta interpretación exige delimitar bien el alcance. Una definición excesivamente amplia puede convertir Shadow AI en una categoría que absorba cualquier riesgo relacionado con IA.
Microsoft
Microsoft plantea el problema desde los datos del puesto de trabajo, la identidad, la gestión de dispositivos, los permisos y el cumplimiento.
Su posición empresarial abarca documentos, correo, colaboración, endpoints, identidad cloud y asistentes de IA. Esta presencia proporciona una base sólida para descubrimiento de uso, controles de sensibilidad, auditoría, gobierno de permisos e identidades de agentes.
El enfoque resulta especialmente atractivo en entornos centrados en Microsoft porque permite combinar contexto de datos, identidad del usuario, postura del dispositivo y actividad de copilotos.
Su solución favorece lógicamente que la actividad de IA permanezca dentro del ecosistema empresarial de Microsoft.
CrowdStrike
CrowdStrike presenta una alineación menor con el Shadow AI convencional centrado en prompts, donde el riesgo principal surge de la interacción legítima de un usuario con una aplicación pública.
Su relevancia aumenta cuando los sistemas de IA ejecutan procesos, utilizan credenciales, invocan scripts, acceden a recursos cloud u operan como identidades autónomas.
La telemetría de endpoint, identidad y cloud puede revelar el comportamiento de los agentes y permitir su contención cuando la actividad autónoma genera riesgo.
Estas capacidades complementan los controles de navegador, CASB y DLP. Cada capa resuelve una parte diferente del problema.
Ningún fabricante ofrece actualmente un control completo de los dos dominios. El principal vacío se encuentra en la capa de integración.
Las organizaciones necesitan correlacionar visibilidad del flujo de datos, contexto de cuenta, identidades no humanas, permisos OAuth, acciones del runtime y capacidades de respuesta. XDR puede ayudar a correlacionar y contener eventos entre endpoint, identidad, cloud y SaaS. Su papel encaja mejor dentro de la arquitectura de respuesta que como control primario de Shadow AI.
Perspectiva final
Shadow AI comienza como un problema de adopción y visibilidad. Se convierte en un riesgo de seguridad de datos cuando usuarios o aplicaciones envían información sensible a servicios no gestionados. Evoluciona hacia un problema de identidad y autoridad cuando los agentes reciben credenciales, acceso persistente y capacidad de actuación.
Las organizaciones ya disponen de muchas de las capacidades necesarias. CASB, SSE, DLP, controles de navegador, clasificación de datos, IAM, PAM, seguridad SaaS, monitorización de endpoint, XDR y respuesta ante incidentes desempeñan funciones complementarias.
El desafío consiste en conectarlas alrededor del comportamiento de los sistemas de IA.
El Shadow AI convencional necesita visibilidad sobre aplicaciones, cuentas y movimiento de información.
El Shadow AI agéntico necesita identidades registradas, propietarios responsables, permisos limitados, puertas de aprobación, telemetría de acciones, contención rápida y desaprovisionamiento fiable.
Un programa maduro debería facilitar que la adopción segura resulte más sencilla que la adopción no gestionada. Para ello necesita herramientas aprobadas, reglas claras sobre los datos, flujos observables y respuestas proporcionadas.
El principio central puede formularse de forma directa.