26/10/2026

NIST AI 100-2: taxonomía de ataques a la IA y evidencias

NIST AI 100-2 es la taxonomía de ataques a la IA que el Instituto Nacional de Estándares y Tecnología (NIST) estadounidense publica como referencia del aprendizaje automático adversario: clasifica cómo se ataca un modelo predictivo o generativo y qué mitigaciones existen. Para un equipo europeo su interés es práctico, porque nombra con precisión los ataques que el artículo 15 del Reglamento de IA obliga a prevenir. Aquí explicamos qué contiene la edición de 2025, qué deja fuera y cómo convertirla en un expediente de evidencias.

Cajón de especímenes de madera abierto con compartimentos etiquetados, pequeñas llaves de latón, una lupa agrietada y un sello de lacre roto, imagen del artículo sobre NIST AI 100-2

Lo esencial

<code>NIST AI 100-2e2025</code> (marzo de 2025) ordena los ataques en 5 categorías y 25 identificadores estables <code>NISTAML</code>, la mejor clave primaria para un registro de amenazas de IA.
Es voluntario: según nuestro recuento, no menciona ni una vez el Reglamento europeo de IA ni ninguna norma ISO/IEC.
Su vocabulario cubre los ataques adversarios que enumera el artículo 15, apartado 5: envenenamiento de datos y de modelos, evasión, ataques a la confidencialidad.
Deja fuera, a propósito, la decisión sobre el riesgo residual que el artículo 9 exige firmar.
En 2026 llegaron ETSI EN 304 223 e ISO/IEC 27090, prEN 18282 cerró su encuesta pública y el NIST empezó a decir «Super Intelligence»; el identificador NIST AI 100-2 no cambia.

NIST AI 100-2: qué es el documento y qué no es

El título completo es «Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations». La edición vigente, <code>NIST AI 100-2e2025</code>, lleva fecha de marzo de 2025: el comité editorial del NIST la aprobó el 20 de marzo y el CSRC anunció su publicación el 24 de marzo. Sustituye a <code>NIST AI 100-2e2023</code>, publicada en enero de 2024. La firman Apostol Vassilev (NIST), Alina Oprea (Northeastern University), Alie Fordyce y Hyrum Anderson (Cisco), Xander Davies (UK AI Security Institute) y Maia Hamin (US AI Safety Institute).

Según nuestro recuento con pypdf, el PDF de la edición 2025 tiene 127 páginas y 449 referencias numeradas, frente a 107 páginas y 354 referencias de la anterior, e incluye un glosario. NIST AI 100-2 adopta los conceptos de seguridad, resiliencia y solidez del NIST AI RMF. Lo que no es: una norma. Una nota (p. viii) aclara que «does not establish any legal standard or any other legal requirement or defense under any law», y el resumen ejecutivo precisa que «does not make recommendations on risk tolerance».

Qué cambió entre NIST AI 100-2e2023 y NIST AI 100-2e2025

Cinco cambios importan a un equipo de cumplimiento. Primero, los identificadores NISTAML: la edición de 2023 no tenía ninguno y la de 2025 contiene 30 códigos. Segundo, la categoría de violaciones propia de la IA generativa pasa de «abuse» a «misuse». Tercero, nace una sección propia para la cadena de suministro de la IA generativa. Cuarto, hay apartados nuevos sobre seguridad de agentes y bancos de pruebas. Quinto, la bibliografía crece de 354 a 449 referencias (ficha del CSRC).

La nueva etiqueta «Super Intelligence»

La orden ejecutiva estadounidense «Inaugurating the Era of Super Intelligence», de 29 de septiembre de 2026, obliga a las agencias federales a usar «Super Intelligence» o «SI» en lugar de «Artificial Intelligence» o «AI» en sus comunicaciones oficiales y documentos no normativos (hoja informativa de la Casa Blanca). La página del NCCoE se titula ahora «Super Intelligence: Adversarial Machine Learning», y el 20 de octubre de 2026 las superposiciones de controles SP 800-53 COSAiS pasaron a llamarse COSIS, precisando que «Previously issued documents and publications have not been altered». Esas superposiciones citan <code>NIST AI 100-2e2025</code> como insumo. A 22 de octubre de 2026 no hemos encontrado ninguna edición E2026 ni borrador público, aunque en marzo de 2025 el NIST anunció actualizaciones anuales.

