El OWASP Top 10 para aplicaciones LLM 2026: cada riesgo con su aspecto real, el control que lo limita y una prueba que puedes ejecutar antes de publicar.
Contenido9 secciones
- ¿Cuáles son los riesgos del OWASP Top 10 para aplicaciones LLM en 2026?
- ¿Qué cambió en la lista de 2026 y por qué importa?
- ¿Cuáles son los 3 principales riesgos de seguridad de la IA?
- ¿Por qué un filtro de prompts no arregla el prompt injection?
- ¿Qué se le escapa a un pen test en una aplicación LLM?
- ¿Qué buenas prácticas de seguridad de IA cubren la mayor parte de la lista?
- ¿Cómo se prueba una aplicación LLM antes de publicarla?
- ¿Qué exige la Ley de IA de la UE para la seguridad de LLM?
- ¿Por dónde debería empezar un equipo pequeño?
La seguridad de LLM consiste en construir el sistema que rodea a un modelo de lenguaje de forma que, cuando el modelo sea engañado, no se rompa nada importante. No puedes hacer inmune al modelo en sí: lee instrucciones y datos como un único flujo de tokens, y la guía de OWASP 2026 dice sin rodeos que hoy no existe una prevención fiable contra el prompt injection. Así que el trabajo pasa al código que lo rodea. Reduce lo que el modelo puede alcanzar, comprueba fuera del modelo cada acción que pide, limita lo que puede gastar y trata lo que escribe como entrada no confiable. La lista de control que usa la mayoría de los equipos es el OWASP Top 10 para aplicaciones LLM, cuya edición 2026 salió en agosto de 2026. Abajo, cada uno de sus diez riesgos aparece con su aspecto en una aplicación real, el control que lo limita y una prueba que puedes ejecutar antes de publicar.
¿Cuáles son los riesgos del OWASP Top 10 para aplicaciones LLM en 2026?
Esta es la lista 2026 en su orden oficial, leída en genai.owasp.org el 7 de octubre de 2026. Los controles y las pruebas están condensados de las secciones de mitigación del documento de OWASP, recortados a lo que un equipo pequeño puede ejecutar de verdad.
| Riesgo (OWASP 2026) | Cómo se ve | Control que lo limita | Cómo probarlo |
|---|---|---|---|
| LLM01 Prompt Injection | Una página web, un correo, un PDF, una imagen o el resultado de una herramienta que lee el modelo contiene instrucciones, y el modelo las sigue | Credenciales y llamadas que cambian el estado, en el código; mínimo privilegio por herramienta; confirmación humana para acciones irreversibles; eliminar el Unicode invisible al ingerir | Planta instrucciones en cada fuente que lee el modelo y mira si se dispara alguna herramienta; repite con probadores que conocen tus defensas |
| LLM02 Sensitive Information Disclosure | El modelo repite el registro de otro cliente, un documento interno o datos personales de los logs | Autoriza dentro de la consulta de recuperación; envía solo los campos que necesita la tarea; limpia logs y trazas; redacta con clasificadores, no solo con regex | Entra como un inquilino y pide los datos de otro por nombre, ID y paráfrasis; busca datos personales en las trazas |
| LLM03 Excessive Agency | Un agente envía, borra o paga porque el modelo lo decidió | Las mínimas herramientas, las funciones más estrechas; actuar con el alcance de acceso del propio usuario; autorización comprobada por código; aprobación para acciones de alto impacto | Lista cada herramienta con sus permisos, anota la peor llamada que permite cada una e intenta provocarla con contenido inyectado |
| LLM04 Supply Chain | Un modelo, adaptador, paquete o servidor MCP que descargaste está manipulado, o alguien vuelve a registrar el nombre de un modelo borrado | Fija versiones y hashes; verifica firmas; mantén un SBOM o ML-BOM; revisa condiciones y licencias del proveedor | Haz fallar la build ante cualquier cambio de hash; comprueba que ningún modelo ni servidor se resuelve solo por nombre |
| LLM05 Data and Model Poisoning | Los datos de ajuste fino, las señales de feedback o el corpus RAG llevan una puerta trasera o un sesgo | Registra el origen y las versiones de los datos; valida los bucles de feedback antes de reentrenar; conjuntos de ajuste fino curados | Busca frases disparadoras tras cada ajuste fino; compara con un conjunto de evaluación congelado |
| LLM06 Unbounded Consumption | Un bucle, una entrada enorme o un usuario automatizado dispara la factura o bloquea el servicio | Límites de frecuencia por tokens; topes de gasto estrictos que detienen la inferencia; límites de pasos, recursión y tiempo en los agentes | Envía entradas de tamaño máximo y una tarea que entra en bucle; confirma que el tope detiene el trabajo en lugar de enviar una alerta |
| LLM07 Misinformation | Una respuesta fluida y equivocada se convierte en una acción: un reembolso fuera de la política, la instalación de un paquete que no existe | Respalda las afirmaciones con fuentes; compruébalas en código antes de actuar; salida estructurada con campos obligatorios | Siembra el corpus con contenido falso verosímil y cuenta cuántas veces acaba en una acción |
| LLM08 Hidden Context Exposure | Se extraen el prompt de sistema, los esquemas de herramientas o las reglas de los guardrails y se usan para apuntar el siguiente ataque | Nada secreto en los prompts; aplica las reglas fuera del modelo; da por hecho que todo el contexto es legible | Intenta extraer el prompt de sistema y la lista de herramientas; bloquea la versión si alguno contiene un secreto |
| LLM09 Vector and Embedding Weaknesses | La recuperación devuelve fragmentos de otros inquilinos, o un documento plantado aparece en todas las consultas | Alcance del inquilino dentro de la consulta al índice; índices separados por nivel de confianza; borra los embeddings junto con su fuente | Consulta entre inquilinos; inserta un documento redactado para coincidir con consultas comunes y mira si aparece |
| LLM10 Improper Output Handling | La salida se renderiza como HTML, se ejecuta como SQL o shell, o una imagen Markdown envía datos al servidor de un atacante | Trata la salida como entrada no confiable: codificación según el contexto, consultas parametrizadas, una CSP estricta, sin imágenes que se rendericen solas | Haz que el modelo emita etiquetas script, SQL y un enlace de imagen a un host externo; comprueba que nada se ejecuta ni se descarga |
La lista cubre el modelo como un componente dentro de tu aplicación. En cuanto el modelo actúa por su cuenta, con herramientas, memoria entre sesiones y acciones posteriores, OWASP remite a una segunda lista, el Top 10 para aplicaciones agénticas, publicado en diciembre de 2025. La mayoría de los agentes en producción necesitan las dos.
¿Qué cambió en la lista de 2026 y por qué importa?
La edición 2026 es la primera contrastada con datos de incidentes. El proyecto reunió 7.714 incidentes de bases públicas de vulnerabilidades y de una base de daños causados por IA, clasificó los 6.639 que tenían suficiente detalle y dio a ese registro una cuarta parte del peso; la votación de profesionales aporta las otras tres cuartas partes.
El orden se movió más que en años anteriores:
- Excessive Agency subió al tercer puesto. OWASP lo llama el cambio de más consecuencias: los agentes son donde está cayendo el daño.
- Unbounded Consumption subió cuatro puestos, al sexto. Los profesionales ahora dan más peso al coste y al agotamiento de recursos que el antiguo puesto.
- Improper Output Handling bajó del quinto al décimo, y ahora también cubre el código inseguro que los asistentes generan a escala.
- System Prompt Leakage pasó a ser Hidden Context Exposure, que cubre los esquemas de herramientas, las instrucciones del desarrollador y el texto de las políticas además del prompt de sistema.
- Misinformation es la séptima, pero los responsables del proyecto OWASP la destacan: los votantes la pusieron cerca del final y el registro de incidentes cerca del principio.
Un detalle conviene saberlo antes de planificar el presupuesto. Ordenado solo por el registro bruto de incidentes, el prompt injection sale de los diez primeros. OWASP lo interpreta como un efecto de la defensa: los equipos combaten mucho la inyección, así que llegan menos exploits limpios a las bases públicas. Sigue en primer lugar porque la superficie existe en cualquier sitio donde un modelo lee entradas no confiables.
¿Cuáles son los 3 principales riesgos de seguridad de la IA?
Según la lista de 2026: prompt injection, divulgación de información sensible y agencia excesiva. Se entienden mejor como una sola cadena.
Una inyección entra por el contenido que lee el modelo: un ticket de soporte, una página web, una invitación de calendario, el título de una incidencia. Lo que pueda hacer después depende de qué datos ve el modelo (riesgo dos) y de qué puede provocar el modelo (riesgo tres). La entrada de prompt injection de OWASP dice que la mayoría de los incidentes de alto impacto registrados se volvieron graves porque la inyección cayó en un sistema cuyas herramientas o alcances dejaban al modelo actuar con los privilegios del usuario.
Eso da una prueba que puedes hacer en una pizarra. Simon Willison la llama la tríada letal (lethal trifecta) y Meta llama a su versión la regla de dos (Rule of Two), y el documento de OWASP cita ambas: un agente que puede leer contenido no confiable, alcanzar datos privados y comunicarse con el exterior (o cambiar el estado) tiene todo lo que un atacante necesita. Quita una pata y el peor desenlace se reduce. OWASP dice que cualquier agente con las tres necesita aprobación humana para cada acción.
¿Por qué un filtro de prompts no arregla el prompt injection?
Porque el atacante se adapta y el filtro no. La entrada de OWASP 2026 cita a Nasr et al. (2025): en 12 defensas recientes, ataques que casi nunca funcionaban en pruebas estáticas lograron más del 90% de éxito contra la mayoría en cuanto el atacante pudo adaptarse a la defensa. Los esquemas de separación estructural como StruQ se saltaron de la misma manera.
Los guardrails gestionados muestran el mismo patrón en la frontera de entrada. ML6 probó cuatro con 80.000 prompts en neerlandés, con un reparto 63/37 entre benignos y dañinos, usando ajustes por defecto o casi por defecto (publicado el 22 de junio de 2026):
El idioma importa (ML6 probó en neerlandés a propósito) y unos ajustes afinados darían otras cifras, pero la conclusión vale para cualquier idioma: un guardrail es una capa que reduce la tasa de ataques. Da por hecho que algunas inyecciones pasan y diseña para que un modelo engañado no pueda hacer mucho.
¿Qué se le escapa a un pen test en una aplicación LLM?
Un pen test web estándar sigue importando: la autenticación, la gestión de sesiones, la inyección en tus propias APIs y la infraestructura se aplican igual a una aplicación LLM. Lo que normalmente no ejercita:
- La inyección indirecta: los probadores escriben en la caja del chat. Las instrucciones peligrosas llegan por documentos, páginas recuperadas, correos y resultados de herramientas que el modelo lee por su cuenta.
- Los permisos de las herramientas: un pen test comprueba si un endpoint está autorizado. Rara vez se pregunta si el modelo debería poder llamarlo, o con qué alcance.
- La persistencia en memoria y en RAG: una inyección escrita en la memoria a largo plazo o en un almacén vectorial afecta a cada sesión posterior que lea de ahí. Una sola sesión de prueba no la mostrará.
- El coste: agotar tu presupuesto de inferencia es un ataque de la lista de 2026. Pocos alcances de pen test incluyen una prueba de gasto.
- Los atacantes que se adaptan: un conjunto fijo de prompts mide lo que logran los ataques estáticos, y Nasr et al. mostraron cuánto infravalora eso a un atacante que se adapta.
- Los destinos de la salida: la salida del modelo que llega a un navegador, una terminal, una base de datos u otro agente necesita la misma revisión que la entrada del usuario, y a menudo queda fuera del alcance probado.
Cuando encargues uno, pon estos puntos por su nombre en el documento de alcance y pide las cargas útiles usadas. Si el probador no sabe decirte cómo llegó al modelo a través del contenido recuperado, la vía indirecta no se probó.
¿Qué buenas prácticas de seguridad de IA cubren la mayor parte de la lista?
Seis controles, todos ellos código tuyo, cierran la mayoría de los diez riesgos. Estas buenas prácticas de seguridad de IA salen directamente de las secciones de mitigación de OWASP.
- La autorización vive fuera del modelo. El modelo propone; el código decide. Cada llamada a una herramienta pasa por una comprobación del usuario, la acción y sus argumentos, lo que OWASP llama mediación completa. Limita a la vez la inyección, la agencia excesiva y la exposición del contexto oculto, porque nada en el prompt concede nada. El hábito que pone una clave de servicio en el bundle del cliente también pone claves de API en los prompts de sistema; las dos se quitan de la misma forma.
- Mínimo privilegio para cada herramienta. Una herramienta que resume correos recibe acceso de lectura, no de envío ni de borrado. Un recomendador de productos recibe acceso de lectura a una tabla. Evita herramientas abiertas (shell, descargar cualquier URL) cuando bastaría una estrecha. Si estás construyendo un servidor MCP, el despliegue por etapas de un servidor MCP en 90 días, primero solo lectura y después acciones con una persona en el circuito, aplica esto directamente.
- Comprobaciones de acceso dentro de la recuperación. Filtra por inquilino y por permiso del documento en la consulta al índice, antes de que vuelvan los resultados. Eso cubre tanto la divulgación de información sensible como el caso entre inquilinos de las debilidades de vectores.
- Topes estrictos, aplicados en código. Límites de tokens por usuario y por minuto, techos de gasto que detienen la inferencia, y límites de pasos, recursión y tiempo en los agentes.
- La salida es entrada no confiable. Codifica según el lugar donde acaba, usa consultas parametrizadas, bloquea las imágenes Markdown que se renderizan solas y las vistas previas de enlaces, y elimina los caracteres de control antes de que la salida llegue a una terminal o a un log. El código que el modelo escribe por ti también es salida, y recibe la misma revisión.
- Una persona aprueba lo que no se puede deshacer. Pagos, mensajes externos, borrados. Muestra a quien revisa la acción exacta que se ejecutará, no un resumen. Dónde trazar esa línea, y cuánto cuesta, está en lo que tu IA no puede decidir.
Detrás del punto 1 hay una lección de un flujo con modelo que tenemos en nuestro propio sitio (cartas construidas con los números de nuestras auditorías): una regla en el prompt no aguantó. Un modelo que redactaba a partir de nuestras propias mediciones invirtió un porcentaje, sumó dos mediciones distintas como si fueran una y ordenó dos cifras al revés. Una instrucción en el prompt contra esto no sobrevivió a dos reescrituras del prompt. El código que comprueba cada afirmación contra los datos de origen antes de enviar nada, sí. Es el patrón de OWASP de comprobar la afirmación antes de actuar (claim-check-act) contra la desinformación.
¿Cómo se prueba una aplicación LLM antes de publicarla?
Trátala como una suite de regresión que se ejecuta con cada cambio del prompt, el modelo, las herramientas o las fuentes de recuperación.
- Monta un conjunto de cargas útiles por riesgo, con la tabla de arriba como esquema: instrucciones inyectadas en cada tipo de contenido que ingieres, consultas entre inquilinos, intentos de extraer el prompt de sistema, entradas enormes, salida que se ejecutaría en tu renderizador. Empieza con unos pocos casos por riesgo, siempre que sigan los caminos de tu propia aplicación.
- Usa herramientas abiertas para la cobertura: garak, de NVIDIA, se describe como un escáner de vulnerabilidades de LLM. PyRIT, de Microsoft, es un framework abierto para encontrar riesgos en sistemas de IA generativa. promptfoo ejecuta escaneos de red team y de vulnerabilidades a partir de configuraciones declarativas y se conecta a la CI. La entrada de OWASP 2026 nombra AgentDojo y JailbreakBench como referencias. La Web Security Academy de PortSwigger tiene laboratorios prácticos de ataques a LLM web si tu equipo nunca ha hecho uno.
- Luego prueba de forma adaptativa: da a un red-teamer la descripción completa de tus defensas y déjale iterar. OWASP dice que hay que rechazar las cifras de éxito de ataques que vienen solo de pruebas estáticas.
- Prueba el radio de daño además de la inyección: para cada herramienta, pregúntate qué pasa cuando el modelo la llama con los peores argumentos válidos. Si la respuesta es inaceptable, la solución está en los permisos o en la aprobación, y ningún cambio de prompt la sostendrá.
- Condiciona la publicación: un caso que falla bloquea el despliegue igual que un test unitario que falla. Vuelve a ejecutar tras cada actualización del modelo: una versión nueva del modelo es una dependencia nueva.
Si tu producto también expone páginas o acciones a agentes de IA externos, SaaS preparado para agentes de navegador cubre la superficie de consentimiento y auditoría que esos agentes esperan de ti.
¿Qué exige la Ley de IA de la UE para la seguridad de LLM?
Para los sistemas de IA de alto riesgo, el artículo 15, apartado 5, de la Ley de IA exige resiliencia frente a los intentos de alterar el uso, las salidas o el rendimiento del sistema, con medidas contra el envenenamiento de datos, el envenenamiento de modelos, los ejemplos adversarios, los ataques a la confidencialidad y los fallos del modelo. Eso corresponde a LLM05 (envenenamiento), LLM02 (confidencialidad) y LLM01 (entradas diseñadas para que el modelo se equivoque).
Las fechas se movieron en 2026. El Reglamento (UE) 2026/1744, el Digital Omnibus sobre IA, fija que los requisitos de alto riesgo se apliquen desde el 2 de diciembre de 2027 a los sistemas del anexo III (empleo, educación, crédito y usos similares) y desde el 2 de agosto de 2028 a la IA integrada en productos cubiertos por las leyes de seguridad del anexo I. Incumplir las obligaciones del proveedor puede sancionarse con hasta 15 millones de euros o el 3% del volumen de negocio anual mundial, lo que sea mayor. El tramo del 7% se aplica a las prácticas prohibidas, no a los fallos de seguridad. Ambos textos se leyeron en EUR-Lex el 7 de octubre de 2026.
Un asistente de atención al cliente o una herramienta de búsqueda interna normalmente no son de alto riesgo según el anexo III. Los controles de OWASP siguen valiendo la pena, y si más adelante pasas a un uso de alto riesgo, los informes de pruebas se convierten en tu evidencia.
¿Por dónde debería empezar un equipo pequeño?
Si vas a lanzar tu primera función con LLM, o heredaste una construida deprisa, este orden da la mayor reducción con el menor trabajo:
- Semana 1: inventario. Cada herramienta que el modelo puede llamar y sus permisos, cada fuente de contenido que lee, cada lugar donde acaba su salida. Marca cualquier agente que tenga las tres patas de la tríada.
- Semana 2: lleva la autoridad al código. Quita los secretos de los prompts, pon comprobaciones de autorización delante de las llamadas a herramientas, estrecha los permisos y añade aprobación para las acciones irreversibles.
- Semana 3: topes y manejo de la salida. Límites de tokens y de gasto que detienen el trabajo, límites de pasos de los agentes, codificación de la salida, sin imágenes que se carguen solas.
- Semana 4: la suite de pruebas. Cargas útiles para cada uno de los diez riesgos, conectadas al flujo de publicación, más una sesión de red team adaptativa.
Después, mantenlo en marcha: vuelve a ejecutar la suite con cada cambio de modelo, prompt o herramienta, y revisa la lista de riesgos cuando OWASP la actualice. Si nadie del equipo se hace cargo del sistema tras el lanzamiento, ese es el hueco que cubre Care: alguien toma el sistema hecho en casa, lo estabiliza y lo sigue vigilando.
Preguntas frecuentes
¿Qué es la seguridad de LLM?
La seguridad de LLM cubre los riesgos que aparecen cuando un modelo de lenguaje está dentro de una aplicación: instrucciones coladas en el contenido que lee el modelo, datos que el modelo puede alcanzar y repetir, herramientas que puede llamar y salidas en las que confían otros sistemas. Se suma a la seguridad de aplicaciones de siempre, que sigue vigente. El OWASP Top 10 para aplicaciones LLM 2026 es la lista de control más usada para ello.
¿Cuáles son las buenas prácticas de seguridad de IA para una aplicación LLM?
Mantén las credenciales y la autorización en el código, nunca en el prompt. Da a cada herramienta la función y el permiso más estrechos que necesite, y actúa con el acceso del propio usuario. Comprueba el acceso dentro de la consulta de recuperación. Pon límites estrictos de gasto y de pasos a cada llamada al modelo y a cada ejecución de agente. Trata la salida del modelo como entrada no confiable. Exige que una persona apruebe las acciones irreversibles, y prueba todo contra atacantes que conocen tus defensas antes de cada versión.
¿Cuáles son los 3 principales riesgos de seguridad de la IA?
En el OWASP Top 10 para aplicaciones LLM 2026, los tres primeros son prompt injection, divulgación de información sensible y agencia excesiva. Forman una cadena: una inyección escondida en un documento hace que el modelo se comporte mal, y el daño depende de qué datos ve el modelo y qué herramientas puede llamar. Cortar el segundo y el tercer eslabón suele ser más fiable que intentar frenar el primero.
¿Pueden los guardrails detener el prompt injection?
Lo reducen, pero no lo detienen. La entrada de OWASP 2026 dice que hoy no existe una prevención fiable, porque los modelos no separan las instrucciones de los datos. En la comparativa de ML6 de junio de 2026 con cuatro guardrails gestionados con ajustes por defecto, el de mejor F1 dejó pasar cerca del 16% de los prompts dañinos y el más débil unas dos terceras partes. Usa los guardrails como una capa y limita lo que puede hacer un modelo engañado.
¿El OWASP Top 10 para LLM de 2026 es distinto de la versión de 2025?
Sí. Se publicó en agosto de 2026 y se reordenó con datos de incidentes. Prompt injection y divulgación de información sensible conservaron el primer y el segundo puesto, la agencia excesiva subió al tercero, el consumo sin límites al sexto, el manejo inadecuado de la salida bajó al décimo y la fuga del prompt de sistema se amplió a exposición del contexto oculto, que también cubre los esquemas de herramientas y el texto de las políticas.
¿La Ley de IA de la UE exige pruebas de seguridad de LLM?
Para los sistemas de alto riesgo, el artículo 15 exige resiliencia frente a ataques al sistema, incluidos el envenenamiento de datos, el envenenamiento de modelos, las entradas adversarias y los ataques a la confidencialidad. Tras el Digital Omnibus de 2026, esas obligaciones se aplican desde el 2 de diciembre de 2027 a los sistemas del anexo III. Incumplir las obligaciones del proveedor puede costar hasta 15 millones de euros o el 3% del volumen de negocio mundial. Un chatbot general que no es de alto riesgo queda fuera de estas obligaciones.