Shadow AI: cómo recuperar el control de la IA no autorizada con DLP, CASB y gobierno del dato

La conversación sobre IA en la empresa suele arrancar con grandes planes, pilotos vistosos y algún comité que se reúne más de lo que decide. Mientras tanto, el problema real ya está dentro: empleados pegando contratos, código fuente, expedientes de clientes o actas internas en herramientas de IA que nadie ha aprobado. A eso se le llama shadow AI, y no es una extravagancia semántica. Es el viejo shadow IT con esteroides, interfaz conversacional y una capacidad notable para hacer que la fuga de datos parezca trabajo eficiente.

Para un CISO o un responsable de cumplimiento, el riesgo no es abstracto. Si un empleado introduce datos personales en un servicio externo sin base jurídica clara, el problema cae de lleno en GDPR, empezando por el principio de minimización del art. 5.1.c, la licitud del tratamiento del art. 6 y la obligación de aplicar medidas técnicas y organizativas apropiadas del art. 32. Si lo que sale es información sensible de negocio, diseños, pricing, modelos de riesgo o secretos comerciales, el golpe no siempre termina en una brecha notificable, pero sí puede traducirse en pérdida de control sobre activos críticos. Y si esa organización entra en el perímetro de NIS2, la discusión deja de ser “esto nos preocupa” para convertirse en “esto entra en gestión de riesgos, seguridad de la cadena de suministro y gobernanza”. Ahí están el art. 21 sobre medidas de gestión de riesgos de ciberseguridad y el art. 20 sobre responsabilidades de los órganos de dirección.

La pregunta, entonces, no es si hay shadow AI. La hay. La pregunta útil es otra: cómo detectarla, cómo reducir el riesgo sin declarar la guerra a la productividad y cómo demostrar, ante auditoría o regulador, que la empresa no se ha limitado a prohibir algo que sabía perfectamente que iba a ocurrir igual.

El primer error: pensar que shadow AI es un problema de uso, cuando en realidad es un problema de datos

Muchas empresas siguen abordando este asunto como si fuera una cuestión de herramientas no autorizadas. Bloquear ChatGPT, Gemini, Claude, Perplexity o el siguiente nombre de moda puede servir de titular interno durante una semana. Sirve bastante menos como estrategia. El usuario que necesita resumir un PDF, traducir una propuesta comercial o generar una consulta SQL buscará otro camino: una app de navegador, una extensión, una cuenta personal, una API gratuita, una herramienta integrada en una suite ofimática o un proveedor con branding más discreto. La demanda no desaparece porque seguridad publique una política de dos páginas.

Aquí está el quid: el riesgo no lo crea la mera existencia de una IA generativa, sino la combinación de tres factores. Primero, datos que no deberían salir del perímetro de control. Segundo, servicios con condiciones de uso, retención, entrenamiento o subprocesamiento que el área de compliance no ha validado. Tercero, usuarios que no distinguen entre “usar una herramienta” y “ceder contenido a un tercero”. Esa mezcla es la receta perfecta para un incidente que, además, llega envuelto en buenas intenciones.

ENISA lleva tiempo situando la IA en el cruce entre ciberseguridad, gobernanza y confianza digital. Y con razón. El problema no es futurista. Es operativo. Cuando un empleado pega un correo con datos personales en un chatbot externo, no está “probando IA”: está realizando un tratamiento de datos. Cuando sube código fuente a un copiloto no aprobado, está exponiendo propiedad intelectual y posiblemente credenciales, secretos o rutas internas. Cuando un analista financiero vuelca información de clientes o escenarios de liquidez en una herramienta SaaS no evaluada, está ampliando la cadena de suministro digital sin contrato, sin DPIA, sin evaluación de transferencias y sin rastro documental serio.

Eso exige un cambio de enfoque. Si tu programa contra shadow AI se centra solo en bloquear dominios, vas tarde y corto. La respuesta madura empieza por el dato: qué datos existen, dónde están, quién los usa, bajo qué reglas pueden salir y qué controles técnicos frenan la exfiltración cuando la política, inevitablemente, no basta.

