La Shadow AI es el mayor riesgo de IA para las empresas — y la mayoría no sabe que la tiene

El 90% de las empresas están preocupadas por esto. El 80% ya ha experimentado incidentes negativos relacionados con datos e IA. Y los agentes que se ejecutan en producción puede que nunca hayan sido aprobados por nadie en TI. Esto es lo que está pasando — y qué hacer antes de que se convierta en tu crisis de cumplimiento.

Qué es realmente el Shadow AI — y por qué no es lo mismo que Shadow IT

La terminología se confunde constantemente, y esa confusión es peligrosa.

Shadow IT es software no autorizado — las aplicaciones SaaS que los empleados contratan sin aprobación de TI, la cuenta personal de Dropbox que se usa para compartir archivos de trabajo, las extensiones de navegador no verificadas instaladas en laptops corporativos. Shadow IT es un problema real, pero tiene un límite fundamental: el software no aprobado sigue requiriendo que un humano lo opere. Los datos se van cuando una persona decide moverlos.

Shadow AI es categoricamente diferente. Shadow AI son agentes de IA no autorizados, LLM y flujos de trabajo de IA operando fuera de la gobernanza de TI — y a diferencia del Shadow IT, estos sistemas pueden actuar de forma autónoma. Pueden leer tus datos, copiarlos, transmitirlos y ejecutar acciones en sistemas sin que un humano dirija explícitamente cada paso.

La distinción importa porque cambia completamente el perfil de riesgo. Un empleado usando una herramienta SaaS no aprobada para almacenar un archivo es un riesgo de exposición de datos. Un agente de IA del empleado que fue entrenado con tu documentación interna, tiene acceso via API a tu CRM, y procesa datos de clientes a través de un LLM API personal — eso es un actor autónomo operando en tu infraestructura sin tu conocimiento ni consentimiento.

La categoría ha evolucionado más rápido de lo que la mayoría de los equipos de seguridad empresarial han registrado. En 2024, Shadow AI mayormente significaba empleados usando ChatGPT para redactar documentos. En 2025 y 2026, cada vez más significa empleados desplegando agentes de IA — flujos de trabajo autónomos que pueden planificar, usar herramientas, ejecutar procesos de múltiples pasos y encadenar acciones en sistemas empresariales. Un empleado que configura un agente de IA para manejar sus aprobaciones de compras, su enrutamiento de soporte al cliente o la generación de reportes puede no tener idea de que el agente está operando con acceso a sistemas que nunca fueron autorizados para ese propósito.

Los empleados no necesariamente están actuando con mala fe. La mayoría de los despliegues de Shadow AI nacen de una motivación genuina de productividad — alguien encontró una herramienta que le ahorra dos horas al día y la configuró sin pensar en las implicaciones de acceso a datos. El problema es que las implicaciones son reales, la conciencia es baja, y los agentes siguen ejecutándose independientemente de si alguien pensó en el riesgo.

Los números — ¿Qué tan malo es realmente?

Los datos de los líderes de TI empresariales son consistentes y alarmantes.

La Encuesta de TI 2025 de Komprise — realizada entre 200 directores y ejecutivos de TI en organizaciones con más de 1,000 empleados en EE.UU. — encontró que el 90% de las empresas estaban preocupadas por el Shadow AI desde una perspectiva de privacidad y seguridad. Eso no es una preocupación marginal de equipos de TI ansiosos. Es un reconocimiento casi universal del riesgo.

La cifra más impactante: casi el 80% de esas mismas empresas reportaron haber experimentado incidentes negativos relacionados con datos e IA. No es un hipótesis. No es un casi-accidente. Es un incidente real involucrando herramientas de IA no autorizadas operando con datos empresariales.

De esas empresas, el 13% experimentó daños financieros, a clientes o reputacionales — daños medibles de un incidente de IA que la dirección puede nunca haber aprobado o incluso conocido. Esa cifra probablemente está subestimada, ya que muchas empresas no tienen la capacidad de detección para saber cuándo ha ocurrido un incidente relacionado con IA.

La investigación de Gartner agrega la dimensión prospectiva. Sus analistas proyectan que para 2030, aproximadamente el 40% de las empresas enfrentarán incidentes de cumplimiento de IA — y el factor principal citado es la filtración de datos a través de canales de Shadow AI, incluyendo lo que Gartner describe como "humanizadores sombra", herramientas que los empleados usan para procesar datos empresariales a través de LLM personales de maneras que enrutan esos datos fuera del control de la empresa.