Cómo se construye la taxonomía: cinco dimensiones y cinco categorías

NIST AI 100-2 clasifica cada ataque según cinco dimensiones:

Tipo de sistema: IA predictiva o IA generativa.
Fase del ciclo de vida: el momento en que actúa el atacante, del entrenamiento al despliegue.
Objetivos del atacante: disponibilidad, integridad y privacidad, a los que la IA generativa añade el uso indebido («misuse»).
Capacidades del atacante: control de los datos de entrenamiento, control del modelo, acceso por consultas o control de recursos externos, como las fuentes de un sistema RAG o las herramientas de un agente.
Conocimiento del atacante: caja blanca, caja negra o caja gris.

Los objetivos se traducen en cinco categorías de violación con su código: <code>NISTAML.01</code> disponibilidad, <code>NISTAML.02</code> integridad, <code>NISTAML.03</code> privacidad, <code>NISTAML.04</code> uso indebido y <code>NISTAML.05</code> cadena de suministro. De ellas cuelgan, según nuestro recuento, 25 identificadores de ataque.

¿Por qué importan estos códigos? Porque un registro de amenazas necesita una clave primaria que no dependa del escáner ni del proveedor de pruebas de turno. La «evasión de caja negra» puede describirse de diez maneras en diez informes; <code>NISTAML.025</code> solo de una. Los identificadores sobreviven a los cambios de herramienta y se cruzan con las técnicas de MITRE ATLAS y con las entradas del OWASP Top 10 para LLM, de modo que el mismo registro alimenta el plan de pruebas, la matriz de controles y el expediente del artículo 15.

Nuestra recomendación central: utilice el código de NIST AI 100-2 como clave y trate las demás taxonomías como atributos. Si cambia de escáner o de proveedor de red teaming, actualizará columnas, no filas.

Ataques a la IA predictiva: evasión, envenenamiento y privacidad

Evasión. Un ataque de evasión (<code>NISTAML.022</code>) modifica la entrada durante la inferencia para que el modelo se equivoque. La variante de caja negra (<code>NISTAML.025</code>) solo necesita acceso por consultas, y la transferibilidad agrava el problema: un ejemplo adversario construido contra un modelo sustituto suele engañar también al modelo objetivo. NIST AI 100-2 recoge casos reales, como señales de stop alteradas que un clasificador lee como límites de velocidad.

Envenenamiento. En el plano de la disponibilidad figuran el envenenamiento de datos (<code>NISTAML.013</code>), el de modelos (<code>NISTAML.011</code>), el envenenamiento con etiquetas limpias (<code>NISTAML.012</code>) y los ataques de energía y latencia (<code>NISTAML.014</code>). En el de la integridad aparecen el envenenamiento dirigido (<code>NISTAML.024</code>), las puertas traseras (<code>NISTAML.023</code>) y su variante con etiquetas limpias (<code>NISTAML.021</code>), así como el envenenamiento de modelos (<code>NISTAML.026</code>). El envenenamiento de modelos por la cadena de suministro tiene código propio, <code>NISTAML.051</code>.

Privacidad. Extracción del modelo (<code>NISTAML.031</code>), reconstrucción de datos (<code>NISTAML.032</code>), inferencia de pertenencia (<code>NISTAML.033</code>) e inferencia de propiedades (<code>NISTAML.034</code>).

Contra la evasión, el NIST cita el entrenamiento adversario, el suavizado aleatorio (randomized smoothing) y la verificación formal; contra el envenenamiento, el saneamiento de datos y la inspección de modelos; contra los ataques de privacidad, la privacidad diferencial. La advertencia es clara: estas mitigaciones son en gran medida empíricas y no existen pruebas de seguridad propias de la teoría de la información para los algoritmos de aprendizaje automático más utilizados.