Por qué el shadow AI crece tan deprisa: fricción cero, beneficio inmediato, control difuso

El shadow IT tradicional tenía una ventaja para el defensor: desplegar software corporativo alternativo llevaba tiempo, presupuesto o ayuda de TI. El shadow AI no necesita casi nada. Basta una pestaña de navegador. La adopción es instantánea porque la promesa también lo es: ahorrar tiempo hoy. No el trimestre que viene. Hoy.

Esa inmediatez cambia por completo el patrón de riesgo. Un empleado no percibe que está “implantando tecnología”. Cree que solo está pidiendo ayuda a una herramienta. Esa percepción reduce la sensación de gravedad y, de rebote, la adherencia a las políticas. Si además la organización no ha ofrecido un servicio aprobado con capacidades similares, el mensaje que recibe el usuario es bastante claro: “haz más con menos, pero no uses lo único que te haría ir más rápido”. Luego nos extrañamos del resultado.

Hay otra razón menos comentada: muchas empresas clasifican bien sus aplicaciones, pero clasifican mal sus datos. Saben inventariar endpoints, identidades y proveedores. Les cuesta bastante más etiquetar información por sensibilidad de forma consistente y operativa. Sin esa base, cualquier control de DLP o CASB se vuelve torpe: o bloquea demasiado y genera rechazo, o deja pasar justo lo que importaba. La IA no ha creado ese problema. Lo ha dejado en evidencia con una crueldad bastante pedagógica.

También hay un elemento contractual. En 2026, el mercado ofrece desde asistentes empresariales con controles de retención y aislamiento razonables hasta servicios gratuitos o freemium donde las garantías son, siendo amables, discutibles. El usuario medio no lee términos de servicio ni anexos de tratamiento. Ni tiene por qué hacerlo. Para eso están compras, legal, seguridad y privacidad. El problema es que el uso se produce antes de la revisión, no después. La gobernanza llega corriendo detrás del navegador.

Lo que realmente se filtra: cuatro clases de datos que más aparecen en incidentes internos

No toda fuga a herramientas de IA tiene el mismo peso. Meter una nota de reunión sin nombres no equivale a subir una base de datos de clientes. Conviene separar categorías porque de ahí salen las reglas útiles.

La primera categoría es datos personales. Aquí entran nombres, correos, teléfonos, identificadores, historiales de soporte, evaluaciones de desempeño o datos de candidatos. Bajo GDPR, cualquier envío a un proveedor externo exige base jurídica, transparencia, limitación de finalidad y medidas de seguridad adecuadas. Si la herramienta actúa como encargado del tratamiento, el art. 28 obliga a un contrato con garantías concretas. Si hay transferencias internacionales, la discusión se mueve además al capítulo V del Reglamento. No es un matiz. Es la diferencia entre un uso corporativo legítimo y una improvisación con posibles consecuencias regulatorias.

La segunda es propiedad intelectual e información confidencial. Código fuente, algoritmos de pricing, documentación de arquitectura, roadmaps de producto, ofertas, M&A, informes jurídicos. Aquí el daño puede no activar por sí mismo el deber de notificar a una autoridad de protección de datos, pero sí golpear la ventaja competitiva, la posición negociadora o el secreto profesional. Muchas organizaciones siguen tratando esta categoría como “riesgo legal” cuando en realidad es también riesgo de ciberseguridad y de resiliencia operacional.

La tercera es información regulada sectorial. En banca, expedientes de crédito, evaluaciones AML, documentación de clientes, resultados de monitorización de fraude, planes de continuidad, inventarios de activos críticos. En sanidad, datos clínicos. En seguros, siniestros y perfiles actuariales. En industrias críticas, planos, telemetría y configuraciones OT. Aquí shadow AI choca con obligaciones específicas, desde DORA en entidades financieras hasta NIS2 para sectores esenciales e importantes.

