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

La adopción de IA generativa en las empresas ha ido más rápido que la capacidad real de gobernarla. Ese desfase ya no es una anécdota de innovación desordenada. Es un problema de cumplimiento, seguridad y trazabilidad. Y no porque la tecnología sea nueva —a estas alturas ya no cuela—, sino porque demasiadas organizaciones siguen tratándola como si fuese una herramienta ofimática algo más vistosa, cuando en realidad introduce flujos de datos, dependencias de terceros y decisiones automatizadas que pisan varias capas regulatorias a la vez.

El resultado es incómodo: el uso corporativo de servicios de IA está creciendo más deprisa que los controles internos para saber quién los usa, con qué datos, bajo qué base jurídica y con qué garantías contractuales. Si eso te suena a mezcla explosiva entre GDPR, DORA, NIS2 y gestión de terceros, acertaste. Lo es.

La cuestión no es si la IA debe prohibirse o celebrarse. La cuestión seria es otra: qué obligaciones concretas ya existen hoy, aunque tu empresa todavía siga llamando “piloto” a un uso que en la práctica ya es producción. Porque el regulador no suele mostrar mucha ternura con los eufemismos.

El problema no es la IA en abstracto. Es el uso opaco

Hay un error recurrente en muchos comités de dirección: discutir la IA como categoría general —riesgos éticos, productividad, transformación— y dejar para más tarde la parte menos glamourosa, que es la única que luego aparece en una investigación interna o en una inspección. Qué herramienta se ha usado. Qué datos han salido. Qué proveedor estaba detrás. En qué jurisdicción. Bajo qué condiciones. Y quién aprobó el uso, si es que alguien lo aprobó.

Ese aterrizaje importa porque el riesgo no nace cuando una organización despliega un gran modelo fundacional propio. Nace mucho antes. Nace cuando un empleado pega en un chatbot público un contrato, un extracto de clientes, código interno, una incidencia de soporte con datos personales o un informe de auditoría. A partir de ahí, el debate deja de ser estratégico y pasa a ser jurídico y operativo.

Si en ese intercambio hay datos personales, GDPR entra por la puerta principal. El artículo 5 exige principios de licitud, minimización, limitación de finalidad e integridad y confidencialidad. El artículo 24 obliga al responsable del tratamiento a aplicar medidas apropiadas para garantizar y poder demostrar que el tratamiento es conforme al Reglamento. Y el artículo 32 aterriza la obligación de seguridad en medidas técnicas y organizativas adecuadas al riesgo. No hace falta una norma específica sobre chatbots para que eso ya importe hoy.

Si además la herramienta pasa a integrarse en procesos internos, o depende de un proveedor externo para una función relevante del negocio, el asunto deja de ser solo privacidad. En entidades financieras, por ejemplo, la conversación conecta enseguida con DORA y su arquitectura sobre gestión del riesgo TIC, incidentes, pruebas de resiliencia y riesgo de terceros en los artículos 5 a 16 y 28 a 30. En sectores esenciales o importantes, NIS2 también aprieta en gobernanza y medidas de ciberseguridad a través del artículo 21. La IA no suspende las reglas anteriores. Se monta encima de ellas.

Lo que sí puede afirmarse con base regulatoria: responsabilidad, roles y trazabilidad

Uno de los atajos narrativos más tentadores consiste en decir que, si un empleado introduce datos personales en un servicio externo de IA, la empresa “sigue siendo responsable” sin más matices. La intuición general va bien encaminada, pero jurídicamente conviene afinarla. Bajo GDPR, la calificación exacta depende de los roles y de los fines y medios del tratamiento.

Si la organización decide utilizar un servicio de IA para tratar datos personales en el contexto de sus actividades, seguirá teniendo obligaciones como responsable del tratamiento en la medida en que determine los fines y medios de ese tratamiento, conforme al artículo 4.7 y a los artículos 24 y 25 del GDPR. El proveedor externo, a su vez, podrá actuar como encargado del tratamiento o, en determinados escenarios, como responsable independiente o incluso corresponsable, según la configuración concreta del servicio y el reparto real de decisiones. Dicho de otra forma: no basta con asumir; hay que calificar bien la relación.

Ese matiz no suaviza el problema. Lo hace más serio. Porque obliga a revisar contratos, instrucciones, transferencias internacionales, medidas de seguridad y límites de uso del proveedor. El artículo 28 GDPR exige que, cuando haya un encargado del tratamiento, exista un contrato con contenido mínimo obligatorio. Y el capítulo V del Reglamento impone condiciones específicas si hay transferencias de datos personales fuera del EEE. Si tu empresa usa una herramienta de IA sin saber con claridad dónde se procesan los datos, quién puede reutilizarlos o si se emplean para entrenamiento adicional, no tienes un problema semántico. Tienes un agujero de gobierno del dato.

