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

La IA en la empresa no suele entrar por la puerta principal. Se cuela por una extensión del navegador, por una cuenta gratuita abierta con correo corporativo, por un copiloto activado en una suite ofimática, por una API contratada por un equipo de producto con la mejor intención del mundo y la peor disciplina documental posible. Luego llega auditoría, o cumplimiento, o el CISO, y descubre que el problema no era filosófico. Era bastante más prosaico: no sabían qué se estaba usando, quién lo estaba usando ni con qué datos.

Esa es la discusión útil. No si la IA “va a transformar el negocio” —gracias, capitán obvio—, sino si la entidad puede demostrar control sobre herramientas que procesan información corporativa, datos personales, secretos comerciales o decisiones con efecto operativo. Ahí es donde la conversación deja de ser de innovación y pasa a ser de gobernanza, seguridad y evidencia. Y ahí también empiezan a cruzarse, de forma incómoda, varias normas que demasiadas organizaciones siguen gestionando como compartimentos estancos.

Si trabajas en una entidad financiera, en una aseguradora, en un proveedor tecnológico crítico o en una organización sujeta a GDPR, NIS2 o DORA, el uso no autorizado de servicios de IA no es un asunto cosmético. Puede convertirse en una combinación bastante desagradable de tercero no evaluado, tratamiento de datos no suficientemente mapeado, controles de seguridad no validados y cadena de subencargados mal entendida. Lo peor no es el titular. Lo peor es no poder explicarlo cuando te lo pregunten.

El problema real no es “shadow AI”. Es no poder demostrar control

El término shadow AI tiene gancho, pero también tiene algo de trampa. Hace pensar en una categoría tecnológica nueva, cuando en realidad mezcla tres problemas antiguos con una capa generativa por encima: compras fuera de proceso, uso de servicios cloud no inventariados y tratamiento de datos sin evaluación suficiente.

La novedad está en la velocidad y en la facilidad de adopción. Un empleado no necesita desplegar infraestructura ni pasar por compras para usar una herramienta de IA generativa. En muchos casos basta con registrarse, pegar contenido y seguir trabajando. Desde el punto de vista del área de control, eso revienta la secuencia clásica de gobernanza: primero evaluación, luego alta en catálogo, después contrato, más tarde controles técnicos, y solo al final uso productivo. Con la IA ocurre a menudo al revés: primero uso, luego alarma, si hay suerte inventario, y después la desagradable tarea de reconstruir qué datos salieron y con qué base jurídica o contractual.

Ese desorden tiene una consecuencia regulatoria muy concreta: una organización puede tener políticas razonables sobre terceros, protección de datos o seguridad, y aun así quedarse sin defensa práctica si no puede probar que esas políticas alcanzaban al servicio realmente utilizado. La distancia entre “teníamos una norma interna” y “podemos evidenciar que se aplicó a esta herramienta, este flujo de datos y este proveedor” es exactamente el tipo de distancia que les gusta medir a supervisores, auditores internos y autoridades de protección de datos.

DORA, GDPR y NIS2 no hablan exactamente de IA. Aun así, el golpe te llega por ahí

Aquí conviene cortar una mala costumbre: esperar a que una norma diga literalmente “inteligencia artificial” para asumir que aplica. Muchas veces no hace falta. Lo relevante es qué función cumple el servicio, qué datos toca, si soporta procesos críticos y si introduce dependencia de terceros o riesgo operativo.

En DORA, por ejemplo, el núcleo no está en si el proveedor se presenta como plataforma de IA, copiloto, motor de inferencia o servicio cognitivo con nombre grandilocuente. El núcleo está en si es un proveedor tercero de servicios TIC y en si su uso afecta a funciones de negocio, procesos o activos de información de la entidad. El régimen de gestión del riesgo de terceros TIC de DORA aparece en el Capítulo V, con el art. 28 como punto de partida para el marco de gestión del riesgo asociado a terceros proveedores de servicios TIC. Ese artículo obliga a adoptar y revisar una estrategia sobre riesgo de terceros TIC, incluyendo política sobre uso de servicios TIC que soportan funciones críticas o importantes. Si tienes herramientas de IA usadas en la práctica, pero fuera del inventario o de la evaluación de terceros, el problema no es semántico. Es de alcance del control.