La cuarta, y a menudo la más subestimada, son credenciales y secretos técnicos. Tokens API, fragmentos de ficheros.env, consultas con cadenas de conexión, claves embebidas en scripts, URLs internas, procedimientos operativos detallados. Un desarrollador puede pegar un stack trace para depurar. Un analista puede compartir un extracto de configuración para que “la IA le ayude”. Y de pronto no hablamos de productividad, sino de posible compromiso de acceso.

Tu programa de control no necesita tratar igual las cuatro categorías. De hecho, no debería. Necesita saber distinguirlas y responder con distintos niveles de bloqueo, alerta, redacción o canal alternativo aprobado.

GDPR no prohíbe la IA. Prohíbe la negligencia envuelta en entusiasmo

Conviene despejar un malentendido cómodo: GDPR no impide usar IA generativa en la empresa. Lo que hace es exigir que el tratamiento de datos personales cumpla reglas que ya existían antes de que los chatbots se convirtieran en asistente de facto de media oficina.

Las piezas clave están bastante claras. El art. 5 fija principios como minimización, limitación de la finalidad e integridad y confidencialidad. El art. 6 exige una base de licitud. El art. 25 obliga a protección de datos desde el diseño y por defecto. El art. 28 regula la relación con encargados. El art. 32 exige seguridad adecuada al riesgo. El art. 33 impone notificación de violaciones de seguridad a la autoridad competente, por regla general, en un plazo de 72 horas desde que el responsable tiene constancia, si la brecha entraña riesgo para los derechos y libertades de las personas físicas. Y el art. 35 exige una evaluación de impacto cuando un tratamiento pueda entrañar alto riesgo.

Trasladado al shadow AI, el mensaje es menos filosófico y más incómodo. Si sabes que tus empleados utilizan herramientas de IA con información personal y no has definido casos de uso permitidos, ni validado proveedores, ni configurado controles de salida, ni formado a usuarios, ni documentado decisiones, tu problema no es la innovación. Tu problema es de gobernanza básica.

Hay una paradoja interesante. Muchas organizaciones invierten meses en revisar una plataforma central de IA, pero toleran durante ese mismo periodo cientos de microtratamientos dispersos realizados por usuarios con cuentas personales. Desde el punto de vista de riesgo, esa dispersión es peor. No porque cada envío aislado sea enorme, sino porque elimina visibilidad, coherencia contractual y capacidad de respuesta. La suma de pequeños deslices suele construir el gran incidente que nadie vio venir porque estaba fragmentado.

También conviene recordar que no toda exposición de datos a una herramienta de IA será necesariamente una “violación de seguridad” en el sentido del art. 4.12 GDPR. Dependerá de si ha habido destrucción, pérdida, alteración, comunicación o acceso no autorizados a datos personales. Pero esperar a discutir la calificación jurídica después del incidente es una forma muy cara de hacer gobierno del dato.

NIS2 mete presión donde más duele: gestión de riesgos, cadena de suministro y responsabilidad del consejo

Si GDPR pone el foco en datos personales, NIS2 amplía el encuadre a la resiliencia y la gobernanza de seguridad. La Directiva (UE) 2022/2555 obliga a los Estados miembros y, una vez transpuesta, a las entidades cubiertas a elevar el listón de forma tangible. El art. 21 enumera medidas de gestión de riesgos de ciberseguridad que incluyen políticas de análisis de riesgos y seguridad de sistemas, gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, seguridad en adquisición, desarrollo y mantenimiento, evaluación de eficacia de medidas, higiene cibernética y formación, criptografía y seguridad de recursos humanos, entre otras.

Shadow AI entra por varias puertas a la vez. La más evidente es la cadena de suministro: cada uso no aprobado de una herramienta externa incorpora, de facto, un tercero digital no evaluado. El art. 21.2.d no se queda en abstracciones; apunta de forma expresa a la seguridad de la cadena de suministro, incluidas las relaciones entre cada entidad y sus proveedores directos o prestadores de servicios. Traducido: no basta con revisar al gran hyperscaler si tus empleados están usando diez servicios de IA satélite sin control contractual ni técnico.