También conviene abandonar otra ficción corporativa: la de que todo uso de IA puede dejarse a la política general de TI o a un código ético de cuatro páginas. No. Cuando una tecnología altera la forma en que los datos se introducen, circulan, se transforman y salen de la organización, la trazabilidad deja de ser una preferencia de buenas prácticas y se convierte en condición mínima de defensa. Sin trazabilidad, demostrar cumplimiento ex post es bastante más difícil. Y cuando llegan un incidente, una reclamación o una auditoría, la memoria institucional suele ser sorprendentemente frágil.

ENISA, DORA y NIS2: menos retórica de innovación, más disciplina operativa

Conviene separar lo que el regulador ha dicho de forma verificable de lo que el mercado ha querido oír. ENISA mantiene trabajo y recursos sobre inteligencia artificial y ciberseguridad, pero atribuirle fórmulas demasiado redondas sin respaldo textual es la clase de exageración que luego se cae en fact-checking. Lo prudente es esto: a escala europea, la IA está siendo tratada de forma creciente como una materia con implicaciones de seguridad, gobernanza y gestión del riesgo, no solo como una cuestión de innovación. Esa lectura sí encaja con la evolución normativa y supervisora de la UE.

DORA, por ejemplo, no habla de IA como categoría autónoma central, pero sí establece un marco exigente de gestión del riesgo relacionado con las TIC para las entidades financieras. Ahí están los artículos 5 a 16: gobernanza interna, identificación, protección, detección, respuesta, recuperación, aprendizaje y comunicación. Si una herramienta de IA entra en la cadena operativa de una entidad, o si se apoya en infraestructuras y proveedores TIC relevantes, no queda fuera de esa lógica por llevar una etiqueta más moderna.

La parte realmente útil de DORA para esta conversación está en dos planos. El primero es interno: el artículo 6 exige un marco sólido, completo y bien documentado de gestión del riesgo TIC; el artículo 8 obliga a identificar, clasificar y documentar de forma adecuada todas las funciones soportadas por TIC, los activos de información y las dependencias relevantes. El segundo es externo: los artículos 28 a 30 aprietan sobre el riesgo derivado de terceros proveedores de servicios TIC, incluidas las exigencias contractuales y de supervisión. Si una organización consume IA como servicio, esas disposiciones importan más que cualquier eslogan sobre “transformación responsable”.

NIS2 sigue una lógica parecida para entidades esenciales e importantes. El artículo 21 exige medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar los riesgos planteados para la seguridad de redes y sistemas de información. Entre esas medidas figuran políticas de análisis de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas, y prácticas básicas de ciberhigiene. Otra vez: no hace falta que la directiva enumere cada caso de uso de IA para que la obligación sea relevante.

La moraleja regulatoria es bastante menos exótica de lo que algunos vendedores de humo quisieran. La IA no crea un universo legal separado. Lo que hace es tensionar requisitos ya existentes: conocer tus activos, gobernar a tus terceros, limitar datos, documentar decisiones, asegurar sistemas y responder con rapidez cuando algo sale mal. Nada muy sexy. Todo muy exigible.

El verdadero punto ciego: uso informal, compras descentralizadas y datos fuera del radar

Donde muchas organizaciones se complican la vida no es en el gran proyecto anunciado por la dirección, sino en el uso pequeño, distribuido y banal que nadie cartografía a tiempo. Suscripciones pagadas con tarjeta corporativa. Plugins conectados por equipos de marketing o ventas. Cargas de documentos en asistentes integrados en suites de productividad. Pruebas de desarrolladores con repositorios de código. Automatizaciones montadas por áreas de negocio sin revisión de legal, seguridad o procurement.

Ese patrón no necesita dramatización para ser peligroso. Basta con entender su efecto acumulativo: multiplica proveedores, dificulta la clasificación del dato, dispersa la evidencia contractual y complica la trazabilidad técnica. Si el uso se canaliza por navegador, aplicaciones SaaS o integraciones ligeras sin un inventario claro ni reglas de registro adecuadas, reconstruir qué información salió, hacia qué servicio y bajo qué cuenta puede convertirse en una tarea muy ingrata. No porque sea imposible en todos los casos, sino porque depende de la visibilidad real que tenga la organización sobre endpoints, identidad, navegación, logs y gobierno SaaS. Y muchas empresas descubren ese déficit cuando ya van tarde.

