Shadow AI: por qué la IA en la sombra es ante todo un problema de gobierno

Lo esencial

• Shadow AI es el uso de cualquier herramienta, función o agente de IA dentro de la organización sin supervisión de gobierno, y hoy está implicado en aproximadamente una de cada cinco brechas de datos empresariales.
• La narrativa dominante es de ciberseguridad. La menos contada, y probablemente la más consecuente, es de gobierno IA: no se puede registrar, evaluar ni auditar lo que no se ve.
• Shadow AI, proliferación de IA (AI sprawl) y lista de materiales de IA (AI bill of materials) son tres conceptos distintos que la industria suele mezclar. Mantenerlos separados es condición necesaria para escalar.
• El Reglamento europeo de IA, la norma ISO/IEC 42001 y el NIST AI Risk Management Framework comparten una suposición tácita: la organización posee un inventario completo de los sistemas de IA en su alcance. El Shadow AI invalida esa suposición en silencio.
• La respuesta no es prohibir (las prohibiciones empujan el uso aún más a la sombra) sino un programa de descubrimiento creíble que alimente un único registro de sistemas de IA, capaz de servir simultáneamente como fuente para el alta del Anexo VIII y como registro de riesgos ISO 42001.

Qué significa realmente Shadow AI

Shadow AI designa el uso de cualquier herramienta, capacidad o agente de inteligencia artificial dentro de una organización sin conocimiento, aprobación ni supervisión de las personas responsables del gobierno de la IA: CISO, delegado de protección de datos, responsable de gobierno IA, compliance, o quien sostenga ese mandato en la estructura.

La imagen común es la del empleado que pega un documento confidencial en ChatGPT. Es un caso, no la categoría completa. Shadow AI se presenta en al menos tres formas, y tratarlas como un problema único produce controles incompletos.

Herramientas GenAI de consumo autónomas. Chatbots gratuitos, generadores de imágenes, asistentes de código, transcriptores de reuniones a los que se accede mediante un navegador o una cuenta personal. Es la superficie clásica, la más sencilla de detectar con telemetría de red.

Funcionalidades de IA integradas en SaaS aprobados. La organización aprobó el SaaS, y el proveedor activó una nueva función de IA en mitad del contrato. De pronto el CRM resume notas de cliente con un modelo de fundación, la suite colaborativa redacta correos automáticamente, la herramienta de proyectos sugiere riesgos. El registro de compras dice que no se aprobó ninguna IA. La realidad dice otra cosa. IBM observa que la adopción empresarial de GenAI pasó del 74 al 96 por ciento entre 2023 y 2024, en gran parte por esta vía integrada (IBM Think).

Modelos, scripts y agentes internos. Un analista afina un modelo de código abierto en su equipo. Un ingeniero de plataforma conecta un agente a un servidor Model Context Protocol con permisos amplios. Un equipo de marketing entrena un GPT propio sobre un corpus sensible. Ninguno de estos flujos pasa por un chatbot público de terceros, por lo que escapa a la detección shadow IT tradicional, pero produce la misma laguna de gobierno.

La distinción útil con shadow IT es de alcance. Shadow IT cubre cualquier activo tecnológico no autorizado. Shadow AI es el subconjunto con forma de IA, y trae riesgos específicos: salidas probabilísticas, alucinaciones, datos de entrenamiento opacos, deriva del modelo, contaminación de la cadena de valor, y un régimen regulatorio propio (el Reglamento europeo de IA) que asigna explícitamente responsabilidades sobre esas características.

Es precisamente ese último punto el que mueve al Shadow AI del registro de la ciberseguridad al registro del gobierno. La seguridad lleva dos décadas persiguiendo SaaS no autorizados. La disciplina nueva de las dos próximas décadas es gobernar la IA cuya existencia se ignoraba.

Shadow AI, AI sprawl, AI bill of materials: tres conceptos distintos

Tres nociones vecinas se usan como sinónimos en blogs y notas de analistas. No son lo mismo, y confundirlas produce un programa de gobierno borroso.

Shadow AI trata de la autorización. Un sistema está en la sombra cuando nadie con responsabilidad ha trazado su existencia. Una herramienta perfectamente aprobada pero usada por un equipo no habilitado sigue siendo Shadow AI, porque falta la pista de auditoría.

AI sprawl trata de la multiplicación, estén los sistemas autorizados o no. Una organización con 80 herramientas de IA aprobadas repartidas en 40 equipos sin catálogo central sufre proliferación, no Shadow AI en sentido estricto. La proliferación es lo que ocurre cuando el descubrimiento funciona pero la consolidación no.

