Susana López Blanco Shadow AI es el uso de herramientas, modelos, aplicaciones o agentes de inteligencia artificial sin que la empresa los haya identificado, evaluado o autorizado formalmente. Puede ser una cuenta personal de ChatGPT utilizada para resumir contratos, una aplicación que analiza currículos, una extensión conectada al correo o un agente con permisos sobre el CRM.
Muchas de estas herramientas entran por una razón bastante sencilla: resuelven trabajo. Una persona prueba una aplicación, descubre que ahorra tiempo y empieza a utilizarla antes de que IT, Seguridad, Legal o Compras sepan que existe. El uso puede tener sentido y, al mismo tiempo, incorporar un proveedor nuevo, sacar información fuera de la empresa o abrir conexiones que nadie ha revisado.
El problema aparece cuando llega a los agentes de ia en la empresa. En su Cyber Pulse de 2026, Microsoft recoge que el 29% de los empleados encuestados utiliza agentes de IA no autorizados para tareas de trabajo. En el mismo informe, solo el 47% de las organizaciones declara haber implantado controles específicos de seguridad para IA generativa. Son datos del propio ecosistema Microsoft, pero muestran bien la velocidad con la que estas herramientas están entrando en las empresas.
Antes de redactar una política hace falta saber qué se está utilizando, para qué, con qué información y qué puede hacer cada sistema. Con ese mapa ya podemos decidir qué usos continúan, cuáles necesitan más controles y cuáles conviene retirar.
Índice de contenidos
Cómo entra Shadow AI en una empresa
Un empleado copia un contrato en ChatGPT para resumirlo. Recursos Humanos utiliza una aplicación gratuita para ordenar currículos. Ventas carga una hoja de clientes en un asistente para preparar mensajes. Marketing autoriza a una herramienta de IA a consultar una carpeta de Google Drive. Un comercial incorpora un bot de transcripción a todas sus reuniones y un desarrollador pide ayuda con fragmentos de código interno.
Hay otro salto importante cuando alguien conecta un modelo al CRM, al correo o a una automatización. En ese momento la IA deja de trabajar únicamente con aquello que una persona copia en una ventana y empieza a acceder directamente a sistemas de la empresa.
Muchos servicios se pueden probar con un correo electrónico, ofrecen una versión gratuita y producen un beneficio inmediato. La adopción aumenta todavía más cuando la empresa no proporciona una herramienta corporativa que resuelva esa misma tarea con una experiencia razonable.
Una aplicación aprobada tampoco queda aprobada para cualquier uso futuro. Un empleado puede conectarle nuevas fuentes de datos, ampliar permisos o utilizarla para una tarea más sensible que aquella para la que se evaluó inicialmente. Por eso el inventario debe recoger casos de uso, datos y permisos, además del nombre de la herramienta.
Primero, averigua qué IA se está utilizando
La auditoría puede empezar preguntando directamente a los equipos qué utilizan y qué trabajo están resolviendo con esas herramientas. Después conviene contrastar esas respuestas con registros técnicos, compras, facturas y accesos corporativos. Una sola de esas fuentes ofrece una visión incompleta.
Entre los lugares que merece la pena revisar están:
- aplicaciones OAuth autorizadas en Google Workspace y Microsoft 365;
- extensiones instaladas en navegadores corporativos;
- cuentas personales utilizadas para tareas de trabajo;
- claves API creadas por equipos o desarrolladores;
- automatizaciones conectadas a aplicaciones corporativas;
- software pagado mediante tarjetas de empresa;
- facturas y suscripciones SaaS;
- aplicaciones conectadas a Drive, SharePoint, correo, CRM o gestores de proyectos;
- bots incorporados a videollamadas y reuniones;
- herramientas desarrolladas internamente sobre APIs de modelos externos.
El inventario no necesita convertirse en una base de datos gigantesca. Sí debe contener información suficiente para valorar después cada uso:
| Campo | Qué registrar |
|---|---|
| Herramienta | Producto, modelo, extensión, API o agente utilizado. |
| Departamento | Equipo o personas que lo emplean. |
| Caso de uso | Tarea concreta que resuelve. |
| Datos | Información que recibe o puede consultar. |
| Conexiones | Aplicaciones, repositorios y sistemas a los que accede. |
| Permisos | Lectura, escritura o capacidad de ejecutar acciones. |
| Proveedor | Empresa que presta el servicio y terceros relevantes. |
| Responsable | Persona o área que responde internamente por ese uso. |
| Coste | Licencia, consumo de API y otros gastos asociados. |
| Criticidad | Consecuencias de un fallo, una filtración o la desaparición del servicio. |
Conviene que los equipos puedan explicar lo que hacen sin que la primera reacción sea disciplinaria. Si la consecuencia de admitir que utilizas una herramienta es recibir una reprimenda, la próxima vez probablemente no la declararás. Saber por qué la están usando aporta además una información que IT difícilmente puede deducir de un registro de conexiones.
El prompt también puede sacar información de la empresa
La IA generativa ha añadido una salida de información especialmente fácil de utilizar: una caja donde escribimos una instrucción o adjuntamos un archivo. Ahí pueden acabar contratos, código fuente, hojas de clientes, información financiera, documentación laboral, correos internos o planes comerciales.
Un análisis publicado el 25 de agosto de 2026 en el Laboratorio de Privacidad de la AEPD advierte de que un prompt puede contener datos personales, información confidencial, secretos empresariales o documentación sometida a reserva. Introducir datos personales en una herramienta externa puede constituir además un tratamiento de datos y obliga a revisar qué papel desempeña el proveedor y bajo qué condiciones trabaja.
Antes de autorizar un servicio que vaya a recibir información corporativa conviene comprobar:
- qué datos procesa;
- con qué finalidad;
- durante cuánto tiempo los conserva;
- si intervienen subproveedores;
- dónde se realiza el tratamiento;
- si las entradas pueden utilizarse para entrenamiento o mejora del servicio;
- qué condiciones ofrece la modalidad empresarial contratada;
- si permite borrar o exportar los datos;
- qué controles administrativos proporciona;
- qué ocurre cuando termina la relación con el proveedor.
Una cuenta gratuita, una cuenta empresarial con garantías contractuales, una API configurada para no utilizar los datos en entrenamiento y un modelo desplegado en infraestructura propia pueden ofrecer condiciones muy distintas. El análisis del Laboratorio de Privacidad insiste precisamente en esa diferencia.
Y los riesgos no desaparecen cuando el archivo carece de datos personales. Código, precios, márgenes, estrategias comerciales, vulnerabilidades o documentación contractual pueden ser confidenciales o formar parte de secretos empresariales.
En nuestra guía sobre Data Governance explicamos cómo ordenar responsabilidades, acceso y uso de la información dentro de la empresa. Shadow AI incorpora nuevos consumidores de esos datos que deben entrar también en ese mapa.
Cuando la IA puede leer, escribir o ejecutar, el riesgo cambia
Un asistente que resume un texto y un agente conectado al correo no tienen la misma capacidad para producir efectos dentro de una empresa. Clasificar los sistemas por lo que pueden hacer ayuda mucho más que discutir si una determinada marca es segura o insegura.
| Nivel | Capacidad | Ejemplo |
|---|---|---|
| 1 · Generar | Recibe información y devuelve contenido. | Resume un documento o redacta una propuesta. |
| 2 · Leer | Consulta fuentes corporativas. | Busca información en Drive, correo, CRM o una base de datos. |
| 3 · Escribir | Crea o modifica información. | Actualiza un contacto, guarda un documento o modifica un registro. |
| 4 · Ejecutar | Activa acciones en otros sistemas. | Envía mensajes, lanza automatizaciones, tramita operaciones o utiliza herramientas externas. |
Esta escala permite poner límites bastante concretos. Un servicio puede estar autorizado para generar borradores y no para leer el correo. Un agente puede consultar oportunidades del CRM y tener bloqueada cualquier modificación. El producto puede ser idéntico y el riesgo cambiar por completo según los permisos concedidos.
Las integraciones mediante OAuth y APIs necesitan una revisión específica: alcance del permiso, persona que lo concedió, credencial utilizada y mecanismo de revocación. El principio de mínimo privilegio resulta especialmente útil aquí. Un agente que solo necesita consultar una carpeta no debería recibir acceso a todos los documentos de la compañía.
También hay que localizar la memoria y los registros de actividad. Un agente puede conservar información para utilizarla en ejecuciones posteriores, mientras que sus logs pueden almacenar prompts, respuestas, decisiones, identificadores y resultados de herramientas.
Las guías de desarrollo seguro de sistemas de IA del NCSC recomiendan identificar y proteger modelos, datos, prompts, software, documentación y logs, controlar a qué información puede acceder la IA y revisar la seguridad de APIs y componentes de terceros.
En IEBS hemos desarrollado esta parte con más detalle en nuestras guías sobre agentes de IA en la empresa, sistemas multiagente y observabilidad de agentes.
Mapa de riesgos de Shadow AI
| Área | Qué puede ocurrir | Qué revisar |
|---|---|---|
| Datos | Información personal, interna o confidencial entra en un servicio no evaluado. | Datos utilizados, finalidad, conservación, ubicación y borrado. |
| Propiedad intelectual | Código, diseños, documentación o conocimiento propio se comparte con terceros. | Contrato, condiciones de uso y tratamiento del contenido introducido. |
| Seguridad | Una aplicación obtiene más acceso del necesario a sistemas corporativos. | OAuth, credenciales, permisos, revocación y alcance de las integraciones. |
| Proveedores | Procesos relevantes dependen de servicios que la empresa no ha evaluado. | Proveedor, subproveedores, continuidad, soporte y capacidad de migración. |
| Modelos | Un cambio de modelo o configuración modifica los resultados. | Versiones utilizadas, controles disponibles y pruebas antes de cambios relevantes. |
| Resultados | Errores o información inventada se incorporan al trabajo. | Validación, fuentes, revisión humana y consecuencias del error. |
| Decisiones | La IA influye o actúa sobre clientes, empleados o proveedores sin controles adecuados. | Grado de autonomía, impacto, supervisión y responsable. |
| Costes | Los equipos acumulan herramientas duplicadas o consumos sin controlar. | Licencias, API, uso efectivo y alternativas ya contratadas. |
Permitido, condicionado o prohibido: una política que se pueda utilizar
Una política resulta mucho más útil cuando clasifica casos de uso, datos, conexiones y permisos. Saber qué aplicación se utiliza importa, pero el nombre del producto no describe por sí solo lo que está ocurriendo.
Usos permitidos
Aquí pueden entrar tareas con información pública o no confidencial dentro de herramientas aprobadas: ideación, borradores, esquemas, traducciones, resúmenes de documentación pública o apoyo sobre materiales que la empresa puede compartir sin restricciones.
La autorización de una herramienta tampoco elimina la responsabilidad profesional sobre el resultado. Un texto incorrecto sigue siendo incorrecto aunque proceda de una aplicación aprobada.
Usos condicionados
Son tareas útiles que trabajan con información interna o permiten acceder a sistemas corporativos. Pueden necesitar una cuenta empresarial, contrato revisado, minimización de datos, permisos limitados, registro de actividad o validación humana antes de incorporarse al proceso.
Algunos ejemplos serían analizar documentación interna dentro de un entorno contratado por la empresa, consultar una base de conocimiento corporativa o conectar un agente al CRM con acceso limitado a determinadas operaciones.
Usos prohibidos
Cada empresa tendrá sus propios límites, pero hay situaciones que deberían levantar una alarma inmediata: introducir contraseñas o credenciales en servicios no aprobados, compartir secretos empresariales desde cuentas personales, conceder permisos generales a un agente individual o permitir acciones de impacto relevante sin controles suficientes.
Esta clasificación pertenece al gobierno interno y debe ajustarse al negocio, los datos tratados, los contratos existentes y las consecuencias que tendría un error.
Bloquear herramientas sin ofrecer alternativas suele desplazar el problema
Imaginemos una tarea que requiere dos horas y una aplicación que permite hacerla en veinte minutos. Si la empresa bloquea el servicio y no proporciona nada que resuelva esa necesidad, el incentivo para buscar otra herramienta seguirá ahí. Puede aparecer una cuenta personal, otra aplicación o un dispositivo fuera del entorno corporativo.
Para reducir Shadow AI, la empresa necesita alternativas aprobadas que funcionen de verdad. Pueden ser cuentas empresariales, asistentes corporativos, entornos de prueba, automatizaciones mantenidas internamente o un proceso rápido para pedir una herramienta nueva.
También podemos controlar cómo llega el conocimiento a una aplicación. Sistemas de recuperación, caché o memoria permiten decidir qué fuentes puede consultar una IA, qué información recibe en cada petición y qué permisos deben aplicarse. En nuestra guía sobre RAG, CAG y MAG explicamos las diferencias entre estas arquitecturas y cuándo tiene sentido utilizar cada una.
Qué dice el AI Act y qué debe decidir cada empresa
Shadow AI no aparece como una categoría jurídica específica en el AI Act. Las obligaciones dependen del sistema utilizado, el caso de uso, el papel que desempeña la organización y, cuando corresponda, la clasificación regulatoria aplicable.
Hay, sin embargo, una obligación especialmente relacionada con la adopción interna. El artículo 4 del AI Act exige a proveedores y responsables del despliegue que adopten medidas para apoyar la alfabetización en IA de las personas que utilizan estos sistemas en su nombre.
La norma cambió en julio de 2026. La obligación continúa, pero ya no exige que la empresa garantice un nivel individual específico o «suficiente» de alfabetización. La Comisión explica además que la supervisión y aplicación de esta disposición corresponde a las autoridades nacionales de vigilancia del mercado.
La Comisión mantiene un repositorio con más de 40 iniciativas de alfabetización en IA desarrolladas por empresas y organismos públicos. Puede servir como referencia, aunque la propia Comisión advierte de que reproducir uno de esos ejemplos no concede automáticamente presunción de cumplimiento.
Inventariar herramientas, clasificar casos de uso, revisar permisos, establecer un proceso de aprobación o auditar periódicamente las conexiones son decisiones de gobierno interno que ayudan a controlar Shadow AI. No deben presentarse como obligaciones generales impuestas por el AI Act.
Tenemos una explicación más completa del marco europeo en nuestra guía EU AI Act explicado para no juristas.
Qué necesita aprender cada equipo
No todos los equipos necesitan saber lo mismo. Toda la plantilla debería conocer las herramientas autorizadas, qué información puede introducir y cuándo debe revisar una respuesta. Las personas que configuran agentes, gestionan datos o toman decisiones sobre proveedores necesitan bastante más profundidad.
| Equipo | Qué necesita conocer |
|---|---|
| Toda la plantilla | Herramientas autorizadas, datos que puede utilizar, revisión de respuestas y canal para comunicar nuevos casos o incidentes. |
| Managers | Qué tareas pueden delegarse, dónde debe mantenerse revisión humana y quién responde por el resultado. |
| IT y Seguridad | OAuth, APIs, credenciales, permisos, logs, integraciones, revocación y proveedores. |
| Legal / DPO | Datos tratados, contratos, proveedores, transferencias, finalidad y usos regulados. |
| Equipos de IA y automatización | Agentes, memoria, herramientas, evaluación, observabilidad, manejo de excepciones y límites de autonomía. |
La formación en IA en la empresa debería partir precisamente de estas diferencias. Quien utiliza un asistente para preparar documentos no necesita la misma formación que quien configura agentes con permisos para actuar sobre sistemas corporativos.
Checklist para auditar Shadow AI
- ¿Qué herramientas de IA utiliza cada equipo?
- ¿Para qué tareas se utilizan?
- ¿Qué datos reciben o pueden consultar?
- ¿Existen cuentas personales utilizadas para trabajo corporativo?
- ¿Qué aplicaciones tienen acceso a correo, archivos, CRM u otros sistemas?
- ¿Qué permisos tienen: lectura, escritura o ejecución?
- ¿Quién presta cada servicio y qué contrato existe?
- ¿Qué sistemas pueden actuar sin intervención inmediata de una persona?
- ¿Quién responde internamente por cada uso relevante?
- ¿Cada caso está clasificado como permitido, condicionado o prohibido?
- ¿La empresa ofrece alternativas corporativas suficientemente útiles?
- ¿Puede revocar accesos, reconstruir las acciones realizadas y cambiar de proveedor si deja de ser adecuado?
Si todavía no podemos responder las primeras preguntas, el primer trabajo es construir ese inventario. A partir de ahí será mucho más fácil decidir qué merece seguir utilizándose, qué necesita mejores controles y qué conviene sacar de los procesos corporativos.