Para un auditor, ninguna medida «cierra» un identificador de NIST AI 100-2: solo reduce el riesgo, y esa reducción hay que medirla y documentarla. Profundizamos en estas familias en nuestra guía sobre IA adversaria.

Ataques a la IA generativa: cadena de suministro, inyección de prompts y agentes

La segunda mitad de NIST AI 100-2 trata la IA generativa, con una sección propia sobre la cadena de suministro (modelos preentrenados, datos y componentes de terceros) y estos identificadores:

<code>NISTAML.018</code> inyección de prompts, que incluye el prompting directo y los jailbreaks.
<code>NISTAML.015</code> inyección indirecta de prompts a través de contenidos recuperados, y <code>NISTAML.017</code>, tareas en segundo plano que consumen tiempo inyectadas por esa misma vía.
<code>NISTAML.027</code> salidas desalineadas.
<code>NISTAML.035</code> extracción de prompts y <code>NISTAML.036</code> fuga de información de las interacciones de los usuarios.
<code>NISTAML.037</code> ataques a los datos de entrenamiento y <code>NISTAML.038</code> extracción de datos.
<code>NISTAML.039</code> compromiso de recursos conectados.

Sobre los agentes, el NIST es prudente: la investigación de seguridad centrada en ellos «is still in its early stages» (sección 3.5). El riesgo, sin embargo, ya es concreto. Cuando un agente dispone de herramientas, una inyección indirecta deja de producir solo texto inadecuado y puede traducirse en ejecución de código o exfiltración de datos. Lo analizamos en nuestro artículo sobre seguridad de la IA agéntica.

El documento cita además investigaciones según las cuales, mientras un modelo conserve alguna probabilidad de comportarse de forma no deseada, existe algún prompt capaz de provocarlo. Consecuencia práctica: el filtrado nunca será completo, y las evidencias deben mostrar capas de defensa y detección, no una promesa de bloqueo total.

Para medir, NIST AI 100-2 menciona bancos de pruebas y herramientas como JailbreakBench, HarmBench, AgentDojo, Garak y PyRIT. La correspondencia con el OWASP Top 10 para LLM y con el perfil de IA generativa NIST AI 600-1 es directa.

Lo que NIST AI 100-2 deja fuera a propósito

Nuestro recuento con pypdf sobre la edición de 2025 arroja cero menciones del Reglamento europeo de IA (ni como «EU AI Act» ni como «Artificial Intelligence Act») y cero de ISO/IEC 42001 o de cualquier otra norma ISO/IEC. La palabra «compliance» aparece una vez y «regulation», dos. No es un descuido de redacción. La sección 4.2.5 lo dice expresamente: «A key question that this taxonomy deliberately leaves aside is how organizations can make decisions about the development and use of AI systems in light of evidence about the increasing diversity of AML attacks and the efficacy and limitations of available mitigations.»

Dicho de otro modo: la taxonomía describe ataques y mitigaciones, pero no responde a cómo debe decidir una organización si desarrolla o utiliza un sistema a la vista de esos ataques y de los límites de las defensas. Tampoco cubre los ataques de ciberseguridad clásicos contra la plataforma (servidores, redes, credenciales), los defectos de diseño no adversarios ni la tolerancia al riesgo.

Ese hueco es exactamente el que llena el Reglamento Europeo de Inteligencia Artificial. El artículo 9 exige un sistema de gestión de riesgos que contemple el uso indebido razonablemente previsible y que considere aceptables los riesgos residuales (apartado 5). El anexo IV, punto 2, letra h), pide describir «las medidas de ciberseguridad adoptadas». NIST AI 100-2 aporta el vocabulario; la decisión y la firma corresponden al proveedor. Para encajar esta pieza con las normas de gestión, consulte qué normas de la pila ISO 42001 exige realmente el Reglamento.

De NIST AI 100-2 al artículo 15, apartado 5, del Reglamento de IA

Esta es la redacción oficial española del párrafo clave del artículo 15, apartado 5, del Reglamento (UE) 2024/1689:

