MITRE ATLAS: de las técnicas de ataque a la IA a los controles de cumplimiento

Lo esencial

• MITRE ATLAS es una base de conocimiento abierta y viva sobre cómo se atacan realmente los sistemas de IA: 16 tácticas y 84 técnicas extraídas de incidentes reales y de trabajo de red team.
• El marco extiende la lógica de MITRE ATT&CK a la superficie de ataque propia del aprendizaje automático, y cubre amenazas como el envenenamiento de datos, la evasión de modelos y la inyección de instrucciones que los estándares de seguridad clásicos nunca nombraron.
• ATLAS, el OWASP LLM Top 10 y el NIST AI RMF son capas complementarias (amenazas, vulnerabilidades de aplicación, gobernanza), no estándares rivales.
• Las clases de ataque que cataloga ATLAS son precisamente aquellas frente a las que el Reglamento europeo de IA obliga a protegerse en los sistemas de alto riesgo, lo que convierte a ATLAS en una fuente de pruebas de cumplimiento.
• La ganancia concreta cabe en una cadena: enlazar cada técnica de ATLAS con un control y con una prueba de auditoría dentro de su programa de gobernanza de la IA.

¿Qué es MITRE ATLAS?

MITRE ATLAS son las siglas de Adversarial Threat Landscape for Artificial-Intelligence Systems. MITRE lo describe como una base de conocimiento de acceso mundial y en constante actualización sobre tácticas y técnicas adversarias contra sistemas basados en IA, construida a partir de observaciones de ataques reales y de demostraciones realizadas por equipos de red team especializados. Dicho de forma sencilla, es un mapa estructurado de cómo se ataca a la IA, alimentado por incidentes que han ocurrido de verdad y no por temores teóricos. En la versión 5.4.0 (febrero de 2026), la matriz ATLAS reúne 16 tácticas, 84 técnicas, 56 subtécnicas, 32 medidas de mitigación y 42 casos de estudio documentados. Son casos tangibles y no académicos: la elusión de la verificación de identidad mediante deepfake, la evasión de un modelo de aprendizaje automático, agentes de IA con puertas traseras o el secuestro de transacciones financieras a través de asistentes de IA. El marco existe porque la IA añade una superficie de ataque que los modelos de seguridad tradicionales nunca se concibieron para describir. Un modelo puede corromperse durante el entrenamiento, engañarse en el momento de la inferencia o interrogarse hasta que revela los datos de los que aprendió. ATLAS ofrece a los equipos de seguridad y de gobernanza un vocabulario común para esos modos de fallo, de modo que un hallazgo de red team, un responsable de control y un auditor puedan señalar la misma técnica y referirse a lo mismo. Para una organización regulada, ese lenguaje compartido es el primer paso para tratar la seguridad de la IA como una disciplina de gobernanza y no como un proyecto aislado. Es también la razón por la que AI Sigil sitúa a ATLAS como capa de referencia bajo su modelo de riesgos y controles.

MITRE ATLAS frente a MITRE ATT&CK

Quien haya trabajado en un centro de operaciones de seguridad reconocerá sus referencias en ATLAS, y no por casualidad. El marco se inspira directamente en la metodología de MITRE ATT&CK: la misma distinción entre tácticas (el objetivo del atacante en cada fase) y técnicas (la manera de lograrlo), presentada como una matriz que se lee de izquierda a derecha a lo largo del ciclo de vida del ataque. La diferencia está en el objetivo. ATT&CK describe los ataques a la informática tradicional: puestos de trabajo, redes, identidades. ATLAS describe los ataques a la propia IA: el modelo, sus datos de entrenamiento, su canal de inferencia y los agentes construidos sobre él. Varias tácticas son comunes a ambos (reconocimiento, acceso inicial, exfiltración, impacto), porque un atacante sigue haciendo phishing, sigue moviéndose lateralmente, sigue robando credenciales. Lo que ATLAS añade es el núcleo propio de la IA: obtener acceso a un modelo, envenenar sus datos, fabricar entradas que lo engañen o extraerlo por completo. Para un equipo de gobernanza, la conclusión no es elegir entre ambos. ATT&CK cubre la infraestructura que rodea al modelo; ATLAS cubre el modelo. Un ataque serio contra la IA suele recorrer los dos caminos.