Aquí es donde suele aparecer una ironía poco graciosa: compañías muy maduras en control de phishing, malware o hardening de endpoint pueden seguir teniendo una visibilidad mediocre sobre flujos de datos hacia servicios de IA utilizados de forma dispersa. No hace falta sostener que todas hayan gastado fortunas en una cosa y desatendido la otra. Basta con observar una realidad operativa: la seguridad clásica y el gobierno del dato no siempre han evolucionado al mismo ritmo, y la IA está explotando justo esa costura.

Qué enfoque tiene sentido sin vender recetas universales

Sería tentador resolver el asunto con una lista definitiva de herramientas y declarar la misión cumplida. Sería también intelectualmente perezoso. No existe un paquete mágico que, por sí solo, devuelva el control sobre el uso corporativo de IA. Lo que sí puede decirse con rigor es que las organizaciones necesitan combinar varias capacidades si quieren gobernar este riesgo de forma creíble.

La primera es visibilidad. Saber qué servicios se están utilizando, desde qué identidades, dispositivos y redes, y con qué nivel de aprobación interna. La segunda es gobierno del dato: clasificar qué información puede o no puede introducirse en determinados entornos, y bajo qué condiciones. La tercera es control técnico proporcionado al riesgo, que puede incluir medidas sobre navegación, protección de datos, gestión de identidades, seguridad de endpoints o supervisión del tráfico, según la arquitectura de la organización. La cuarta es norma interna operativa, no decorativa: una política de uso aceptable y procedimientos asociados que digan qué está permitido, qué requiere evaluación previa y qué queda prohibido.

La combinación exacta variará según el sector, la exposición regulatoria, el tipo de datos y el modelo de adopción tecnológica. Un banco sujeto a DORA y a supervisión intensa no parte del mismo punto que una empresa mediana sin cargas sectoriales equivalentes. Una entidad sanitaria, por su dependencia de datos sensibles, tampoco juega con la misma tolerancia al error que una firma con información menos crítica. El consejo útil no es fingir uniformidad, sino evitar dos extremos igual de malos: pensar que basta con bloquearlo todo o pensar que bastan unas guías voluntarias publicadas en la intranet.

GDPR no prohíbe improvisar porque sí. Te obliga a justificar

Buena parte del debate sobre IA y privacidad está contaminado por una pregunta mal planteada: “¿se puede usar?” La pregunta seria es otra: “¿bajo qué base, con qué garantías, para qué finalidad, y con qué límites?” GDPR rara vez funciona como un semáforo binario. Funciona como una máquina de justificación documentada. Si no puedes explicar y demostrar por qué el tratamiento es lícito, necesario y proporcional, vas mal. Si además no puedes demostrar seguridad, minimización y control sobre terceros, vas peor.

El artículo 5.1.c exige minimización de datos: solo los adecuados, pertinentes y limitados a lo necesario. Eso choca frontalmente con el hábito bastante humano de pegar “un poco más de contexto” en un prompt para obtener mejor respuesta. El artículo 25 impone protección de datos desde el diseño y por defecto. Si un proceso incorpora IA y no ha definido restricciones sobre el tipo de datos que pueden introducirse, retención, acceso y salidas, cuesta defender que el diseño sea precisamente ejemplar. Y el artículo 35 obliga a realizar una evaluación de impacto cuando un tipo de tratamiento, en particular si utiliza nuevas tecnologías, pueda entrañar un alto riesgo para los derechos y libertades de las personas físicas. No toda IA requiere automáticamente una EIPD, pero muchos usos corporativos serios tampoco deberían descartarla por reflejo.

Hay además un ángulo práctico que las organizaciones subestiman: la respuesta a incidentes. Si se produce una divulgación no autorizada de datos personales a través de una herramienta externa de IA, la obligación de analizar si existe una violación de seguridad de los datos personales aparece enseguida. Los artículos 33 y 34 GDPR fijan el marco de notificación a la autoridad de control y, en ciertos casos, a los interesados. Sin visibilidad suficiente sobre qué salió y a quién, cumplir con tiempos y contenido de notificación se vuelve mucho más complicado. La regulación no perdona la falta de información solo porque el canal fuese nuevo o la fuga tuviera estética de productividad.

DORA añade algo que cambia la conversación: dependencia operativa de terceros