Ejemplos reales de cómo se ve esto en la práctica: empleados enrutando datos empresariales a través de plataformas de mensajería como Telegram hacia APIs de LLM personales. Agentes de IA no aprobados manejando flujos de trabajo de compras con acceso a sistemas de gestión de proveedores. Equipos de ventas usando herramientas de IA para redactar comunicaciones a clientes que se almacenan en el sistema del proveedor en lugar del de la empresa. El hilo conductor es que nadie en TI aprobó estas herramientas, y nadie en TI sabe que los datos han salido del edificio.

Las implicaciones de cumplimiento se acumulan cuando se superponen datos regulados. Las organizaciones de salud que manejan PHI a través de herramientas de IA no sancionadas potencialmente están violando requisitos de HIPAA. Las firmas de servicios financieros que enrutan datos de clientes a través de APIs de IA personales pueden estar violando requisitos de residencia y manejo de datos. Los empleados que hacen esto rara vez intentan violar marcos de cumplimiento — están intentando hacer su trabajo más rápido. Pero la exposición al cumplimiento es real independientemente de la intención.

Por qué la gobernanza tradicional falla aquí

La mayoría de las empresas ya tienen alguna forma de gobernanza de IA. Pero generalmente está construida para el modelo de amenaza equivocado.

El marco típico de gobernanza de IA asume una herramienta sancionada — algo que TI evaluó, aprobó y desplegó. Especifica qué modelos de IA puede usar la organización, sobre qué datos pueden ser entrenados, y qué registros de auditoría deben mantenerse. Esto es gobernanza necesaria. También es gobernanza que no tiene mecanismo de aplicación para el problema del Shadow AI, porque Shadow AI específicamente significa herramientas de IA que nunca fueron sancionadas, nunca evaluadas, y nunca conocidas.

La brecha entre la velocidad de adopción de IA por empleados y la velocidad de aprobación de TI es estructural. Los empleados pueden configurar un agente de IA en minutos, conectarlo a su correo de trabajo, y tenerlo procesando su flujo de trabajo antes de que TI haya recibido siquiera la solicitud de aprobación. Las herramientas para hacer esto son gratuitas, de grado consumidor, y no requieren conocimiento técnico. El proceso de aprobación de nuevo software empresarial toma semanas o meses. Los empleados que quieren trabajar más rápido no van a esperar a que TI complete una revisión de seguridad.

La amplificación de la IA agéntica complica este problema significativamente. La gobernanza tradicional de IA fue diseñada para interfaces de chat y generación de documentos — IA que produce salidas que un humano revisa antes de usar. Los agentes de IA son diferentes: planifican, usan herramientas, ejecutan flujos de trabajo de múltiples pasos de forma autónoma. Un empleado que configura un agente de IA para manejar su flujo de trabajo de onboarding de clientes le ha dado a ese agente la capacidad de leer datos de clientes, actualizar registros de CRM, enviar correos y tomar decisiones — todo sin que un humano revise cada paso. La velocidad y autonomía de los agentes de IA está fundamentalmente desajustada con procesos de gobernanza diseñados para herramientas de IA con humano en el medio.

El stack de seguridad tiene puntos ciegos aquí. La infraestructura de seguridad empresarial — detección y respuesta en endpoints (EDR), secure access service edge (SASE), firewalls, gestión de identidades — genera señales significativas relacionadas con el uso de herramientas de IA. Los usuarios están accediendo a servicios de IA desde redes corporativas. Los datos se están moviendo hacia APIs de proveedores de servicios de IA. Las credenciales de servicios de IA se están usando en endpoints. Pero el stack de seguridad no fue construido para correlacionar estas señales en una imagen coherente de exposición a Shadow AI, y la mayoría de los equipos de seguridad no tienen las herramientas para actuar sobre las señales que ya están generando.

