Shadow AI: cómo gobernar las herramientas de IA que su equipo ya está usando

Esta semana, alguien de su equipo pegó datos de clientes en un chatbot. Ustedes no aprobaron la herramienta, no pueden ver el prompt y un tercero conserva ahora una copia. Eso es shadow AI, y suponer que una prohibición lo va a frenar es la hipótesis más cara de todo su programa de seguridad. Si esos datos eran personales, el problema es doble: acaban de transferir información a un tercero sin base jurídica, algo que en España choca de frente con el RGPD y la LOPDGDD, y en Latinoamérica con leyes como la LFPDPPP mexicana, la Ley 1581 colombiana o la Ley 25.326 argentina.

El shadow AI es una señal de demanda, no un problema de disciplina

Cuando los empleados esquivan a TI para usar ChatGPT, Claude, Gemini o alguno de los cientos de wrappers de IA que hay en el mercado, les están comunicando algo muy preciso: el circuito autorizado es más lento que el no autorizado. Tómenlo como feedback de producto, no como insubordinación.

Prohíban las herramientas y pasarán tres cosas, siempre:

• El uso migra a teléfonos personales y cuentas personales, donde ustedes tienen cero visibilidad y cero protección contractual.
• Su mejor gente, la que automatiza su propio trabajo, es la primera en desertar. Terminan vigilando precisamente a sus perfiles de mayor rendimiento.
• La organización pierde la ganancia de productividad y conserva todo el riesgo, porque los datos siguen saliendo. Solo que salen por canales que ustedes no pueden registrar.

En nuestra experiencia, las empresas que ejecutan un ejercicio de descubrimiento encuentran varias veces más herramientas de IA en uso activo de las que la dirección imaginaba. Marketing tiene una herramienta de copywriting pagada con tarjeta personal. Ingeniería tiene un asistente de código en la mitad de los IDE. Finanzas resume contratos en un chatbot gratuito. Nada de eso pasó por compras.

El objetivo de la gobernanza no es llegar a cero shadow AI. El objetivo es que la vía autorizada sea más rápida y más segura que la vía en la sombra, y después verificarlo con controles en lugar de confiar.

Por dónde se fugan los datos en realidad

"Fuga de datos" es un término vago. Sean específicos con los mecanismos, porque cada uno exige un control distinto.

Las cuatro vías de fuga

• Contenido del prompt. Un empleado pega código fuente, datos personales de clientes, cifras financieras o credenciales directamente en un chatbot de consumo. En los planes gratuitos, ese contenido puede retenerse y usarse para entrenar modelos según los términos por defecto. Es el caso clásico y sigue siendo el más frecuente.
• Contexto retenido. Incluso en planes de pago, el historial de conversaciones, los archivos subidos y las funciones de "memoria" persisten en la infraestructura del proveedor. Una cuenta personal comprometida expone de un solo golpe meses de contexto acumulado de la empresa.
• Extensiones de navegador y plugins. Las extensiones de IA suelen pedir permisos de lectura de página. Eso significa que cada panel interno, cada ficha del CRM y cada correo que el usuario visualiza puede transmitirse al fabricante de la extensión. Esta vía se salta por completo su DLP, porque lee el DOM ya renderizado.
• Permisos OAuth y agentes. "Conecte su Google Drive" y "deje que el agente lea su bandeja de entrada" son autorizaciones permanentes, no transferencias puntuales. Un agente de IA con scope de Drive es un canal de exfiltración permanente que sobrevive a la sesión. Los atacantes también lo saben, y cada vez apuntan más a estos permisos, un patrón que analizamos en ciberataques potenciados por IA en 2026.

Prioricen estas vías para su propio entorno. En la mayoría de las empresas, las extensiones y los permisos OAuth son la pareja subestimada: invisibles en registros de red que solo vigilan dominios de chatbots, y persistentes mucho después de que el empleado deje de usar la herramienta.

Descubrimiento: encuentren lo que ya está funcionando

No se puede gobernar lo que no se ve. Ejecuten el descubrimiento antes de escribir una sola línea de política, o la política regulará un entorno imaginario.

• Registros de DNS y proxy. Extraigan 30 días de tráfico de salida y crúcenlo con los endpoints de IA conocidos. Incluso una consulta simple revela el panorama general:

SELECT domain, COUNT(DISTINCT src_user) AS users, COUNT(*) AS requests
FROM dns_logs
WHERE domain SIMILAR TO
  '%(openai|anthropic|gemini.google|perplexity|midjourney|huggingface)%'
  AND ts > NOW() - INTERVAL '30 days'
GROUP BY domain ORDER BY users DESC;