AI bill of materials (AI BOM) es el artefacto documental, modelado libremente sobre la lista de materiales de software. Para un sistema dado, la lista enumera componentes: modelo de fundación y versión, fuentes de datos de entrenamiento y ajuste fino, bases de recuperación, API de terceros invocadas en inferencia, puntos de control humano. El AI BOM no es un problema, es un entregable, y es lo que hace auditable la remediación del Shadow AI.

Un programa maduro aborda los tres: hacer emerger el Shadow AI mediante descubrimiento, reducir la proliferación mediante consolidación, y producir un AI BOM por sistema para que el registro tenga sustancia, no solo un nombre y un propietario.

Por qué el fenómeno explota ahora

En un preprint de 2026, Silic y colegas proponen leer el Shadow AI como fallo de gobierno sociotécnico más que como incidente de seguridad, argumentando que el carácter generativo, opaco y autónomo de la IA crea desafíos que el gobierno IT existente no absorbe (Silic et al., Preprints.org). Su marco coincide con lo que se observa en el terreno. Cuatro fuerzas se refuerzan.

La consumerización de la GenAI. Una cuenta gratuita de OpenAI o una suscripción de quince euros mensuales entrega capacidades que hace dos años requerían un ciclo de compras y una factura cloud. La fricción que frenaba el utillaje no aprobado se ha desvanecido.

La IA integrada en los SaaS aprobados. Cuando un proveedor bajo contrato activa una función de IA por defecto, el contrato no cambia, pero el flujo de datos sí. Pocos CISO disponen de la instrumentación contractual necesaria para saber cuándo su quinto proveedor SaaS ha activado en silencio la generación aumentada por recuperación sobre datos del cliente.

Los agentes y la capa MCP. Los servidores Model Context Protocol y los agentes autónomos representan una superficie nueva que los gateways web seguros tradicionales no estaban diseñados para inspeccionar. Un agente que invoca un servidor MCP hereda los permisos de ese servidor, que pueden exceder los del usuario invocador. Sin visibilidad dedicada, el radio de impacto de un despliegue de agente es desconocido.

La brecha de velocidad entre IT y negocio. Los empleados recurren al Shadow AI por la misma razón por la que recurrían al shadow SaaS: porque va más rápido que la vía oficial. Como señala una guía de Splunk, prohibir las herramientas GenAI de consumo sin ofrecer una alternativa interna no hace más que empujar el uso más hondo a la sombra (Splunk).

Las cifras son inequívocas. Gartner prevé que más del 40 por ciento de las empresas experimentarán un incidente de seguridad o compliance vinculado al Shadow AI antes de 2030 (nota de prensa Gartner, noviembre de 2025). El informe IBM Cost of a Data Breach 2025 cuantifica la prima de coste de las brechas ligadas a Shadow AI en alrededor de 4,63 millones de dólares frente a 3,96 millones para brechas estándar, y observa que solo el 37 por ciento de las organizaciones cuenta con una política para gestionar o detectar el Shadow AI (IBM Cost of a Data Breach 2025). Una brecha de cada cinco implica hoy al Shadow AI como factor contribuyente.

La dirección es clara. La pregunta estratégica es si la organización trata la laguna como un problema de seguridad que parchear, o como una disciplina de gobierno que construir.

El riesgo de gobierno: qué rompe realmente el Shadow AI

El relato de seguridad es intuitivo: datos sensibles salen del perímetro, el regulador sanciona, los clientes se van. Es real, y otros artículos lo cuentan bien. El relato de gobierno se cuenta menos y pesa más. Tres regímenes regulatorios y normativos convergen, y los tres descansan sobre una sola suposición que el Shadow AI invalida.

El mandato de registro del Reglamento de IA

El Artículo 49 del Reglamento europeo de IA exige que los proveedores de sistemas de IA de alto riesgo enumerados en el Anexo III se registren ellos y el sistema en la base de datos pública de la UE antes de la introducción en el mercado o de la puesta en servicio. Los responsables del despliegue que sean autoridades públicas deben registrar también el uso. El contenido exigido, definido en el Anexo VIII, incluye identidad del proveedor, denominación y finalidad del sistema, instrucciones de uso, certificado de evaluación de conformidad, estado (en el mercado, retirado, recordado) y resúmenes de las evaluaciones de impacto (Artículo 49, Anexo VIII).

