La mayoría de las empresas ya no están valorando si usar IA generativa. Ya la están usando.
A veces de forma formal, con copilots corporativos, entornos controlados o servicios integrados en suites empresariales. Y a veces de forma desordenada, con cuentas personales, prompts pegados directamente desde documentos internos, asistentes conectados a repositorios, extensiones de navegador, herramientas de código o automatizaciones creadas por empleados sin supervisión real.
Ese desfase entre adopción y control es hoy uno de los problemas más serios de seguridad empresarial.
Microsoft define este fenómeno como shadow AI: uso de herramientas de IA sin supervisión adecuada, con riesgo de fuga de datos, incumplimiento y uso indebido de información sensible. Además, su blueprint de protección frente a shadow AI se basa en una secuencia muy reveladora: descubrir aplicaciones de IA, bloquear acceso a apps no autorizadas, bloquear datos sensibles hacia apps autorizadas y gobernar la información enviada a herramientas de IA. Eso, por sí solo, ya deja claro que el problema no se resuelve con una simple política interna. Se resuelve con visibilidad, restricciones y gobierno técnico.
El contexto externo tampoco invita a la complacencia. El NCSC británico ha evaluado que la IA seguirá aumentando la eficacia y eficiencia de ciertos elementos de las intrusiones y que, de aquí a 2027, es probable que eleve la frecuencia y el impacto de determinadas amenazas. No se trata solo de que los atacantes tengan mejores herramientas. Se trata también de que las empresas están ampliando su superficie de exposición más deprisa de lo que la están gobernando.
La tesis de este artículo es simple: el principal riesgo de la IA en la empresa no está solo en usar un modelo, sino en conectar LLMs, copilots y agentes a personas, datos, código y procesos sin límites claros, sin trazabilidad y sin controles compensatorios.
El problema no es usar IA: es usarla sin arquitectura, sin límites y sin evidencias
No todos los usos de IA generativa tienen el mismo riesgo. En la práctica, conviene separar tres escenarios.
1. Uso asistencial de bajo impacto
Resumen de textos no sensibles, reformulación de contenido, traducciones, ideación o redacción de borradores sobre información pública o de bajo riesgo.
2. Uso conectado a datos o herramientas internas
Copilots o asistentes que leen correo, documentos, tickets, SharePoint, CRM, bases de conocimiento, repositorios o entornos de colaboración.
3. Uso con capacidad de acción
Agentes o herramientas que no solo sugieren, sino que pueden ejecutar tareas, modificar código, interactuar con sistemas, lanzar flujos o encadenar acciones sobre el entorno corporativo.
A medida que una organización avanza del primer escenario al tercero, el riesgo cambia de naturaleza. Ya no es solo un riesgo de calidad del resultado. Es un riesgo de seguridad, de datos, de terceros, de operación y de cumplimiento.
OWASP recoge en su Top 10 para aplicaciones con LLM de 2025 riesgos centrales como prompt injection, divulgación de información sensible, debilidades en la cadena de suministro y exceso de agencia. NIST, por su parte, publicó el perfil de GenAI de su AI RMF como guía específica para gestionar de forma estructurada los riesgos de IA generativa en las organizaciones.
La lectura correcta no es “la IA tiene riesgos”. La lectura correcta es otra: si la IA ya participa en flujos empresariales, entonces la gestión de riesgos debe subir de nivel y entrar en arquitectura, gobierno, seguridad y auditoría.
Qué cambia de verdad cuando una empresa empieza a usar LLMs, copilots y agentes
Lo más importante no es el modelo en sí. Lo importante es la combinación de varios factores técnicos y organizativos que antes no estaban tan expuestos a la vez.
1. Los datos salen más veces y por más sitios
Cuando un empleado copia un correo, un contrato, una incidencia, un extracto de código o una hoja de cálculo a una herramienta de IA, la cuestión ya no es solo qué respuesta recibe. La cuestión es qué dato ha salido, a qué proveedor, con qué retención, con qué garantías y bajo qué control.
Microsoft advierte precisamente de ese riesgo en shadow AI: herramientas no aprobadas o no gobernadas pueden implicar fuga de información sensible y problemas de cumplimiento. Netskope, en su informe sobre shadow AI y agentic AI, añade que el uso de aplicaciones SaaS de IA por parte de usuarios empresariales siguió creciendo con fuerza y que también aumentó la cantidad de datos cargados a estas plataformas.
En una empresa real, esto suele verse así:
- prompts con datos de clientes
- documentos internos subidos para resumir o reescribir
- consultas con cifras comerciales o financieras
- tickets copiados desde herramientas ITSM
- extractos de contratos o evidencias de cumplimiento
- fragmentos de código propietario o configuraciones internas
El problema no es hipotético. El problema es que muchas organizaciones todavía no ven ese tráfico con suficiente detalle.
2. El contenido no confiable puede convertirse en instrucción
La indirect prompt injection es uno de los riesgos más importantes y, a la vez, uno de los peor entendidos.
Microsoft explica que este tipo de ataque se produce cuando un sistema de IA procesa contenido de terceros, como emails, documentos, webs o plugins, y el modelo interpreta instrucciones maliciosas incrustadas en esos datos como si fueran órdenes legítimas. El impacto puede incluir acciones no autorizadas, exposición de datos o pérdida de integridad del sistema. En paralelo, Microsoft también ha documentado su estrategia de defensa en profundidad frente a esta técnica.
Esto cambia por completo la forma de pensar en ciertos asistentes empresariales. Porque si un copiloto puede leer contenido externo y además tiene acceso a correo, documentos o acciones sobre herramientas, ya no estás solo ante un “chat más listo”. Estás ante un componente que mezcla datos no fiables con capacidad de decisión.
Ahí es donde muchas empresas fallan: siguen pensando en términos de interfaz conversacional, cuando en realidad deberían pensar en términos de frontera entre instrucciones y datos.
3. El desarrollo acelera, pero la seguridad no siempre acompaña
En el ámbito de desarrollo, la situación es todavía más delicada. Los LLMs ya no se usan solo para autocompletar. Se usan para generar funciones, tests, integraciones, consultas, configuraciones, scripts y cambios completos en varios archivos. Ahí aparece el llamado vibe coding: producir software a gran velocidad con ayuda intensiva de IA, validando por sensación de avance más que por diseño seguro.
El problema no es que el código generado falle siempre. El problema es que puede parecer correcto y seguir siendo inseguro.
Veracode analizó más de 100 modelos en Java, JavaScript, Python y C# y concluyó que el 45% del código generado falló las pruebas de seguridad que evaluaban su capacidad para evitar vulnerabilidades. En Java, la tasa de fallo subió al 72%. El informe también señala que los modelos fallaron especialmente en categorías como XSS y log injection.
Eso obliga a abandonar una idea peligrosa: que el código producido por IA es más o menos igual al de un desarrollador con experiencia. No lo es. En seguridad, el patrón real es otro: produce rápido, parece útil, pero introduce deuda de seguridad a una velocidad que muchos equipos todavía no saben absorber.
En entornos donde ya se trabaja con desarrollo interno, automatización o prototipado, este punto conecta directamente con una revisión técnica seria del código, de la arquitectura y de la superficie expuesta. Ahí encajan especialmente bien servicios como una auditoría de seguridad informática o un trabajo más continuo de gestión de vulnerabilidades.
4. Los secretos y credenciales se filtran más rápido
Si hay un indicador que resume muy bien el desorden que puede generar la combinación de IA y desarrollo, es el de los secretos expuestos.
GitGuardian reportó 28.649.024 nuevos secretos detectados en commits públicos de GitHub en 2025, un crecimiento interanual del 34%. Su informe también destaca una subida del 81% en fugas relacionadas con servicios de IA y concluye que los commits asistidos por IA filtran secretos aproximadamente al doble de la línea base observada en GitHub público.
Esto no es un detalle secundario. Significa que, cuando una organización introduce copilots, agentes o asistentes de desarrollo sin disciplina suficiente, el riesgo no se limita a código mejor o peor. Incluye también:
- tokens API
- credenciales de servicio
- secretos hardcodeados
- configuraciones de entornos
- claves temporales convertidas en permanentes
- conectores a terceros mal protegidos
En otras palabras: la IA puede acelerar también la propagación de errores de seguridad básicos, y hacerlo en ramas, repos o automatizaciones que después acaban en producción o en exposición pública.
5. Los agentes añaden una capa nueva: la capacidad de actuar
Una cosa es pedirle a un modelo un resumen. Otra cosa muy distinta es darle capacidad para buscar, leer, decidir y ejecutar.
OWASP trata este riesgo como excessive agency: más capacidad de acción de la necesaria, con impacto potencial sobre sistemas, datos o flujos. Netskope, además, subraya que el crecimiento de agentic AI y soluciones locales u on-premises añade nuevas complejidades de seguridad, especialmente cuando se conectan herramientas, datos y acciones en una misma cadena.
En empresa, esto puede tomar muchas formas:
- agentes que consultan correo y documentos
- asistentes que crean borradores o tickets automáticamente
- automatizaciones que tocan repositorios o CI/CD
- copilots con acceso transversal a información mal segmentada
- herramientas conectadas a M365, CRM, ERP o knowledge bases
El salto cualitativo es enorme. Porque cuando un agente puede actuar, el problema ya no es solo la exactitud de una respuesta. El problema es qué puede hacer con los permisos que le has dado.
Los riesgos más serios hoy en una empresa que usa IA generativa
Si hubiera que priorizar los riesgos reales, hoy pondría estos en la parte alta de la lista.
Shadow AI sin inventario ni gobierno
Es probablemente el problema más extendido. No por sofisticado, sino por cotidiano.
La mayoría de los incidentes ligados a IA en empresa no empiezan con un actor avanzado explotando una cadena compleja. Empiezan con empleados usando herramientas no aprobadas, con datos reales, desde entornos sin supervisión.
Eso obliga a tener un inventario real de:
- qué herramientas se usan
- quién las usa
- con qué cuentas
- con qué datos
- con qué conectores
- con qué políticas de retención
- con qué base jurídica y contractual
Si no existe esa visibilidad, la organización ya está por detrás del problema.
Fuga de información sensible
Este riesgo no solo afecta a privacidad. Afecta también a propiedad intelectual, información comercial, documentación de clientes, evidencias de auditoría, análisis de incidentes, diseños, código y estrategia.
En organizaciones que trabajan con M365, entornos cloud o documentación sensible, esta parte conecta de forma natural con trabajos de seguridad en Microsoft 365 y con una visión de cumplimiento y GRC donde el foco no sea solo normativo, sino también operativo.
Prompt injection e interacción con contenido externo no fiable
Es uno de los riesgos con mayor proyección, porque afecta justo al tipo de asistentes que más crecimiento están teniendo: copilots conectados a correo, documentos, webs, búsquedas y plugins.
La defensa útil aquí no es poner un prompt mejor. La defensa útil es multicapa:
- segmentar permisos
- separar instrucciones y datos
- reducir agencia
- exigir aprobación humana en acciones críticas
- filtrar salidas
- monitorizar comportamiento anómalo
- tratar contenido externo como no confiable por defecto
Microsoft insiste precisamente en ese enfoque de defensa en profundidad.
Código inseguro generado o aceptado demasiado deprisa
Aquí el error típico es psicológico: el desarrollador ve algo funcional, el revisor confía en exceso, el plazo aprieta y el cambio entra.
Pero la evidencia disponible hoy no justifica esa confianza ciega. La conclusión correcta del informe de Veracode no es “la IA programa mal”. Es más matizada y más peligrosa: la IA puede generar código suficientemente convincente como para que entre en el flujo normal de desarrollo pese a no ser seguro.
Secretos, credenciales y conectores mal gobernados
Si la empresa no tiene disciplina sobre secretos antes de adoptar IA, con IA lo normal es empeorar. Más herramientas implican más claves, más conectores, más tokens y más riesgo de exposición.
Eso convierte la gestión de secretos en un componente central de cualquier programa serio de seguridad aplicado a IA.
Qué controles debería tener ya una empresa razonable
No hace falta paralizar el uso de IA. Pero sí hace falta gobernarlo con un mínimo de seriedad técnica.
1. Inventario real de herramientas y usos
No basta con saber qué herramientas están aprobadas. Hay que descubrir las que ya se están usando de verdad.
2. Política de uso de IA por niveles de dato
Debe quedar claro qué datos pueden usarse, cuáles no y en qué plataformas.
3. DLP y controles de salida
La concienciación ayuda, pero no sustituye a controles técnicos sobre prompts, uploads y conectores.
4. Revisión obligatoria del código generado por IA
Con SAST, SCA, secret scanning y revisión humana real.
5. Mínimo privilegio para copilots y agentes
Si una herramienta puede actuar, debe hacerlo con el menor alcance posible y con posibilidad de aprobación humana.
6. Trazabilidad
Hay que poder reconstruir qué herramienta se usó, por quién, sobre qué datos y con qué efecto.
7. Supervisión continua
En entornos con exposición, datos sensibles o alta dependencia operativa, tiene mucho sentido que la organización complemente esto con capacidades de detección y seguimiento continuo, por ejemplo a través de un SOC gestionado.
Qué debería revisar dirección en los próximos 30 días
Una empresa que ya usa LLMs, copilots o asistentes de código debería poder responder ya a estas preguntas:
Gobierno
- ¿Qué herramientas de IA se usan realmente?
- ¿Cuáles están aprobadas y cuáles no?
Datos
- ¿Qué tipo de información está saliendo hacia herramientas de IA?
- ¿Existen restricciones técnicas o solo normas internas?
Desarrollo
- ¿Qué controles aplican al código generado por IA?
- ¿Se están escaneando secretos y dependencias en todos los repos activos?
Operación
- ¿Hay agentes con capacidad de ejecución?
- ¿Qué aprobaciones humanas existen antes de acciones sensibles?
Cumplimiento
- ¿Tenemos trazabilidad suficiente para investigar un incidente o defender una auditoría?
- ¿Sabemos qué implicaciones tiene esto a nivel contractual, regulatorio y de gobierno del dato?
Lo que no conviene hacer
Hay cuatro errores especialmente frecuentes.
Error 1. Tratar esto solo como productividad
No lo es. Es productividad, sí, pero también seguridad, datos, terceros, desarrollo, arquitectura y gobierno.
Error 2. Creer que una versión enterprise resuelve el problema
Reduce riesgos, pero no arregla permisos excesivos, mala segmentación, contenido no confiable, código inseguro o secretos expuestos.
Error 3. Limitarse a una política y una sesión de formación
Sin inventario, restricciones, telemetría y controles compensatorios, eso se queda corto.
Error 4. Pensar que el riesgo está solo en el chat
Hoy una parte importante del riesgo está en navegador, SaaS, M365, copilots, repositorios, conectores, IDE y estaciones de trabajo de desarrollo.
Las empresas no tienen que elegir entre usar IA y ser seguras. Pero sí tienen que asumir una realidad: cuando los empleados usan LLMs, copilots, asistentes de código y agentes, la superficie de ataque de la organización cambia aunque no haya existido un gran proyecto formal de IA.
El riesgo real no está solo en el modelo. Está en la combinación de:
- datos sensibles saliendo sin control
- contenido no confiable tratado como instrucción
- código generado a gran velocidad sin revisión suficiente
- secretos multiplicándose en repos y herramientas
- agentes con demasiado alcance
- ausencia de trazabilidad y gobierno
La postura madura no consiste en prohibirlo todo. Consiste en introducir límites, arquitectura, visibilidad y controles antes de que la velocidad de adopción convierta un problema gestionable en una deuda de seguridad mucho más cara.
Si una organización ya está usando LLMs, copilots o asistentes de desarrollo, el primer paso serio no es comprar otra herramienta. El primer paso serio es evaluar qué se está usando, qué datos están saliendo, qué permisos existen, qué riesgos ya están activos y qué controles faltan.
En ese punto, una combinación de auditoría de seguridad informática, gestión de vulnerabilidades, seguridad en Microsoft 365, SOC gestionado y una capa de Cumplimiento & GRC suele ser mucho más útil que seguir improvisando.
Fuentes
- OWASP Top 10 for LLM Applications 2025. (owasp.org)
- NIST AI RMF: Generative AI Profile. (nist.gov)
- Microsoft Purview: Prevent data leak to Shadow AI. (learn.microsoft.com)
- Microsoft: Defend against indirect prompt injection attacks. (learn.microsoft.com)
- Microsoft Security Response Center: defense against indirect prompt injection. (microsoft.com)
- Netskope Cloud and Threat Report: Shadow AI and Agentic AI 2025. (netskope.com)
- GitGuardian State of Secrets Sprawl 2026. (gitguardian.com)
- Veracode 2025 GenAI Code Security Report. (veracode.com)
- NCSC: Impact of AI on cyber threat from now to 2027. (ncsc.gov.uk)
FAQ
1. ¿Cuáles son los principales riesgos de seguridad al usar LLMs en empresas?
Los principales riesgos incluyen shadow AI, fuga de información sensible, prompt injection, exposición de secretos, generación de código inseguro y uso excesivo de agentes con demasiados permisos.
2. ¿Qué es shadow AI y por qué preocupa a las empresas?
Shadow AI es el uso de herramientas de IA sin supervisión adecuada. Preocupa porque puede provocar fugas de datos, incumplimientos y uso de información sensible fuera de los controles corporativos.
3. ¿Es seguro usar copilots o asistentes de IA para programar?
Puede ser útil, pero no debe asumirse que el código generado es seguro. Distintos análisis han mostrado tasas relevantes de fallos de seguridad en código generado por modelos de IA, por lo que sigue siendo necesaria la revisión humana y el análisis técnico.
4. ¿Qué riesgos tiene el vibe coding en una empresa?
El principal riesgo es acelerar el desarrollo sin mantener el mismo nivel de revisión de seguridad, arquitectura y control de secretos, lo que puede aumentar la deuda técnica y la exposición a vulnerabilidades.
5. ¿Cómo puede una empresa reducir el riesgo al usar IA generativa?
Mediante inventario de herramientas, políticas por nivel de dato, DLP, revisión del código generado, mínimo privilegio para agentes, trazabilidad y supervisión continua. Estas medidas están alineadas con enfoques de gobierno y defensa en profundidad recomendados por organismos y fabricantes.
Thilina Manana, COO y director de seguridad en Hard2bit Cybersecurity