La segunda puerta es gobernanza. El art. 20 atribuye a los órganos de dirección la aprobación y supervisión de las medidas de gestión de riesgos. Eso complica bastante el clásico reflejo corporativo de mandar el asunto a seguridad “para que lo vea”. Si el shadow AI ya afecta a procesos críticos, atención al cliente, desarrollo, finanzas o RR.HH., no es un tema marginal de herramientas. Es un tema de riesgo empresarial. Y si el consejo aún lo ve como capricho tecnológico, tiene deberes pendientes.

La tercera puerta es notificación de incidentes. Dependiendo de la transposición nacional y del tipo de entidad, un incidente significativo vinculado a un proveedor de IA o a fuga de información a través de servicios no autorizados puede activar plazos de notificación a CSIRT o autoridad competente. NIS2 ha endurecido las expectativas de reporte y coordinación. La época del “ya lo arreglaremos internamente si no trasciende” se ha quedado bastante vieja.

Para sectores regulados intensivamente, la superposición es todavía más exigente. Una entidad financiera puede tener a la vez obligaciones de GDPR, NIS2 donde aplique, DORA en materia de terceros TIC y resiliencia operativa, y requisitos de ISO 27001 o políticas internas del grupo. Si cada marco se gestiona por separado, aparecerán duplicidades absurdas y lagunas peligrosas. Shadow AI es una de esas materias donde conviene construir una sola capa operativa que sirva a varios marcos: inventario, clasificación, control de salida, evaluación de terceros, formación, logging, respuesta y evidencia.

DLP y CASB: útiles, sí; mágicos, no

Cuando una organización descubre shadow AI, la reacción técnica más frecuente es pedir DLP. Tiene lógica. Si el problema es la salida no autorizada de datos, el control de prevención de fuga parece la herramienta natural. Lo es, pero con dos advertencias.

La primera: el DLP sin clasificación de datos razonable genera dos resultados igual de malos. O bloquea en exceso y la gente busca rodearlo, o alerta demasiado poco y se convierte en decoración cara. Un buen programa de DLP para IA necesita al menos tres cosas: diccionarios y patrones para datos sensibles, integración con etiquetas de clasificación corporativa y políticas adaptadas al canal. No es lo mismo correo, endpoint, navegador, API o SaaS.

La segunda: el DLP tradicional fue diseñado pensando en canales relativamente conocidos. Shadow AI añade navegación cifrada, prompts fragmentados, cargas de archivos, extensiones de navegador, integraciones SaaS y servicios que cambian de dominio o de arquitectura con rapidez. El control funciona mejor cuando se combina con CASB o SSPM, proxy seguro, controles de endpoint y visibilidad DNS/HTTP. Si intentas resolver todo con un único motor de inspección, acabarás peleándote con falsos positivos, bypasses y mucho enfado legítimo de negocio.

¿Qué controles concretos suelen funcionar mejor?

Inspección de prompts y cargas de archivos

El objetivo no es leer cada interacción por curiosidad corporativa, sino detectar patrones que indiquen envío de información que no debe salir: números de identificación, IBAN, datos de salud, claves, dumps de bases de datos, fragmentos de repositorios o documentos etiquetados como confidenciales. Las políticas deben distinguir entre bloquear, alertar o permitir con redacción automática. Para ciertos casos, la redacción es más eficaz que la prohibición total.

Bloqueo selectivo por riesgo de proveedor

No todas las herramientas merecen el mismo trato. Algunas permiten configuración empresarial, exclusión de entrenamiento con datos del cliente, residencia regional y logging; otras, no. El CASB ayuda a clasificar aplicaciones cloud, descubrir uso no autorizado y aplicar controles según perfil de riesgo. La pregunta útil no es “IA sí o no”, sino “qué proveedor, con qué contrato, qué retención, qué subprocesadores, qué telemetría y para qué datos”.

Controles en endpoint y navegador