El art. 30 de DORA, sobre el contenido contractual esencial en el uso de servicios TIC, también importa más de lo que parece en este debate. Si una herramienta se usa de hecho para tratar información corporativa o soportar actividad relevante, la entidad debería poder explicar qué base contractual existe, qué derechos de acceso, auditoría o terminación se han previsto y cómo se gestiona la cadena de subcontratación cuando procede. En servicios de consumo o freemium, esa explicación suele ser, siendo generosos, creativa.

GDPR es igual de incómodo, quizá más. Si en una herramienta de IA se introducen datos personales, el análisis no empieza preguntando si la herramienta “aprende” o si el proveedor promete no entrenar modelos con las entradas del cliente. Empieza con preguntas bastante menos glamurosas: quién es responsable del tratamiento, quién es encargado, qué base del art. 6 GDPR se invoca, si hay categorías especiales del art. 9, qué deber de información se ha cumplido, si existe transferencia internacional bajo el Capítulo V y si procede un contrato de encargado conforme al art. 28 GDPR. Si además el tratamiento puede implicar alto riesgo, la organización debería preguntarse si toca una evaluación de impacto de protección de datos con arreglo al art. 35. Muchas discusiones internas sobre IA se atascan en el “ya veremos la política”. El regulador, en cambio, suele empezar por el mapa de tratamiento y la legitimación.

NIS2 tampoco necesita pronunciar la palabra mágica para ser relevante. El art. 21 exige medidas de gestión de riesgos de ciberseguridad “apropiadas y proporcionadas”, incluyendo políticas de análisis de riesgos, seguridad en la cadena de suministro, gestión de incidentes, continuidad, seguridad en adquisición, desarrollo y mantenimiento, y prácticas de evaluación de la eficacia de las medidas. Si un servicio de IA se integra en procesos operativos o manipula información sensible, su uso cae de lleno en preguntas de cadena de suministro y de control técnico. Otra vez: no por la etiqueta, sino por la función y el riesgo.

La fragmentación existe, pero el error es tratarla como una excusa

El mercado de herramientas de IA cambia deprisa y resulta heterogéneo. Hay modelos generalistas accesibles por interfaz web, servicios embebidos en suites ya contratadas, funcionalidades generativas dentro de productos SaaS tradicionales, API consumidas por equipos de desarrollo, complementos de navegador y soluciones verticales que hacen una sola cosa muy bien. Todo eso complica el inventario, sí. Pero cuidado con convertir esa complejidad en coartada.

La organización no necesita una taxonomía perfecta del universo IA para empezar a gobernarlo. Necesita algo bastante menos heroico y más útil: saber qué servicios están siendo utilizados desde su entorno, con qué cuentas, para qué casos de uso y con qué tipos de datos. Lo que mata el control no es la sofisticación del ecosistema. Es la ausencia de una disciplina básica de descubrimiento, clasificación y decisión.

De hecho, uno de los fallos más repetidos en comités internos es discutir la IA como si fuera una categoría homogénea. No lo es. El riesgo de un chatbot público usado para reformular texto comercial no es idéntico al de una API integrada en un flujo que procesa expedientes de clientes, ni al de un copiloto que accede al correo, al calendario y a la base documental de la compañía. Juntar todo bajo la misma etiqueta produce dos males clásicos: o bien se prohíbe en bloque y nadie obedece, o bien se aprueba en abstracto y nadie controla el detalle. Ambas salidas son una forma elegante de perder el tiempo.

Qué debería mirar una entidad antes de hablar de prohibiciones

La tentación inicial de muchas organizaciones es redactar una política grandilocuente con dos verbos favoritos de cumplimiento: “prohibir” y “autorizar”. Queda muy firme sobre el papel. Luego alguien descubre que la mitad del uso real discurre por servicios que no estaban en el radar, por funcionalidades activadas por defecto en herramientas ya licenciadas o por integraciones contratadas directamente por negocio. La política no fracasa porque sea blanda. Fracasa porque describe un mundo más ordenado del que existe.

La secuencia útil suele ser otra.

Primero, descubrir. No en abstracto, sino con evidencia técnica y documental: telemetría de red cuando sea posible, registros de identidad y acceso, inventario de SaaS, revisión de extensiones y aplicaciones autorizadas, contratos ya firmados por áreas de negocio y análisis de los servicios activados dentro de suites existentes. Si una entidad ya tiene CASB, SSPM, logs de proxy, control de endpoints o herramientas de descubrimiento de aplicaciones cloud, aquí es donde deberían dejar de decorar presentaciones y empezar a trabajar.

