Shadow AI: sus empleados ya usan IA con datos de la empresa y usted no sabe cuáles

Cuando entramos a revisar el estado de adopción de IA en una organización mediana, la dirección suele tener una lista de tres o cuatro iniciativas: un piloto de atención al cliente, algo de asistencia al desarrollo, quizá un resumen automático de actas. Al cruzar esa lista con lo que hacen los equipos aparece otra realidad: decenas de flujos de trabajo cotidianos que ya pasan por un modelo de lenguaje sin que nadie los haya autorizado, documentado ni evaluado. Es lo que el sector llama shadow AI, la versión actualizada de la vieja shadow IT.

El problema no está en la iniciativa del empleado que busca hacer su trabajo más rápido. Está en que esa iniciativa mueve información —contratos, listados de clientes, código propietario, documentación interna— hacia servicios cuyos términos de tratamiento nadie ha leído, con cuentas personales, fuera de cualquier registro de accesos y sin posibilidad de revocación cuando esa persona se marcha.

Qué dicen los datos disponibles

La magnitud del uso no autorizado se documentó pronto. El Work Trend Index de Microsoft y LinkedIn de 2024 encontró que el 78 % de quienes ya usaban IA generativa en su trabajo llevaban sus propias herramientas a la oficina, y que el 52 % era reacio a admitir que las empleaba en tareas relevantes. Ese segundo dato importa tanto como el primero: la opacidad es deliberada, porque el empleado intuye que está en zona gris.

Del lado del riesgo, el Cost of a Data Breach Report de IBM de 2025 puso cifras a las consecuencias. Un 20 % de las organizaciones consultadas atribuyó una brecha a incidentes relacionados con IA en la sombra, y esas brechas resultaron unos 670.000 dólares más caras que las sufridas por organizaciones con poca o ninguna IA no gobernada, sobre un coste medio global de 4,44 millones de dólares por incidente. El mismo informe señalaba que el 97 % de las entidades que sufrieron un incidente de seguridad vinculado a IA carecía de controles de acceso adecuados sobre esas herramientas, y que el 63 % no disponía de una política de gobernanza de IA.

Lo que estas cifras describen no es un fallo tecnológico sofisticado. Es la ausencia de lo básico: saber qué herramientas se usan, con qué datos y bajo qué cuenta.

Por qué la prohibición empeora la situación

La reacción habitual del comité de dirección, cuando descubre el alcance real del uso, es bloquear los dominios de los principales proveedores en la red corporativa. Hemos visto el resultado varias veces. El uso no desaparece: se traslada al móvil personal, al portátil de casa y a la cuenta gratuita registrada con el correo particular.

El desplazamiento agrava el riesgo en tres frentes. La empresa pierde toda visibilidad sobre qué información sale. El empleado pasa de una cuenta empresarial —donde el proveedor suele comprometerse a no entrenar con los datos y ofrece registro de actividad— a una cuenta de consumo donde esas garantías no aplican por defecto. Y, cuando llega una auditoría, un requerimiento regulatorio o una consulta del delegado de protección de datos, no hay nada que enseñar.

Primer paso: inventario de casos de uso

Antes de escribir una sola línea de política conviene saber qué está pasando. Recomendamos levantar el inventario combinando tres fuentes, en este orden.

  • Datos de red y gestión de identidades. Registros del proxy o del CASB con las peticiones a dominios de proveedores de IA, y listado de aplicaciones OAuth que empleados han conectado a la suite corporativa. Esto da el mapa técnico.
  • Facturación y gastos. Suscripciones a herramientas de IA pagadas con tarjeta de empresa o pasadas como gasto reembolsable, que rara vez han pasado por compras.
  • Entrevistas por área, con amnistía explícita. Sesiones cortas con cada equipo preguntando qué usan y para qué, dejando claro por escrito que el objetivo es habilitar y que declarar no acarrea consecuencias. Sin esa garantía, las respuestas serán inútiles.

Cada caso de uso identificado debería quedar registrado con cinco campos mínimos: proceso de negocio afectado, herramienta y tipo de cuenta, categoría de datos que se introducen, responsable funcional y frecuencia de uso. Con eso ya se puede clasificar por riesgo y decidir.

Segundo paso: una política que autoriza

Una política útil se lee en cinco minutos y responde a la pregunta que el empleado se hace de verdad: qué puedo meter aquí. Nuestra recomendación es estructurarla por categoría de dato, no por herramienta, porque el catálogo de herramientas cambia cada trimestre.

  • Uso libre: información pública, borradores sin datos identificativos, código de ejemplo, documentación abierta.
  • Uso permitido solo en el entorno corporativo contratado: documentación interna, datos de clientes no sensibles, código propietario. Con cuenta empresarial, inicio de sesión federado y compromiso contractual de no entrenamiento.
  • Uso prohibido salvo autorización expresa: categorías especiales de datos personales, información financiera no publicada, credenciales, documentación bajo acuerdo de confidencialidad con terceros.

La política debe ir acompañada de una alternativa aprobada y de calidad razonable para cada uso frecuente detectado en el inventario. Una norma que restringe sin ofrecer sustituto se incumple en cuestión de semanas. También conviene un canal de excepciones con plazo de respuesta corto —cuarenta y ocho horas es un objetivo realista— para que pedir permiso salga más barato que esquivar la norma.

Implicaciones para la dirección

El marco regulatorio europeo refuerza esta línea de trabajo. Las obligaciones de alfabetización en IA del Reglamento Europeo de IA presuponen que la organización sabe dónde se usan estos sistemas y quién los maneja, algo imposible de acreditar sobre una base de uso informal y no registrado.

Para un comité de dirección que quiera cerrar este frente en un trimestre, la secuencia razonable es: inventario en las tres o cuatro primeras semanas, política y catálogo de herramientas aprobadas en las cuatro siguientes, despliegue de cuentas corporativas y formación en el resto. El coste de ese trabajo es una fracción de lo que el informe de IBM sitúa como sobrecoste de una sola brecha con IA en la sombra de por medio.