OWASP Top 10 LLM 2026: qué cambia y cómo acreditarlo

El OWASP Top 10 LLM estrenó edición el 3 de agosto de 2026 y nunca su orden había cambiado tanto. Excessive Agency sube al tercer puesto, System Prompt Leakage pasa a llamarse Hidden Context Exposure y, por primera vez, la clasificación se ha contrastado con 7714 incidentes reales. Casi todos los resúmenes se limitan a repetir las diez entradas. Esta guía lee la lista como lo haría un auditor o una autoridad de vigilancia del mercado: qué se ha movido, cómo se construyó la clasificación, qué obligaciones europeas toca cada entrada y qué registros demuestran que usted se ocupó de ella.

Lo esencial

• La edición 2026 salió el 3 de agosto: ocho de diez entradas cambian de puesto; solo Prompt Injection y Sensitive Information Disclosure conservan el suyo.
• La clasificación pondera el voto profesional (75 %) y un registro de incidentes (25 %): el puesto es una señal de consenso, no una puntuación de riesgo de su sistema.
• El Apéndice A del OWASP Top 10 LLM enlaza con nueve marcos de seguridad; el Reglamento de IA e ISO/IEC 42001 no figuran.
• El artículo 15.5 del Reglamento de IA cita envenenamiento de datos y de modelos, ejemplos adversarios, ataques a la confidencialidad y defectos del modelo: los cinco están en la lista.
• La lista es voluntaria; las evidencias no, si se aplican el Reglamento de IA, el de Ciberresiliencia, el RGPD, NIS2 o DORA.

¿Qué es el OWASP Top 10 LLM?

El OWASP Top 10 LLM (título oficial: OWASP Top 10 for LLM Applications) es un documento de concienciación comunitario que pone nombre a los diez riesgos de seguridad más críticos de las aplicaciones construidas sobre grandes modelos de lenguaje. Lo mantiene el OWASP GenAI Security Project, de la fundación cuyo Top 10 de aplicaciones web existe desde 2003. Para el contexto general, véase nuestra guía de seguridad de la IA. Existen cuatro ediciones del OWASP Top 10 LLM: la versión 1.0 (1 de agosto de 2023), la 1.1 (16 de octubre de 2023), la edición 2025 (18 de noviembre de 2024) y la edición 2026 (3 de agosto de 2026). El documento vigente ocupa 122 páginas bajo licencia CC BY-SA 4.0. Cada entrada incluye descripción, ejemplos, estrategias de prevención y mitigación y escenarios de ataque. Según nuestro recuento, suman 96 estrategias de mitigación numeradas, de 3 en Hidden Context Exposure (exposición del contexto oculto) a 19 en Sensitive Information Disclosure (divulgación de información sensible). La carta de presentación fija la postura: deje de perseguir un modelo al que no se pueda engañar y diseñe el sistema que lo rodea para que un modelo engañado no rompa nada importante. Es una tesis de arquitectura con efectos de gobernanza, porque el punto de control pasa del proveedor del modelo al equipo que despliega la aplicación.

Un documento de concienciación, no una norma de control

Nadie se certifica en el OWASP Top 10 LLM. No hay requisitos vinculantes ni auditores acreditados. Su valor es un vocabulario compartido: ingenieros, especialistas en pruebas de intrusión, proveedores y auditores usan ya los mismos nombres. Un hallazgo etiquetado como LLM03 se lee igual en un informe de pruebas, en un cuestionario a proveedores y en una nota para el consejo. El alcance es más estrecho de lo que sugiere el título. El OWASP Top 10 LLM cubre el modelo como componente de su aplicación. Cuando el modelo actúa, con herramientas, memoria entre sesiones y efectos en otros sistemas, OWASP remite a su Top 10 for Agentic Applications, anunciado el 9 de diciembre de 2025 y tratado más abajo.

La lista OWASP Top 10 LLM 2026: qué se ha movido