«Entre las soluciones técnicas destinadas a subsanar vulnerabilidades específicas de la IA figurarán, según corresponda, medidas para prevenir, detectar, combatir, resolver y controlar los ataques que traten de manipular el conjunto de datos de entrenamiento (“envenenamiento de datos”), o los componentes entrenados previamente utilizados en el entrenamiento (“envenenamiento de modelos”), la información de entrada diseñada para hacer que el modelo de IA cometa un error (“ejemplos adversarios” o “evasión de modelos”), los ataques a la confidencialidad o los defectos en el modelo.»

La tabla es trabajo nuestro: cruza cada término con los identificadores de NIST AI 100-2 y con la evidencia que una autoridad de vigilancia del mercado o un organismo notificado puede pedir en la evaluación de la conformidad.

Término del artículo 15, apartado 5	Clases e identificadores de NIST AI 100-2	Evidencias para el expediente
Envenenamiento de datos	<code>NISTAML.013</code>, <code>NISTAML.012</code>, <code>NISTAML.024</code>; puertas traseras <code>NISTAML.021</code> y <code>NISTAML.023</code>	Procedencia y saneamiento de los datos de entrenamiento, pruebas de envenenamiento, vínculo con el artículo 10
Envenenamiento de modelos (componentes entrenados previamente)	<code>NISTAML.011</code>, <code>NISTAML.026</code>; cadena de suministro <code>NISTAML.051</code>	Lista de materiales de IA, procedencia del modelo y control de hashes, declaraciones de proveedores
Ejemplos adversarios o evasión de modelos	<code>NISTAML.022</code>, <code>NISTAML.025</code>; en sistemas generativos, también <code>NISTAML.018</code> y <code>NISTAML.015</code> (lectura nuestra)	Plan y resultados de pruebas adversarias, métricas de solidez en el anexo IV
Ataques a la confidencialidad	<code>NISTAML.031</code> a <code>NISTAML.039</code> (extracción, inferencias, extracción de prompts y de datos)	Pruebas de ataques a la privacidad, limitación de consultas, filtrado de salidas, vínculo con la evaluación de impacto del RGPD
Defectos en el modelo	En gran parte fuera de NIST AI 100-2 (excluye los defectos no adversarios)	Pruebas de precisión y solidez del artículo 15, apartados 1 a 4
Bucles de retroalimentación (artículo 15, apartado 4)	Envenenamiento por retroalimentación, <code>NISTAML.013</code> y <code>NISTAML.024</code>	Vigilancia de deriva y datos de entrada, plan de vigilancia poscomercialización (artículo 72)

Tras el Ómnibus Digital sobre IA (Reglamento (UE) 2026/1744), el artículo 15 obliga a los sistemas de alto riesgo del anexo III desde el 2 de diciembre de 2027 y a los del anexo I desde el 2 de agosto de 2028. Para los modelos de uso general con riesgo sistémico, el artículo 55, apartado 1, letras a) (pruebas de simulación de adversarios) y d) (ciberseguridad), rige desde el 2 de agosto de 2025, y la Comisión puede multar a los proveedores desde el 2 de agosto de 2026. El capítulo de seguridad del Código de buenas prácticas para la IA de uso general (10 de julio de 2025) lo concreta en evaluaciones, pruebas adversarias y medidas de protección.

Las normas europeas que darán contenido al artículo 15

prEN 18282. Proyecto de norma europea de ciberseguridad para sistemas de IA, del grupo de trabajo 5 de CEN-CENELEC JTC 21, en apoyo del artículo 15. Su encuesta pública fue del 15 de mayo a mediados de julio de 2026 y la publicación se prevé entre finales de 2026 y principios de 2027. Solo dará presunción de conformidad cuando su referencia se publique en el Diario Oficial.

ETSI EN 304 223. Publicada el 14 de enero de 2026 (nota de prensa de ETSI), fija 13 principios en cinco fases del ciclo de vida: diseño seguro, desarrollo, despliegue, mantenimiento y fin de vida. Se basa en ETSI TS 104 223; para la IA generativa se ha anunciado ETSI TR 104 159.

