Cuando alguien te pida «revisa la seguridad de este chatbot» o «monta el modelo de amenaza de este agente», la primera pregunta útil no es por dónde empezar a atacar, sino qué documento ya resuelve parte del trabajo por ti. Existen media docena de marcos que cubren piezas distintas del mismo problema, los mantienen organizaciones distintas, con calendarios de actualización distintos, y hoy en día es fácil citar una versión vieja sin darte cuenta porque el documento que Google te devuelve primero no siempre es el vigente.
Este módulo no explica todavía ningún ataque en detalle: eso empieza en el módulo 3. Aquí construyes el mapa de qué documento consultar según la pregunta que tengas, con qué versión exacta trabajar hoy, y cómo se combinan cuando tienes que entregar un informe real. Cada marco que aparece aquí vuelve a aparecer, con desarrollo completo, en los módulos siguientes de este curso.
Qué aprenderás
- Los diez riesgos del OWASP Top 10 for LLM Applications 2025, con su identificador exacto, su nombre en inglés y su denominación en la traducción oficial al español.
- Qué cambió entre la edición de 2023 y la de 2025, y por qué entraron la fuga del prompt de sistema y las debilidades de vectores y embeddings.
- Qué añade el Top 10 de aplicaciones agénticas de 2026 de OWASP sobre el Top 10 de aplicaciones LLM, y por qué solo existe en PDF.
- Cómo está organizado MITRE ATLAS (tácticas, técnicas, mitigaciones, casos de estudio), en qué se parece a ATT&CK y cómo consultarlo sin depender de su web.
- El vocabulario y la estructura de la taxonomía de aprendizaje automático adversario de NIST, y la diferencia entre sistemas predictivos y generativos.
- Para qué sirven el NIST AI RMF, su perfil de IA generativa y la extensión SP 800-218A del desarrollo seguro de software.
- Qué cubren las guías conjuntas de NCSC y CISA sobre desarrollo seguro de sistemas de IA, fase a fase.
- La estructura general de ISO/IEC 42001 y para qué sirve certificarse, sin entrar en el contenido de pago de sus controles.
- Cómo se combinan estos marcos en un mismo informe real, y a qué pregunta responde cada uno.
El OWASP Top 10 for LLM Applications 2025
El proyecto que hoy se llama OWASP GenAI Security Project empezó en 2023 como el «OWASP Top 10 for Large Language Model Applications». La lista se revisó completa en 2024 y se publicó como versión 2025 el 18 de noviembre de 2024 en inglés; la traducción oficial al español, firmada por un equipo de tres traductores humanos (Sebastián Passaro, Pablo Alzuri y Cecilia Belón, con Talesh Seeparsan como líder de traducción), salió el 11 de marzo de 2025 bajo el título «Top 10 2025 de riesgos y mitigaciones para LLMs y aplicaciones de IA Generativa». Los diez riesgos, con su nombre oficial en cada idioma, son estos.
| Identificador | Nombre en inglés | Nombre en la traducción oficial al español |
|---|---|---|
| LLM01:2025 | Prompt Injection | Inyección de prompt |
| LLM02:2025 | Sensitive Information Disclosure | Divulgación de información sensible |
| LLM03:2025 | Supply Chain | Cadena de suministro |
| LLM04 | Data and Model Poisoning | Envenenamiento de datos y modelo |
| LLM05:2025 | Improper Output Handling | Manejo inadecuado de la salida |
| LLM06:2025 | Excessive Agency | Agencia excesiva |
| LLM07:2025 | System Prompt Leakage | Filtración de prompts de sistema |
| LLM08:2025 | Vector and Embedding Weaknesses | Debilidades de vector y representaciones vectoriales |
| LLM09:2025 | Misinformation | Desinformación |
| LLM10:2025 | Unbounded Consumption | Consumo ilimitado |
LLM04 aparece así en el propio documento oficial, en inglés y en español: sin el sufijo «:2025» que llevan los otros nueve. No es un error de transcripción de este módulo, es una inconsistencia del propio índice y de los encabezados de esa entrada dentro del PDF original. Vale la pena mencionarlo porque es justo el tipo de detalle que un resumen de tercero suele «corregir» sin decirlo, y entonces citas un identificador que nunca existió tal cual en la fuente.
Con el identificador de cada riesgo puesto, esto es lo que cubre cada uno en dos o tres frases; el desarrollo completo de cada uno llega en un módulo posterior de este curso, así que aquí no hay ejemplos de ataque ni listas de mitigación.
LLM01:2025 Inyección de prompt
Ocurre cuando una entrada, escrita por quien conversa con el modelo o incrustada en contenido externo que el modelo procesa, altera su comportamiento de forma no prevista por quien construyó la aplicación. El módulo 3 de este curso lo desarrolla entero, con sus variantes directa e indirecta.
LLM02:2025 Divulgación de información sensible
Cubre la exposición de datos personales, credenciales, algoritmos propietarios o información comercial confidencial a través de la salida del modelo, ya sea porque entraron en su entrenamiento o porque están disponibles en el contexto de la conversación.
LLM03:2025 Cadena de suministro
Trata las vulnerabilidades que llegan desde fuera: modelos preentrenados de terceros, conjuntos de datos, adaptadores de fine-tuning como LoRA, o paquetes de software que la aplicación importa sin verificar su procedencia.
LLM04 Envenenamiento de datos y modelo
Se produce cuando los datos de preentrenamiento, de ajuste fino o los embeddings se manipulan para introducir sesgos, puertas traseras o vulnerabilidades que después condicionan el comportamiento del modelo en producción.
LLM05:2025 Manejo inadecuado de la salida
Aborda qué pasa cuando la salida de un modelo se pasa a otro componente (un navegador, una consulta a base de datos, un intérprete de comandos) sin la validación o el saneamiento que se le exigiría a cualquier otra entrada no confiable. El módulo 4 de este curso lo desarrolla entero.
LLM06:2025 Agencia excesiva
Cubre los daños que puede causar un modelo o un agente al que se le concedieron más permisos, funciones o autonomía de los necesarios para su tarea. Es la entrada que más ha crecido en la edición de 2025 por el auge de los agentes, y tiene su desarrollo completo en el módulo 6.
LLM07:2025 Filtración de prompts de sistema
Trata el riesgo de que el prompt de sistema, que a menudo contiene reglas de negocio o incluso credenciales, se filtre al usuario a través de la conversación, dejando al descubierto información que se asumía secreta sin serlo realmente.
LLM08:2025 Debilidades de vector y representaciones vectoriales
Cubre los riesgos propios de sistemas con recuperación aumentada por contexto (RAG): cómo se generan, almacenan y recuperan los vectores, y cómo un documento manipulado puede acabar influyendo en la respuesta del modelo. El módulo 5 de este curso entra en detalle en las bases vectoriales y el control de acceso al conocimiento recuperado.
LLM09:2025 Desinformación
Aborda las salidas del modelo que parecen creíbles pero son falsas o erróneas, y el daño de reputación, legal o de seguridad que puede causar que un usuario o un sistema automatizado actúe sobre esa información sin verificarla.
LLM10:2025 Consumo ilimitado
Cubre desde la denegación de servicio clásica hasta el abuso de la facturación por uso, la extracción de un modelo a través de consultas repetidas, y cualquier otro escenario en el que la inferencia se consuma sin límite ni control de coste.
Qué cambió respecto a la edición anterior
La carta de los líderes del proyecto en el propio documento de 2025 explica cuatro cambios de fondo, y conviene citarlos con la razón que da el propio proyecto en vez de suponerla.
Consumo ilimitado amplía lo que antes se llamaba «Denegación de servicio» para incluir la gestión de recursos y los costes inesperados, algo que los propios autores describen como un problema apremiante en despliegues de LLM a gran escala. Debilidades de vector y representaciones vectoriales es una entrada nueva por completo, añadida en respuesta a peticiones de la comunidad de orientación específica sobre la seguridad de RAG y otros métodos basados en embeddings, que para 2024 ya eran una práctica habitual para anclar las salidas del modelo a datos concretos. Filtración de prompts de sistema también es nueva: el proyecto reconoce que muchas aplicaciones habían asumido que el contenido del prompt de sistema quedaba aislado de forma segura, y que incidentes reales demostraron que esa suposición no se sostiene. Y Agencia excesiva, que ya existía en la lista anterior, se amplió de forma sustancial por el aumento del uso de arquitecturas de agentes, donde un permiso sin control puede convertirse en una acción no deseada con mucha más facilidad que en un chatbot puramente conversacional.
El patrón que conecta los tres cambios es el mismo: la lista de 2023 describía sobre todo un modelo que conversa, y la de 2025 describe un modelo que recupera contexto externo, guarda secretos en su configuración y a menudo actúa por cuenta propia. Ese mismo patrón es el que explica por qué en diciembre de 2025 OWASP publicó un documento aparte específicamente para aplicaciones agénticas, en vez de seguir ampliando la lista de aplicaciones LLM.
El Top 10 de aplicaciones agénticas 2026
El «OWASP Top 10 for Agentic Applications 2026» lo publicó el 9 de diciembre de 2025 la Agentic Security Initiative del OWASP GenAI Security Project, y a fecha de este módulo solo existe como PDF descargable, sin versión en HTML equivalente a la del Top 10 de aplicaciones LLM. Conviene decirlo así de claro porque la mayoría de resúmenes que circulan sobre este documento están escritos a partir de notas de prensa, no del PDF en sí, y varios de ellos afirman que participaron «más de cien expertos»; la propia carta de los líderes del documento dice, en cambio, que colaboraron «decenas de expertos en seguridad de la industria, la academia y el gobierno», una cifra bastante más modesta que conviene no inflar.
Los diez riesgos, con su identificador ASI, son estos.
| Identificador | Nombre en inglés |
|---|---|
| ASI01 | Agent Goal Hijack |
| ASI02 | Tool Misuse and Exploitation |
| ASI03 | Identity and Privilege Abuse |
| ASI04 | Agentic Supply Chain Vulnerabilities |
| ASI05 | Unexpected Code Execution (RCE) |
| ASI06 | Memory and Context Poisoning |
| ASI07 | Insecure Inter-Agent Communication |
| ASI08 | Cascading Failures |
| ASI09 | Human-Agent Trust Exploitation |
| ASI10 | Rogue Agents |
No hay traducción oficial al español verificada para este documento, así que la tabla se queda en inglés en vez de inventarte una denominación que OWASP no ha publicado.
Lo que añade este listado no es una lista nueva de vulnerabilidades desde cero, es una capa encima de la que ya conoces. El propio documento incluye, en su apéndice A, una matriz que cruza cada entrada ASI con la entrada o entradas del Top 10 de LLM de las que deriva. ASI01 (secuestro del objetivo del agente) combina LLM01 (inyección de prompt) con LLM06 (agencia excesiva): el vector de entrada sigue siendo el mismo texto no confiable del módulo 1 de este curso, lo que cambia es que ahora ese texto puede redirigir un plan de varios pasos en vez de una sola respuesta. ASI03 (abuso de identidad y privilegios) deriva de LLM01, LLM02 y LLM06 a la vez, y trata un problema que no existía tal cual en el Top 10 de aplicaciones LLM: un agente necesita una identidad propia frente a los sistemas con los que interactúa, y sin ella opera en lo que el documento llama un vacío de atribución que hace casi imposible aplicar el mínimo privilegio de verdad. ASI04 (vulnerabilidades de la cadena de suministro agéntica) reconoce que LLM03 ya cubre la cadena de suministro estática, y se centra en lo que un agente añade encima: componentes que se cargan en tiempo de ejecución, como servidores del protocolo de contexto para modelos o registros de descubrimiento de otros agentes, que un chatbot sin agencia nunca llega a tocar. Y ASI08 (fallos en cascada) es, quizás, la entrada más nueva del conjunto: describe cómo un único fallo (una alucinación, una entrada envenenada) se propaga entre agentes que se delegan tareas entre sí, hasta convertirse en un daño de todo el sistema que ningún riesgo individual del Top 10 de LLM llega a describir por sí solo, porque ese Top 10 razona sobre una sola aplicación, no sobre una red de agentes que se llaman entre ellos.
MITRE ATLAS
ATLAS son las siglas de Adversarial Threat Landscape for Artificial-Intelligence Systems. Empezó como el «Adversarial ML Threat Matrix» y se relanzó bajo el nombre ATLAS en junio de 2021. El repositorio de datos del proyecto en GitHub lo describe, en su propio README, como «a public knowledge base of adversary TTPs targeting AI systems» (una base de conocimiento pública de tácticas, técnicas y procedimientos de adversarios dirigidos contra sistemas de IA), y lo posiciona explícitamente como el equivalente de ATT&CK para la seguridad de la inteligencia artificial.
Esa filiación va más allá del nombre: ATLAS reutiliza la misma estructura de matriz que ATT&CK (tácticas arriba, técnicas debajo de cada táctica) y varios de sus nombres de táctica son literalmente los mismos (Reconnaissance, Persistence, Exfiltration, Impact). Quien ya sepa leer una matriz de ATT&CK, cubierta en la guía de MITRE ATT&CK del blog, puede leer ATLAS el primer día sin curva de aprendizaje adicional. Lo que cambia es el objetivo: ATT&CK documenta cómo se compromete infraestructura de TI convencional, y ATLAS documenta cómo se ataca, manipula o abusa un sistema de inteligencia artificial en concreto, desde el robo del propio modelo hasta la inyección de prompt.
Su web pública exige JavaScript para renderizar la matriz, así que no se puede leer con una petición HTTP simple. El propio proyecto publica sus datos completos en un archivo YAML descargable, que es la forma correcta de consultarlo desde un script o desde un entorno sin navegador:
curl -s https://raw.githubusercontent.com/mitre-atlas/atlas-data/main/dist/v6/ATLAS-latest.yamlEse comando, tal como está, no descarga la matriz: el archivo «ATLAS-latest.yaml» no es un compilado completo, es un puntero de una sola línea con el nombre del archivo con la versión vigente en ese momento (algo como ATLAS-2026.06.yaml). Hay que leer esa línea primero y descargar después el archivo al que apunta:
version=$(curl -s https://raw.githubusercontent.com/mitre-atlas/atlas-data/main/dist/v6/ATLAS-latest.yaml)
curl -s -o ATLAS.yaml "https://raw.githubusercontent.com/mitre-atlas/atlas-data/main/dist/v6/$version"El archivo resultante organiza los datos en un puñado de bloques: collection con la cabecera y la versión, tactics, techniques, mitigations, case-studies y relationships. Cada técnica tiene su identificador con el prefijo AML.T, un nombre, una descripción, una fecha de creación y de modificación, y una lista de las plataformas a las que se aplica (el archivo que descargué para este módulo etiqueta las técnicas como «Predictive AI», «Generative AI», «Agentic AI» o «Enterprise», lo que confirma que ATLAS ya cubre de forma explícita el terreno agéntico, no solo el aprendizaje automático clásico). Las subtécnicas comparten el identificador de su técnica padre con un sufijo numérico, por ejemplo AML.T0051.001 para la variante indirecta de la inyección de prompt.
Cualquier cifra de «tácticas y técnicas totales» que leas en un blog de terceros hay que tratarla con sospecha, porque ATLAS cambia con cada actualización y esas cifras quedan desfasadas rápido. La forma correcta de obtenerla es contarla tú mismo en el archivo que acabas de descargar:
import yaml
with open("ATLAS.yaml", encoding="utf-8") as f:
atlas = yaml.safe_load(f)
tecnicas = atlas["techniques"]
principales = [t for t in tecnicas if t.count(".") == 1]
subtecnicas = [t for t in tecnicas if t.count(".") == 2]
print(len(atlas["tactics"]), "tacticas")
print(len(principales), "tecnicas principales")
print(len(subtecnicas), "subtecnicas")
print(len(atlas["mitigations"]), "mitigaciones")
print(len(atlas["case-studies"]), "casos de estudio")En la versión que descargué para escribir este módulo (identificada internamente como 2026.06, con fecha de modificación 2026-05-27), ese script cuenta 16 tácticas, 103 técnicas principales, 70 subtécnicas, 35 mitigaciones y 63 casos de estudio, de los cuales 45 están marcados como ejercicios y 18 como incidentes reales documentados. La cifra de «16 tácticas y 84 técnicas» que circula por artículos de terceros no coincide con lo que devuelve esta versión: puede que fuera correcta en algún momento anterior del proyecto, pero no la des por buena sin volver a contarla tú en la versión que tengas delante.
Los casos de estudio son la parte más útil para escribir un informe de amenazas, porque cada uno enlaza sus pasos a técnicas concretas mediante relaciones tipadas: un caso de estudio «emplea» una técnica en un paso determinado, con una descripción de lo que ocurrió en ese paso. Eso permite citar no solo «esto es una técnica de envenenamiento de datos», sino un incidente o ejercicio real donde esa técnica se usó, con su identificador AML.CS####.
Un detalle que conviene tener presente si citas identificadores de ATLAS junto a documentos de otros proyectos: los nombres cambian con el tiempo. El propio OWASP Top 10 de 2025 cita la técnica AML.T0018 como «Backdoor ML Model»; en la versión de ATLAS que descargué para este módulo, esa misma técnica se llama «Manipulate AI Model». El identificador es estable, el nombre no siempre lo es, así que cuando cites una técnica de ATLAS en un documento propio, cita el identificador y comprueba el nombre en la versión vigente en el momento de escribir, no en la que tenías guardada de una sesión anterior.
NIST AI 100-2 E2025: la taxonomía de aprendizaje automático adversario
NIST AI 100-2e2025, titulado «Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations», lo aprobó el consejo editorial de NIST el 20 de marzo de 2025, con seis autores de NIST, Northeastern University, el U.S. AI Safety Institute, Cisco y el U.K. AI Security Institute. No define controles ni requisitos: define vocabulario, y ese vocabulario es el que vas a encontrar reutilizado en informes, herramientas comerciales y el resto de marcos de este módulo.
Su división principal separa dos familias de sistemas con taxonomías de ataque distintas: la IA predictiva (PredAI), que sigue dominando aplicaciones industriales de clasificación y predicción, y la IA generativa (GenAI). Para PredAI, el documento organiza los ataques en tres categorías con nombre propio: ataques de evasión (manipular una entrada en el momento de la inferencia para que el modelo se equivoque), ataques de envenenamiento (manipular los datos de entrenamiento o el propio modelo, con subtipos como el envenenamiento de disponibilidad, el dirigido y el de puerta trasera) y ataques a la privacidad (reconstrucción de datos, inferencia de pertenencia, inferencia de propiedades y extracción del modelo).
Para GenAI, la taxonomía cambia de forma: en vez de evasión y envenenamiento como bloques separados, el documento agrupa los ataques por el tipo de violación que producen, con un identificador numerado con el prefijo NISTAML. Violaciones de disponibilidad (NISTAML.01), violaciones de integridad (NISTAML.02, que incluye la inyección de prompt directa e indirecta y el envenenamiento de datos), compromisos de privacidad (NISTAML.03, con la extracción del prompt de sistema y la fuga de información de las interacciones del usuario como entradas propias) y violaciones de uso indebido (NISTAML.04), la categoría que recoge lo que en otros documentos se llama abuso: el uso del propio sistema, tal como fue diseñado, para producir un resultado dañino. A esas cuatro se suma una quinta categoría de ataques a la cadena de suministro, compartida entre PredAI y GenAI.
NIST AI RMF y su perfil de IA generativa
El AI Risk Management Framework (AI RMF 1.0) lo publicó NIST en enero de 2023 como un marco voluntario, sin controles técnicos concretos, organizado en cuatro funciones (gobernar, mapear, medir y gestionar) que una organización aplica a su propio contexto de riesgo. NIST AI 600-1, publicado el 26 de julio de 2024 bajo el título «Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile», es un perfil de ese marco: toma las mismas cuatro funciones y las aplica de forma específica a la IA generativa, con un catálogo de doce categorías de riesgo propias o agravadas por la IA generativa (entre ellas, información o capacidades relacionadas con armas químicas, biológicas, radiológicas o nucleares; confabulación, el término que usa NIST para lo que coloquialmente se llama alucinación; privacidad de datos; integridad de la información; seguridad de la información, y propiedad intelectual).
El documento se desarrolló en cumplimiento de la orden ejecutiva 14110 del entonces presidente Biden, que el actual gobierno de Estados Unidos revocó el 20 de enero de 2025. Eso no retira el documento: NIST AI 600-1 sigue publicado, sigue vigente como recurso voluntario y se sigue citando en pliegos de contratación pública, independientemente del estado de la orden ejecutiva que motivó su encargo original.
SP 800-218A: el desarrollo seguro extendido a la IA generativa
NIST SP 800-218A, publicado también el 26 de julio de 2024 con el título «Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile», hace por el Secure Software Development Framework (SSDF, NIST SP 800-218) lo que AI 600-1 hace por el AI RMF: toma un marco general de desarrollo seguro de software, que ya existía y no se pensó para IA, y añade las prácticas, tareas y consideraciones específicas de entrenar, ajustar y desplegar un modelo generativo o un modelo de fundación de doble uso a lo largo del mismo ciclo de vida de desarrollo. Va dirigido tanto a quien produce modelos como a quien construye sistemas encima de ellos y a quien los adquiere para su organización.
Las guías de NCSC y CISA
«Guidelines for Secure AI System Development» la publicó el Centro Nacional de Ciberseguridad del Reino Unido (NCSC) junto con la agencia estadounidense CISA el 26 de noviembre de 2023, con el respaldo conjunto de otras 21 agencias y ministerios internacionales, veintitrés organizaciones firmantes en total. A diferencia de los documentos anteriores, esta guía no propone una taxonomía de riesgos ni un vocabulario: organiza recomendaciones de «seguridad desde el diseño» a lo largo de cuatro fases del ciclo de vida de un sistema de IA.
Diseño seguro cubre la evaluación de riesgos y el modelado de amenazas antes de escribir una sola línea de código. Desarrollo seguro entra en la seguridad de la cadena de suministro y la gestión de la deuda técnica del propio sistema. Despliegue seguro trata la protección de la infraestructura sobre la que corre el modelo y una publicación responsable, con planes de reversión si algo falla. Y operación y mantenimiento seguros cubre la monitorización continua y la gestión de actualizaciones una vez el sistema ya está en producción. Están pensadas sobre todo para quien construye o provee sistemas de IA, pero las propias agencias recomiendan su lectura a cualquier perfil que participe en alguna de esas cuatro fases: desarrolladores, científicos de datos, gestores de riesgo y responsables de la decisión final.
ISO/IEC 42001
ISO/IEC 42001:2023, titulada «Information technology – Artificial intelligence – Management system», se publicó en diciembre de 2023 y es la primera norma certificable para un sistema de gestión de inteligencia artificial. El documento completo son 51 páginas y su adquisición tiene coste (alrededor de 230 euros en las tiendas oficiales de venta de normas), así que este módulo no describe su contenido detallado ni sus controles: eso sería reproducir un texto de pago, y cada organización que quiera certificarse necesita leerlo de primera mano, no un resumen de segunda mano.
Lo que sí se puede decir de su estructura general, porque es información pública, es que sigue la misma organización de alto nivel que otras normas de sistemas de gestión de ISO, como la 27001 de seguridad de la información: un bloque de cláusulas sobre contexto de la organización, liderazgo, planificación, soporte, operación, evaluación del desempeño y mejora continua, más un anexo informativo con objetivos de control específicos de IA. Esa familiaridad de estructura es intencionada: una organización que ya tiene un sistema de gestión certificado bajo otra norma ISO puede integrar el de IA sin reinventar todo su aparato documental desde cero. Certificarse no es obligatorio en ningún marco legal que este módulo cubra, es una decisión comercial: sirve para demostrar ante un cliente o un regulador que existe un sistema de gestión auditado, no que la aplicación concreta esté libre de los riesgos del Top 10 de OWASP. El gobierno del riesgo de IA como programa de la organización, más allá de esta norma concreta, tiene su desarrollo completo en el curso de GRC.
Tabla comparativa de los marcos
| Marco | Qué pregunta responde | Perfil al que sirve | Gratuito | Versión vigente |
|---|---|---|---|---|
| OWASP Top 10 LLM 2025 | Qué riesgos concretos tiene mi aplicación con modelo de lenguaje | Desarrolladores y arquitectos de aplicaciones | Sí | 2025 (18 nov. 2024 en inglés, 11 mar. 2025 en español) |
| OWASP Top 10 Agentic 2026 | Qué añaden los agentes autónomos sobre ese riesgo | Igual, más equipos de agentes y de MCP | Sí, solo en PDF | 2026 (9 dic. 2025) |
| MITRE ATLAS | Cómo opera un adversario contra un sistema de IA, paso a paso | Analistas de amenazas, equipos rojos y azules | Sí | Actualización continua, comprobar el YAML en cada consulta |
| NIST AI 100-2 E2025 | Qué vocabulario y categorías de ataque existen en aprendizaje automático adversario | Investigadores y arquitectos de seguridad de ML | Sí | E2025 (aprobada el 20 mar. 2025) |
| NIST AI RMF + AI 600-1 | Cómo gestiono el riesgo de IA como programa de la organización | Gestión de riesgo y gobierno de IA | Sí | AI RMF 1.0 (ene. 2023) + AI 600-1 (26 jul. 2024) |
| NIST SP 800-218A | Cómo extiendo mi ciclo de desarrollo seguro a modelos generativos | Equipos de desarrollo seguro | Sí | 26 jul. 2024 |
| Guías NCSC + CISA | Qué controles aplico en cada fase del ciclo de vida de un sistema de IA | Proveedores y desarrolladores de sistemas de IA | Sí | 26 nov. 2023 |
| ISO/IEC 42001 | Cómo certifico un sistema de gestión de IA ante un cliente o un regulador | Dirección y cumplimiento | No, de pago | 2023 |
Cómo se usan juntos en la práctica
Imagina que te piden revisar un asistente interno con recuperación de documentos y una herramienta que consulta un sistema de tickets. El punto de partida razonable es el Top 10 de OWASP como lista de comprobación: repasas los diez riesgos, componente a componente, y marcas cuáles aplican a esta aplicación en concreto y con qué severidad, apoyándote en las secciones de «ejemplos comunes» que trae cada entrada.
Cuando toca describir cómo actuaría un atacante contra los puntos que marcaste, ATLAS aporta el vocabulario de tácticas y técnicas que un informe de amenazas necesita para no quedarse en generalidades: en vez de «un atacante podría manipular el contexto recuperado», escribes que la vía de entrada corresponde a la técnica AML.T0051.001, inyección de prompt indirecta, y citas el identificador exacto en vez de una descripción libre. NIST entra en dos sitios distintos: la taxonomía de AI 100-2 te da el vocabulario preciso para clasificar cada hallazgo (esto es una violación de integridad, no de disponibilidad), y el AI RMF con su perfil de IA generativa te da la estructura para convertir esos hallazgos en un programa de gestión de riesgo con dueños y plazos, no solo una lista de bugs.
Las guías de NCSC y CISA entran cuando el encargo es acompañar el desarrollo desde el principio, no auditar algo que ya existe: dan la estructura de ciclo de vida (diseño, desarrollo, despliegue, operación) sobre la que organizar en qué fase corresponde aplicar cada control que identificaste con los otros marcos. Cuando la organización necesita demostrar ante un cliente o un regulador que tiene un sistema de gestión auditado, no solo una aplicación revisada una vez, ahí es donde entra ISO/IEC 42001. El Reglamento europeo de IA marca, por su parte, qué obligaciones legales concretas tiene esa organización según el uso que le dé al sistema, algo que el módulo 14 de este curso desarrolla entero.
Ejercicio: mapea cinco riesgos del Top 10 a su técnica ATLAS
El objetivo es que practiques exactamente el paso que acabas de leer en la sección anterior: convertir un riesgo del Top 10 de OWASP en un identificador concreto de ATLAS, verificado en la fuente primaria, no copiado de un resumen. Todo el software que hace falta es gratuito.
Primero, descarga los dos documentos que vas a cruzar. El PDF en español del Top 10 de OWASP:
curl -s -o owasp-top10-es.pdf "https://genai.owasp.org/download/46116/?tmstv=1741814891"Y el YAML de ATLAS, siguiendo el puntero como se explicó antes:
version=$(curl -s https://raw.githubusercontent.com/mitre-atlas/atlas-data/main/dist/v6/ATLAS-latest.yaml)
curl -s -o ATLAS.yaml "https://raw.githubusercontent.com/mitre-atlas/atlas-data/main/dist/v6/$version"Ahora el método, con un ejemplo ya resuelto. Cada entrada del Top 10 de OWASP que tiene una sección «Frameworks y taxonomías relacionados» cita ahí mismo el identificador de ATLAS que le corresponde, con el nombre que tenía la técnica cuando se escribió ese documento. La entrada LLM01:2025, Inyección de prompt, cita tres: AML.T0051.000 (inyección directa), AML.T0051.001 (inyección indirecta) y AML.T0054 (jailbreak). Para comprobar el nombre vigente de cada una en tu copia del YAML:
import yaml
with open("ATLAS.yaml", encoding="utf-8") as f:
atlas = yaml.safe_load(f)
for tid in ["AML.T0051.000", "AML.T0051.001", "AML.T0054"]:
print(tid, "->", atlas["techniques"][tid]["name"])No todas las entradas del Top 10 tienen esa sección: Manejo inadecuado de la salida, Agencia excesiva y Debilidades de vector y representaciones vectoriales no citan ningún identificador de ATLAS en el documento oficial. Elige cuatro riesgos más entre los que sí la tienen (Divulgación de información sensible, Cadena de suministro, Envenenamiento de datos y modelo, Filtración de prompts de sistema, Desinformación y Consumo ilimitado) y repite el mismo proceso para cada uno: abre esa sección del PDF, apunta el identificador que cita OWASP, búscalo en tu YAML de ATLAS y anota el nombre vigente hoy. Para cada uno de los cinco (el de inyección de prompt más los cuatro que elijas), escribe una frase que conecte el riesgo con la técnica: qué parte del comportamiento que describe OWASP corresponde exactamente a lo que describe la técnica de ATLAS. Guarda el resultado, porque el módulo 12 de este curso, sobre red teaming, pide retomar este mismo cruce para construir escenarios de prueba.
Preguntas frecuentes
¿Tengo que memorizar los diez identificadores del Top 10 de OWASP?
No hace falta memorizarlos de entrada. Lo importante de este módulo es que sepas que existen, qué cubre cada uno a grandes rasgos y dónde consultarlos cuando los necesites. Los módulos siguientes de este curso vuelven sobre los riesgos con más peso (inyección de prompt, salida no confiable, RAG, agencia excesiva) con tanto detalle que el identificador se te queda solo de usarlo.
¿Por qué el listado de aplicaciones agénticas solo existe en PDF y el de aplicaciones LLM tiene también versión web?
Es una decisión editorial del propio proyecto, no una limitación técnica: el Top 10 de LLM lleva más de dos años publicado y ha tenido tiempo de generar una versión HTML navegable en el sitio del proyecto; el de aplicaciones agénticas se publicó en diciembre de 2025 y, a fecha de este módulo, todavía no tiene ese formato adicional. Puede que aparezca más adelante, pero hoy el PDF es la única fuente completa.
¿MITRE ATLAS sustituye a ATT&CK en mi organización?
No, lo complementa. ATT&CK sigue siendo el marco para infraestructura de TI convencional (redes, endpoints, identidad), y ATLAS cubre específicamente los componentes de un sistema de inteligencia artificial: el modelo, los datos de entrenamiento, la cadena de inferencia. Un mismo incidente puede necesitar técnicas de los dos marcos si el atacante entra por una vía convencional y después ataca el modelo, o al revés.
¿Necesito certificarme en ISO/IEC 42001 para trabajar en seguridad de IA?
No. La certificación es una decisión de la organización, normalmente motivada por exigencias contractuales o de un cliente grande, no un requisito para que una persona trabaje en este campo. Lo que sí conviene es entender su estructura general, porque te la vas a encontrar citada en pliegos de contratación y en cuestionarios de proveedores.
¿Qué marco uso si me piden «la lista de riesgos de IA» sin más contexto?
Empieza por el Top 10 de OWASP que corresponda al tipo de sistema (LLM o agéntico): es el más orientado a aplicación concreta y el más fácil de convertir en una lista de comprobación accionable. Si la petición es más amplia, sobre el programa de gestión de riesgo de toda la organización, el AI RMF de NIST con su perfil de IA generativa es el punto de partida más adecuado.
¿Todo esto va a quedar desfasado pronto?
Las cifras y los identificadores concretos de un marco vivo como ATLAS sí cambian con cada actualización, y por eso este módulo te enseña a contarlos y verificarlos tú mismo en vez de memorizar un número. La estructura general (qué pregunta responde cada marco, quién lo mantiene, cómo se combinan) cambia mucho más despacio, y es la parte de este módulo pensada para seguir siendo útil pasado un año.