<table header-row=»true»> <tr> <td>ID 2026</td> <td>Entrada</td> <td>Puesto en 2025</td> <td>Qué ha cambiado</td> </tr> <tr> <td>LLM01</td> <td>Prompt Injection</td> <td>1</td> <td>Sigue primera. Incluye ataques multimodales ocultos en imágenes, audio o vídeo e inyecciones persistentes en la memoria o en un corpus RAG</td> </tr> <tr> <td>LLM02</td> <td>Sensitive Information Disclosure</td> <td>2</td> <td>Sigue segunda. Nuevas superficies: argumentos de llamadas a herramientas, trazas de razonamiento, registros, embeddings y canales laterales de tiempo</td> </tr> <tr> <td>LLM03</td> <td>Excessive Agency</td> <td>6</td> <td>Sube tres. Mismas causas raíz: funcionalidad, permisos y autonomía excesivos</td> </tr> <tr> <td>LLM04</td> <td>Supply Chain</td> <td>3</td> <td>Baja uno. Cubre artefactos de modelo promocionados que no son lo que dicen ser, adaptadores y cadenas de conversión</td> </tr> <tr> <td>LLM05</td> <td>Data and Model Poisoning</td> <td>4</td> <td>Baja uno. Absorbe la subversión del ajuste fino y el envenenamiento por ingesta de recuperación</td> </tr> <tr> <td>LLM06</td> <td>Unbounded Consumption</td> <td>10</td> <td>Sube cuatro. Se centra en la asimetría de costes: modelos de razonamiento, entradas multimodales, bucles de agentes</td> </tr> <tr> <td>LLM07</td> <td>Misinformation</td> <td>9</td> <td>Sube dos, impulsada por el registro de incidentes</td> </tr> <tr> <td>LLM08</td> <td>Hidden Context Exposure</td> <td>7</td> <td>Antes System Prompt Leakage. Se amplía a textos de políticas recuperados, esquemas de herramientas y cualquier contexto oculto</td> </tr> <tr> <td>LLM09</td> <td>Vector and Embedding Weaknesses</td> <td>8</td> <td>Baja uno. Incluye la memoria vectorial de los agentes y las cachés semánticas</td> </tr> <tr> <td>LLM10</td> <td>Improper Output Handling</td> <td>5</td> <td>Baja cinco, la mayor caída. Añade caracteres de control de terminal, renderizadores con carga automática y código generado inseguro</td> </tr> </table> Tres lecturas del OWASP Top 10 LLM de 2026 importan a quien gobierna el riesgo. El daño llega donde el modelo actúa. OWASP considera el ascenso de Excessive Agency (capacidad de actuación excesiva) el movimiento de mayor calado, porque voto e incidentes coinciden. Un asistente que solo responde puede inducir a error; uno que envía correos, escribe en una base de datos o tramita una devolución puede ejecutar una instrucción manipulada. Sus tres causas raíz sirven de lista de revisión: ¿hay herramientas innecesarias, permisos más amplios que la tarea o capacidad de actuar sin aprobación? Los identificadores han cambiado de significado. LLM03 era Supply Chain en 2025 y es Excessive Agency en 2026; LLM06 era Excessive Agency y ahora es Unbounded Consumption (consumo sin límites). Todo registro de riesgos, plan de pruebas o cuestionario a proveedores que cite el identificador a secas resulta ambiguo. Escriba siempre el año (LLM03:2026) y recodifique los antiguos. El contexto oculto se da por descubrible. LLM08 pide diseñar como si el prompt de sistema, las políticas recuperadas y los esquemas de herramientas pudieran extraerse: ninguna credencial en el prompt y ninguna instrucción oculta como único control de autorización. La prueba es simple: si mañana se filtrara toda la ventana de contexto, ¿qué ganaría un atacante? Las familias de ataque que hay detrás las repasa nuestra guía de IA adversaria.

Cómo se elaboró la clasificación de 2026: un voto contrastado con incidentes

Las ediciones anteriores del OWASP Top 10 LLM se apoyaban solo en el criterio profesional. Para 2026, el proyecto reunió 7714 incidentes de bases de datos públicas de vulnerabilidades y de una base de datos de daños causados por la IA, construyó clasificadores y clasificó 6639. El orden final da tres cuartas partes del peso al voto y una cuarta parte a los incidentes. Las dos fuentes discrepan en puntos instructivos:

• Prompt Injection (inyección de prompts). Primera según el voto; fuera de los diez primeros según el registro bruto de incidentes. OWASP lo lee como un efecto de la defensa: se combate tanto que pocos ataques limpios llegan a una base pública. El riesgo sigue vivo, como mostró CVE-2025-32711, un fallo zero-click en un asistente en producción.
• Misinformation (información errónea). Voto bajo, registro alto: la mayor brecha de la lista. Acabó séptima.
• Sensitive Information Disclosure. El único punto de la cabeza donde creencia y evidencia coinciden.

Para un registro de riesgos, de ahí salen tres consecuencias.

1. El puesto no mide la gravedad en su sistema. Un asistente sin herramientas apenas se expone a LLM03; un agente interno con permisos de escritura, mucho. Puntúe cada entrada frente a su arquitectura.
2. Los recuentos públicos infravaloran los riesgos bien defendidos. La nota de la Cloud Security Alliance del 15 de agosto de 2026 lo resume: que no haya incidentes no prueba que no haya riesgo.
3. Misinformation es ya una entrada de seguridad: una respuesta errónea que dispara una llamada a una herramienta se convierte en una acción errónea. Eso acerca el OWASP Top 10 LLM a las obligaciones de precisión, como explicamos en las alucinaciones, riesgo principal de la IA generativa.

Lo que el OWASP Top 10 LLM no relaciona: el Reglamento de IA e ISO/IEC 42001

El Apéndice A del OWASP Top 10 LLM relaciona la lista con nueve marcos, cada uno fijado a una versión: OWASP Top 10 for Agentic Applications, OWASP GenAI Data Security 2026, MITRE ATLAS, MITRE ATT&CK, CWE, NIST AI 600-1, NIST AI RMF, CSA AI Controls Matrix y OWASP AI Vulnerability Scoring System. Ninguno es el Reglamento de IA (AI Act) ni ISO/IEC 42001. El Reglamento aparece tres veces en 122 páginas, siempre en torno a LLM02, y una mención aún sitúa las obligaciones de alto riesgo en agosto de 2026, fecha que el Ómnibus Digital, Reglamento (UE) 2026/1744, trasladó al 2 de diciembre de 2027 para los sistemas del anexo III. No es un defecto en un documento de seguridad; sí un vacío para quien debe mostrar a un regulador cómo su trabajo de seguridad responde a una obligación legal. El puente es corto. El artículo 15, apartado 5, exige que los sistemas de IA de alto riesgo resistan los intentos de terceros no autorizados de alterar su uso, sus resultados de salida o su funcionamiento, y enumera envenenamiento de datos, envenenamiento de modelos, ejemplos adversarios o evasión de modelos, ataques a la confidencialidad y defectos del modelo. Los cinco están en el OWASP Top 10 LLM. La tabla es nuestra lectura, no una correspondencia de OWASP ni de la Comisión. <table header-row=»true»> <tr> <td>Entrada</td> <td>Anclaje en el Reglamento de IA</td> <td>Evidencias que pide un auditor</td> </tr> <tr> <td>LLM01 Prompt Injection</td> <td>Art. 15.5, entradas adversarias; art. 55.1.a), pruebas adversarias</td> <td>Informe de pruebas por versión frente a atacantes que conocen la defensa; inventario de canales de entrada no fiables</td> </tr> <tr> <td>LLM02 Sensitive Information Disclosure</td> <td>Art. 15.5, ataques a la confidencialidad; art. 10; art. 32 RGPD</td> <td>Clasificación de datos de cada fuente de contexto; pruebas de enmascaramiento; procedimiento ante incidentes de divulgación</td> </tr> <tr> <td>LLM03 Excessive Agency</td> <td>Art. 14, supervisión humana; art. 26, obligaciones del responsable del despliegue</td> <td>Registro de herramientas y permisos por aplicación; regla de aprobación para acciones de alto impacto; registros de llamadas a herramientas</td> </tr> <tr> <td>LLM04 Supply Chain</td> <td>Art. 25, cadena de valor; art. 15.5, componentes preentrenados</td> <td>Procedencia de modelos y conjuntos de datos; inventario de componentes firmados; evaluaciones de proveedores</td> </tr> <tr> <td>LLM05 Data and Model Poisoning</td> <td>Art. 10, gobernanza de datos; art. 15.5, envenenamiento de datos y modelos</td> <td>Linaje de los conjuntos de datos; validación del ajuste fino y de la ingesta de recuperación; aprobación de reentrenamientos</td> </tr> <tr> <td>LLM06 Unbounded Consumption</td> <td>Art. 15.4, resistencia a errores y fallos</td> <td>Topes de gasto; límites de peticiones; pruebas de cortacircuitos; alertas de coste</td> </tr> <tr> <td>LLM07 Misinformation</td> <td>Art. 15.1 y 15.3, precisión declarada; art. 14.4.b), sesgo de automatización</td> <td>Métricas de precisión y fundamentación; resultados de evaluación; pautas al usuario sobre el exceso de confianza</td> </tr> <tr> <td>LLM08 Hidden Context Exposure</td> <td>Art. 15.5, ataques a la confidencialidad</td> <td>Análisis de secretos en prompts y esquemas de herramientas; prueba de que la autorización se aplica fuera del modelo</td> </tr> <tr> <td>LLM09 Vector and Embedding Weaknesses</td> <td>Art. 10; art. 15.5; art. 32 RGPD</td> <td>Pruebas de aislamiento entre clientes en la recuperación; registro de procedencia de la ingesta; procedimiento de supresión de embeddings</td> </tr> <tr> <td>LLM10 Improper Output Handling</td> <td>Art. 15.5, defectos del modelo; anexo I del Reglamento de Ciberresiliencia</td> <td>Pruebas de codificación de salidas; inventario de sistemas receptores; registros de desarrollo seguro</td> </tr> </table> En ISO/IEC 42001, esos artefactos encajan en las áreas de control del anexo A: ciclo de vida del sistema de IA (verificación y validación, operación y seguimiento, registros de eventos), datos para los sistemas de IA (calidad y procedencia), relaciones con terceros y clientes y uso de los sistemas de IA. Un auditor de certificación no preguntará si «cumple con OWASP», sino cómo identificó los riesgos de seguridad de la IA y qué decidió para cada uno. Un registro de decisión por entrada del OWASP Top 10 LLM lo responde.