La implicación de cumplimiento para el Shadow AI es directa. Si una herramienta usada en la organización, autorizada o no, encaja en las categorías de alto riesgo del Anexo III (selección laboral, scoring crediticio, identificación biométrica, infraestructuras críticas, educación, aplicación de la ley, migración, administración de justicia), el registro es una obligación legal, no una buena práctica. Un sistema en la sombra que resulta de alto riesgo es un alta no realizada, precisamente el tipo de no conformidad fáctica que las autoridades nacionales de vigilancia del mercado perseguirán.

Las obligaciones del responsable del despliegue de los Artículos 26 y 27 agravan la exposición. El responsable debe seguir las instrucciones de uso del proveedor, mantener registros, garantizar la supervisión humana y, para responsables públicos o sectoriales en el alcance, realizar una evaluación de impacto en derechos fundamentales (FRIA). El despliegue en la sombra rompe en silencio las cuatro, porque el sistema nunca estuvo en el inventario que las habría activado.

Esta sección es puramente descriptiva del texto jurídico. El punto no es qué deberían hacer los lectores. El punto es que el Shadow AI convierte una obligación documental en un fallo documental sin que nadie se entere hasta que llega una auditoría.

La declaración de aplicabilidad ISO/IEC 42001

La cláusula 6 de ISO/IEC 42001 exige que la organización identifique riesgos y oportunidades ligados a la IA, los trate y documente el tratamiento en un registro de riesgos IA. El Anexo A ofrece un catálogo de controles recomendados, y la declaración de aplicabilidad (Statement of Applicability) declara qué controles están incluidos o excluidos, con justificación.

El Shadow AI rompe esa estructura dos veces. Primero, el registro de riesgos es incompleto por construcción: un sistema desconocido no puede tener tratamiento documentado. Segundo, la declaración de aplicabilidad afirma que ciertos controles se aplican a ciertos sistemas. En cuanto un sistema en la sombra entra en alcance, esas afirmaciones se vuelven inexactas, y las organizaciones certificadas se exponen a una no conformidad en la reauditoría.

La implicación práctica es que una certificación 42001 solo vale lo que vale el programa de descubrimiento que la sostiene. Las organizaciones que se preparan para certificarse descubren, a menudo dolorosamente, que el hueco entre la lista oficial de IA y la huella real excede lo que el calendario de auditoría puede absorber.

La función MAP del NIST AI RMF

El NIST AI Risk Management Framework 1.0 organiza las actividades de IA de confianza en cuatro funciones: GOVERN, MAP, MEASURE, MANAGE. GOVERN fija política y responsabilidad. MAP, la segunda función, exige lo que NIST llama análisis contextual: para cada sistema de IA, conocer finalidad, propietarios, datos de entrenamiento, estado de despliegue, puntos de integración (NIST AI RMF).

El Shadow AI inhabilita MAP desde la raíz. No se puede caracterizar el contexto de un sistema no identificado. El NIST AI 600-1 (perfil GenAI) añade capa al enumerar doce riesgos específicos de la GenAI (privacidad de datos, seguridad de la información, cadena de valor, configuración humano-IA, confabulación, sesgo dañino, etc.) que requieren todos visibilidad a nivel de sistema para gestionarse (NIST AI 600-1).

El OWASP AI Exchange, proyecto bandera de OWASP desde marzo de 2025, formula el mismo punto desde la óptica del catálogo de controles: toda amenaza y todo control suponen un activo conocido. Allí donde el activo está en la sombra, el modelo de amenazas calla por defecto (OWASP AI Exchange). Los proyectos de normas armonizadas del CEN-CENELEC en elaboración (prEN 18228 y prEN 18282) siguen la misma lógica en el nivel europeo.

Tres marcos, una dependencia no enunciada: hay que saber qué IA se tiene.

Descubrir el Shadow AI: cinco capas indispensables

El descubrimiento debe ser estratificado, porque ninguna señal única capta todas las formas. Las cinco capas siguientes, ejecutadas en combinación, ofrecen una cobertura defendible.

Capa 1: telemetría de red y SaaS. Logs DNS, datos del secure web gateway, telemetría CASB y extensiones de navegador revelan tráfico hacia endpoints de IA de consumo conocidos. Capta el caso clásico de ChatGPT en el navegador. No ve lo que corre dentro de un SaaS aprobado o detrás de una IP corporativa.

Capa 2: auditoría de identidad. Historial de concesiones OAuth, logs SSO y pantallas de consentimiento muestran qué servicios de IA de terceros han recibido acceso a la identidad corporativa. Capta los servicios que se apoyan en Google Workspace o Microsoft 365. No ve los usos totalmente aislados.