Buena parte del uso ocurre en navegador o a través de extensiones. Ahí entran aislamiento del navegador, políticas de extensión, clipboard control, restricción de cargas y supervisión de actividades de alto riesgo. Un detalle poco glamuroso pero muy práctico: desactivar o limitar el pegado masivo de contenido etiquetado como confidencial hacia dominios no aprobados reduce muchísimo la exposición accidental.

Tokenización, seudonimización y redacción previa

Para algunos procesos sí hay uso legítimo de IA externa, pero no con dato crudo. Seudonimizar expedientes, tokenizar identificadores o redactar nombres y cuentas antes del envío permite aprovechar capacidades de resumen o clasificación con menos riesgo. GDPR art. 25 y art. 32 encajan bien con este enfoque. No elimina el riesgo, pero lo reduce de forma material.

Canal corporativo alternativo

Si no ofreces una vía aprobada, el usuario improvisará. Un asistente corporativo con autenticación empresarial, retención acotada, filtrado de datos, logging y proveedores validados recorta el incentivo para escapar. La productividad compite mal contra la prohibición pura; compite bastante mejor contra una alternativa útil.

Hay algo que la industria tecnológica a veces vende con alegría excesiva: la idea de que “AI security posture management” o etiquetas similares resolverán el problema por sí solas. Ayudan, desde luego. Pero si la organización no sabe qué datos son críticos, qué procesos admiten IA, qué áreas tienen mayor exposición y qué excepciones están formalmente aprobadas, el tooling se convierte en un radar sin doctrina de respuesta.

Descubrimiento real: si no mides uso, no estás gobernando nada

La fase más delicada suele ser la primera: descubrir cuánta shadow AI existe de verdad. Muchas compañías se llevan una sorpresa incómoda al cruzar logs de navegación, DNS, SSO, proxy y facturación. La sorpresa no es que aparezca una herramienta. Es que aparecen decenas. Algunas de uso anecdótico, otras con adopción sostenida en áreas enteras.

Un enfoque útil combina varias fuentes. Los logs de proxy o secure web gateway revelan accesos a dominios de herramientas generativas. El CASB descubre aplicaciones SaaS usadas sin aprobación. La telemetría del endpoint identifica extensiones o aplicaciones locales vinculadas a IA. El SSO muestra qué servicios se usan con correo corporativo. Y compras o finanzas pueden detectar suscripciones reembolsadas a pequeña escala, ese maravilloso agujero por el que entra medio shadow IT desde hace años.

Pero el descubrimiento de verdad no se limita al inventario de herramientas. Debe responder al menos a cinco preguntas operativas:

• Qué departamentos las usan y con qué frecuencia.
• Qué tipo de datos intentan introducir o adjuntar.
• Qué proveedores concentran más actividad.
• Qué casos de uso son legítimos y cuáles no tienen defensa razonable.
• Qué porcentaje de interacciones bloqueadas, permitidas o redactadas acaba en incidencia o excepción.

Esas métricas sí sirven para gobernar. Contar solo número de dominios bloqueados es una vanity metric. Puede impresionar en una diapositiva, pero dice poco sobre el riesgo real.

Para CISOs y compliance, hay tres indicadores que suelen aportar valor temprano. Uno: porcentaje de usuarios únicos que acceden a herramientas de IA no aprobadas al menos una vez al mes. Dos: volumen de eventos DLP relacionados con IA por categoría de dato. Tres: porcentaje de casos de uso migrados a un canal corporativo aprobado. Si el primero baja, el segundo se vuelve más preciso y el tercero sube, estás ganando control de forma tangible.

Política de uso aceptable: corta, concreta y diseñada para sobrevivir al contacto con humanos

La mayoría de políticas sobre IA fracasan por el mismo motivo que muchas políticas de seguridad: parecen escritas para proteger a la organización de una auditoría, no para orientar a una persona que tiene que decidir en veinte segundos si puede pegar un texto en una herramienta.

Una política útil sobre IA no autorizada debería responder de forma inequívoca a cuatro asuntos.