Qué normas hacen exigibles estas evidencias

El OWASP Top 10 LLM es voluntario. Lo que describe deja de serlo cuando se le aplica alguno de estos regímenes.

• Reglamento de IA, artículo 15. Obliga a los sistemas de alto riesgo: tras el Ómnibus Digital, los del anexo III desde el 2 de diciembre de 2027 y los productos del anexo I desde el 2 de agosto de 2028. Empiece por saber si su sistema es de alto riesgo.
• Reglamento de IA, artículo 55. Los proveedores de modelos de uso general con riesgo sistémico deben realizar y documentar pruebas adversarias y dar una protección de ciberseguridad adecuada al modelo y a su infraestructura física (artículo 55). Se aplica desde el 2 de agosto de 2025; la Comisión tiene facultades de ejecución desde el 2 de agosto de 2026.
• Reglamento de Ciberresiliencia. El Reglamento (UE) 2024/2847 cubre los productos con elementos digitales, es decir, casi todo el software comercial que integra un modelo de lenguaje. Desde el 11 de septiembre de 2026, los fabricantes notifican las vulnerabilidades explotadas activamente y los incidentes graves, por la plataforma única de notificación, al CSIRT coordinador y a ENISA: alerta temprana en 24 horas y notificación en 72 (resumen de Jones Day). Los requisitos esenciales completos rigen desde el 11 de diciembre de 2027. Según su artículo 12, un sistema de IA de alto riesgo que los cumpla se considera conforme con el requisito de ciberseguridad del artículo 15 del Reglamento de IA.
• RGPD, artículo 32. La seguridad del tratamiento alcanza a toda aplicación que toque datos personales. LLM02 y LLM09 describen violaciones de la seguridad de los datos personales antes de que ocurran.
• NIS2 y DORA. Las entidades esenciales e importantes y las entidades financieras ya deben gestionar riesgos y notificar incidentes en sus sistemas de TIC. DORA se aplica desde el 17 de enero de 2025.