Segundo, clasificar por caso de uso y por dato. La misma herramienta puede ser aceptable para generar borradores de contenido público y totalmente inapropiada para cargar documentación de clientes, información financiera no pública o código fuente sensible. Esta diferencia no se resuelve con una lista de “herramientas buenas” y “herramientas malas” en el vacío. Se resuelve uniendo servicio, usuario, función y tipo de información.

Tercero, decidir el tratamiento de control. Algunas herramientas acabarán bloqueadas; otras, toleradas con restricciones; otras, aprobadas formalmente para usos concretos con controles contractuales, técnicos y de formación. Esa segmentación suele funcionar mejor que el maximalismo. También exige más trabajo, que es precisamente por lo que mucha gente intenta esquivarla.

El inventario ya no puede limitarse a proveedores contratados por compras

Este punto merece una pausa porque aquí se están produciendo algunos de los errores más caros, aunque todavía no siempre sean visibles en balances ni en resoluciones sancionadoras públicas. Muchas organizaciones siguen hablando de “inventario de proveedores” cuando en realidad gestionan “inventario de proveedores que pasaron por compras”. No es lo mismo. Y con la IA, menos aún.

Si un empleado se registra directamente en un servicio con su correo corporativo, si un equipo conecta una API con tarjeta del departamento, o si un administrador activa una funcionalidad generativa dentro de una plataforma ya contratada, el riesgo puede materializarse sin que el tercero aparezca en el circuito clásico de alta. Desde una perspectiva DORA, eso erosiona la capacidad de cumplir con un marco de gestión del riesgo de terceros TIC consistente con el art. 28. Desde una perspectiva GDPR, puede implicar tratamientos con encargados o destinatarios no suficientemente mapeados. Desde una perspectiva NIS2, debilita el control sobre cadena de suministro y medidas de seguridad del art. 21.

Aquí está el quid: el catálogo útil no es solo una lista de contratos. Es una vista operativa de servicios realmente usados. Si tu organización aún separa radicalmente el inventario jurídico, el inventario tecnológico y el inventario de uso real, ya sabes por qué la discusión sobre IA suele volverse tan absurda. Cada área cree tener “su” foto, y ninguna coincide con la realidad completa.

Medir bien importa, pero conviene no convertir una intuición en dogma

Cuando aparece un problema nuevo, el reflejo de cualquier organización seria es medirlo. Correcto. El peligro llega cuando se presentan determinadas métricas como si fueran estándar obligatorio o verdad revelada. No lo son. Lo que sí puede decirse con prudencia es que una entidad necesita indicadores que le permitan distinguir entre uso autorizado, uso no catalogado y uso incompatible con sus reglas internas, y hacerlo con suficiente detalle para tomar decisiones.

Eso puede incluir, según la arquitectura y las herramientas de control disponibles, señales como qué servicios se acceden desde dispositivos gestionados, qué identidades corporativas los utilizan, qué áreas concentran el uso, si existen integraciones mediante API, o si se observan flujos hacia servicios no incluidos en el catálogo interno. No hace falta fingir precisión matemática donde no existe. Hace falta construir una línea de visibilidad razonable y mejorarla con el tiempo.

Lo relevante para el CISO, para cumplimiento y para compras no es ganar una discusión sobre la métrica perfecta. Es detectar si hay una brecha entre la política aprobada y el comportamiento real, y si esa brecha se explica por falta de control técnico, por un proceso de alta demasiado lento o por ambas cosas. Cuando la divergencia es significativa, el problema rara vez se arregla mandando otro correo con recomendaciones bienintencionadas. Suele exigir revisar inventario, proceso de aprobación y controles de acceso a servicios externos.

El riesgo contractual de la IA sigue siendo ridículamente infravalorado

Hay un sesgo persistente en estas conversaciones: dedicar horas al riesgo de fuga de datos y apenas minutos al contrato. Error. Si el servicio va a utilizarse de forma corporativa, la pregunta no es solo qué hace técnicamente, sino qué ha aceptado jurídicamente la empresa, qué facultades conserva el proveedor y qué garantías existen sobre subprocesadores, retención, borrado, localización del tratamiento, auditoría y cambios de condiciones.

