Elegir un marco de seguridad de la IA antes de una auditoría del Reglamento de IA o de ISO obliga a decidir entre más de quince opciones, y cada proveedor de nube promueve la suya. En este análisis las comparamos en cuatro familias que responden a cuatro preguntas distintas, explicamos lo que cambió en octubre de 2026 y cerramos con una regla de selección según su papel de operador y con la lista de evidencias que un auditor acepta.
Lo esencial
- La primera pregunta no es «qué marco»: la ley fija qué acreditar, los catálogos qué probar, los controles qué evidenciar y la arquitectura quién responde.
- Octubre de 2026 cambió la respuesta: llegó ISO/IEC 27090:2026, EN 18286 es la primera norma armonizada citada en el Diario Oficial y prEN 18282 cerró su información pública.
- El nuevo artículo 42, apartado 3, permite cubrir la ciberseguridad del artículo 15 con el Reglamento de Ciberresiliencia, no la precisión ni la solidez.
- Solo CSA AICM y DASF publican correspondencias por control con el Reglamento de IA e ISO/IEC 42001; SAIF, CoSAI, AWS, Microsoft y Cisco, ninguna.
- Su marco de seguridad de la IA: uno por familia, mapeado una vez contra las seis clases de ataque del artículo 15, apartado 5, y bajo control de cambios.
Qué es un marco de seguridad de la IA y qué no es
Un marco de seguridad de la IA es un conjunto con nombre y versión de amenazas, controles o responsabilidades para proteger un sistema de IA (datos, modelo, cadena de entrenamiento y despliegue, aplicación y agentes) frente al cual un tercero puede contrastar lo que usted hace. Sin versión, el auditor no sabe qué edición aplicó; sin verificación, es una opinión.
Hay cuatro familias, con preguntas distintas:
- La ley dice qué acreditar: el artículo 15 del Reglamento de IA, el artículo 55, apartado 1, letra d), y el Reglamento de Ciberresiliencia.
- Los catálogos de amenazas dicen qué probar: MITRE ATLAS, OWASP y NIST AI 100-2.
- Los conjuntos de controles dicen qué evidenciar: CSA AICM, DASF, el anexo A de ISO/IEC 42001, ISO/IEC 27090, las superposiciones de NIST, ETSI EN 304 223 y ENISA.
- Las guías de arquitectura dicen quién se ocupa de qué: SAIF, CoSAI, AWS, Microsoft y Cisco.
Tratarlas como alternativas es el error que más vemos: un catálogo no contiene controles auditables y una matriz de responsabilidad no acredita nada. Un marco de seguridad de la IA útil toma un elemento de cada familia.
No es una herramienta de gestión de la postura de seguridad (AI-SPM) ni un marco de «AI safety»: Cisco defendió el 16 de diciembre de 2025 que seguridad y prevención de daños son inseparables, pero el Reglamento de IA las regula en artículos separados. Tampoco es el marco de gobernanza de la IA, del que es una pieza técnica. Visión de conjunto: nuestra página sobre la seguridad de la IA.
El mapa de 2026: todos los marcos en una tabla
| Marco | Editor | Familia | Última versión (fecha) | Tamaño | Correspondencia con ley o norma |
|---|---|---|---|---|---|
| Artículo 15 del Reglamento de IA | Unión Europea | Ley | Reglamento (UE) 2024/1689; aplicable el 2 dic. 2027 (anexo III) y el 2 ago. 2028 (anexo I) | un artículo, seis clases de ataque nombradas | es la ley |
| Reglamento de Ciberresiliencia (CRA) | Unión Europea | Ley | Reglamento (UE) 2024/2847; notificación desde el 11 sept. 2026, aplicación plena el 11 dic. 2027 | requisitos esenciales del anexo I | su art. 12.1 da por cumplida la ciberseguridad del art. 15 |
| prEN 18282 | CEN-CENELEC JTC 21 | Norma armonizada (proyecto) | información pública del 15 may. al 14 jul. 2026 | no público | redactada para el art. 15 |
| ISO/IEC 27090:2026 | ISO/IEC JTC 1/SC 27 | Guía | oct. 2026, 56 páginas | guía, no certificable | evidencia en auditorías ISO/IEC 27001 y 42001 |
| ISO/IEC 42001:2023, anexo A | ISO/IEC JTC 1/SC 42 | Sistema de gestión certificable | dic. 2023 | controles A.6.2, A.7, A.8.4, A.10.3 | certificado |
| NIST AI RMF 1.0 y NIST AI 600-1 | NIST | Marco de riesgos | ene. 2023, jul. 2024 | cuatro funciones, característica «segura y resiliente» | voluntario; mapeado por AICM y DASF |
| NIST Cyber AI Profile (IR 8596) | NIST y MITRE | Perfil comunitario del CSF 2.0 | borrador preliminar inicial, 16 dic. 2025; sin borrador público | tres áreas (Secure, Defend, Thwart) | CSF 2.0 y AI RMF |
| NIST SP 800-53 Control Overlays for Securing AI Systems | NIST | Superposición de controles | documento conceptual, 14 ago. 2025; sin borrador | cinco superposiciones | SP 800-53 Rev. 5 |
| NIST AI 100-2 E2025 | NIST | Taxonomía de amenazas | 24 mar. 2025, 127 páginas | dos taxonomías (IA predictiva y generativa) | ninguna |
| Guidelines for Secure AI System Development | NCSC y CISA, 23 organizaciones firmantes | Guía de ciclo de vida | 27 nov. 2023 | cuatro fases | ninguna |
| ETSI EN 304 223 | ETSI (desde el código británico) | Requisitos de base | TS abr. 2025, EN dic. 2025 | 13 principios, 72 disposiciones, cinco fases | ninguna |
| ENISA FAICP | ENISA | Buenas prácticas | 7 jun. 2023 | tres capas | cooperación del considerando 78 |
| MITRE ATLAS | MITRE | Base de conocimiento de amenazas | 2026.10 (28 oct. 2026) | 16 tácticas, 129 técnicas, 92 subtécnicas, 44 mitigaciones | ATT&CK |
| OWASP Top 10 for LLM 2026, Agentic Top 10, AI Exchange | OWASP GenAI Security Project | Listas de amenazas y guía de controles | ago. 2026, dic. 2025, insignia desde mar. 2025 | 10 + 10 entradas, más de 50 controles | NIST, ATLAS, CWE; el AI Exchange contribuyó a ISO/IEC 27090 y prEN 18282 |
| CSA AI Controls Matrix | Cloud Security Alliance | Conjunto de controles | v1.1, 22 jun. 2026 | 247 controles, 18 dominios, AI-CAIQ de 320 preguntas | ISO/IEC 42001, ISO 27001, NIST AI RMF, AI 600-1, BSI AIC4, Reglamento de IA |
| Databricks DASF | Databricks | Conjunto de controles | v3.0, 20 mar. 2026 | 13 componentes, 97 riesgos, 73 controles | ATLAS, OWASP, SP 800-53, CSF, ENISA, ISO/IEC 42001, 27001, Reglamento de IA |
| Google SAIF | Google (datos donados a CoSAI) | Arquitectura y mapa de riesgos | SAIF 2.0, 6 oct. 2025 | 15 riesgos, 24 controles, tres principios para agentes | ninguna |
| CoSAI, AWS, Microsoft | OASIS, AWS, Microsoft | Responsabilidad compartida y alcance | CoSAI Shared Responsibility Framework v1.0, may. 2026; AWS AI Security Framework, may. 2026; modelo de agentes de Microsoft, ago. 2026 | capas, ámbitos, principios | ninguna (referencias a OWASP y ATLAS) |
La tabla dice qué es cada elemento, no cuál adoptar: decide la familia. Dos filas de una misma familia compiten y dos de familias distintas se complementan; un marco de seguridad de la IA completo nunca cabe en una fila. El Integrated AI Security and Safety Framework de Cisco (16 de diciembre de 2025, 19 objetivos del atacante, más de 150 técnicas) es una taxonomía: va con los catálogos. Solo AICM y DASF enlazan cada control con el Reglamento de IA y con ISO/IEC 42001.
Catálogos de amenazas: lo que el artículo 15, apartado 5, le obliga a probar
El artículo 15, apartado 5, exige que los sistemas de IA de alto riesgo resistan los intentos de terceros no autorizados de alterar su uso, sus resultados o su funcionamiento, y pide medidas contra el «envenenamiento de datos», el «envenenamiento de modelos», los «ejemplos adversarios» o la «evasión de modelos», los ataques a la confidencialidad y los defectos del modelo. Seis clases; la ley no dice cómo probarlas.
MITRE ATLAS 2026.10 (28 de octubre de 2026) reúne 16 tácticas, 129 técnicas, 92 subtécnicas, 44 mitigaciones y 77 casos de estudio; las primeras técnicas para agentes llegaron con la versión 5.0.0 (30 de septiembre de 2025) y desde mediados de 2026 hay una versión al mes (guía de MITRE ATLAS).
El OWASP Top 10 for LLM 2026 (3 de agosto de 2026) ordena así: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Excessive Agency, LLM04 Supply Chain, LLM05 Data and Model Poisoning, LLM06 Unbounded Consumption, LLM07 Misinformation, LLM08 Hidden Context Exposure, LLM09 Vector and Embedding Weaknesses y LLM10 Improper Output Handling. El Agentic Top 10 (9 de diciembre de 2025) va de ASI01 Agent Goal Hijack a ASI10 Rogue Agents (véanse seguridad de la IA agéntica y nuestra guía del OWASP Top 10 para LLM).
NIST AI 100-2 E2025 (24 de marzo de 2025) aporta dos taxonomías, predictiva (evasión, envenenamiento, privacidad) y generativa (cadena de suministro, inyección de prompts directa e indirecta, agentes), con revisiones anuales previstas (taxonomía de NIST AI 100-2). Nuestro mapeo de trabajo:
| Clase de ataque del artículo 15, apartado 5 | MITRE ATLAS | OWASP | NIST AI 100-2 |
|---|---|---|---|
| Envenenamiento de datos | técnicas de envenenamiento | LLM05 | envenenamiento |
| Envenenamiento de modelos | técnicas de cadena de suministro y de envenenamiento | LLM04 y LLM05 | envenenamiento y cadena de suministro |
| Ejemplos adversarios o evasión de modelos | técnicas de evasión | LLM01 para la evasión en el prompt | evasión |
| Ataques a la confidencialidad | técnicas de exfiltración y de inferencia | LLM02 | privacidad |
| Defectos del modelo | no es una clase de ataque | LLM07, LLM10 | no es una clase de ataque |
| Alteración no autorizada del uso o de los resultados | técnicas de configuración de agentes y de envenenamiento de contexto (AML.T0080 y AML.T0081) | ASI03, ASI06 | sección de agentes |
Los defectos del modelo no son un ataque, sino la debilidad que el atacante explota. Un marco de seguridad de la IA que no recorra las seis clases no responde a la primera pregunta del auditor (más en IA adversaria).
Conjuntos de controles: donde el marco de seguridad de la IA se convierte en evidencia
Un catálogo dice qué atacar; un conjunto de controles, qué debe existir, quién lo ejecuta y qué registro queda: es la parte del marco de seguridad de la IA que lee el auditor.
La CSA AI Controls Matrix v1.1 (22 de junio de 2026) reúne 247 objetivos de control en 18 dominios y cinco pilares, mapeos con análisis de brechas (ISO/IEC 42001, ISO 27001, NIST AI RMF, AI 600-1, BSI AIC4, Reglamento de IA), el AI-CAIQ de 320 preguntas y STAR for AI: autoevaluación (nivel 1) o certificación sobre ISO 42001 o 27001 (nivel 2). Encaja si ya usa la CCM o ISO 27001.
DASF 3.0 (20 de marzo de 2026) añade los agentes: 13 componentes, 97 riesgos, 73 controles, pestañas de aplicabilidad y mapeos a ATLAS, OWASP, SP 800-53, CSF, ENISA, ISO/IEC 42001, 27001 y el Reglamento de IA. Rinde más sobre un lakehouse.
El anexo A de ISO/IEC 42001 sitúa la seguridad en A.6.2.2 (requisitos), A.6.2.4 (verificación y validación), A.6.2.5 (despliegue), A.6.2.6 (operación y seguimiento), A.6.2.7 (documentación técnica), A.6.2.8 (registros de eventos), A.7.2 a A.7.6 (datos), A.8.4 (incidentes) y A.10.3 (proveedores). ISO/IEC 27090:2026 (octubre de 2026, 56 páginas, SC 27), no certificable, explica al auditor de ISO 27001 o 42001 qué es proteger un sistema de IA; ISO/IEC 27091 (privacidad) está en FDIS desde julio de 2026 (pila de normas ISO 42001).
NIST aún no ofrece una base citable: las superposiciones de SP 800-53 solo tienen un documento conceptual (14 de agosto de 2025) y un esquema anotado (enero de 2026), y el Cyber AI Profile, un borrador preliminar inicial (16 de diciembre de 2025). El NIST AI RMF no tiene controles.
ETSI EN 304 223, nacida del código británico del 31 de enero de 2025, es la única base con disposiciones numeradas (13 principios, 72 disposiciones, cinco fases). Las directrices del NCSC y CISA y la guía agéntica de CISA (1 de mayo de 2026) cubren el despliegue, y el FAICP de ENISA recuerda que la ciberseguridad general va primero.
La regla: un solo conjunto de controles, con análisis de brechas frente a la ley, como documento vivo. Con dos conjuntos, su marco de seguridad de la IA ofrecerá al auditor dos verdades.
Arquitectura y responsabilidad compartida: SAIF, CoSAI, AWS y Microsoft
SAIF 2.0 (6 de octubre de 2025) reúne cuatro áreas de componentes, 15 riesgos, 24 controles y tres principios para agentes (controladores humanos bien definidos, poderes limitados, acciones y planificación observables), más una autoevaluación que genera un informe. Google donó sus datos a CoSAI en septiembre de 2025 (CoSAI Risk Map).
CoSAI (OASIS, julio de 2024) ha publicado principios para sistemas agénticos seguros desde el diseño (16 de julio de 2025: gobernados por humanos y responsables; acotados y resilientes; transparentes y verificables), un AI Incident Response Framework mapeado a ATLAS (octubre de 2025), el AI Shared Responsibility Framework v1.0 (mayo de 2026: cinco capas, un responsable por componente), MCP Security v2.0 (septiembre de 2026) y Zero Trust for AI Systems (16 de septiembre de 2026).
AWS ofrece matrices de alcance generativa (cinco ámbitos, octubre de 2023) y agéntica (cuatro ámbitos, noviembre de 2025) y el AWS AI Security Framework (mayo de 2026: tres capas, tres fases, controles acumulativos); Microsoft, su modelo de responsabilidad compartida para la IA y, desde agosto de 2026, uno para agentes mapeado a OWASP y ATLAS.
Nuestro veredicto: dicen quién responde de cada control y en qué capa, pero ninguno se mapea al artículo 15. Úselos para repartir controles con su proveedor de nube y el del modelo, nunca para afirmar cumplimiento: un marco de seguridad de la IA que presente SAIF como prueba de conformidad no pasará la primera reunión de auditoría. Con agentes, registre cada herramienta invocada como componente con su responsable en la AI-BOM.
La ley detrás del marco de seguridad de la IA: artículos 15 y 42 y Reglamento de Ciberresiliencia
El artículo 15 del Reglamento (UE) 2024/1689 exige precisión, solidez y ciberseguridad adecuadas durante todo el ciclo de vida, resistencia a errores y fallos, redundancia técnica y control de los bucles de retroalimentación en los sistemas que siguen aprendiendo. El artículo 13, apartado 3, letra b), inciso ii), lleva a las instrucciones de uso el nivel con el que se probó el sistema de IA de alto riesgo. El artículo 55, apartado 1, letras a) y d), exige a los proveedores de modelos de uso general con riesgo sistémico, desde el 2 de agosto de 2025, pruebas adversarias documentadas y ciberseguridad del modelo y su infraestructura física.
El artículo 42 abre dos vías. El apartado 2 presume la conformidad con la ciberseguridad del artículo 15 de los sistemas certificados en un esquema del Reglamento (UE) 2019/881, desde el 2 de agosto de 2026. El nuevo apartado 3, del Ómnibus Digital sobre IA (Reglamento (UE) 2026/1744, en vigor desde el 27 de julio de 2026), remite al artículo 12, apartado 1, del Reglamento de Ciberresiliencia: un sistema de alto riesgo que es producto con elementos digitales se considera conforme con esa ciberseguridad si satisface los requisitos esenciales del CRA y su declaración de conformidad lo acredita; los organismos notificados del Reglamento de IA pueden verificar el CRA (artículo 12, apartado 2). Límite, según el considerando 77: solo ciberseguridad, no solidez ni precisión. Para el marco de seguridad de la IA de un fabricante, el expediente del CRA sirve dos veces.
Calendario: anexo III desde el 2 de diciembre de 2027, anexo I desde el 2 de agosto de 2028; en el CRA, notificaciones desde el 11 de septiembre de 2026 y aplicación plena el 11 de diciembre de 2027. EN 18286 (gestión de la calidad) es la primera norma armonizada citada en el Diario Oficial (Decisión de Ejecución (UE) 2026/2274, octubre de 2026). prEN 18282, sobre ciberseguridad de sistemas de IA (JTC 21, WG 5), estuvo en información pública del 15 de mayo al 14 de julio de 2026; la petición de normalización vence el 28 de febrero de 2027. No citamos su contenido: es un proyecto.
ENISA suma el FAICP (7 de junio de 2023), su posición sobre la IA de frontera (leer juntos NIS2, CRA y Reglamento de IA para los modelos con riesgo sistémico) y el Plan de Acción de la UE sobre Ciberseguridad e IA, ambos del 7 de julio de 2026, y el ENISA Threat Landscape 2026 (22 de septiembre), que sitúa los ataques facilitados por IA entre las principales amenazas.
Según el artículo 73, una brecha de seguridad solo se notifica si es un incidente grave (artículo 3, punto 49); el responsable del despliegue vigila y suspende (artículo 26, apartado 5). El marco de seguridad de la IA debe dejar escrita esa decisión (notificación de incidentes).
Cómo elegir: una regla de selección según su papel de operador
Cruce su papel con las cuatro familias; la última columna es la que cuenta.
| Su papel | Anclaje jurídico | Catálogo de amenazas | Conjunto de controles | Evidencia que acepta un auditor |
|---|---|---|---|---|
| Proveedor de un sistema de IA de alto riesgo | artículos 9, 11, 13, 15 y 43 | ATLAS, OWASP, NIST AI 100-2 | anexo A de ISO/IEC 42001 o CSA AICM; prEN 18282 cuando esté armonizada | sección de ciberseguridad del anexo IV, informes de pruebas y de red teaming, métricas en las instrucciones de uso, declaración UE de conformidad |
| Proveedor de un producto con elementos digitales | artículo 12 del CRA, artículo 42, apartado 3, del Reglamento de IA | los mismos | requisitos esenciales del anexo I del CRA | declaración de conformidad del CRA que acredita el nivel del artículo 15 |
| Responsable del despliegue | artículos 26 y 73 | OWASP Agentic Top 10 para agentes | AI-CAIQ dirigido al proveedor, matriz de responsabilidad compartida (CoSAI, AWS o Microsoft), supervisión | cuestionario del proveedor, registro de las instrucciones de uso, registro de supervisión, decisión de suspensión |
| Proveedor de un modelo de uso general con riesgo sistémico | artículo 55, apartado 1, letras a) y d) | ATLAS, evaluaciones de modelos de frontera | CoSAI, la posición de ENISA, el código de buenas prácticas | pruebas adversarias documentadas, medidas de ciberseguridad del modelo y de su infraestructura |
| Empresa que construye sobre una plataforma en la nube | artículo 15 o 26 según el papel | OWASP Top 10 for LLM | el marco de la plataforma (SAIF, DASF, AWS, Microsoft) como capa de implementación, AICM para la afirmación de cumplimiento | mapeo de controles con análisis de brechas |
Tres reglas hacen operativo este marco de seguridad de la IA: un conjunto de controles, un catálogo de amenazas y un modelo de responsabilidad; un único mapeo de cada uno contra las seis clases del artículo 15, apartado 5; y control de cambios, porque una nueva versión del marco, un nuevo modelo o un nuevo agente reabren el mapeo. La evaluación de la conformidad parte de ahí.
En España, la Agencia Española de Supervisión de la Inteligencia Artificial (AESIA) es la autoridad de supervisión de la IA. En el sector público, el Centro Criptológico Nacional y el Esquema Nacional de Seguridad (ENS) fijan la base de ciberseguridad; INCIBE orienta a las empresas y la AEPD vigila los datos personales. Si ya cumple el ENS, mapee su marco de seguridad de la IA contra sus medidas antes de abrir otro frente documental.
Del marco de seguridad de la IA a la evidencia de auditoría
Un auditor no audita un marco de seguridad de la IA, sino los registros que produce. Estos son los siete que esperamos ver.
- Mapeo de controles con análisis de brechas frente al artículo 15, con responsable y fecha por brecha. AICM y DASF traen uno de partida: adáptelo.
- Modelo de amenazas por sistema contra las seis clases del artículo 15, apartado 5. Indica qué técnicas de ATLAS u OWASP aplican y cuáles no.
- Informes de pruebas adversarias y de red teaming, fechados. Se repiten tras cada cambio sustancial del modelo, los datos o las herramientas del agente.
- Sección de ciberseguridad del anexo IV y métricas de las instrucciones de uso. Las cifras de ambos documentos deben coincidir.
- Cuestionario AI-CAIQ de cada proveedor y reparto de responsabilidades. La matriz dice qué controles son del proveedor y cuáles suyos.
- Manuales de respuesta a incidentes y registro de decisiones del artículo 73. Cada evento lleva su decisión: incidente grave o no, quién y cuándo.
- Informe de riesgos de SAIF o DASF como documento de trabajo. Sirve para encontrar brechas, nunca como afirmación de cumplimiento.
En una plataforma de gobernanza, el orden importa: primero el inventario de sistemas de IA, después un conjunto de controles por sistema y, al final, evidencias fechadas por control. La monitorización del cumplimiento avisa cuando una evidencia caduca o un cambio reabre el mapeo; la auditabilidad exige historial en cada registro.
Preguntas frecuentes
<b>¿Qué es un marco de seguridad de la IA?</b>
Es un conjunto con nombre y versión de amenazas, controles o responsabilidades para proteger un sistema de IA, frente al cual un tercero puede verificar lo que usted hace. Hay cuatro familias: la ley fija qué acreditar, los catálogos qué probar, los controles qué evidenciar y la arquitectura quién responde. Un marco de seguridad de la IA completo toma un elemento de cada familia y los mapea una vez.
<b>¿Qué marco de seguridad de la IA exige el Reglamento de IA?</b>
Ninguno con nombre propio. El artículo 15 exige precisión, solidez y ciberseguridad adecuadas y enumera las clases de ataque, sin imponer catálogo ni controles. La presunción de conformidad llegará con la norma armonizada, hoy en proyecto (prEN 18282). Ya hay dos vías: un certificado de un esquema del Reglamento (UE) 2019/881 (artículo 42, apartado 2) o, para productos con elementos digitales, la declaración de conformidad del CRA (artículo 42, apartado 3).
<b>¿Es ISO/IEC 27090 una norma certificable?</b>
No. ISO/IEC 27090:2026, publicada en octubre de 2026 por el ISO/IEC JTC 1/SC 27 con 56 páginas, es una guía sobre las amenazas y compromisos de los sistemas de IA, sin requisitos certificables. Sirve en las auditorías de ISO/IEC 27001 y 42001 para explicar al auditor qué significa proteger un sistema de IA. Lo que se certifica sigue siendo el sistema de gestión ISO/IEC 42001 o 27001.
<b>NIST AI RMF o NIST Cyber AI Profile: ¿cuál es el marco de seguridad?</b>
Ninguno funciona hoy como conjunto de controles citable. El AI RMF 1.0 (enero de 2023) y el perfil AI 600-1 (julio de 2024) gestionan riesgos con cuatro funciones, sin controles. El Cyber AI Profile (IR 8596), perfil del CSF 2.0, es solo un borrador preliminar inicial del 16 de diciembre de 2025. Estructure el riesgo con el AI RMF y tome los controles de AICM, DASF o ISO/IEC 42001 (véase nuestro NIST CSF).
<b>¿Necesito un marco si mi proveedor gestiona el modelo?</b>
Sí. Como responsable del despliegue, el artículo 26 le obliga a usar el sistema según las instrucciones, vigilarlo y suspenderlo ante un riesgo, y el artículo 73 le implica en los incidentes graves. Necesita el AI-CAIQ respondido por el proveedor, una matriz de responsabilidad compartida, el OWASP Agentic Top 10 si usa agentes y un registro de supervisión; véase nuestra guía de aseguramiento de la IA.
<b>¿Qué diferencia hay entre un marco de seguridad de la IA y la gestión de la postura (AI-SPM)?</b>
El marco define qué amenazas considerar, qué controles aplicar y quién responde: es un documento con versión frente al cual se le audita. La gestión de la postura de seguridad es una categoría de herramientas que descubre modelos, datos y configuraciones y señala desviaciones. Puede alimentar la evidencia de algunos controles, pero no sustituye la elección del marco ni el mapeo al artículo 15.
Conclusión
La ley decide qué acreditar, el catálogo de amenazas qué probar y el conjunto de controles qué mostrar; el modelo de responsabilidad dice quién lo hace. Elegir un marco de seguridad de la IA deja así de ser una apuesta por un proveedor y se convierte en un ejercicio de mapeo: uno por familia, un mapeo contra las seis clases del artículo 15, apartado 5, y control de cambios. Octubre de 2026 trajo piezas firmes (ISO/IEC 27090, EN 18286, la vía del CRA) y dejó otras en proyecto. Nuestra recomendación: empiece por el inventario, fije su papel en cada sistema y prepare las evidencias antes de que el auditor las pida. Más en nuestra guía de gobernanza de la IA.