Dentro de la matriz MITRE ATLAS: las 16 tácticas

La matriz se lee mejor como un ciclo de vida. El adversario empieza por el reconocimiento (estudia su modelo, su API, su documentación pública), atraviesa el desarrollo de recursos y el acceso inicial, y luego alcanza las fases propias de la IA: acceso al modelo, preparación del ataque, ejecución, persistencia, exfiltración e impacto. Cada táctica agrupa técnicas que describen un movimiento concreto. Cuatro familias de técnicas importan de forma especial para la gobernanza, porque se solapan con riesgos expresamente nombrados por la normativa:

• Envenenamiento de datos. Manipular los datos de entrenamiento para que el modelo aprenda lo equivocado, ya sea una puerta trasera oculta o una degradación general de la precisión.
• Evasión de modelos (ejemplos adversarios). Construir entradas pensadas para que un modelo en producción cometa un error, por ejemplo una imagen alterada de forma imperceptible o una instrucción de elusión que derrota a un filtro de seguridad.
• Extracción e inversión de modelos. Interrogar un modelo hasta poder reconstruirlo o recuperar los datos confidenciales con los que se entrenó: un ataque a la confidencialidad.
• Inyección de instrucciones y jailbreaks. Secuestrar un modelo de lenguaje o un agente de IA mediante instrucciones hostiles ocultas en el contenido que procesa.

Estas familias se alinean con nitidez con la taxonomía oficial estadounidense. El NIST AI 100-2 E2025, taxonomía federal del aprendizaje automático adversario, clasifica los ataques a la IA predictiva en evasión, envenenamiento y privacidad, y los ataques a la IA generativa en inyección de instrucciones, jailbreaks y compromiso de la cadena de suministro. ATLAS aporta las técnicas probadas sobre el terreno; el NIST aporta la terminología formal. Usarlos juntos ofrece tanto el qué como el cómo.

ATLAS, el OWASP LLM Top 10 y el NIST AI RMF

Una de las preguntas más frecuentes es cómo se relaciona ATLAS con los demás marcos de seguridad y gobernanza de la IA. La respuesta breve es que operan a alturas distintas y se diseñaron para usarse juntos.

• MITRE ATLAS es un modelo del adversario. Responde a «¿cómo atacaría alguien este sistema?» y sirve para el modelado de amenazas, el red teaming y la ingeniería de detección.
• El OWASP LLM Top 10 es un modelo de vulnerabilidades. Responde a «¿qué suele fallar en las aplicaciones LLM?» (inyección de instrucciones, gestión insegura de salidas, envenenamiento de datos de entrenamiento) y sirve para el desarrollo seguro y la revisión de código.
• El NIST AI RMF es un modelo de gobernanza. Sus cuatro funciones (Gobernar, Mapear, Medir y Gestionar) responden a «¿cómo supervisa nuestra organización el riesgo de la IA?» y se dirigen a responsables de riesgo y cumplimiento.

Son capas, no alternativas: la amenaza (ATLAS), la debilidad que explota (OWASP) y la supervisión que decide qué hacer (NIST). El motivo práctico es el coste. Según el análisis de la matriz publicado por Vectra, cerca del 70 % de las mitigaciones de ATLAS se corresponden con controles de seguridad que las organizaciones ya operan. Rara vez se parte de cero: se enlaza una amenaza de IA con un control que ya se posee y se demuestra el vínculo. Los recursos de gobernanza de AI Sigil tratan los tres marcos como una sola pila coherente y no como listas rivales.

Por qué MITRE ATLAS importa para el cumplimiento, no solo para la seguridad