Capa 3: auditoría de funciones de IA integradas en los SaaS aprobados. Diálogo directo con cada uno de los veinte principales proveedores SaaS: qué funciones están activas por defecto, cuáles son opt-in, adónde van los datos. Trabajo poco glamoroso de gobernanza de compras, pero saca a la superficie la forma integrada que la telemetría no ve.

Capa 4: programas de amnistía y encuesta. Una ventana de amnistía claramente comunicada donde los empleados declaran su uso de IA sin sanción. Combinada con una encuesta corta y honesta, produce un descubrimiento cualitativo que ninguna telemetría iguala. La condición de éxito es la seguridad psicológica, no la herramienta.

Capa 5: DLP consciente de IA. Inspección a nivel de prompt en canales aprobados, en busca de patrones de exfiltración de datos sensibles. Es el foco actual de inversión de la industria de ciberseguridad y la capa más presente en blogs de proveedores. Necesaria pero no suficiente por sí sola.

Ninguna organización alcanza el cien por ciento de cobertura. El objetivo realista es un barrido lo bastante fino para que el residuo desconocido sea pequeño, documentado y decreciente. El error es sobreinvertir en una sola capa y llamar a eso descubrimiento.

Del descubrimiento al registro de sistemas de IA

El descubrimiento sin destino es una hoja de cálculo de un solo uso que envejece en un trimestre. El destino es un registro de sistemas de IA central que alberga cada sistema conocido, con una estructura que satisface simultáneamente al regulador, a los organismos de normalización y a la función de riesgos interna.

Lo que el registro debe capturar por sistema:

• Identidad: nombre, propietario, patrocinador de negocio, patrocinador técnico
• Finalidad: uso previsto, usos prohibidos, poblaciones de usuarios en alcance
• Datos: clasificaciones de entradas y salidas, fuentes de entrenamiento y ajuste, bases de recuperación
• Cadena de proveedores: modelo de fundación y versión, proveedor de ajuste fino, entorno de hosting, API de terceros en inferencia
• Estado del ciclo de vida: piloto, producción, retirado; fecha de puesta en servicio
• Nivel regulatorio: clasificación de riesgo Reglamento UE, aplicabilidad Anexo A ISO 42001, perfil NIST AI RMF
• Riesgo residual: tras controles, con el aceptador identificado
• Evidencias: enlaces a FRIA, evaluaciones de conformidad, model cards, datasheets

La sección AI BOM de cada entrada es lo que hace auditable al sistema. Linaje del modelo, composición de los datos de entrenamiento, índices de recuperación y dependencias API aguas abajo forman un grafo que un auditor externo puede verificar contra los despliegues reales.

Bien hecho, el registro es la fuente única que alimenta tres artefactos aguas abajo: el paquete de alta del Anexo VIII cuando un sistema cae bajo el Reglamento UE, el registro de riesgos y los anexos de la declaración de aplicabilidad ISO 42001, y las salidas MAP del NIST AI RMF. Construidos en tres hojas separadas, derivan unos respecto a otros en semanas. Construidos una vez, con el esquema correcto, generan apalancamiento de gobierno.

Sacar el Shadow AI a la luz: un plan de 60 días

La secuencia importa, porque descubrir sin habilitar genera resentimiento y empuja el Shadow AI aún más a la sombra.

Semanas 1-2. Anuncio de la ventana de amnistía. Comunicación centrada en el objetivo: habilitar la IA, no prohibirla. Levantamiento del esqueleto del registro con un esquema mínimo. Captura de la telemetría base en las cinco capas.

Semanas 3-4. Barrido de descubrimiento. Combinación de telemetría, auditoría de identidad, diálogo con proveedores SaaS y encuesta de amnistía. Sorpresas esperables en la categoría IA integrada.

Semanas 5-6. Triaje. Exposición regulatoria primero, criticidad de negocio después. Identificar sistemas que correspondan al Anexo III del Reglamento UE, pues acarrean obligaciones de registro independientes de la madurez del resto del programa.

Semanas 7-8. Migración del triaje al registro. Para cada sistema Tier 1, adjuntar el AI BOM, la FRIA cuando aplique, la model card, la clasificación de datos. Para los tiers inferiores, capturar identidad y finalidad, y aplazar la documentación profunda al siguiente sprint.

Más allá del día 60, el programa se vuelve operativo: el alta de nuevos sistemas sustituye al descubrimiento, el registro alimenta las pipelines regulatorias y de auditoría, y el siguiente sprint aborda la proliferación (consolidación, retirada, descomisión).