ISO/IEC 27090:2026. Primera edición, de octubre de 2026, con 56 páginas (heise). Es una guía, no certificable, y cubre envenenamiento, manipulación de pesos, evasión, extracción, inferencia de pertenencia, inversión de modelos e inyección de prompts.

Reglamento de Ciberresiliencia. Según el artículo 12 del Reglamento (UE) 2024/2847, se considera que un sistema de IA de alto riesgo que sea también producto con elementos digitales cumple los requisitos de ciberseguridad del artículo 15 si satisface el anexo I de ese reglamento y la declaración UE de conformidad acredita el nivel de protección; precisión y solidez siguen bajo el Reglamento de IA. Desde el 11 de septiembre de 2026 rige la obligación de notificar vulnerabilidades explotadas activamente e incidentes graves: alerta temprana en 24 horas, notificación en 72 horas e informe final en 14 días tras la medida correctora (un mes tras la notificación para incidentes graves), vía la plataforma única de ENISA, también para productos comercializados antes del 11 de diciembre de 2027.

Artículo 42, apartado 2. Los sistemas de alto riesgo certificados con arreglo a un esquema del Reglamento (UE) 2019/881 se presumen conformes con los requisitos de ciberseguridad del artículo 15, en la medida en que el certificado los cubra.

En España, la AESIA (Agencia Española de Supervisión de la Inteligencia Artificial, creada por el Real Decreto 729/2023, con sede en A Coruña) supervisa la IA, y INCIBE y CCN-CERT son las referencias en ciberseguridad. Un expediente en clave NISTAML sirve a ambos interlocutores.

Nuestra lectura: todos estos textos enumeran las mismas clases de ataque, como ya hacía en 2021 el catálogo de ENISA Securing Machine Learning Algorithms. Un registro indexado por los identificadores de NIST AI 100-2 puede reetiquetarse para cada norma en lugar de reconstruirse. Más contexto en nuestra guía de seguridad de la IA.

Cómo convertir NIST AI 100-2 en un expediente de evidencias

Inventariar y clasificar. Registre cada sistema de IA como predictivo, generativo o agéntico, y como de alto riesgo, modelo de uso general u otro. La doble clasificación decide qué identificadores y artículos aplican; vea nuestra guía sobre el sistema de IA de alto riesgo.
Modelar las amenazas. Contraste cada sistema con los identificadores NISTAML y anote las capacidades realistas del atacante: solo acceso por consultas, API de ajuste fino, ingesta en el RAG o acceso a herramientas. Motive por escrito cada identificador descartado: también es evidencia.
Asignar controles. Vincule cada identificador retenido con sus controles y use MITRE ATLAS y el OWASP Top 10 para LLM para el detalle técnico. El código de NIST AI 100-2 sigue siendo la clave; las técnicas de los otros marcos son atributos.
Probar. Realice pruebas adversarias y ejercicios de red teaming de IA con herramientas que el NIST cita, como Garak, PyRIT o AgentDojo. Documente método, alcance y resultados por identificador.
Decidir y firmar el riesgo residual. Para cada identificador, un responsable con cargo definido declara si el riesgo residual es aceptable. Es la decisión que NIST AI 100-2 deja fuera y que el artículo 9, apartado 5, exige.
Redactar la documentación. Escriba la sección de ciberseguridad del anexo IV, punto 2, letra h), y la parte de la declaración relativa al artículo 15, citando los identificadores. El evaluador podrá seguir la traza de la amenaza a la prueba y a la firma.
Vigilar y notificar. Integre los identificadores en la vigilancia poscomercialización (artículo 72), en la notificación de incidentes graves (artículo 73) y en la alerta temprana de 24 horas del Reglamento de Ciberresiliencia para vulnerabilidades explotadas activamente. Revise el registro cada año, al ritmo de actualización anunciado por el NIST.

Nuestro software de gestión de riesgos de IA vincula riesgos, controles y evidencias por sistema de IA.

Preguntas frecuentes

¿Es obligatorio aplicar NIST AI 100-2 en Europa?