Aquí está el punto que la mayoría de las presentaciones de ATLAS omite. Suele presentarse como una herramienta para el centro de operaciones de seguridad. Para una organización regulada es también un instrumento de cumplimiento, porque los ataques que cataloga son los ataques que la ley ahora nombra. El artículo 15 del Reglamento europeo de IA exige que los sistemas de IA de alto riesgo alcancen «un nivel adecuado de precisión, solidez y ciberseguridad». En el apartado 5 va más lejos: tales sistemas «serán resistentes frente a los intentos de terceros no autorizados de alterar su uso, salidas o funcionamiento aprovechando vulnerabilidades del sistema». El mismo apartado nombra después las amenazas por categoría. Las soluciones técnicas deben, cuando proceda, abordar los «ataques que traten de manipular el conjunto de datos de entrenamiento (envenenamiento de datos) o los componentes preentrenados utilizados en el entrenamiento (envenenamiento de modelos), las entradas diseñadas para que el modelo de IA cometa errores (ejemplos adversarios o evasión de modelos), los ataques a la confidencialidad o los defectos del modelo». Vuelva a leer esa lista junto a las familias de técnicas de ATLAS anteriores: son las mismas amenazas. El Reglamento enuncia la obligación; ATLAS aporta el catálogo operativo que permite demostrar cómo la cumple. Cuando un evaluador pregunta cómo aborda los ejemplos adversarios o el envenenamiento de datos, «hemos enlazado las técnicas pertinentes de ATLAS con controles y las hemos probado» pesa mucho más que una declaración de principios. La misma lógica vale hacia arriba: el código de buenas prácticas para los modelos de IA de uso general espera pruebas adversarias para los modelos con riesgo sistémico, y ATLAS es una fuente natural de casos de prueba. En España esta expectativa prolonga criterios que la AEPD y la AESIA ya promueven en materia de solidez y seguridad de los sistemas. Es precisamente ese cambio de enfoque lo que marca la diferencia. ATLAS no es solo un modo de detectar ataques: es un modo de demostrar que los anticipó.

Poner ATLAS en funcionamiento dentro de un programa de gobernanza de la IA

Llevar ATLAS del póster de referencia a una pieza operativa de la gobernanza se reduce a una cadena: amenaza, control, prueba. Amenaza. Para cada sistema de IA de su inventario, seleccione las técnicas de ATLAS que realmente aplican. Un asistente LLM expuesto al público se enfrenta a la inyección de instrucciones y a los jailbreaks; un modelo antifraude entrenado con datos de terceros se enfrenta al envenenamiento; un modelo expuesto mediante una API se enfrenta a la extracción. No necesita las 84 técnicas, solo aquellas que su arquitectura invita. Control. Enlace cada técnica seleccionada con un control de sistema. Como la mayoría de las mitigaciones de ATLAS se corresponden con controles de seguridad existentes, suele tratarse de vincular una amenaza de IA con la gestión de accesos, la validación de entradas, la monitorización, las verificaciones de la cadena de suministro o las pruebas de red team que ya puede exhibir. Donde persista una brecha real, acaba de identificar un control que construir. Prueba. Adjunte la demostración de que el control funciona: un informe de red team contra la técnica, el resultado de una prueba de detección de envenenamiento, un registro de accesos, una aprobación firmada. Es lo que convierte un control declarado en un artefacto de auditoría. Esa cadena es exactamente lo que piden las funciones Medir y Gestionar del NIST AI RMF, y concuerda con los controles del anexo A de la norma ISO 42001, el estándar certificable de sistema de gestión de la IA. Además aclara las responsabilidades: conforme al Reglamento de IA, el proveedor responde de la solidez integrada en el modelo, mientras que el responsable del despliegue responde de las condiciones de uso; una misma técnica de ATLAS puede, por tanto, generar obligaciones para ambas partes. Una plataforma como AI Sigil sirve precisamente para custodiar esa correspondencia (amenazas, controles, pruebas y obligaciones) en un solo lugar, de modo que la cadena siga siendo auditable en vez de reconstruirse de memoria el día de la evaluación.

Cómo empezar con MITRE ATLAS

No hace falta un programa enorme para empezar. Una primera pasada se ve así:

1. Inventaríe sus sistemas de IA y anote, para cada uno, el tipo de modelo, las fuentes de datos y el modo de exposición.
2. Para cada sistema, preseleccione las técnicas de ATLAS plausibles según esa arquitectura.
3. Evalúe su cobertura de controles actual frente a esa preselección y registre dónde es sólido y dónde está expuesto.
4. Priorice las brechas por impacto, empezando por los sistemas de alto riesgo según el Reglamento de IA o críticos para el negocio.
5. Documente las pruebas de los controles que ya funcionan, para no perder nada antes de la próxima auditoría.
6. Revise cada trimestre, porque ATLAS es un marco vivo y su parque de modelos cambia.

