La IA no gestionada en el entorno corporativo genera riesgos internos y exige gobernanza

Un problema operando en muchas organizaciones ya no está solo en manos de atacantes externos: son los agentes de IA no gestionados que empleados instalan o utilizan en estaciones de trabajo y servidores, con acceso a credenciales y sistemas internos sin supervisión formal. Según un informe de Bitdefender de 2026, solo el 51,8% de las organizaciones dicen tener visibilidad completa de las herramientas de IA que usan sus plantillas; y, en otro estudio citado por empresas de seguridad, IBM ha señalado que alrededor del 20% de las intrusiones han involucrado "shadow AI" como vector de compromiso. Estas cifras —si bien dependen de cómo se definan y midan esos términos— apuntan a una brecha operativa: mucha IA útil para el trabajo también puede convertirse en un riesgo interno si no hay controles.

Técnicamente, ¿cómo aparecen estos riesgos en la red corporativa? Hay varios patrones recurrentes: asistentes de código y extensiones de navegador que piden o almacenan claves de API, agentes locales que gestionan tareas automatizadas y servidores privados de modelos (MCP) configurados por equipos de desarrollo. Muchos de estos componentes se comunican directamente con servicios en la nube mediante HTTPS y tokens temporales, saltándose proxies empresariales, o funcionan como procesos de usuario que las soluciones tradicionales de red no catalogan como riesgos. El riesgo clave es que una pieza de software con credenciales y sin propietario humano definido actúa, desde el punto de vista de seguridad, como un empleado sin supervisión: puede acceder a bases de datos, llamar a APIs internas y exfiltrar información.

Esto ocurre por razones prácticas: las herramientas de IA prometen productividad y automatización, así que usuarios y equipos oprimiendo plazos adoptan soluciones "rápidas" —extensiones de navegador, integraciones de terceros, o agentes que guardan logins— sin pasar por procesos de compras o seguridad. Además, la tendencia a usar APIs de modelos alojados implica que el flujo de datos críticos puede salir directamente desde el endpoint al proveedor de IA, complicando la detección y el control por parte de equipos de seguridad que dependen principalmente de inspección de red o listas de aplicaciones corporativas.

Las consecuencias reales son varias y no puramente teóricas. A corto plazo, una IA no gestionada puede filtrar secretos (claves API, contraseñas de bases de datos), provocar fugas de propiedad intelectual a proveedores de modelos en la nube, o ejecutar comandos no autorizados que comprometan sistemas internos. A medio y largo plazo, esto agrava cumplimiento normativo y exposiciones contractuales con clientes: los controles de acceso y los contratos de procesamiento de datos pueden verse infringidos si datos sensibles se envían a servicios externos. Además, desde el punto de vista operativo, la presencia de agentes autónomos sin control complica la investigación forense y la respuesta ante incidentes.

Es importante separar lo confirmado de lo estimado. Confirmado: empresas de seguridad y algunas investigaciones (p. ej. informes públicos de proveedores como Bitdefender) documentan la aparición de asistentes y agentes de IA en endpoints y reportan métricas sobre visibilidad limitada. Estimado/Probable: la extensión exacta de exfiltración o el número de brechas directas atribuibles exclusivamente a agentes de IA puede variar entre sectores y metodologías de reporte. Incierto: la proporción precisa de agentes maliciosos contra agentes benignos mal configurados no es algo que pueda generalizarse sin estudios forenses publicados con detalle.

¿Qué medidas concretas deben tomar los equipos de seguridad, especialmente aquellos con recursos limitados? Aquí hay un orden práctico de pasos que se pueden implementar en semanas o meses, con prioridad táctica y técnica.

1) Detectar y inventariar: habilite telemetría en endpoints y registre procesos y conexiones salientes. Si ya dispone de EDR/endpoint telemetry, busque procesos desconocidos que realicen conexiones TLS a proveedores de modelos o que abran sockets inusuales. Si no tiene EDR, comience por inventarios de software mediante MDM o herramientas de gestión de activos y escaneo pasivo de red.

2) Control de credenciales y secretos: prohíba almacenamiento de claves en ficheros locales o en variables de entorno sin cifrado. Implemente un gestor de secretos (vault) y asegúrese de que las integraciones usen roles temporales y rotación automática de tokens. Restrinja el uso de claves de larga duración y aplique políticas de acceso mínimo.

3) Filtrado de salida y visibilidad TLS: considere inspección TLS donde sea legalmente y técnicamente viable, o despliegue proxies que obliguen el tráfico de APIs de IA por gateways corporativos. Para entornos en que la inspección no es posible, registre metadatos de conexión (SNI, IPs destino, volúmenes de tráfico) para identificar patrones inusuales.

4) Gobernanza de adopción: en lugar de bloquear toda IA (medida que suele fallar por adopción de shadow IT), defina una lista de herramientas aprobadas, ofrezca alternativas seguras (por ejemplo, integraciones corporativas con llaves gestionadas) y cree procesos de aprobación ágil para que los equipos incorporen nuevas herramientas sin saltarse controles.

5) Políticas de datos y DLP: aplique prevención de pérdida de datos en endpoints y en el correo, con reglas específicas para detectar data exfiltrada hacia plataformas de IA (búsqueda de formatos, patrones de datos sensibles). Combine esto con clasificación de datos y políticas que limiten qué información puede procesarse fuera del perímetro corporativo.

6) Identidad y acceso condicional: proteja recursos críticos con autenticación multifactor, gestión de identidades privilegiadas y políticas de acceso condicional que evalúen el contexto del dispositivo y la app. Revoque tokens si encuentra uso anómalo y automatice rotaciones ante detección.

7) Respuesta y monitoreo continuo: integre alertas en SIEM/SOAR para comportamientos de agentes de IA: picos de llamadas a APIs externas, accesos nocturnos a bases de datos desde endpoints de desarrollo, o ejecuciones de procesos no autorizados. Establezca playbooks para revocar credenciales, aislar máquinas y recolectar artefactos forenses.

Para equipos reducidos, priorice: visibilidad (inventario), protección de secretos (vault y rotación), y controles de acceso (MFA/roles temporales). Estos son palancas de alto impacto con inversión moderada. A medio plazo, acompañe con capacitación a usuarios y un proceso de gobernanza que facilite uso seguro en vez de prescribir prohibiciones absolutas.

Si quiere fuentes y marcos de referencia para diseñar controles, consulte guías públicas como el NIST AI Risk Management Framework para principios y prácticas de gobernanza (https://www.nist.gov/itl/ai), y los recursos de respuesta a brechas y protección de datos de proveedores líderes (https://www.bitdefender.com/, https://www.ibm.com/security/data-breach).

En resumen: la amenaza no es solo que atacantes usen IA, sino que la IA útil para la organización pueda estar actuando con el mismo poder que un empleado sin supervisión. La solución más efectiva combina detección técnica, gestión de secretos, políticas de acceso y un marco de gobernanza que permita aprovechar la IA sin ceder el control de los datos. Para los responsables de seguridad, la prioridad inmediata es recuperar visibilidad y proteger las credenciales: el resto es gobernanza y cultura operativa.