Dos fechas llegan con nueve días de diferencia: el 2 de diciembre de 2027 para el alto riesgo del anexo III y el 11 para la plena aplicación del Reglamento de Ciberresiliencia. Un único expediente de seguridad, estructurado por entrada de OWASP y con referencias cruzadas a ambos reglamentos, prepara para las dos. La norma armonizada sobre ciberseguridad de la IA seguía en preparación en CEN-CENELEC a mediados de 2026, así que una taxonomía pública y reconocida es, por ahora, la estructura más defendible. En España, la AESIA (Real Decreto 729/2023, con sede en A Coruña) supervisa el Reglamento de IA, y el CCN-CERT, del Centro Criptológico Nacional, es el CERT de referencia del sector público. Un expediente ordenado según el OWASP Top 10 LLM se explica igual ante ambos.

Del OWASP Top 10 LLM a las evidencias: un método en seis pasos

1. Inventaríe cada aplicación basada en un modelo de lenguaje. Anote modelo, fuentes de contexto, herramientas, almacenes de memoria y sistemas receptores. Sin inventario de sistemas de IA nadie sabe qué entradas aplican; el AI Registry de AI Sigil guarda esa ficha por sistema.
2. Decida la aplicabilidad entrada por entrada. Escriba «no aplica» con su motivo: OWASP señala que un sistema de recuperación sin vectores no tiene superficie LLM09. Un descarte registrado es evidencia; el silencio, una laguna.
3. Seleccione mitigaciones y nombre a un responsable. Elija entre las 96 estrategias del OWASP Top 10 LLM, vincúlelas a sus controles existentes y nombre el artefacto que lo acredita.
4. Pruebe antes de cada despliegue y tras cada cambio. Una nueva versión del modelo, prompt de sistema, herramienta o corpus de recuperación reabre LLM01, LLM03 y LLM08. Las pruebas deben simular atacantes adaptativos que han leído la defensa desplegada, como explica nuestra guía de red teaming de IA.
5. Lleve la cadena de suministro al contrato. LLM04 y LLM05 exigen procedencia, firma, aviso de vulnerabilidades y notificación de cambios: materia de la due diligence de proveedores de IA.
6. Fije de antemano umbrales y plazos de incidentes. Defina el incidente grave del artículo 73 del Reglamento de IA, la vulnerabilidad explotada activamente del Reglamento de Ciberresiliencia y la violación de datos personales del RGPD, y quién notifica en 24 o 72 horas (véase notificación de incidentes de IA).

Cada paso deja un registro. Juntos forman una declaración de aplicabilidad para el riesgo de los modelos de lenguaje: diez entradas y, para cada una, una decisión, un control, un responsable y un resultado de prueba. Así el OWASP Top 10 LLM deja de ser un póster y se convierte en evidencia de auditoría.

Top 10 LLM o Top 10 agéntico: qué lista se aplica

OWASP traza la línea por el papel del modelo. Si es un componente que devuelve texto a su código, basta el OWASP Top 10 LLM. Si es un actor que invoca herramientas, conserva memoria y produce efectos en otros sistemas, se añade el OWASP Top 10 for Agentic Applications. El Apéndice A empareja cada entrada con las agénticas: Excessive Agency aparece como ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse y ASI08 Cascading Failures. Casi todos los despliegues empresariales viven en la frontera: el asistente gana un conector, luego otro, luego permisos de escritura, y nadie revisa el alcance. Dos comprobaciones ayudan.

• Registre tres atributos por aplicación (herramientas, memoria persistente, capacidad de actuar sin aprobación) y aplique ambas listas cuando cambie alguno.
• Use la «tríada letal» (lethal trifecta) que OWASP toma de Simon Willison: datos privados, contenido no fiable y comunicación exterior reúnen las condiciones de una explotación de alto impacto. Quite una pata y desaparecen.

La aprobación humana es el control al que OWASP más recurre y en el que menos confía a gran volumen: la fatiga de aprobación desgasta el criterio del revisor. Es un problema de diseño de la supervisión humana del artículo 14. Amplíe en nuestras guías sobre agentes de IA autónomos e IA agéntica frente a IA generativa, y en el documento conjunto de la ANSSI francesa y el BSI alemán sobre principios de diseño Zero Trust para sistemas basados en LLM.