La brecha de rendición de cuentas es quizás la pieza más irresuelta. Cuando un incidente de Shadow AI causa daños — una filtración de datos, una violación de cumplimiento, un registro de cliente enviado al lugar equivocado — ¿quién es responsable? ¿El empleado que configuró el agente? ¿El gerente del empleado? ¿TI, por no tener gobernanza que lo habría detectado? ¿El CISO, por no tener capacidad de detección? Los marcos actuales de gobernanza empresarial no tienen respuestas claras a estas preguntas. El default práctico tiende a ser una rendición de cuentas difusa, lo que significa que no es responsabilidad específica de nadie — lo que significa que no se arregla.

El problema del Shadow AI agéntico empeora

La primera ola de Shadow AI fue principalmente empleados usando interfaces de LLM consumidor para redactar documentos, responder preguntas y resumir información. Malo, pero manejable, porque siempre había un humano en el medio.

La segunda ola — la que es la crisis real — es sobre agentes de IA operando de forma autónoma en flujos de trabajo empresariales. Aquí es donde el riesgo transiciona de "privacidad de datos" a "exposición operativa", y donde la brecha de gobernanza se vuelve crítica.

La infraestructura para desplegar agentes de IA personales se ha vuelto trivially fácil. Los servidores MCP (Model Context Protocol), que permiten a los agentes de IA conectarse a herramientas y fuentes de datos externas, están siendo configurados por empleados no técnicos sin participación de TI. Las claves de API para servicios de IA se crean en cuentas personales. Los empleados están construyendo agentes que se ejecutan en infraestructura personal, usando suscripciones personales a servicios de IA, con acceso a sistemas corporativos autenticado a través de credenciales que la empresa no sabe que existen.

El resultado es una población creciente de agentes de IA que operan fuera de la visibilidad y control de la empresa — no porque la empresa haya fallado en construir gobernanza, sino porque los agentes fueron configurados por personas que no sabían que necesitaban aprobación de gobernanza. Un empleado que construyó un agente de IA para manejar el enrutamiento de tickets de TI de su equipo ha creado, sin saberlo, un sistema autónomo con acceso a sistemas internos de TI, credenciales de usuarios y datos organizacionales. El agente se ejecuta los fines de semana, procesa tickets y escala lo que no puede manejar. Nadie en TI sabe que existe.

La exposición operativa se acumula con el tiempo. Cuanto más tiempo opera un agente de IA no gobernado, más se integra en los procesos de negocio. Otros empleados empiezan a depender de él. Se forman dependencias. Cuando algo sale mal — el agente comete un error, el servicio personal en el que está construido cambia sus términos de API, la suscripción del empleado caduca — la interrupción es real y la brecha de gobernanza se vuelve visible bajo presión.

Los equipos de seguridad están comenzando a reconocer esta dinámica. ArmorCode y plataformas similares de gobernanza de IA han comenzado a enmarcar el problema como un desafío de "gestión de exposición de IA": las señales de riesgo de IA existen en tu stack de seguridad actual, pero ningún equipo individual las posee ni tiene las herramientas para actuar sobre ellas. El equipo de seguridad ve el tráfico de red hacia servicios de IA. El equipo de TI no sabe qué agentes se están ejecutando en cuáles endpoints. El equipo de gobernanza de datos no sabe qué datos han sido procesados por cuáles sistemas de IA. La rendición de cuentas por el riesgo de IA está distribuida entre todos ellos y concentrada en ninguno.

Lo que realmente funciona — Un marco de gobernanza

Las empresas que están logrando avances significativos en gobernanza de Shadow AI no están tratándolo como un problema tecnológico. Lo están tratando como un problema de fuerza laboral y política con la tecnología como habilitador. Cinco componentes aparecen consistentemente en marcos efectivos.

1. Programas de Amnistía de IA — Descubre lo que ya tienes

El paso más inmediatamente accionable es crear un mecanismo de divulgación segura para empleados que ya están usando herramientas de IA no sancionadas. Un Programa de Amnistía de IA toma prestada la lógica de los marcos de divulgación voluntaria: los empleados que revelan su uso de herramientas de IA no autorizadas dentro de una ventana definida reciben asistencia para transición a alternativas sancionadas, sin castigo por la no divulgación inicial.

La lógica es pragmática. Muchos empleados que usan herramientas de Shadow AI lo hacen porque encontraron algo que genuinamente les ayuda a hacer mejor su trabajo, no porque estén intentando evadir la gobernanza corporativa. Si la organización responde a la divulgación castigando a los empleados, la divulgación se detiene y las herramientas siguen ejecutándose. Si la organización responde ofreciendo alternativas sancionadas y ayuda con la transición, la visibilidad ganada vale más que el fallo de gobernanza que la precedió.

