El Top 10 de OWASP para LLM 2026 no se cumple: se reparte
OWASP publicó el 4 de agosto de 2026 la edición 2026 de su Top 10 para aplicaciones con modelos de lenguaje, y es la lista de riesgos de IA más usada del sector. También la más malusada: se reparte como lista de comprobación, se marcan las diez casillas y se archiva. No está hecha para eso. Es un ranking de consenso, sin requisitos ni certificación detrás, y su valor está en otro sitio: da a seguridad, a quien construye la aplicación y a quien decide un vocabulario común para asignar cada riesgo a alguien que lo acepte y a una prueba que lo sostenga.
La carta de los responsables del proyecto lo resume en una frase que es más de gobierno que de técnica: dejar de intentar construir un modelo que no se pueda engañar y construir el sistema de alrededor para que, cuando lo engañen, no se rompa nada importante. Esa frase convierte la lista en un reparto de responsabilidades, no en un examen.
La lista como examen
Diez riesgos, diez casillas, todas marcadas. Es el uso más común de la lista de OWASP: se repasa antes de una salida a producción y se archiva con el resto de la documentación.
Lo que falla: un visto no dice quién aceptó el riesgo que queda. Y en la primera fila, la inyección de instrucciones, siempre queda: la superficie no se cierra.
El voto y el registro no dicen lo mismo
Por primera vez el orden mezcla el voto de los profesionales (tres cuartos del peso) con 6.639 incidentes reales clasificados (el cuarto restante). La inyección de instrucciones es primera en el voto y se cae del top 10 si se mira solo el registro; la desinformación, al revés.
Lo que falla: leer el puesto como una probabilidad. La inyección aparece poco en el registro porque se defiende mucho, y la desinformación aparece mucho porque una respuesta equivocada acaba convertida en una acción equivocada.
Componente o actor
La lista de LLM cubre el modelo cuando es una pieza dentro de la aplicación. Cuando llama a herramientas, guarda memoria entre sesiones o desencadena consecuencias fuera, el propio prefacio remite a la lista de aplicaciones con agentes, de diciembre de 2025.
Lo que falla: evaluar un agente con la lista de LLM sola. Ninguna de las dos cubre ese terreno por separado, y el inventario rara vez dice si un sistema actúa.
La misma lista, repartida
Las mismas diez filas sirven cuando cada una dice quién acepta el riesgo que queda y qué prueba lo sostiene: una prueba de intrusión con fecha, un ejercicio de red teaming o una revisión de permisos.
Lo que falla: repartirla solo a seguridad. La agencia excesiva se decide al dar permisos al modelo y la desinformación, en el proceso que usa su respuesta: no son filas de un único equipo.
Qué cambió en la edición 2026
El orden se movió más que en otras ediciones, y por una razón de método. Hasta 2025 la lista era solo juicio experto. En 2026 el proyecto contrastó el voto con un corpus de 7.714 incidentes públicos, de los que clasificó 6.639, y dio al registro un cuarto del peso. Lo bastante para mover una entrada un escalón cuando creencia y evidencia se separan, y no tanto como para que un año de datos imperfectos reescriba la lista.
Los movimientos que importan para gobierno:
- La agencia excesiva sube al tercer puesto. Es el cambio de más consecuencias, porque voto y registro coinciden en que el daño está llegando por los despliegues con agentes. La entrada distingue tres causas: funcionalidad de más (la herramienta que además de leer puede borrar), permisos de más y autonomía de más.
- El consumo sin límite sube cuatro puestos y la gestión indebida de la salida baja del quinto al décimo.
- La inyección de instrucciones sigue primera por el voto, aunque el registro la saque del top 10: se defiende tanto que pocos ataques limpios llegan a una base pública, y eso infravalora un riesgo que los equipos maduros ya pagan por contener.
- La fuga del prompt de sistema pasa a ser la exposición del contexto oculto. El cambio de nombre trae una regla de diseño clara: todo lo que se pone en el contexto del modelo hay que darlo por descubrible. Ni credenciales ni lógica de autorización pueden depender de que el prompt sea secreto.
- Varias entradas crecen sin crear categorías nuevas. La inyección incluye ahora las instrucciones escondidas en una imagen o un audio; el envenenamiento, la subversión del ajuste fino; la gestión de la salida, el código inseguro que generan los asistentes.
Dónde termina la lista: componente o actor
El prefacio traza una frontera que conviene llevar al inventario. La lista de LLM cubre el riesgo cuando el modelo es un componente de la aplicación. En el momento en que actúa (herramientas que puede llamar, memoria que conserva entre sesiones, consecuencias que pone en marcha fuera) el riesgo pasa al Top 10 for Agentic Applications, publicado el 9 de diciembre de 2025: secuestro del objetivo del agente, uso indebido de herramientas, abuso de identidad y privilegios, cadena de suministro de agentes, ejecución inesperada de código, envenenamiento de memoria y contexto, comunicación insegura entre agentes, fallos en cascada, explotación de la confianza entre persona y agente, y agentes que se desvían.
La consecuencia práctica es una columna del inventario que casi ningún inventario tiene: ¿este sistema actúa? De la respuesta depende con qué lista se evalúa. Es la misma lógica que hace de la IA en la sombra un fallo de inventario: lo que no está bien descrito en la lista no se puede evaluar con el criterio correcto.
Lo que OWASP no cruza: el reglamento y la norma
El apéndice de correspondencias de la edición 2026 cruza cada riesgo con NIST, MITRE ATLAS y ATT&CK, CWE y la matriz de controles de CSA. No cruza con el Reglamento (UE) 2024/1689, que solo aparece de pasada, ni con ISO/IEC 42001, ni con ISO/IEC 27090, publicada dos meses después. Ese cruce es trabajo de la casa, y conviene hacerlo con una advertencia por delante: señalar dónde el reglamento pide algo relacionado con un riesgo no es cumplirlo, y estas obligaciones son las de los sistemas de alto riesgo.
| Riesgo (OWASP LLM 2026) | Dónde lo toca el reglamento | Dónde lo trata ISO/IEC 27090 |
|---|---|---|
| 1 · Inyección de instrucciones | Art. 15.5, primer párrafo: resistencia a terceros que alteran su uso aprovechando vulnerabilidades | 6.9 |
| 2 · Divulgación de información sensible | Art. 15.5: ataques a la confidencialidad | 6.4, 6.5, 6.6 y 6.8 |
| 3 · Agencia excesiva | Art. 14.4: poder no usar el sistema, descartar o revertir su resultado, o detenerlo; y la gestión de riesgos del art. 9 | 6.11 (comportamiento no deseado en operación) |
| 4 · Cadena de suministro | Art. 15.5 (componentes entrenados previamente) y art. 25.4, que desde el Reglamento (UE) 2026/1744 nombra expresamente al tercero que suministra un modelo | 5.5 |
| 5 · Envenenamiento de datos y de modelos | Art. 15.5 y gobierno de datos del art. 10 | 6.2 y 6.7 |
| 6 · Consumo sin límite | Art. 15.4: solidez frente a errores y fallos | 7.8 (limitar el uso del modelo) |
| 7 · Desinformación | Arts. 15.1 y 15.3 (precisión declarada) y art. 14.4.b (sesgo de automatización) | Sin apartado: no es un ataque |
| 8 · Exposición del contexto oculto | Art. 15.5: ataques a la confidencialidad | 6.8, en parte |
| 9 · Debilidades de vectores y embeddings | Art. 15.5 | Sin apartado propio |
| 10 · Gestión indebida de la salida | Art. 15.5, primer párrafo, y art. 15.4 | 6.10 |
Dos lecturas. La primera, que casi toda la lista cae en el artículo 15.5, y que la 27090 cubre bien los riesgos de ataque y se queda sin palabras en el que más pesa en el registro de incidentes, la desinformación, porque no necesita atacante. La segunda, que la agencia excesiva, la que más sube, no es en el reglamento una cuestión de ciberseguridad sino de supervisión humana: el artículo 14 pide que la persona pueda descartar o revertir el resultado, o parar el sistema, y un agente con permisos de más es exactamente uno al que eso le llega tarde.
Lo que decide la organización
Usada como reparto, la lista obliga a tres decisiones que como examen nunca aparecen.
Quién acepta cada residual, por escrito. Hay filas que no se cierran, empezando por la primera. La decisión no es si el riesgo existe sino quién acepta lo que queda tras las mitigaciones, con qué permisos mínimos para el modelo y hasta cuándo. Una aceptación sin nombre ni fecha es un visto con otra forma.
Qué equipo tiene cada fila. Seguridad de la información tiene la inyección, la divulgación y la cadena de suministro. La agencia excesiva es de quien concede permisos al modelo y a sus herramientas. La desinformación es del dueño del proceso que convierte la respuesta en una decisión. Si las diez van a un solo equipo, las tres que más pesan quedan sin dueño real. Es la misma frontera que en la rueda de quien usa el sistema separa lo que existe de quien responde de ello.
Qué cuenta como prueba. Un visto no es evidencia. Lo es una prueba con fecha y alcance, un ejercicio de red teaming contra los escenarios de la lista o una revisión de permisos de las herramientas. Y caduca: cada cambio de modelo, de herramienta o de fuente de contexto reabre las filas que toca.
La lista de OWASP no dice quién responde de nada. Precisamente por eso sirve: obliga a decidirlo en voz alta.