Preguntas frecuentes

¿Qué es el OWASP Top 10 LLM explicado de forma sencilla? El OWASP Top 10 LLM es una lista ordenada de los diez riesgos de seguridad más críticos de las aplicaciones basadas en grandes modelos de lenguaje, elaborada por el OWASP GenAI Security Project. Cada entrada explica el fallo, da ejemplos y propone defensas. Los equipos de seguridad lo usan para delimitar pruebas, los proveedores para describir su cobertura y los auditores como vocabulario de referencia. ¿Qué ha cambiado en el OWASP Top 10 LLM en 2026? Ocho de las diez entradas del OWASP Top 10 LLM cambian de puesto. Excessive Agency sube del sexto al tercero, Unbounded Consumption del décimo al sexto y Misinformation del noveno al séptimo; Improper Output Handling cae del quinto al décimo. System Prompt Leakage pasa a llamarse Hidden Context Exposure. Cambia también el método: el voto profesional pesa un 75 % y un registro de 7714 incidentes, el 25 % restante. ¿Es obligatorio el OWASP Top 10 LLM? No. El OWASP Top 10 LLM es un documento voluntario, sin esquema de certificación. Pero los riesgos que nombra están cubiertos por normas vinculantes: el artículo 15 del Reglamento de IA para los sistemas de alto riesgo, el artículo 55 para los modelos de uso general con riesgo sistémico, el Reglamento de Ciberresiliencia y el artículo 32 del RGPD. Estructurar sus evidencias con la lista es una elección; tenerlas, no. ¿Qué relación tiene el OWASP Top 10 LLM con el Reglamento de IA? El OWASP Top 10 LLM no incluye correspondencia alguna con el Reglamento de IA. El anclaje más cercano es el artículo 15.5: envenenamiento de datos, envenenamiento de modelos, ejemplos adversarios, ataques a la confidencialidad y defectos del modelo corresponden, por ese orden, a LLM05, LLM04, LLM01, LLM02 (con LLM08 y LLM09) y LLM10. Excessive Agency enlaza con la supervisión humana del artículo 14 y Misinformation con los niveles de precisión que el artículo 15 obliga a declarar a los proveedores. ¿Sigue siendo la inyección de prompts el riesgo número uno? Sí, por voto. En el OWASP Top 10 LLM de 2026 conserva el primer puesto, aunque por los datos públicos de incidentes quedaría fuera de los diez primeros: los equipos maduros contienen los intentos antes de que sean notificables. El NCSC británico lo explica en su nota «prompt injection is not SQL injection»: los modelos no separan instrucciones de datos, así que la superficie no puede cerrarse, solo contenerse. ¿En qué se diferencian el Top 10 LLM y el Top 10 agéntico? El OWASP Top 10 LLM cubre el modelo como componente de una aplicación. La lista agéntica, anunciada el 9 de diciembre de 2025, cubre el modelo como actor autónomo con herramientas, memoria y efectos en otros sistemas. Están pensadas para usarse juntas: si su aplicación invoca herramientas o actúa sin que una persona apruebe cada paso, lea las dos y anote en el inventario cuál aplica.

Conclusión

El OWASP Top 10 LLM es el vocabulario más compartido sobre la seguridad de los modelos de lenguaje, y la edición 2026 es más honesta porque contrasta la creencia con un registro de incidentes. Sigue siendo un documento de seguridad: no dice qué norma se aplica, cuándo, ni qué pedirá ver un regulador. Esa parte es suya: un inventario, una decisión por entrada, un control con responsable, un resultado de prueba tras cada cambio y plazos de incidentes pactados de antemano. La notificación del Reglamento de Ciberresiliencia ya está en vigor y diciembre de 2027 trae las obligaciones de alto riesgo y los requisitos completos de producto. AI Sigil vincula cada aplicación basada en un modelo de lenguaje del registro con sus entradas aplicables, controles seleccionados, resultados de pruebas y decisiones sobre incidentes, de modo que la respuesta a un auditor sea un informe, no una reconstrucción.