Primero, qué datos no pueden introducirse nunca en herramientas no aprobadas. Aquí no vale “información sensible” como etiqueta vaga. Hay que nombrar clases concretas: datos personales de clientes y empleados, información financiera no pública, secretos comerciales, código fuente, credenciales, documentación legal privilegiada, expedientes disciplinarios, datos sanitarios, claves privadas y cualquier documento etiquetado como confidencial o restringido.

Segundo, qué herramientas están aprobadas y para qué. Si un asistente corporativo solo puede utilizarse para redactado, resumen de textos no confidenciales y búsqueda interna, debe quedar claro. Si existe un proveedor empresarial con controles contractuales reforzados para ciertos equipos, también.

Tercero, qué hacer cuando un empleado necesita usar IA en un caso no cubierto. El proceso de excepción no puede ser un laberinto de tres meses. Si lo es, nadie lo usará. Debe tener un responsable, un formulario breve, criterios de evaluación y un tiempo de respuesta razonable.

Cuarto, qué ocurre si se incumple. No para amenazar por deporte, sino para dar seriedad al control. Formación adicional, revisión de accesos, medidas disciplinarias según gravedad o escalado a privacidad/seguridad si ha habido exposición de datos.

Una observación incómoda pero útil: la política no debería hablar como folleto de innovación ni como sermón de seguridad. Debe sonar a instrucción de trabajo. Los usuarios necesitan reglas de decisión, no poesía corporativa.

Gobierno del dato: la parte menos sexy y más decisiva

Si el shadow AI prospera, casi siempre hay una debilidad de fondo en gobierno del dato. La organización no sabe con suficiente precisión qué información tiene, dónde está, quién es su owner y bajo qué restricciones puede usarse. Sin eso, cualquier programa de control quedará cojo.

La base mínima incluye inventario de activos de información, clasificación por sensibilidad, propietarios de dato, reglas de retención y matriz de usos permitidos. ISO/IEC 27001:2022 encaja bien aquí, especialmente en controles del Anexo A relacionados con inventario de información y otros activos asociados, clasificación de la información, etiquetado, transferencia de información y prevención de fuga de datos. No hace falta convertir el artículo en una exégesis de controles ISO para entender lo relevante: si no tienes esos cimientos, la IA no hará más que amplificar la desorganización existente.

El gobierno del dato también obliga a decidir algo que muchas compañías esquivan: qué procesos empresariales admiten realmente apoyo de IA y con qué nivel de supervisión humana. No es lo mismo un resumen de información pública para marketing que el análisis de reclamaciones, la redacción de cláusulas contractuales o la preparación de una respuesta a un supervisor. La gobernanza madura no pregunta solo “qué herramienta”; pregunta “para qué proceso”, “con qué datos” y “con qué revisión”.

Aquí aparece además el puente con el AI Act, aunque la pieza no gire sobre esa norma. En 2026, muchas empresas ya están alineando sus prácticas de uso de IA con exigencias de gobernanza, documentación y control de riesgos que el Reglamento europeo empuja a consolidar. Shadow AI choca de frente con esa lógica porque introduce sistemas o funcionalidades fuera del circuito de evaluación interna. No todo uso de IA generativa corporativa entra en categorías de alto riesgo. Pero todo uso sin gobierno erosiona la trazabilidad que el ecosistema regulatorio europeo está intentando imponer.

Escenarios por sector: mismo problema, consecuencias muy distintas

Servicios financieros

En una entidad financiera, shadow AI rara vez se queda en “un empleado ha probado una herramienta”. Suele tocar procesos con una densidad regulatoria alta: onboarding, atención al cliente, fraude, scoring, desarrollo, compliance o gestión de incidencias. Si un analista usa una IA externa para resumir expedientes KYC o generar respuestas sobre alertas AML, no solo aparece GDPR; también emergen cuestiones de confidencialidad, trazabilidad y, en muchos casos, obligaciones de control interno. Bajo DORA, los terceros TIC críticos y la gestión del riesgo asociado a proveedores ya exigen una disciplina que resulta incompatible con la proliferación invisible de herramientas no evaluadas. DORA art. 28 sobre gestión del riesgo de terceros TIC y artículos conexos sobre registro de información y estrategia contractual no estaban pensando solo en grandes outsourcers. El espíritu aplica igual: lo que conecta con procesos esenciales no puede estar en la sombra.