En el sector financiero, DORA mete bisturí donde antes abundaban los parches. Si una entidad utiliza soluciones de IA soportadas por proveedores externos de servicios TIC, no está gestionando solo un riesgo de software. Está gestionando dependencia operativa. Y DORA quiere que eso se trate con bastante menos informalidad que en etapas anteriores.

El artículo 28 exige que las entidades financieras gestionen el riesgo asociado a terceros proveedores de servicios TIC como parte integrante del marco de gestión del riesgo TIC. El artículo 30 enumera elementos contractuales clave que deben abordarse, incluidos la descripción completa de funciones y servicios, lugares de prestación y tratamiento, disponibilidad, integridad, acceso, recuperación, asistencia en incidentes, terminación y derechos de acceso, inspección y auditoría. Si tu proveedor de IA no encaja cómodamente en esa conversación contractual, el problema no es DORA. Es tu onboarding.

Esto tiene una derivada operativa muy concreta. Muchas compras de tecnología de IA se han producido por vías rápidas: área usuaria, prueba funcional, contratación SaaS, despliegue. El orden regulatoriamente sensato es casi el inverso: evaluación del caso de uso, clasificación del dato, análisis del proveedor, encaje contractual, integración de controles, y solo entonces despliegue. Sí, va más despacio. También reduce la probabilidad de que seguridad, compliance y negocio acaben reuniéndose de urgencia cuando el servicio ya se ha extendido.

DORA añade otra capa que suele pasarse por alto: la documentación. El reglamento no está pensado para premiar intuiciones heroicas ni dependencias que solo conoce un equipo concreto. Está diseñado para que la entidad pueda demostrar estructura, inventario, gobernanza y capacidad de respuesta. Eso obliga a aterrizar qué papel juega cada servicio de IA en procesos críticos o importantes, si es que lo juega, y cómo se gestiona su dependencia. El romanticismo de “ya veremos” funciona fatal cuando hay que enseñar evidencias.

NIS2 y cadena de suministro: la IA también entra por esa puerta

En organizaciones sujetas a NIS2, el riesgo no termina en el modelo o en el interfaz. Sigue hacia la cadena de suministro. El artículo 21.2.d menciona expresamente la seguridad de la cadena de suministro, incluidas las relaciones entre cada entidad y sus proveedores directos o prestadores de servicios. Eso vuelve especialmente relevante el fenómeno de capas sobre capas: proveedor principal, subencargados, infraestructura cloud subyacente, APIs externas, herramientas de entrenamiento o moderación y servicios de soporte.

La pregunta incómoda es simple: ¿tu proceso de evaluación de terceros ve realmente toda esa cadena o solo la primera caja del diagrama comercial? Porque una cosa es contratar un servicio con una marca conocida, y otra saber qué arquitectura, localizaciones de tratamiento y dependencias adicionales hay detrás. Con IA, esa distancia entre marketing y realidad técnica puede ser considerable.

NIS2 también insiste en continuidad, gestión de incidentes y seguridad en adquisición y mantenimiento. Si una capacidad de IA empieza a formar parte de operaciones relevantes —atención al cliente, análisis de fraude, soporte al desarrollo, automatización interna, clasificación documental—, conviene preguntarse qué pasa cuando falla, se degrada, cambia condiciones, introduce errores materialmente relevantes o deja de estar disponible. No todo es confidencialidad. También hay integridad, disponibilidad y resiliencia.

El choque entre productividad y minimización de datos ya está aquí

La promesa comercial de muchos servicios de IA es sencilla: cuanto más contexto les das, mejor responden. El principio jurídico de privacidad dice casi lo contrario: da solo lo necesario. Ahí está una de las tensiones más reales de 2026, y no se resuelve con presentaciones sobre innovación responsable.

En la práctica, los equipos de negocio quieren velocidad y resultados útiles. Los equipos de legal y seguridad quieren límites, revisión y evidencia. Ninguno está del todo equivocado. El error consiste en pensar que esa tensión desaparecerá sola. No va a desaparecer. Hay que diseñarla. Eso significa definir categorías de datos permitidos y prohibidos para distintos tipos de herramientas, procesos de aprobación por nivel de riesgo, condiciones de uso empresarial frente a cuentas personales o no gestionadas, y requisitos de logging y supervisión allí donde el caso de uso lo justifique.

También significa asumir que no todos los servicios de IA merecen el mismo trato interno. Un asistente para reformular textos no plantea exactamente el mismo perfil que una herramienta conectada a repositorios de código, una solución de transcripción de reuniones con datos de clientes o un agente con acceso a sistemas corporativos. El gobierno maduro distingue. El inmaduro redacta una política genérica y confía en que nadie pregunte demasiado.