DORA vuelve a ser útil aquí por una razón bastante sencilla: obliga a tomarse en serio la relación con terceros TIC. El art. 30 establece elementos contractuales clave, y el art. 28 exige una estrategia y un marco de gestión del riesgo. No basta con decir que la herramienta es “de productividad” y por tanto merece una excepción alegre. Si soporta actividad relevante o toca información sensible, el contrato importa. Mucho.

En GDPR, además, el espejismo del “proveedor reputado” no sustituye a un análisis real del rol del proveedor ni de las condiciones del tratamiento. Un nombre conocido no convierte por arte de magia un flujo de datos en compatible con el art. 28 GDPR ni resuelve por sí solo las cuestiones de transferencias internacionales del Capítulo V. Tampoco elimina la necesidad de valorar minimización de datos del art. 5.1.c o seguridad del tratamiento del art. 32. Si el servicio se usa para cargar datos personales, la compañía necesita algo más sólido que confianza de marca y una presentación comercial con colores tranquilos.

Y hay otro detalle incómodo: muchas funcionalidades de IA vienen embebidas en contratos marco más amplios, mediante anexos, actualizaciones de producto o términos suplementarios que nadie lee hasta que ya es tarde. La frase “ya teníamos contrato con ese proveedor” tranquiliza mucho en comité. A veces tranquiliza más de la cuenta.

Reevaluar proveedores no es un ritual anual; debe responder al cambio real

Otra afirmación que conviene aterrizar: no existe una caducidad universal y mágica de las evaluaciones de proveedores aplicable a todos los casos. Decir que una revisión está “vieja” a partir de un plazo fijo sin apoyo normativo es vender certeza donde solo hay criterio. Lo sensato es otra cosa: revisar con una frecuencia basada en riesgo y, sobre todo, reabrir la evaluación cuando cambian de forma material el servicio, los casos de uso, los datos tratados, la arquitectura de integración o las condiciones contractuales.

Eso encaja bastante mejor con la lógica de DORA y NIS2 que una costumbre burocrática de calendario. DORA exige un marco vivo de gestión del riesgo de terceros TIC; NIS2, en su art. 21, apunta a medidas apropiadas y proporcionadas, no a rituales vacíos. Si un proveedor añade una función generativa que antes no existía, si amplía acceso a repositorios corporativos o si cambia la cadena de subprocesamiento, la pregunta correcta no es cuántos meses han pasado desde el último cuestionario. La pregunta correcta es si el perfil de riesgo ha cambiado lo suficiente como para exigir nueva revisión. En muchos casos, la respuesta será que sí.

Esta distinción importa porque demasiadas organizaciones siguen operando con un modelo de due diligence que sirve para software estable y falla estrepitosamente cuando el servicio evoluciona por capas, despliega nuevas capacidades sin renegociación visible y altera de hecho el tratamiento de datos o la superficie de acceso. El calendario ayuda, pero no sustituye al gatillo por cambio material.

La política de uso aceptable ya no basta si no se conecta con controles técnicos

Una política interna que diga “no introduzca datos confidenciales en herramientas no autorizadas” puede ser perfectamente razonable. También puede ser prácticamente inútil si la entidad no sabe qué herramientas se están usando y no tiene mecanismos para restringir o encauzar ese uso. Con la IA se está viendo con especial claridad porque la fricción de acceso es mínima y la utilidad percibida por el usuario es alta.

La lección es poco romántica pero muy práctica: la gobernanza documental sin ejecución técnica tiene recorrido limitado. Si el riesgo es real, la política debe conectarse con identidad, acceso, filtrado web, controles de endpoint, DLP cuando proceda, segmentación de datos, gestión de extensiones, configuración segura de suites empresariales y catálogos internos consumibles por el usuario. No hace falta prometer control absoluto. Hace falta reducir la brecha entre norma escrita y entorno operativo.

Esto también tiene una derivada de accountability. Bajo GDPR, el principio de responsabilidad proactiva del art. 5.2 exige poder demostrar cumplimiento. Bajo DORA, la gestión del riesgo TIC no se satisface con una biblioteca de políticas bonitas. Bajo NIS2, los órganos de dirección tienen responsabilidad en la aprobación y supervisión de medidas de gestión del riesgo de ciberseguridad; el art. 20 lo deja bastante claro. Traducido al castellano menos diplomático: si la dirección aprueba una política que nadie puede aplicar, no ha resuelto gran cosa.

El choque con el AI Act llegará, pero muchos ya tienen deberes previos sin hacer