Para bancos, aseguradoras y fintech, la conclusión operativa es evidente. La política sobre shadow AI no puede vivir solo en seguridad. Debe coordinarse con riesgo operacional, privacidad, compras, arquitectura y el equipo que gestiona DORA o controles equivalentes.

Sanidad y ciencias de la vida

Aquí el riesgo es más brutal porque la sensibilidad del dato no admite mucho margen. Si personal administrativo o clínico usa herramientas de IA externas para resumir historiales o redactar comunicaciones a pacientes sin salvaguardas, la exposición puede ser grave incluso cuando la intención sea banal. El principio de minimización y la seguridad del tratamiento dejan de ser teoría muy rápido. Además, los procesos asistenciales castigan especialmente las alucinaciones y los errores contextuales. El shadow AI no solo puede filtrar datos; puede contaminar decisiones.

Industria y sectores esenciales

En entornos industriales, energía, transporte o agua, el dato subestimado suele ser el técnico: configuraciones, procedimientos de mantenimiento, esquemas, inventarios de activos, credenciales operativas. Meter eso en una IA externa no siempre parecerá crítico al usuario que solo quiere “entender mejor un log”, pero puede facilitar reconocimiento para un atacante o debilitar la seguridad de sistemas OT. NIS2, precisamente, pretende que estas entidades se tomen en serio la seguridad de los sistemas y de la cadena de suministro. Shadow AI es una vía de ampliación descontrolada de ambas cosas.

Legal y recursos humanos

Los departamentos jurídico y de RR.HH. tienden a manejar información extremadamente sensible y, al mismo tiempo, se benefician mucho de tareas que la IA acelera: resumen de documentos, extracción de cláusulas, preparación de borradores, comparación de CV, actas o políticas. Eso los convierte en usuarios de alto valor y alto riesgo. La solución no es vetar la IA en bloque. Es darles una ruta segura con datos limitados, supervisión y proveedores validados. Si no, seguirán usando herramientas externas porque la productividad manda y las bandejas de entrada no esperan al comité.

Respuesta a incidentes: cuándo un uso indebido de IA se convierte en crisis

No todo evento de shadow AI es un incidente mayor, pero algunos lo son y conviene tratarlos con un playbook específico. Cuando se detecta que un empleado ha subido datos sensibles a un servicio no autorizado, las primeras preguntas deberían ser muy concretas: qué datos exactos se enviaron, en qué fecha y hora, desde qué cuenta, a qué proveedor, con qué configuración de retención, si hubo entrenamiento posterior con esos datos, si el contenido quedó accesible a terceros, y si el proveedor ofrece borrado, exportación o registros de actividad.

La respuesta no puede depender solo del equipo de seguridad. Deben activarse, según el caso, privacidad, legal, negocio afectado y compras/proveedores. Si hay datos personales, la evaluación de brecha bajo GDPR debe hacerse con rapidez real, no ceremonial, porque el reloj del art. 33 no se detiene mientras departamentos discuten de quién era el problema. Si hay secreto comercial o información estratégica, quizá no haya obligación de notificar a una autoridad de protección de datos, pero sí necesidad urgente de contención contractual y técnica.

Un buen playbook para shadow AI incluye al menos: preservación de evidencias, contacto con el proveedor, evaluación del tipo de dato, clasificación de impacto, decisión sobre notificación, medidas de borrado o minimización, comunicación interna al área afectada y revisión de control para evitar repetición. Ese último punto suele olvidarse. Se cierra el ticket y nadie corrige la causa raíz. Luego llega el siguiente caso, con un prompt distinto y la misma torpeza organizativa.

Qué evidencias pediría una auditoría seria