El modo de fallo a vigilar es la sobreingeniería. Un registro perfecto que nadie actualiza vale menos que un registro tosco que cubre el ochenta por ciento de los sistemas y se refresca trimestralmente. Empezar ligero, hacer fluir las entradas y dejar que la presión regulatoria modele la precisión con el tiempo.

Preguntas frecuentes

¿Qué es el Shadow AI en pocas palabras? El Shadow AI es el uso de cualquier herramienta, función o agente de IA en la organización del que los responsables del gobierno IA no tienen conocimiento. Puede ser un empleado que usa un chatbot gratuito, una función de IA activada dentro de un SaaS aprobado, o un modelo interno corriendo en un portátil. El denominador común es la ausencia del inventario y, por lo tanto, la ausencia de gestión.

¿Shadow AI y shadow IT son lo mismo? No. Shadow IT es la categoría más amplia de activos tecnológicos no autorizados. Shadow AI es el subconjunto con forma de IA y trae riesgos propios: salidas probabilísticas, alucinaciones, datos de entrenamiento opacos, deriva del modelo, y un régimen regulatorio propio en la UE. Los controles de shadow IT capturan parte del Shadow AI, pero se les escapan por completo las formas integradas e internas.

¿Qué dimensión tiene el fenómeno en 2026? Gartner estima que más del 40 por ciento de las empresas sufrirán un incidente de seguridad o compliance vinculado al Shadow AI antes de 2030. El informe IBM 2025 indica que aproximadamente una brecha de cada cinco incluye hoy al Shadow AI como factor, y que esas brechas cuestan, en promedio, 0,67 millones de dólares más que las brechas estándar. Solo el 37 por ciento de las organizaciones declara disponer de una política de gestión o detección.

¿El Reglamento UE me obliga a inventariar el Shadow AI? El Reglamento UE no usa la palabra «inventario», pero el efecto es el mismo. El Artículo 49 exige el alta de los sistemas de alto riesgo del Anexo III antes de su introducción en el mercado. Los Artículos 26 y 27 imponen al responsable del despliegue obligaciones (registro, supervisión, instrucciones de uso, FRIA para los responsables en alcance) que no pueden cumplirse sin saber qué sistemas están en alcance. Un sistema en la sombra que resulta ser de alto riesgo es, en la práctica, una laguna de cumplimiento a la espera de la actuación.

¿Cómo trata ISO 42001 al Shadow AI? La cláusula 6 de ISO/IEC 42001 exige un registro de riesgos IA. El Anexo A aporta un catálogo de controles, y la declaración de aplicabilidad establece cuáles aplican a cada sistema. El Shadow AI rompe ambos: el registro de riesgos es incompleto por construcción, y la declaración de aplicabilidad se vuelve inexacta en el momento en que un sistema en la sombra entra en alcance. Por eso las auditorías de certificación suelen empezar con un ejercicio de descubrimiento más que con una revisión de controles.

¿Diferencia entre Shadow AI y AI sprawl? Shadow AI trata de la autorización: un sistema está en la sombra cuando el gobierno no lo ve. AI sprawl trata de la multiplicación: muchos sistemas de IA, autorizados o no, que se extienden sin catálogo central. Puede haber proliferación sin sombra (todo está registrado, pero son ochenta) y sombra sin proliferación (dos herramientas no autorizadas con uso extendido). Un programa maduro aborda los dos, y el AI BOM por sistema es el entregable que tiende el puente.

¿Qué debe contener un registro de IA, como mínimo? Como mínimo: identidad del sistema y propietario, finalidad y usuarios en alcance, clasificaciones de datos, modelo de fundación y versión, API de terceros en inferencia, estado del ciclo de vida, nivel regulatorio, riesgo residual tras controles y enlaces a evidencias (model card, datasheet, evaluación de conformidad, FRIA). Cada entrada sirve simultáneamente como fuente para el alta del Anexo VIII, el registro de riesgos ISO 42001 y la salida MAP del NIST AI RMF.

Conclusión

El Shadow AI no cederá ni ante prohibiciones ni ante la sola herramienta de ciberseguridad. Es un problema de descubrimiento de gobierno disfrazado de problema de seguridad, y las organizaciones que lo tratan como tal pasarán los dos próximos años construyendo registros, AI BOM y tratamientos de riesgo que sobreviven a una auditoría. Las que lo traten como un problema de perímetro pasarán esos mismos dos años persiguiendo incidentes. El entregable es idéntico en ambos casos: un inventario único, vigente y creíble de cada sistema de IA que la organización opera. La pregunta es si se construye al ritmo propio o bajo presión del regulador.