Lo que deberías revisar ya, sin esperar a la próxima moda regulatoria

Si tu organización usa IA de forma corporativa —aunque sea de manera parcial, distribuida o todavía poco formalizada—, hay varias preguntas que ya deberían tener respuesta verificable.

• Inventario: qué servicios de IA están autorizados, tolerados o detectados; quién es el propietario interno del caso de uso; y qué proveedor está detrás.
• Datos: qué categorías de información pueden introducirse, cuáles quedan prohibidas y qué base jurídica aplica cuando hay datos personales.
• Roles GDPR: si el proveedor actúa como encargado, responsable independiente o en otra configuración jurídicamente defendible, con reflejo contractual adecuado bajo el artículo 28 cuando corresponda.
• Transferencias: si hay tratamiento fuera del EEE o acceso desde terceros países, y bajo qué mecanismo del capítulo V del GDPR se sostiene.
• Seguridad y trazabilidad: qué registros, controles de acceso, supervisión y medidas de protección se aplican al uso de estas herramientas.
• Terceros: si el servicio ha pasado un proceso de due diligence proporcional al riesgo y si su encaje contractual soporta las exigencias regulatorias aplicables, incluidas las de DORA si la entidad está dentro de su ámbito.
• Incidentes: cómo se detectaría, escalaría e investigaría una divulgación no autorizada de datos o un uso no aprobado de una herramienta externa.

No hace falta convertir esto en un teatro burocrático. Sí hace falta que exista evidencia. La diferencia entre una organización gobernada y otra improvisada no suele estar en el PowerPoint. Está en si puede responder con precisión cuando alguien pregunta: “¿qué estáis usando, con qué datos y bajo qué control?”

La objeción habitual: “si frenamos demasiado, el negocio se irá por la puerta de atrás”

La objeción tiene parte de razón. Los bloqueos indiscriminados empujan al shadow IT. Si todo requiere semanas de revisión o si la única respuesta interna es “no”, los equipos buscarán atajos. Ha pasado con cloud, con mensajería, con compartición de archivos y ahora pasa con IA. Pero usar esa objeción como excusa para no gobernar nada también es una forma elegante de rendición.

El enfoque sensato no es prohibir por defecto ni bendecir por defecto. Es segmentar. Casos de bajo riesgo, carril rápido con condiciones claras. Casos de riesgo medio, validación abreviada con requisitos mínimos. Casos de riesgo alto —datos sensibles, decisiones relevantes, integración con sistemas críticos, proveedores opacos—, revisión robusta y aprobación formal. Eso no elimina toda fricción. La pone donde debe estar.

Además, una gobernanza mínimamente inteligente puede convertirse en ventaja operativa. Cuando los equipos saben qué herramientas están aprobadas, qué usos son aceptables y qué datos no deben salir, la adopción tiende a ser menos caótica. Y cuando seguridad, legal y negocio comparten criterios desde el principio, el coste de corregir errores después suele bajar. No siempre. Pero bastante más a menudo de lo que admiten quienes prefieren llamar “agilidad” a la ausencia de control.

La conclusión incómoda: el problema ya no es descubrir la IA, sino gobernarla

El mercado ha gastado mucha energía en debatir si la IA cambiará la empresa. Esa discusión ya está superada. La está cambiando. La pregunta adulta es si la organización está preparada para responder por ese cambio cuando entren en juego privacidad, seguridad, continuidad, terceros y supervisión regulatoria.

Lo relevante hoy no es repetir que la IA trae riesgos. Gracias, ya lo sabíamos. Lo relevante es aceptar que esos riesgos ya encajan en obligaciones bastante concretas: GDPR exige licitud, minimización, seguridad, responsabilidad demostrable y, cuando toque, evaluación de impacto; DORA exige marco de gestión del riesgo TIC, documentación y disciplina con terceros; NIS2 exige medidas de seguridad, gobierno y atención a la cadena de suministro. Si el uso corporativo de IA sigue creciendo en tu organización sin inventario claro, sin clasificación de datos, sin revisión de proveedores y sin criterios internos exigibles, no estás ante una fase temprana de innovación. Estás acumulando deuda de control.

Y esa deuda tiene una costumbre desagradable: no se presenta sola. Suele aparecer acompañada de un incidente, una auditoría, una reclamación o una pregunta del supervisor. Justo cuando menos apetece improvisar.