Si mañana te sientas ante auditoría interna, un supervisor sectorial o una revisión de certificación ISO 27001, prohibir “el uso no autorizado de IA” no va a impresionar a nadie. Lo que pesa son evidencias. Aquí sí merece la pena ser concreto.

• Inventario de herramientas de IA aprobadas y matriz de casos de uso permitidos por área.
• Registro de descubrimiento de aplicaciones no autorizadas vía CASB, proxy, DNS o endpoint, con tendencia mensual.
• Políticas DLP específicas para dominios o categorías de IA, con reglas diferenciadas por tipo de dato.
• Contratos o anexos de tratamiento con proveedores aprobados, incluyendo rol de encargado si aplica bajo GDPR art. 28.
• Evaluaciones de impacto o análisis de riesgo para casos de uso que impliquen datos personales o información crítica.
• Materiales de formación y porcentaje de empleados formados, con campañas dirigidas a colectivos de mayor exposición.
• Procedimiento de gestión de excepciones y decisiones documentadas.
• Playbook de respuesta a incidentes por fuga a herramientas de IA externas, con pruebas o tabletop recientes.
• Evidencias de revisión por dirección o comité de riesgos, especialmente relevante bajo la lógica de NIS2 art. 20.

Si esa documentación no existe, el problema no es solo técnico. Es de control interno. Y esa clase de vacío suele salir cara cuando una investigación externa pregunta no si había política, sino si la organización podía demostrar que la aplicaba.

El equilibrio incómodo: permitir lo útil sin abrir la compuerta

La tentación de muchas organizaciones es irse a un extremo. O permitir casi todo y confiar en la buena fe del usuario, o bloquearlo todo y fingir que el fenómeno desaparecerá. Ninguno de los dos modelos aguanta mucho en 2026.

El enfoque que mejor está funcionando en empresas europeas maduras se parece más a esto: catálogo reducido de herramientas aprobadas, clasificación de datos obligatoria, DLP afinado por canal, monitorización de uso no autorizado, excepciones controladas, formación muy pegada al puesto y revisión continua de proveedores. No suena revolucionario. No lo es. Pero suele funcionar porque parte de una idea sensata: la IA ya forma parte del trabajo diario, así que la seguridad tiene que moldear el uso, no fantasear con abolirlo.

También conviene introducir una dosis de honestidad ejecutiva. Si el negocio exige rapidez y los equipos están saturados, la demanda de IA no va a bajar. La empresa debe decidir si quiere que esa demanda se canalice por una arquitectura gobernada o por la creatividad anónima de sus empleados. La segunda opción es, por desgracia, la predeterminada cuando la primera tarda demasiado.

La ironía final es esta: muchas organizaciones creen que el gran riesgo de la IA es un modelo futurista que tome malas decisiones. Antes de llegar ahí, el daño más probable sigue siendo bastante menos cinematográfico: alguien pega lo que no debía en el lugar equivocado. Shadow AI no es un debate sobre el mañana. Es una disciplina de control sobre lo que ya está pasando esta semana.

Qué debería hacer ahora un CISO o un responsable de cumplimiento

Primero, medir. No opiniones; datos. Descubre qué herramientas se usan realmente, por quién y con qué patrones. Segundo, clasificar el riesgo por tipo de dato y por proveedor. Tercero, ofrecer una alternativa aprobada para los casos de uso legítimos. Cuarto, ajustar DLP y CASB sobre escenarios reales, no sobre una lista teórica de dominios. Quinto, revisar contratos, roles de tratamiento y transferencias internacionales cuando haya datos personales. Sexto, entrenar a usuarios con ejemplos de su trabajo, no con slogans. Séptimo, llevar el asunto a comité de riesgo o a dirección cuando afecte a procesos críticos. Si entra en el negocio, entra en gobernanza.

No hace falta dramatizar para justificar la inversión. Basta con reconocer algo bastante simple: la IA no autorizada convierte el dato en una frontera porosa. Y una frontera porosa, en cumplimiento y ciberseguridad, nunca se arregla solo con buenas intenciones.