MITRE ATLAS
ATLAS describe lo que hace un adversario para envenenar el dato de entrenamiento, copiar el modelo, sortear las barreras y hacer que el sistema entregue lo que no debería. Es el vocabulario que falta en la mayor parte de las evaluaciones de seguridad de IA que se venden hoy, que terminan en un informe sobre la aplicación web que sirve el modelo.
MITRE ATLAS es la base de conocimiento que describe los ataques dirigidos a sistemas de inteligencia artificial, mantenida por MITRE. DM11 evalúa tus sistemas de IA contra las técnicas del catálogo, prueba el modelo y la cadena de datos junto con la aplicación que los expone, y entrega el resultado con la prueba de lo que fue posible hacer. Cuando el objetivo también incluye un documento para enviar a un cliente o a un regulador, el camino es la certificación ISO/IEC 42001, y la evidencia producida aquí entra entera en ese proyecto.
Quién conduce la evaluación
CEH, Certified Ethical Hacker por EC-Council
SYCP y SYES, certificaciones ofensivas de Solyd
CISA, auditoría de sistemas de información
17 años de gobernanza, riesgos y cumplimiento
QUÉ ES
ATLAS es la sigla de Adversarial Threat Landscape for AI Systems, el panorama de amenazas adversarias a sistemas de inteligencia artificial que MITRE mantiene en abierto. Reaprovecha la estructura de MITRE ATT&CK, el catálogo de tácticas y técnicas de adversario que la misma organización mantiene para sistemas corporativos, y la aplica a lo que ATT&CK deja fuera: el modelo, el dato que lo entrenó y la cadena que lleva uno al otro. En la distribución de junio de 2026 son 16 tácticas, 103 técnicas de primer nivel más otras 70 subtécnicas, 35 mitigaciones y 63 estudios de caso.
Envenenar el dato de entrenamiento para que el modelo aprenda mal a propósito. Publicar un conjunto de datos o un modelo ya contaminado para que alguien lo descargue. Extraer el modelo con consultas repetidas hasta reconstruir una copia utilizable. Inferir si un registro específico estuvo en el conjunto de entrenamiento, lo que en una base de salud o de crédito es una fuga de dato personal sin que salga ningún archivo. Manipular la entrada hasta que el modelo clasifique mal, que es como se sortea un detector. Ninguna de esas técnicas aparece en una prueba de infraestructura, porque ninguna depende de una falla de infraestructura.
Además de las tácticas heredadas de ATT&CK, ATLAS tiene dos propias: acceso al modelo y preparación del ataque de IA. La primera reconoce que el grado de acceso lo cambia todo, y va desde conocer solo la aplicación hasta tener el archivo del modelo en la mano, pasando por el acceso por consulta, que es el caso de la mayoría. La segunda describe el trabajo que el adversario hace antes de atacar, como entrenar un modelo aproximado para ensayar contra él y llegar al objetivo con el ataque ya calibrado. Ese ensayo es invisible para quien monitorea solo el tráfico de la aplicación.
Son 63, y es lo que separa a ATLAS de una lista de amenazas imaginadas. Están documentados allí, con el objetivo y quién lo ejecutó, casos de evasión de detectores de malware basados en aprendizaje automático, envenenamiento de un chatbot público, réplica de un modelo de lenguaje por consultas, inyección indirecta de instrucción en un asistente corporativo con acceso a correo y a documentos, elusión de verificación de identidad por video sintético y extracción de un modelo embebido en una aplicación de celular. El catálogo se actualiza en cadencia casi mensual, lo que lo vuelve más parecido a un boletín de amenazas que a una norma.
Conviene alinear la expectativa temprano, porque cambia la planificación. Lo que la evaluación produce es un mapa de cobertura, técnica por técnica, que dice qué se intentó, qué funcionó y con qué evidencia. MITRE publica el catálogo y no acredita evaluadores, así que no existe un sello ATLAS para emitir ni un organismo que verifique el tuyo. Cuando tu cliente o tu regulador necesita un documento firmado por un tercero, quien responde es la certificación ISO/IEC 42001, y el resultado de esta evaluación entra allí como la evidencia técnica que el auditor va a pedir.
QUIÉN SUELE NECESITARLO
Las tres llegan por el mismo camino: hay IA en producción, hay alguna verificación de seguridad hecha, y nadie puede decir si el modelo en sí fue probado alguna vez.
La empresa contrató una prueba de intrusión en la aplicación de IA y recibió un informe competente sobre autenticación, sesión, permisos y configuración de servidor. Nada de eso responde si es posible extraer el modelo por consulta, envenenar el próximo ciclo de entrenamiento o hacer que el sistema revele la instrucción que lo gobierna. Son preguntas distintas, con método distinto, y casi ningún alcance de pentest estándar las incluye.
El asistente dejó de solo responder y pasó a consultar la base interna, abrir tickets, leer la bandeja de entrada y ejecutar acciones en sistemas. A partir de ahí, una instrucción escondida en un documento que envió un tercero se vuelve un camino de ejecución, y el contenido que entra en el contexto del modelo pasa a tener el mismo peso de seguridad que una entrada de usuario. Es la categoría de incidente que más crece en los propios estudios de caso de ATLAS.
El proyecto de ISO/IEC 42001 avanzó, o el NIST AI RMF, el framework de gestión de riesgo de IA del instituto americano de estándares, se adoptó como método, y llegó el momento de responder qué amenazas concretas enfrenta cada sistema. Sin un catálogo de técnicas detrás, esa parte se convierte en una planilla de riesgos genéricos que nadie puede probar ni cerrar. ATLAS es la lista que transforma un riesgo declarado en una amenaza verificable.
HISTORIAS
Cambiamos los nombres de los clientes con el mismo sigilo que protegerá a tu empresa después. Los nombres cambian, el patrón de los problemas se repite. Cuando el cliente lo autoriza, damos referencias con nombre en una conversación.
Salud privada
Un asistente interno respondía dudas del equipo de atención consultando la base de documentos de la aseguradora, y esa base recibía archivos enviados por prestadores externos. La prueba de seguridad hecha seis meses antes había cubierto el portal, la autenticación y la infraestructura, y pasó limpia. Nadie había mirado qué ocurre cuando el texto de un documento llega al modelo.
Reprodujimos la técnica de inyección indirecta de instrucción de ATLAS: dentro de un documento común colocamos un pasaje dirigido al modelo y no al lector humano. Después seguimos el camino hasta el final, probando qué podía buscar y devolver el asistente a partir de ahí, y por dónde salía la respuesta de la empresa.
El asistente cumplía la instrucción escondida y traía pasajes de documentos de otros prestadores a la misma conversación. La corrección entera cayó fuera del servidor: separar el contenido de terceros del contenido confiable, restringir qué puede buscar el asistente por sesión y registrar cada recuperación, para que el próximo intento deje rastro.
Tecnología y software
Una empresa de software exponía, dentro de su producto, un modelo de clasificación entrenado con años de dato propio. Era el principal activo del negocio. El acceso era autenticado y se cobraba por uso, y la percepción era que con eso bastaba, porque cada consulta tenía dueño y había un límite de solicitudes por minuto.
Aplicamos la técnica de extracción de modelo de ATLAS desde una cuenta legítima de cliente: consultas construidas para maximizar información por llamada, dentro del límite contratado, a lo largo de días. Entrenamos un modelo aproximado con las respuestas y medimos cuánto coincidía con el original.
El modelo aproximado reproducía la decisión del original en la mayoría de los casos, con un volumen de consultas que cabía holgado en el plan contratado. El límite por minuto nunca se tocó, porque este ataque trabaja por paciencia y no necesita volumen. La defensa pasó a mirar el patrón de consultas a lo largo del tiempo, y la dirección pasó a tratar el modelo como propiedad intelectual con control de acceso, y no como una funcionalidad.
Telecomunicaciones
Un modelo de priorización de atención se reentrenaba periódicamente con el historial de tickets, incluido el texto libre que escribía quien abría el ticket y la categoría que el propio cliente marcaba. El ciclo era automático y nadie revisaba qué entraba. La conversación sobre seguridad de IA en la empresa estaba concentrada por completo en la aplicación que servía el modelo.
Mapeamos la cadena de datos desde el punto de entrada hasta el entrenamiento y probamos el envenenamiento en el origen, con un volumen pequeño de registros construidos para desplazar la decisión del modelo en una franja específica. Después medimos el efecto en un ambiente de prueba, con el mismo procedimiento de reentrenamiento que corre en producción.
Una fracción pequeña de los registros del ciclo ya alcanzaba para cambiar la prioridad de una categoría entera de tickets, y nada en ese proceso disparaba una alerta. Entraron validación y límite de influencia por origen, revisión por muestreo de lo que entra al entrenamiento, y comparación del modelo nuevo con el anterior antes de la publicación, que se volvió el paso que frena el ciclo cuando algo se desplaza.
CÓMO LO CONDUCIMOS
La evaluación vale por lo que logra demostrar. Una técnica de ATLAS aquí se marca como intentada, exitosa o no aplicable, con la prueba adjunta y el camino reproducible, porque parecer inseguro y ser demostrablemente inseguro llevan a decisiones de inversión distintas.
Relevamos qué sistemas de IA existen, oficiales y no oficiales, qué decide o automatiza cada uno, de dónde viene el dato que lo entrena o alimenta la respuesta, y a qué tiene acceso después de responder. Sin ese dibujo, cualquier prueba se vuelve un ejercicio sobre la pantalla.
Inventario de sistemas y casos de uso de IA, con dueño por ítem
Origen del dato de entrenamiento y del contenido consultado en producción
Herramientas, integraciones y permisos que el modelo acciona
Grado de acceso disponible para la prueba, acordado con la dirección
Hito de entregaCadena dibujada desde el dato de origen hasta la acción que el sistema ejecuta.
No toda técnica del catálogo tiene sentido para todo diseño, y probarlas todas es la forma más cara de descubrirlo. Seleccionamos las técnicas pertinentes a tu tipo de modelo, a tu grado de exposición y al acceso que tendría un adversario realista, y sometemos la lista a tu aprobación antes de ejecutar cualquier cosa.
Modelado de amenazas por sistema, mapeado a las tácticas de ATLAS
Lista de técnicas seleccionadas, con justificación de inclusión y de exclusión
Reglas de compromiso, ventana de ejecución y criterio de parada
Autorización formal, incluido lo que permite el contrato del proveedor del modelo
Hito de entregaAlcance aprobado, con cada técnica seleccionada rastreada al identificador del catálogo.
Probamos el modelo, el contenido que llega hasta él, el punto donde entra el dato de entrenamiento y las herramientas que acciona, junto con la aplicación y la infraestructura alrededor. Es la etapa en que la diferencia entre este trabajo y una prueba de aplicación aparece por entero.
Intentos de evasión, extracción, inferencia sobre el entrenamiento y elusión de barreras
Inyección de instrucción por contenido de terceros, hasta la acción que el modelo ejecuta
Prueba de envenenamiento en el punto de entrada del dato, en ambiente controlado
Prueba reproducible para cada técnica exitosa
Hito de entregaCada técnica ejecutada con resultado registrado y camino reproducible.
El mapa técnico solo no sostiene una decisión de inversión. Ligamos cada hallazgo a la mitigación correspondiente del catálogo y al control de gobernanza que tu empresa ya usa, para que el asunto llegue a la dirección en el vocabulario que ella sigue. Después de las correcciones, repetimos las mismas técnicas con el mismo método.
Hallazgos ligados a las mitigaciones de ATLAS y a los controles de ISO/IEC 42001
Informe ejecutivo en lenguaje de negocio, con riesgo y esfuerzo separados
Plan de corrección con responsable y fecha por hallazgo
Nueva prueba de las técnicas exitosas, comparable a la ejecución inicial
Hito de entregaCorrecciones demostradas con la repetición de las técnicas que habían funcionado.
CUÁNTO TIEMPO LLEVA
No publicamos plazo estándar, porque plazo publicado se convierte en promesa. El inventario suele ser la parte corta cuando alguien ya sabe qué existe, y larga cuando nadie lo sabe. Estos son los tres factores que más mueven el reloj, y la primera conversación ya muestra en cuál está tu empresa.
Una empresa con inventario de usos de IA empieza a modelar amenazas en la primera semana. Una empresa sin inventario pasa el inicio descubriendo qué ya está en producción, y ese descubrimiento casi siempre incluye usos que el área de tecnología nunca aprobó.
Probar solo por la aplicación, como haría alguien de afuera, es más rápido y ve menos. Tener acceso al modelo, al conjunto de entrenamiento y a la cadena de publicación permite cubrir las técnicas de envenenamiento y de cadena de suministro, que son las más caras de descubrir después. La elección es de alcance y de presupuesto, y se toma contigo antes de empezar.
Con modelo propio, casi todo el catálogo se aplica. Con modelo de tercero consumido por interfaz de programación, buena parte de la prueba se concentra en el contexto, en las herramientas y en las barreras que tú controlas, y lo que puede probarse en el modelo mismo depende de lo que autoriza el contrato del proveedor. Esa lectura del contrato entra temprano, porque suele ser la que más atrasa.
PREGUNTAS FRECUENTES
Las dudas que aparecen en casi toda primera reunión, respondidas sin rodeos.
No. MITRE publica y mantiene el catálogo en abierto, y no acredita evaluadores ni emite sellos, para ninguna empresa. Quien ofrece un certificado ATLAS está vendiendo otra cosa. Lo que existe es el informe de evaluación, con el mapa de cobertura por técnica y la prueba detrás, y se acepta como evidencia técnica dentro de un proyecto de ISO/IEC 42001, que es la norma de IA que rinde un certificado emitido por un tercero.
Empezamos por el inventario de lo que ya está en producción y por la selección de las técnicas de ATLAS que tienen sentido para tu diseño. El resultado es un mapa de qué se intentó, qué funcionó y qué hacer primero, en el lenguaje que la dirección sigue.