No. Es un documento voluntario de un organismo estadounidense y su propia nota a pie de página descarta todo valor jurídico. En Europa obligan el Reglamento de IA, el Reglamento de Ciberresiliencia y el RGPD. Pero el artículo 15 exige medidas contra ataques que NIST AI 100-2 describe y codifica con detalle, así que adoptarlo como vocabulario de referencia es fácil de justificar. Para la ciberseguridad general, use el NIST CSF.

¿Qué cambió entre las ediciones de 2023 y 2025?

La edición <code>NIST AI 100-2e2025</code> introduce 30 códigos NISTAML (5 categorías y 25 identificadores de ataque), inexistentes en 2023. Renombra «abuse» como «misuse» y añade secciones sobre la cadena de suministro de la IA generativa, la seguridad de los agentes y los bancos de pruebas. Según nuestro recuento, pasa de 107 a 127 páginas y de 354 a 449 referencias. Para un registro de amenazas, el cambio decisivo es el primero.

¿Cubre NIST AI 100-2 los agentes de IA?

Sí, aunque con cautela. La edición de 2025 incluye una sección sobre la seguridad de los agentes y reconoce que la investigación sobre ellos «is still in its early stages». Los identificadores más pertinentes son la inyección indirecta de prompts (<code>NISTAML.015</code>) y el compromiso de recursos conectados (<code>NISTAML.039</code>), porque un agente con herramientas convierte una instrucción maliciosa en una acción real. Sus pruebas, por ejemplo con AgentDojo, deben cubrir cada herramienta expuesta al agente.

¿Qué relación tiene con MITRE ATLAS y con el OWASP Top 10 para aplicaciones LLM?

Son complementarios. NIST AI 100-2 ofrece la taxonomía con identificadores estables; MITRE ATLAS describe tácticas y técnicas de adversarios con casos documentados; el OWASP Top 10 para LLM prioriza los riesgos de las aplicaciones con modelos de lenguaje. Recomendamos usar el código NISTAML como clave primaria y añadir las referencias ATLAS y OWASP como atributos, para trazar cada prueba y cada control sin duplicar filas.

¿Basta con seguir NIST AI 100-2 para cumplir el artículo 15 del Reglamento de IA?

No. El documento cubre bien los ataques adversarios, pero deja fuera los defectos no adversarios, los ataques clásicos contra la plataforma y, sobre todo, la decisión sobre el riesgo residual. El artículo 15 exige además precisión, solidez y control de los bucles de retroalimentación, y el anexo IV, documentación técnica completa. NIST AI 100-2 le da el mapa de amenazas; el expediente, las pruebas y la aceptación del riesgo son tarea del proveedor.

¿Por qué las páginas del NIST dicen ahora «Super Intelligence»?

Por la orden ejecutiva de 29 de septiembre de 2026, que obliga a las agencias federales a sustituir «Artificial Intelligence» por «Super Intelligence» en sus comunicaciones oficiales. El NIST ha renombrado páginas y proyectos, como la página del NCCoE o el proyecto COSIS, pero afirma que no ha modificado los documentos ya publicados. Cite en su expediente el identificador <code>NIST AI 100-2e2025</code>, que no cambia. La orden no crea obligaciones para las empresas privadas.

Conclusión

NIST AI 100-2 es hoy el vocabulario más preciso del que dispone un equipo europeo para nombrar los ataques que el artículo 15 del Reglamento de IA obliga a prevenir, y su edición de 2025 aporta identificadores estables que pueden servir de clave a todo el expediente. Pero el documento se detiene, a propósito, donde empieza la responsabilidad del proveedor: decidir qué riesgo residual es aceptable, demostrarlo y firmarlo. Las normas de 2026 nombran los mismos ataques con otras etiquetas: el trabajo sobre los códigos NISTAML no se pierde. Empiece este trimestre por el inventario y el modelado de amenazas de sus sistemas de alto riesgo y de uso general, antes de que las fechas de 2027 y 2028 conviertan la tarea en urgencia.

Elena Vargas