Seguridad de LLM: los 10 riesgos de OWASP y cómo demostrarlo
Los modelos de lenguaje han entrado en la empresa más rápido de lo que ha entrado la seguridad que necesitan. Y el riesgo número uno tiene nombre propio: el prompt injection, primera posición del OWASP Top 10 para aplicaciones LLM (edición 2025).
Esta guía explica los riesgos reales —empezando por el principal—, por qué algunos no se eliminan del todo por diseño, y por qué, desde el 2 de agosto de 2026, defenderse deja de ser una buena práctica para convertirse en una obligación de conformidad.
Prompt injection: el riesgo número uno (LLM01)
Consiste en manipular la entrada de un modelo para que ignore sus instrucciones originales y ejecute las del atacante: revelar información, realizar una acción no prevista o comportarse de forma que su empresa no autorizó.
Encabeza la lista de OWASP por una razón incómoda: es, probablemente, la más difícil de prevenir por completo.
Directa e indirecta: la segunda es la que debe preocuparle
Inyección directa. El atacante escribe en el propio chat instrucciones que anulan las del sistema: sustitución de instrucciones, reasignación de rol, confusión de delimitadores, ofuscación mediante codificación, o escalada progresiva a lo largo de varios turnos.
Inyección indirecta. Aquí está el riesgo real en un entorno corporativo. Las instrucciones maliciosas no las escribe el usuario: vienen escondidas en el contenido que el modelo procesa — un PDF, una página web rastreada, un correo, un ticket de soporte, una invitación de calendario. El empleado no hace nada sospechoso: simplemente pide un resumen de un documento. Y el documento lleva dentro la orden.
Cuanto más conectado esté su sistema —a documentos, a correo, a bases de datos, a herramientas—, mayor es la superficie.
Por qué no se arregla como una inyección SQL
Esta es la parte que hay que decir claro. La inyección SQL se resuelve con consultas parametrizadas: se separa la instrucción del dato, de forma tajante.
Con un LLM no existe esa separación. El modelo está entrenado para seguir instrucciones en lenguaje natural, y el contenido que procesa también es lenguaje natural. Distinguir una petición legítima de una instrucción maliciosa incrustada es intrínsecamente ambiguo. No es un fallo de implementación que se parchee: es una consecuencia del diseño de la tecnología.
Cualquiera que le prometa un filtro que elimine el prompt injection al 100 % le está vendiendo una estimación disfrazada de garantía.
Los 10 riesgos del OWASP Top 10 para LLM (2025)
El prompt injection es el primero, pero no el único. La lista completa dibuja el mapa del problema:
| Riesgo | En una frase | |
|---|---|---|
| LLM01 | Prompt Injection | Entradas manipuladas hacen que el modelo obedezca al atacante en vez de a usted. |
| LLM02 | Divulgación de información sensible | El modelo expone datos personales, credenciales o información propietaria en sus salidas. |
| LLM03 | Cadena de suministro | Modelos, conjuntos de datos, paquetes y plugins de terceros introducen componentes vulnerables o maliciosos. |
| LLM04 | Envenenamiento de datos y del modelo | Datos manipulados de entrenamiento o de fine-tuning introducen puertas traseras, sesgos o degradación. |
| LLM05 | Tratamiento inadecuado de la salida | La salida del modelo pasa a otros sistemas sin validar, habilitando inyección, SSRF o ejecución remota de código. |
| LLM06 | Agencia excesiva | Se concede al modelo demasiada funcionalidad, permisos o autonomía: si lo manipulan, actúa. |
| LLM07 | Fuga del prompt de sistema | Se filtran las instrucciones internas que gobiernan el modelo. |
| LLM08 | Debilidades de vectores y embeddings | Fallos en cómo se generan, almacenan o recuperan los vectores (RAG) permiten inyección o fuga de datos. |
| LLM09 | Desinformación | El modelo produce salidas falsas que los usuarios sobre-confían. |
| LLM10 | Consumo sin límites | Uso descontrolado de recursos o consultas: denegación de servicio y costes desbocados. |
Tres merecen atención especial por lo que conectan:
- LLM03 (cadena de suministro) es, además, una medida obligatoria del artículo 21 de NIS2 y un pilar entero de DORA. Su proveedor de modelos es, a efectos regulatorios, un proveedor TIC.
- LLM05 (tratamiento de la salida) es el que convierte un fallo del modelo en un fallo de su infraestructura.
- LLM06 (agencia excesiva) es la puerta al riesgo agéntico: cuando el modelo no solo responde, sino que ejecuta. (Lo desarrollamos en el silo de IA agéntica.)
Mitigaciones: defensa en profundidad
OWASP no propone una bala de plata, sino capas:
- Restringir el comportamiento del modelo mediante instrucciones de sistema explícitas sobre su rol y sus límites.
- Definir formatos de salida esperados y validarlos antes de pasarlos a otro sistema.
- Segregar y marcar el contenido no confiable, de modo que los datos externos no puedan influir como si fueran instrucciones.
- Validación de entrada y filtrado de salida.
- Restricción de privilegios: que el modelo tenga el mínimo acceso imprescindible.
- Humano en el bucle para las operaciones sensibles.
Fíjese en el patrón: las capas más sólidas no intentan detectar el ataque, sino limitar lo que el sistema puede hacer aunque el ataque tenga éxito. Esa distinción es la clave de todo lo que sigue.
El ángulo que casi nadie menciona: defenderse ya es una obligación legal
La seguridad de los LLM suele tratarse como un asunto técnico. Pero si su sistema de IA es de alto riesgo conforme al EU AI Act, deja de serlo.
El artículo 15 del Reglamento (UE) 2024/1689 exige que los sistemas de IA de alto riesgo alcancen un nivel adecuado de precisión, solidez y ciberseguridad, y que funcionen de manera uniforme en esos sentidos durante todo su ciclo de vida. Deben ser, además, lo más resistentes posible frente a errores, fallos o incoherencias, incluidos los derivados de su interacción con personas u otros sistemas.
Y el propio Reglamento contempla de forma explícita que los ciberataques contra sistemas de IA pueden dirigirse contra activos específicos de la IA —los datos de entrenamiento (envenenamiento de datos, el LLM04 de OWASP) o los modelos entrenados (ataques adversarios)— o aprovechar las vulnerabilidades de la infraestructura subyacente.
Traducción práctica: desde el 2 de agosto de 2026, la resistencia de su sistema a estos ataques es materia de conformidad, no de buenas intenciones. Y para las entidades bajo NIS2, la gestión de incidentes y la seguridad de los sistemas —incluida la cadena de suministro— ya son obligatorias hoy.
Qué implica según el tamaño de su empresa
- Pyme: empiece por lo más rentable — limitar privilegios. Un asistente que solo lee y no actúa reduce drásticamente el daño posible.
- Mediana empresa: el riesgo se dispara al conectar el modelo a documentos y correo. Segregue el contenido no confiable y valide las salidas antes de que toquen otro sistema (LLM05).
- Gran empresa: si despliega agentes con acceso a herramientas, asuma que la inyección indirecta llegará. Su defensa no puede depender de detectarla: debe apoyarse en límites verificables. Y si el sistema es de alto riesgo, debe poder demostrarlo ante el supervisor.
El reto de fondo: demostrar el límite, no estimar el filtro
Aquí converge todo. Los filtros, los clasificadores de intención y el red teaming son necesarios, pero comparten una limitación estructural: producen una estimación —«no hemos conseguido romperlo»— y nunca una garantía. Y el artículo 15 no pide intentos: pide solidez demostrable.
Deflank aborda el problema por el otro extremo: en lugar de intentar adivinar cada ataque posible, trabaja sobre lo que el sistema tiene permitido hacer. Mediante una metodología de verificación propia, convierte los límites y requisitos aplicables en una prueba demostrable, reproducible y auditable — de modo que, aunque una inyección tenga éxito en engañar al modelo, la acción prohibida no puede ejecutarse. Y eso se puede acreditar ante un supervisor.
La prueba, no la estimación.
¿Su asistente o agente de IA puede hacer algo que usted no autorizó? Solicite un diagnóstico de seguridad de sus sistemas de IA.
En este silo: [OWASP Top 10 para LLM] · [jailbreaks] · [DLP para IA]. Puentes: [IA agéntica] · [precisión, robustez y ciberseguridad en el AI Act] · [NIS2: cadena de suministro].
Contenido informativo. Fuentes: OWASP Top 10 for LLM Applications (2025); Reglamento (UE) 2024/1689, artículo 15 y considerandos sobre ciberseguridad de los sistemas de IA; Directiva (UE) 2022/2555, artículo 21.
Preguntas frecuentes
¿Qué es el prompt injection?
Una técnica que manipula la entrada de un modelo de lenguaje para que ignore sus instrucciones originales y ejecute las del atacante. Es **LLM01**, el primer riesgo del OWASP Top 10 para aplicaciones LLM de 2025.
¿Cuál es la diferencia entre inyección directa e indirecta?
En la **directa**, el atacante escribe las instrucciones maliciosas en el propio prompt. En la **indirecta**, van escondidas en el contenido que el modelo procesa (un PDF, una web, un correo), de modo que el usuario legítimo las activa sin saberlo.
¿Se puede eliminar por completo?
No de forma fiable. A diferencia de la inyección SQL, no hay separación estricta entre instrucción y dato: el modelo procesa ambos como lenguaje natural. OWASP la considera la vulnerabilidad más difícil de prevenir del todo.
¿Cuáles son los 10 riesgos del OWASP Top 10 para LLM?
Prompt injection, divulgación de información sensible, cadena de suministro, envenenamiento de datos y del modelo, tratamiento inadecuado de la salida, agencia excesiva, fuga del prompt de sistema, debilidades de vectores y embeddings, desinformación y consumo sin límites.
¿Cómo se mitiga el prompt injection?
Con defensa en profundidad: instrucciones de sistema que acoten el rol, segregación del contenido no confiable, validación de entrada y salida, **restricción de privilegios** y supervisión humana en operaciones sensibles.
¿El AI Act obliga a protegerse de estos ataques?
De forma indirecta pero clara: el **artículo 15** exige un nivel adecuado de precisión, solidez y ciberseguridad en los sistemas de alto riesgo, y el Reglamento contempla expresamente los ciberataques dirigidos contra los activos de la IA.
¿Y si uso agentes con acceso a herramientas?
El riesgo se multiplica (es el LLM06, «agencia excesiva»): una inyección exitosa deja de ser una fuga de datos y pasa a ser una **acción ejecutada**. La defensa debe basarse en límites verificables sobre lo que el agente puede hacer.