Existe la tentación de convertir toda conversación sobre IA en una conversación exclusiva sobre el AI Act. Sería cómodo. También sería una forma bastante eficiente de olvidar obligaciones que ya están aquí por otras vías. Para muchas entidades, el primer problema no será clasificar un sistema como de alto riesgo según el AI Act, sino demostrar que sabían qué herramienta utilizaban, qué datos trataba y bajo qué controles. Dicho de otro modo: antes de la sofisticación regulatoria llega la higiene básica.

Eso no resta importancia al AI Act. Si una organización desarrolla, integra o despliega sistemas que entren en categorías reguladas, tendrá que mirar obligaciones específicas según el rol que ocupe en la cadena de valor. Pero en la práctica operativa, una parte relevante del caos actual no nace de sistemas de alto riesgo formalmente desplegados, sino de usos dispersos, poco inventariados y mal conectados con terceros, datos y seguridad. Ahí es donde DORA, GDPR y NIS2 ofrecen ya una base suficientemente incómoda como para actuar sin esperar a que otra norma venga a repetir lo obvio con más páginas.

Qué hacer ahora si tu organización sospecha que va tarde

Si la entidad tiene la sensación de que el uso de IA ha corrido más que su gobernanza, no hace falta dramatizar. Hace falta priorizar. La secuencia razonable no empieza por un gran manifiesto ético ni por una prohibición universal de escasa vida útil. Empieza por cuatro movimientos bastante terrenales.

• Levantar visibilidad real de uso. Combina fuentes técnicas y administrativas para identificar servicios accedidos, funcionalidades generativas activadas en plataformas existentes e integraciones mediante API o conectores. Si no puedes ver el uso, no podrás gobernarlo con seriedad.
• Clasificar por caso de uso, datos y criticidad. Distingue entre usos de bajo impacto y usos que implican datos personales, información confidencial, decisiones relevantes o soporte a procesos críticos. Esa clasificación debe conectarse con los marcos de terceros, privacidad y seguridad, no quedarse en un PowerPoint.
• Revisar el encaje regulatorio y contractual de los servicios realmente utilizados. Para terceros TIC, DORA art. 28 y art. 30 son referencias centrales. Para tratamiento de datos personales, revisa al menos art. 28, art. 32 y, cuando proceda, art. 35 GDPR, además del Capítulo V si hay transferencias internacionales. Si la organización entra en NIS2, contrasta el uso con las medidas del art. 21 y la gobernanza del art. 20.
• Ajustar controles y catálogo. Algunas herramientas requerirán bloqueo; otras, una versión empresarial con contrato adecuado y configuración reforzada; otras, una guía de uso restringido. El objetivo no es castigar al usuario. Es darle un camino viable para hacer su trabajo sin convertir cada atajo en una incidencia latente.

Lo que no conviene hacer es fingir que todo se resuelve con formación. La formación ayuda. Pero si la herramienta útil tarda tres meses en aprobarse y la no aprobada funciona en cinco minutos, ya sabes cuál ganará la partida en la mayoría de equipos. La gobernanza compite con la fricción. Casi nunca gana solo con buenos modales.

La conclusión incómoda: el problema de IA suele ser un problema de gobierno corporativo mal conectado

Después de revisar políticas, contratos, registros técnicos y obligaciones regulatorias, la conclusión más honesta no es que la IA haya creado un universo totalmente nuevo. Ha expuesto, con bastante crueldad, fallos antiguos de coordinación entre seguridad, compras, legal, privacidad, arquitectura y negocio.

Cuando una entidad no sabe qué servicios se usan de verdad, no tiene un problema exclusivamente tecnológico. Tiene un problema de gobierno. Cuando conoce los servicios pero no puede enlazarlos con base jurídica, contrato, evaluación de riesgo y control técnico, tiene un problema de trazabilidad. Cuando sí tiene la documentación, pero el negocio la esquiva porque el proceso formal llega tarde, tiene un problema de diseño operativo.

La IA solo ha acelerado el ritmo y ha rebajado el coste del desorden.

Si quieres una pregunta útil para llevar al próximo comité, que sea esta: ¿podemos demostrar, con evidencia y no con esperanza, qué herramientas de IA se usan, para qué, con qué datos, bajo qué contrato y con qué controles? Si la respuesta es no, no hace falta un eslogan nuevo. Hace falta ponerse a trabajar.