2. Inventaría todo — Gestión continua de exposición de IA

El descubrimiento no puede ser un evento único. El panorama de herramientas de IA cambia demasiado rápido, y los agentes desplegados por empleados aparecen continuamente. La gobernanza efectiva de Shadow AI requiere inventario continuo: cada herramienta de IA, modelo, clave de API, servidor MCP y flujo de trabajo agéntico que tiene acceso a datos o sistemas empresariales.

Esto es técnicamente no trivial, pero no imposible. El análisis de tráfico de red puede identificar llamadas a APIs de servicios de IA. La detección en endpoints puede señalar procesos de agentes de IA ejecutándose en hardware corporativo. La gobernanza de identidades puede superficial credenciales de API que fueron emitidas fuera de canales normales de aprovisionamiento. La clave es correlacionar estas señales en un inventario de activos de IA que el equipo de seguridad pueda realmente actuar.

3. Gobierna los agentes, no solo los modelos

Los marcos de gobernanza de IA construidos alrededor de "qué modelos de IA pueden usarse" se pierden el problema real, que es "qué agentes de IA pueden operar en nuestros sistemas y con qué acceso". La pregunta de gobernanza necesita cambiar de aprobación a nivel de modelo a autorización a nivel de agente.

Tratar a los agentes de IA como parte de la fuerza laboral es la analogía útil. Los agentes necesitan roles definidos, permisos de acceso, rutas de escalamiento y registros de auditoría — el mismo marco de gobernanza que aplicarías a un miembro de la fuerza laboral humana con acceso equivalente. Un agente que procesa datos de clientes necesita los mismos controles de acceso y monitoreo que un empleado humano haciendo el mismo trabajo.

4. Integra con el stack de seguridad existente

La gobernanza de IA que opera en un silo separado de la infraestructura de seguridad existente es gobernanza que no se hará cumplir. Las señales de Shadow AI ya están presentes en tu stack de seguridad — simplemente no se están correlacionando ni actuando sobre ellas.

Los datos de EDR pueden señalar procesos de agentes de IA ejecutándose en endpoints. La infraestructura SASE puede identificar acceso a servicios de IA no sancionados. Los sistemas de gestión de identidades pueden superficial credenciales de API emitidas fuera del aprovisionamiento normal. Cuando estas señales alimentan una plataforma de gobernanza de IA que puede correlacionarlas y actuar sobre ellas — en lugar de sentarse en herramientas separadas — la organización gana visibilidad que no tenía antes.

5. Establece una política de uso aceptable de IA — y hazla cumplir

La mayoría de las empresas tienen una política de uso aceptable de IA. La mayoría de ellas están escritas como documentos de política que los empleados deben reconocer, no como controles técnicos que previenen violaciones de política. Una política que dice "no envíes datos de clientes a servicios de IA no sancionados" es necesaria pero no suficiente si no hay mecanismo técnico para detectar o prevenir que esos datos se vayan.

La gobernanza efectiva de uso aceptable de IA requiere ambas cosas: una política clara que establezca expectativas, y controles técnicos que las hagan cumplir. Proxies web que bloqueen dominios de servicios de IA en dispositivos gestionados. Reglas de prevención de pérdida de datos (DLP) que señalen datos sensibles moviéndose a endpoints de servicios de IA. Controles de gateway de API que requieran acceso a servicios de IA sancionados. La política establece la expectativa. Los controles técnicos previenen la violación.

Los Principios de IA Responsable de EY proporcionan un marco útil para la capa de política: los sistemas de IA deben ser transparentes en cómo operan, responsables ante propietarios definidos, y sujetos a los mismos principios de gestión de riesgos que cualquier otro sistema empresarial. Estos principios aplican a la gobernanza de Shadow AI tanto si las herramientas fueron sancionadas por TI como si fueron desplegadas por empleados.

Síntesis de investigación por Agencie. Fuentes: Encuesta de TI 2025 de Komprise, Gartner (predicciones de gobernanza de IA hasta 2030), Principios de IA Responsable de EY. Todas las fuentes citadas son publicaciones de 2025-2026.