Los equipos que ya trabajan con MITRE ATT&CK suelen hacer la misma pregunta cuando aparece el primer sistema de IA en producción: dónde encaja esto en la matriz. La respuesta corta es que no encaja, y que existe una matriz aparte para eso. Se llama ATLAS, la mantiene la misma organización y su valor no está en el catálogo de técnicas sino en la estructura que impone al razonamiento.
Esa distinción importa más de lo que parece. La mayoría de los modelados de amenazas sobre IA que revisamos son listas de preocupaciones sin orden: una mezcla de riesgos técnicos, éticos y reputacionales que nadie sabe cómo priorizar. ATLAS aporta lo que faltaba, que es un eje sobre el cual ordenarlas.
Qué es ATLAS y qué no es
ATLAS es una base de conocimiento pública sobre tácticas y técnicas adversariales dirigidas a sistemas de aprendizaje automático e IA. Reproduce deliberadamente el formato de ATT&CK: tácticas como columnas, técnicas como celdas, y estudios de caso que muestran secuencias concretas. La familiaridad del formato es intencional y es su principal ventaja práctica, porque el equipo de seguridad no tiene que aprender un vocabulario nuevo para empezar a usarlo.
Conviene entender también qué no es. No es un estándar de cumplimiento: no hay nada que certificar ni cláusulas que citar. No es una lista de controles, aunque cada técnica sugiere las mitigaciones asociadas. Y no todo su contenido proviene de incidentes observados en entornos reales: una parte relevante procede de investigación académica y de ejercicios de red team documentados. Eso no le resta valor, pero cambia cómo se debe leer. Una técnica presente en la matriz indica que el ataque es viable, no que sea frecuente en tu sector.
En qué se diferencia de ATT&CK
ATT&CK describe cómo un adversario compromete infraestructura informática: obtiene acceso inicial, ejecuta código, escala privilegios, se mueve lateralmente, exfiltra. Los activos son equipos, cuentas y redes. ATLAS conserva ese esqueleto porque un ataque real casi siempre lo atraviesa —para envenenar un conjunto de datos hay que acceder primero al repositorio donde vive—, pero incorpora tácticas cuyo objetivo es el sistema de IA en sí.
Las diferencias sustantivas están en tres lugares. El primero es el reconocimiento: al adversario le interesa averiguar qué modelo hay detrás, cómo fue entrenado y qué defensas tiene, y buena parte de eso se obtiene consultando el sistema desde fuera. El segundo es la preparación del ataque, una fase sin equivalente en el mundo tradicional, en la que el atacante construye un modelo sustituto o elabora las entradas adversariales que va a usar. El tercero es el objetivo final: además de datos y accesos, aparecen activos que ATT&CK no contempla, como los pesos del modelo, el conjunto de entrenamiento o la integridad de las predicciones.
Un ataque contra un sistema de IA rara vez es solo un ataque de IA: casi siempre empieza con técnicas convencionales y termina en un activo que la matriz convencional no describe.
Cómo leer la matriz sin perderse
La confusión más común es tratar las tácticas como categorías de riesgo. No lo son. Una táctica es el objetivo intermedio del adversario, el porqué de un paso: quiere entender el sistema, quiere acceso, quiere persistir, quiere evadir la defensa, quiere sacar algo. Una técnica es una manera concreta de conseguirlo, el cómo.
De ahí se sigue la forma correcta de leerla, que es por columnas y en secuencia aproximada, no celda por celda. Un ejercicio útil consiste en recorrer las tácticas de izquierda a derecha preguntando, para cada una, qué haría un atacante contra tu sistema en ese punto y qué se lo impediría. Muchas celdas simplemente no aplicarán, y descartarlas de forma explícita es parte del trabajo: un descarte razonado y documentado vale más que una celda marcada en verde.
Cómo ordenar un modelado de amenazas con esta estructura
Un ejercicio de dos o tres sesiones, con el equipo de producto en la sala, suele bastar para el primer sistema.
- Delimita el sistema y sus activos. Escribe qué modelo se usa y de dónde viene, qué datos lo alimentan, quién puede consultarlo, qué herramientas puede invocar y qué artefactos existen —pesos, conjuntos de ajuste, índices vectoriales, prompts de sistema—. Sin este paso, el recorrido por las tácticas se vuelve especulativo.
- Recorre las tácticas como preguntas, no como listas. Para cada objetivo adversarial, plantea quién tendría ese objetivo contra tu sistema en particular. Un clasificador interno sin exposición externa y un asistente público tienen adversarios distintos y descartan columnas distintas.
- Retén solo las técnicas plausibles según tu construcción. Si consumes un modelo por API, las técnicas de manipulación de pesos son irrelevantes y las de consulta abusiva son centrales. Si entrenas con datos aportados por usuarios, ocurre lo contrario. Deja constancia del criterio de descarte.
- Asocia cada técnica retenida a un control y a una prueba. El control responde qué lo dificulta; la prueba responde cómo sabrías que el control funciona. Sin la segunda columna, el ejercicio produce un documento y no una mejora. Ese es además el insumo natural para un primer ejercicio de red teaming, porque convierte el listado en casos ejecutables.
El resultado no es una matriz completa ni conviene que lo sea. Es un conjunto acotado de escenarios que tu organización considera creíbles, cada uno con su control y su forma de verificarlo, y con un registro de lo que se descartó y por qué. Ese documento envejece bien: cuando cambie el modelo, se conecte una herramienta nueva o el sistema pase de interno a público, basta con revisar qué descartes dejaron de ser válidos. Ese es el uso real de ATLAS, y es bastante más valioso que tenerlo como referencia bibliográfica en una presentación. Si buscas un punto de partida más liviano, los controles básicos de un trimestre cubren las técnicas más frecuentes sin necesidad de recorrer la matriz completa.