Para los equipos regulados, añada una columna al ejercicio: la obligación que cada técnica ayuda a satisfacer. Ese único vínculo, de la técnica de ATLAS al deber normativo, es lo que convierte una lista de seguridad en gobernanza.

Preguntas frecuentes

¿Qué es MITRE ATLAS? MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) es una base de conocimiento abierta y viva de las tácticas y técnicas que emplean los atacantes contra los sistemas de IA, basada en observaciones reales y demostraciones de red team. La matriz actual reúne 16 tácticas y 84 técnicas, organizadas como MITRE ATT&CK pero centradas en el aprendizaje automático. ¿Qué diferencia hay entre MITRE ATLAS y MITRE ATT&CK? ATT&CK describe los ataques a los sistemas informáticos tradicionales (puestos, redes, identidades). ATLAS describe los ataques a los propios sistemas de IA: el modelo, sus datos de entrenamiento y su canal de inferencia. ATLAS reutiliza la estructura de ATT&CK y comparte algunas tácticas, pero añade técnicas propias de la IA como el envenenamiento de datos, la evasión de modelos y la extracción de modelos. ¿Qué diferencia hay entre MITRE ATLAS y el OWASP LLM Top 10? Resuelven problemas distintos. ATLAS es un modelo del adversario que se usa para el modelado de amenazas y el red teaming. El OWASP LLM Top 10 es una lista de las vulnerabilidades más comunes en las aplicaciones LLM, que se usa para el desarrollo seguro. ATLAS dice cómo podrían atacarle; el OWASP dice dónde suelen estar las debilidades. Son complementarios. ¿Cuántas tácticas tiene MITRE ATLAS? En la versión 5.4.0 (febrero de 2026), la matriz ATLAS reúne 16 tácticas, además de 84 técnicas, 56 subtécnicas, 32 medidas de mitigación y 42 casos de estudio. Las fuentes que citan 14 tácticas son anteriores a las actualizaciones recientes: compruebe siempre la matriz actualizada en atlas.mitre.org. ¿Exige el Reglamento europeo de IA el uso de MITRE ATLAS? El Reglamento no nombra a ATLAS, por lo que no es obligatorio. Sin embargo, el artículo 15 exige que los sistemas de alto riesgo sean resistentes al envenenamiento de datos, al envenenamiento de modelos, a los ejemplos adversarios y a los ataques a la confidencialidad, es decir, exactamente las amenazas que ATLAS cataloga. ATLAS es una forma práctica de ordenar y demostrar las soluciones técnicas esperadas. ¿Qué relación hay entre MITRE ATLAS y el NIST AI RMF? Actúan a niveles distintos. ATLAS es un catálogo de amenazas; el NIST AI RMF es un marco de gobernanza articulado en torno a Gobernar, Mapear, Medir y Gestionar. En la práctica, ATLAS alimenta las funciones Medir y Gestionar: aporta las amenazas concretas que usted evalúa y trata, mientras que el RMF aporta la estructura de supervisión a su alrededor.

Conclusión

La mayoría de los equipos conoce MITRE ATLAS como un artefacto de seguridad, una matriz de ataques que el red team estudia. Esa visión es correcta pero incompleta. Para cualquier organización que opere IA bajo regulación, ATLAS es el puente entre dos mundos que suelen hablarse de espaldas: el equipo de seguridad que sabe cómo se ataca la IA y el equipo de cumplimiento que debe demostrar que el sistema es sólido. Sus técnicas son las amenazas nombradas por el Reglamento de IA hechas concretas, y enlazarlas con controles y pruebas es exactamente lo que una auditoría quiere ver. Empiece en pequeño, con un sistema y sus técnicas plausibles, y amplíe el mapa desde ahí. Para que ese mapa viva en un único lugar auditable, descubra cómo AI Sigil conecta amenazas, controles y obligaciones de la IA.