• Auditoría de OAuth. En Google Workspace o Entra ID, listen las aplicaciones de terceros con permisos concedidos. Ordenen por sensibilidad del scope (mail.read, drive, files.readwrite). Revoquen todo lo que no reconozcan y exijan después aprobación de administrador para cada permiso nuevo.
• Gastos y tarjetas. Busquen cargos recurrentes de proveedores de IA. El SaaS pagado con tarjeta personal es el truco más viejo del shadow IT y funciona igual de bien con la IA. En el ecosistema startup latinoamericano, donde los equipos crecen más rápido que los procesos de compras y las tarjetas corporativas escasean, esta vía suele ser la más nutrida de todas.
• Inventario de extensiones de navegador. La gestión corporativa del navegador (Chrome Browser Cloud Management, la administración de Edge) les da la lista de extensiones instaladas por usuario. Marquen cualquiera que declare read and change all your data on websites you visit.
• Encuesta con amnistía. Anuncien una ventana de dos semanas sin consecuencias: cuéntennos qué usan y para qué, e intentaremos autorizarlo o encontrar un equivalente. Aprenderán más con esto que con cualquier escáner, pero solo si respetan la amnistía.

Un marco de decisión en tres niveles

No evalúen las herramientas una por una desde cero. Clasifiquen cada herramienta descubierta en uno de tres niveles, con criterios publicados para que la decisión sea predecible.

• Nivel 1, Autorizadas. Contrato enterprise firmado. Entrenamiento con sus datos excluido por contrato. SSO obligatorio, registros de auditoría disponibles, residencia de datos aceptable (si están sujetos al RGPD, eso suele significar alojamiento en la UE). Estas herramientas se promocionan internamente, se pagan de forma centralizada y se entregan precargadas con sus bibliotecas de prompts.
• Nivel 2, Toleradas con salvaguardas. Herramientas útiles sin condiciones enterprise. Permitidas solo a través del gateway (más abajo), solo con la redacción de datos activa y solo para información clasificada como pública o interna. Nunca para datos de clientes, información personal ni código fuente de sistemas propietarios.
• Nivel 3, Bloqueadas. Sin términos aceptables, con permisos excesivos o con un proveedor opaco. Bloqueadas en DNS y en el navegador, con una página de bloqueo que enlace al equivalente de Nivel 1. Un bloqueo sin alternativa es una invitación a ser esquivado.

El dilema es real: una postura estricta de solo Nivel 1 es más limpia de auditar, pero deja a los equipos sin herramientas de nicho, y eso hace crecer de nuevo la sombra. Un Nivel 2 generoso mantiene a la gente dentro del perímetro, pero multiplica su superficie de monitorización. Elijan según la sensibilidad de sus datos, no según su ambición.

Pongan un gateway entre su equipo y el modelo

El control de mayor apalancamiento es un gateway de IA: un proxy situado entre sus usuarios y todos los proveedores de modelos. Todo el tráfico de IA autorizado pasa por ahí. Esto convierte un problema inobservable en un problema de ingeniería.

Una configuración mínima con el proxy de LiteLLM ilustra el patrón:

model_list:
  - model_name: chat-default
    litellm_params:
      model: azure/gpt-4.1
      api_base: https://your-tenant.openai.azure.com
  - model_name: chat-sensitive
    litellm_params:
      model: anthropic/claude-sonnet-4-5

litellm_settings:
  callbacks: ["presidio"]        # detección y enmascaramiento de PII antes de la llamada
  max_budget: 2000               # tope mensual en USD para toda la organización
  budget_duration: "30d"

general_settings:
  master_key: os.environ/GATEWAY_MASTER_KEY
  database_url: os.environ/DATABASE_URL   # registro de uso por clave

Lo que el gateway les compra:

• Registro centralizado. Cada prompt y cada respuesta quedan registrados bajo una clave por usuario o por equipo. Cuando ocurre un incidente, tienen forense en lugar de conjeturas. Alimenten esos registros con el mismo flujo de triaje que el resto de su playbook de respuesta a incidentes.
• Redacción antes de la salida. El enmascaramiento de PII (Presidio, expresiones regulares propias o un pequeño modelo clasificador) se ejecuta antes de que el prompt abandone su perímetro. No es perfecto, pero convierte "se fuga todo" en "se fugan algunos casos límite".
• Portabilidad de proveedor y control de costos. Un endpoint, muchos modelos. Pueden enrutar por nivel de sensibilidad, imponer presupuestos por equipo y cambiar de proveedor sin tocar el código cliente. Esa misma capa de enrutamiento es donde la mayoría de los equipos aplica después las técnicas de nuestra guía de optimización de costos de LLM.
• Botón de apagado. Un cambio de configuración desactiva una clave comprometida o una herramienta que se porta mal, al instante y en todas partes.

El modo de fallo que hay que evitar: un gateway que añade 800 ms de latencia o rompe el streaming. Si la vía autorizada se siente peor que pegar el texto en un chatbot gratuito, la gente pegará el texto en el chatbot gratuito. Presupuesten tiempo real de ingeniería para latencia, passthrough de streaming e integración con los IDE. El gateway tiene que ganar por experiencia de uso, no solo por política.

Escriban una política que la gente lea de verdad

La mayoría de las políticas de IA son ocho páginas de prosa jurídica que nadie vuelve a abrir después del onboarding. La suya debe caber en una página. Esta es la estructura que desplegamos:

1. Empiecen por lo que sí está permitido. Abran con las herramientas autorizadas y para qué están aprobadas. Una política que abre con prohibiciones entrena a la gente a dejar de leer.
2. Definan las clases de datos en lenguaje llano. Con tres clases basta: pública, interna, restringida. Den cinco ejemplos concretos de cada una. "Restringida" debe nombrar explícitamente los datos personales de clientes, las credenciales, las cifras financieras no publicadas y el código fuente propietario.
3. Crucen clases con niveles. Una sola tabla: qué clase de datos puede entrar en qué nivel de herramienta. Esa tabla es toda la política operativa. Lo demás es comentario.
4. Prohíban las cuentas personales para datos de trabajo, de forma explícita. La frontera de la cuenta importa más que la frontera de la herramienta. Misma herramienta, inicio de sesión personal, realidad jurídica distinta. Bajo el RGPD, además, la diferencia entre encargado de tratamiento con contrato y tercero sin contrato pasa exactamente por ahí.
5. Fijen la regla de revisión del output de IA. Quién debe revisar el código, los contratos o los entregables de cliente generados con IA antes de que salgan, y quién responde por el resultado. La responsabilidad se queda con el humano. Siempre.
6. Publiquen la vía de excepción. Un responsable con nombre, un formulario de solicitud, un SLA de 5 días hábiles. Si aprobar una herramienta toma un trimestre, la sombra vuelve en una semana.
7. Enuncien la regla de incidentes sin amenazas. "Si pegó algo que no debía, repórtelo en un plazo de 24 horas. Reportar rápido nunca se sanciona. Ocultarlo, sí." Ustedes quieren el reporte, no la confesión bajo auditoría.

Revisen la política cada trimestre. El panorama de herramientas de IA rota tan rápido que un ciclo anual de revisión garantiza que la política gobierne las herramientas del año pasado.

Salvaguardas que aguantan bajo presión

Una política sin aplicación es una sugerencia. Apilen estos controles, empezando por el más barato:

• SSO en todas partes. Cada herramienta de Nivel 1 detrás de su IdP. Solo con esto obtienen aprovisionamiento, baja de accesos y traza de auditoría, y es el control por el que los auditores preguntan primero. Encaja con el modelo centrado en identidad que explicamos en arquitectura zero trust.
• Política de navegador gestionado. Bloqueen centralizadamente los dominios de Nivel 3 y las extensiones de IA sin evaluar. En la política enterprise de Chrome, una lista blanca explícita de extensiones vence a una lista negra que nunca lograrán mantener al día:

{
  "ExtensionInstallBlocklist": ["*"],
  "ExtensionInstallAllowlist": ["approved_extension_id_1"]
}

• DLP en la frontera del pegado. Un DLP de endpoint que inspeccione el portapapeles y las subidas hacia dominios de IA atrapa el pegado clásico. Esperen falsos positivos al principio. Ajusten durante dos semanas antes de activar el modo de bloqueo, o quemarán su capital político en tres días.
• Lista blanca de aplicaciones OAuth. Exijan consentimiento de administrador para cualquier aplicación de terceros que solicite scopes sensibles. Esto cierra el canal de autorizaciones permanentes que el DLP nunca ve.

Ninguno de estos controles es hermético por sí solo. Un insider motivado los derrota todos. La pila está diseñada para la mayoría honesta que fuga datos por comodidad, no por malicia. Ahí vive casi todo el riesgo real.

El ángulo de la auditoría

Si están en camino hacia SOC 2, ISO 27001 o, en el caso español, el Esquema Nacional de Seguridad, el shadow AI ya es una línea de preguntas estándar: cómo inventarían las herramientas de IA, por dónde fluyen los datos regulados y si pueden demostrar los controles. Un gateway con registros por clave, una lista blanca de OAuth y una política de una página con fechas de revisión es exactamente el paquete de evidencias que los auditores quieren ver. Es también el mismo material que les pedirá la AEPD, o el regulador de datos de su país, si algún día un incidente escala. Los equipos que montaron esta pila antes de la auditoría describen la parte de IA como un trámite; los que no, la describen de otra manera. Si la certificación está en su hoja de ruta, integren la gobernanza de IA en el mismo conjunto de controles desde el primer día, como planteamos en nuestra guía de SOC 2 para startups.

Cómo puede ayudar Innovation T

Innovation T construye y opera esta pila para empresas de España, Latinoamérica y otros mercados: barridos de descubrimiento, despliegue de gateways de IA con redacción de datos y presupuestos por equipo, endurecimiento de navegador y OAuth, y políticas escritas para ser leídas. Somos ingenieros antes que nada, así que la vía autorizada que entregamos es la que su equipo termina prefiriendo.

Conozcan nuestros servicios de ciberseguridad y cloud o hablen con nosotros sobre una evaluación de shadow AI. Las herramientas ya están dentro. La única pregunta es si van a gobernarlas o a descubrirlas en un informe de incidente.