Un AI BOM (lista de materiales de IA) es el registro estructurado y legible por máquina de aquello de lo que está hecho un sistema de IA: modelos, conjuntos de datos, dependencias de software, infraestructura y sus relaciones. Hasta 2026, su contenido era lo que decidiera cada fabricante de herramientas. Desde el 12 de mayo de 2026 existe una base oficial, publicada por las agencias de ciberseguridad del G7: 7 grupos y 50 elementos según nuestro recuento, de aplicación voluntaria. Esta guía lee esa lista como la leería un auditor: qué registra, qué deja fuera, qué normas hacen exigible su contenido y cómo se construye.
Lo esencial
- Un AI BOM extiende el SBOM a modelos, datos, infraestructura y su linaje. Lo complementa, no lo sustituye.
- La guía del G7 del 12 de mayo de 2026 enumera 7 grupos y 50 elementos mínimos según nuestro recuento. Es voluntaria y no cita ninguna ley.
- Ningún texto de la UE lo exige por su nombre, pero el Reglamento de IA (anexo IV, artículo 25.4, anexos XI y XII) y el Reglamento de Ciberresiliencia (anexo I) exigen casi todo su contenido.
- No recoge el riesgo de la finalidad prevista, la supervisión humana, las pruebas ni los riesgos: es una lista de ingredientes, no un expediente técnico.
- Fechas: modelos de uso general desde agosto de 2025, notificación de ciberresiliencia desde septiembre de 2026, alto riesgo y SBOM en diciembre de 2027.
¿Qué es un AI BOM?
La definición más útil es la de las agencias del G7: un registro estructurado, o inventario, de los detalles y de las relaciones de la cadena de suministro de los componentes utilizados para construir un sistema de IA. El documento lo resume con una imagen doméstica: una lista de ingredientes. El SBOM clásico no basta por tres motivos. Un modelo no es una biblioteca: su comportamiento procede de unos pesos y de unos datos de entrenamiento que ningún manifiesto de paquetes describe. Un conjunto de datos tiene procedencia, licencia y nivel de sensibilidad. Y un sistema de IA llama a servicios externos que no figuran en el código compilado. El G7 no propone por ello abandonar el SBOM: los sistemas de IA también son sistemas de software, de modo que el SBOM sigue siendo válido y los elementos propios de la IA se suman a los elementos mínimos generales.
AI BOM, AIBOM, ML-BOM, SBOM para IA: un artefacto, varios nombres
AIBOM o AI BOM (AI bill of materials) es el uso de la industria y de OWASP. ML-BOM es el nombre que CycloneDX da al objeto. SBOM for AI es la denominación del G7 y de las agencias. AI SBOM es el nombre de la iniciativa de OWASP. Todos designan el mismo artefacto. Conviene separarlo de dos vecinos:
- La model card es documentación en prosa sobre un modelo concreto, pensada para personas. La lista del G7 remite a ella mediante un enlace, como explicamos en la guía sobre la model card de IA.
- El inventario o registro de IA es la lista de sistemas de IA de la organización. De cada ficha del inventario de sistemas de IA cuelga un AI BOM por cada versión del sistema.
Qué contiene un AI BOM: los 50 elementos mínimos del G7
El texto de referencia, «Software Bill of Materials for AI, Minimum Elements», se publicó el 12 de mayo de 2026. Lo firman la BSI (Alemania), la ACN (Italia), la ANSSI (Francia), el CSE (Canadá), la CISA (Estados Unidos), el NCSC (Reino Unido) y la NCO (Japón), en colaboración con la Comisión Europea. La ACN y la BSI codirigieron el trabajo bajo las presidencias canadiense (2025) y francesa (2026) del G7. Sigue a la «visión compartida del G7» de junio de 2025 y se redactó entre agosto de 2025 y febrero de 2026. Son 26 páginas, disponibles en la CISA y en la BSI. Las hemos leído y hemos contado: <table header-row=»true»> <tr> <td>Grupo</td> <td>Elementos</td> <td>Qué registra</td> </tr> <tr> <td>Metadatos</td> <td>10</td> <td>El documento: autor, versión, formato y su versión, firma digital del autor, herramienta, contexto de generación, marca temporal, dependencias</td> </tr> <tr> <td>Propiedades del sistema</td> <td>9</td> <td>El sistema: nombre, componentes, productor, versión, marca temporal, flujo de datos interno y hacia servicios externos, uso de los datos, entradas y salidas, ámbito de aplicación previsto</td> </tr> <tr> <td>Modelos</td> <td>13</td> <td>Cada modelo: nombre, identificador, versión, marca temporal, productor, descripción (capacidades, limitaciones, linaje), hash y algoritmo, arquitectura y parámetros, entradas y salidas, entrenamiento, licencia, referencias externas (model card)</td> </tr> <tr> <td>Conjuntos de datos</td> <td>10</td> <td>Cada conjunto: nombre, descripción, contenido, identificador, hash, procedencia (origen, recogida, etiquetado, datos sintéticos), estadísticas, sensibilidad (datos personales, con derechos de autor, financieros o médicos), dependencias, licencia</td> </tr> <tr> <td>Infraestructura</td> <td>2</td> <td>Software de ejecución (firmware, bibliotecas, marcos, entornos, herramientas) y hardware, por enlace a una lista de materiales de hardware (HBOM)</td> </tr> <tr> <td>Propiedades de seguridad</td> <td>4</td> <td>Controles generales y específicos de IA (inyección de instrucciones, filtros de entrada y salida), certificaciones y normas, política de ciberseguridad (security.txt), referencia de vulnerabilidades</td> </tr> <tr> <td>Indicadores clave de rendimiento</td> <td>2</td> <td>Métricas de seguridad (resiliencia frente a la manipulación por terceros) y rendimiento operativo (disponibilidad, resolución de incidentes, latencia, caudal)</td> </tr> </table> Total: 7 grupos y 50 elementos. Ninguna de las 14 páginas mejor posicionadas que analizamos recoge esta lista. De su lectura salen tres observaciones. El peso está en los modelos y los datos. 23 de los 50 elementos los describen. Solo 2 describen la infraestructura, y el hardware se resuelve con un enlace. La integridad viene de serie. Cada modelo lleva un hash y su algoritmo, cada conjunto de datos lleva un hash y el documento lleva la firma digital de su autor. Cuando el autor no dispone de un dato, la guía pide indicar que es desconocido en lugar de dejar el campo vacío, una regla útil para la seguridad de la IA. La model card no desaparece. Los elementos «propiedades de entrenamiento del modelo» y «referencias externas del modelo» apuntan a ella mediante un enlace.
Formatos de AI BOM: CycloneDX y SPDX
Dos formatos abiertos transportan hoy el artefacto. CycloneDX, proyecto de OWASP normalizado como ECMA-424, incluye una lista de materiales de aprendizaje automático (ML-BOM) desde su versión 1.5. SPDX 3.0, de la Linux Foundation, añadió un perfil de IA y un perfil de conjuntos de datos, descritos en el informe sobre AI BOM con SPDX 3.0. La comparación siguiente procede de una presentación impartida en el NIST el 19 de mayo de 2026 (Crossley y Friedman): <table header-row=»true»> <tr> <td>Formato</td> <td>Punto fuerte</td> <td>Límite</td> </tr> <tr> <td>CycloneDX ML-BOM (versiones 1.5 a 1.7)</td> <td>Tipos nativos de aprendizaje automático y amplio soporte en herramientas</td> <td>Menos campos de metadatos de IA; sin campo nativo para datos personales sensibles, explicabilidad, autonomía o riesgo de seguridad</td> </tr> <tr> <td>Perfil de IA de SPDX 3.0.1</td> <td>Los metadatos de IA más profundos y relaciones formales «entrenado con» y «probado con»</td> <td>Herramientas en maduración y un formato JSON-LD menos cómodo en las cadenas de compilación</td> </tr> </table> Según la misma fuente, el AIBOM Generator de la iniciativa AI SBOM de OWASP, de código abierto y presentado en la RSAC 2025, produce documentos CycloneDX 1.6 para modelos alojados en Hugging Face; la correspondencia con SPDX seguía en curso en mayo de 2026. La guía del G7 no prescribe formato: su grupo de metadatos solo pide declarar el nombre y la versión del formato. La regla práctica: elija el que su herramienta de SBOM ya produce, porque el Reglamento de Ciberresiliencia le pedirá el SBOM en la misma cadena de compilación, y deje constancia de la elección en su sistema de gestión ISO 42001 si lo tiene.
Lo que un AI BOM no demuestra
El texto del G7 declara que no crea requisitos, normas ni legislación, y sus 26 páginas no nombran ningún reglamento (lo hemos comprobado sobre el texto completo). Es un documento de ciberseguridad: dice de qué está hecho el sistema, no para qué se usa, qué riesgo supone, quién lo supervisa ni cómo se probó. Hemos cruzado la lista con el anexo IV del Reglamento de IA, que fija el contenido de la documentación técnica de un sistema de IA. Es nuestra lectura, no una correspondencia del G7 ni de la Comisión: <table header-row=»true»> <tr> <td>Lo que pide el anexo IV</td> <td>¿Está en el AI BOM?</td> <td>Dónde vive la prueba</td> </tr> <tr> <td>Finalidad prevista, proveedor, versiones (punto 1)</td> <td>En parte: nombre, productor, versión, ámbito de aplicación previsto</td> <td>Instrucciones de uso, registro de clasificación</td> </tr> <tr> <td>Sistemas preentrenados y herramientas de terceros, y su integración (punto 2, letra a)</td> <td>Sí: grupo Modelos, linaje, componentes</td> <td>AI BOM y acuerdos con suministradores</td> </tr> <tr> <td>Arquitectura y relación entre componentes (punto 2, letra c)</td> <td>Sí: componentes, flujo de datos</td> <td>AI BOM y descripción de arquitectura</td> </tr> <tr> <td>Datos de entrenamiento: procedencia, alcance, obtención, etiquetado, limpieza (punto 2, letra d)</td> <td>En gran medida: grupo Conjuntos de datos</td> <td>Fichas de datos, gobernanza de datos (artículo 10)</td> </tr> <tr> <td>Medidas de supervisión humana (punto 2, letra e)</td> <td>No</td> <td>Diseño y asignación de la supervisión (artículo 14)</td> </tr> <tr> <td>Validación y pruebas: métricas, registros, informes firmados (punto 2, letra g)</td> <td>Marginal: dos indicadores</td> <td>Informes de pruebas, métricas de precisión (artículo 15)</td> </tr> <tr> <td>Sistema de gestión de riesgos (punto 5)</td> <td>No</td> <td>Expediente de gestión de riesgos (artículo 9)</td> </tr> <tr> <td>Normas aplicadas, declaración UE de conformidad, seguimiento poscomercialización (puntos 7, 8 y 9)</td> <td>No (solo certificaciones de seguridad)</td> <td>Expediente de conformidad</td> </tr> </table> Quien clasifique un sistema de IA de alto riesgo y prepare su evaluación de la conformidad necesita el resto del expediente. Hay además una omisión deliberada. El grupo del G7 debatió incluir el nivel de toma de decisiones o de autonomía del sistema, reconoció su pertinencia (por la IA agéntica) y decidió no convertirlo en un elemento, porque cada jurisdicción puede abordarlo de forma distinta, también mediante requisitos de seguridad. Para un lector europeo, de eso tratan el artículo 14 (supervisión humana) y la clasificación de alto riesgo: ese registro debe existir en otro sitio. La conclusión del propio G7 va en la misma dirección: un SBOM para IA no basta por sí solo. Debe conectarse con las herramientas de gestión de vulnerabilidades y con los avisos de seguridad.
Qué normas hacen exigible el contenido de un AI BOM
- Reglamento de IA, artículo 11 y anexo IV. El Reglamento (UE) 2024/1689 exige la documentación técnica de los sistemas de alto riesgo, elaborada antes de la introducción en el mercado y mantenida al día. El punto 2 del anexo IV pide, entre otras cosas, los sistemas preentrenados o las herramientas de terceros utilizados y su integración, la arquitectura y las fichas de datos de entrenamiento con su procedencia. Se conserva 10 años (artículo 18). Tras el ómnibus digital, Reglamento (UE) 2026/1744, se aplica al anexo III desde el 2 de diciembre de 2027 y a los productos del anexo I desde el 2 de agosto de 2028.
- Reglamento de IA, artículo 25, apartado 4. El proveedor de un sistema de alto riesgo y el tercero que suministre un sistema, herramienta, servicio, componente o proceso utilizado en él especifican por acuerdo escrito la información, las capacidades, el acceso técnico y la asistencia necesarios. Se exceptúan las herramientas y los componentes, distintos de los modelos de uso general, con licencia libre y de código abierto. Es la base jurídica para pedir un AI BOM a un suministrador.
- Reglamento de IA, artículo 53 y anexos XI y XII. Los proveedores de modelos de uso general documentan el modelo para la Oficina de IA e informan a los proveedores posteriores: arquitectura y número de parámetros, modalidad y formato de entradas y salidas, licencia, tipo y procedencia de los datos de entrenamiento. Aplicable desde el 2 de agosto de 2025.
- Reglamento de IA, artículo 15. Precisión, solidez y ciberseguridad de los sistemas de alto riesgo, incluidas las medidas contra el envenenamiento de datos y de modelos, técnicas catalogadas en MITRE ATLAS.
- Reglamento de Ciberresiliencia. El anexo I, parte II, del Reglamento (UE) 2024/2847 obliga a los fabricantes de productos con elementos digitales a elaborar un SBOM en un formato de uso común y legible por máquina que cubra, como mínimo, las dependencias de nivel superior. Forma parte de la documentación técnica, se entrega a las autoridades de vigilancia del mercado si lo solicitan y no es obligatorio publicarlo. La notificación de vulnerabilidades aprovechadas activamente se aplica desde el 11 de septiembre de 2026 y el reglamento completo desde el 11 de diciembre de 2027. Según su artículo 12, un sistema de alto riesgo que sea un producto con elementos digitales y cumpla sus requisitos esenciales se considera conforme con el requisito de ciberseguridad del artículo 15 del Reglamento de IA.
- NIS2. La seguridad de la cadena de suministro es una de las medidas de gestión de riesgos de su artículo 21.
En su análisis del 16 de junio de 2026, Morgan Lewis observa que la lista del G7 se solapa con los artículos 11 y 13 y con el anexo IV, y espera que las orientaciones de la UE recojan parte de sus elementos. Es su opinión, no un compromiso de la Comisión. España no es miembro del G7, de modo que ninguna agencia española firmó la lista. La Comisión Europea sí participó, y es la referencia que los lectores del INCIBE encontrarán en los documentos de sus suministradores. La supervisión del Reglamento de IA corresponde a la AESIA, creada por el Real Decreto 729/2023 y con sede en A Coruña.
Cómo elaborar un AI BOM: un método en siete pasos
- Delimite el alcance. Un AI BOM por sistema de IA y por versión, unido a la ficha del sistema en el inventario de sistemas de IA o en un registro de IA estructurado.
- Genérelo, no lo teclee. Extráigalo del registro de modelos, de la cadena de entrenamiento y de la compilación, en el formato de su herramienta de SBOM. Un documento escrito a mano caduca en el siguiente reentrenamiento.
- Rellene los siete grupos y escriba «desconocido» donde no sepa, sobre todo en los modelos de terceros.
- Calcule los hashes y firme. Ficheros de modelo, ficheros de datos y el propio documento.
- Enlace lo que el AI BOM no contiene. Model card, expediente de gestión de riesgos, medidas de supervisión e informes de pruebas, incluidos los de red teaming de IA.
- Llévelo a los contratos. Pida un AI BOM a sus suministradores en la incorporación y en cada versión del modelo, al amparo del artículo 25, apartado 4, cuando el sistema sea de alto riesgo. Encaja en la due diligence de proveedores de IA.
- Manténgalo vivo. Regenérelo en cada reentrenamiento, ajuste fino o cambio de dependencia o de herramienta, y vigile la deriva del modelo. Conéctelo a la gestión de vulnerabilidades y a la notificación de incidentes de IA, y conserve las versiones 10 años donde se apliquen ambos reglamentos.
Cada paso deja un registro fechado: lo que permite responder a un cliente o a una autoridad en una hora, y no en una semana.
AI BOM para modelos de terceros y agentes de IA
Modelos consumidos a través de una API. No hay pesos y, por tanto, no hay hash. La entrada honesta es «desconocido», acompañada de la documentación del proveedor. En los modelos de uso general, el proveedor debe a los proveedores posteriores la información del anexo XII, que cubre la mayor parte del grupo Modelos. Si hay datos personales, el análisis sigue en el RGPD. Agentes. El elemento «flujo de datos del sistema» del G7 ya nombra las API de servicios externos, los protocolos de comunicación entre agentes y la conexión con la web. La presentación del NIST de mayo de 2026 esboza una «lista de materiales de sistema agéntico» que añade herramientas, servidores MCP, instrucciones, políticas, memoria y vínculos de identidad, además de pruebas en tiempo de ejecución (llamadas a herramientas, aprobaciones, acciones denegadas). Hoy ningún formato normaliza esa capa: registre las herramientas y sus permisos en los grupos de componentes e infraestructura, y conserve aparte los registros de ejecución. Véanse la guía de seguridad de la IA agéntica y las directrices del NCSC. Los responsables del despliegue rara vez redactan un AI BOM: lo piden, leen tres cosas (qué modelo y versión, qué sensibilidad de datos, qué servicios externos) y lo archivan junto a la ficha del sistema.
Preguntas frecuentes
¿Qué es un AI BOM en términos sencillos? Es la lista de ingredientes de un sistema de IA: qué modelos usa y en qué versión, con qué datos se entrenaron, de qué bibliotecas y servicios externos depende y sobre qué infraestructura funciona. Se genera en un formato legible por máquina, lleva hashes y va firmado por su autor. Permite saber pronto si una vulnerabilidad publicada le afecta y qué cambió entre dos versiones. ¿Qué diferencia hay entre un AI BOM y un SBOM? El SBOM describe los componentes de software: paquetes, bibliotecas, versiones y dependencias. El AI BOM añade lo que el SBOM no ve: modelos (arquitectura, parámetros, linaje, hash), conjuntos de datos (procedencia, sensibilidad, licencia), flujos hacia servicios externos y propiedades de seguridad propias de la IA. Según el G7, no compiten: los elementos de IA se suman a los elementos mínimos generales. ¿Es obligatorio un AI BOM según el Reglamento de IA? Con ese nombre, no: el Reglamento de IA no menciona el artefacto. Su contenido sí es exigible en los sistemas de alto riesgo, a través de la documentación técnica del artículo 11 y del anexo IV, y en los modelos de uso general, a través del artículo 53 y de los anexos XI y XII. El Reglamento de Ciberresiliencia exige además un SBOM a los fabricantes. La guía del G7 es voluntaria. ¿Qué formato conviene utilizar? El que ya produzca su herramienta de SBOM. CycloneDX ofrece tipos nativos de aprendizaje automático y amplio soporte en herramientas, con menos metadatos de IA. El perfil de IA de SPDX 3.0.1 aporta metadatos más profundos y relaciones formales de entrenamiento y prueba, con herramientas en maduración. La guía del G7 no impone ninguno: solo pide declarar nombre y versión del formato. ¿Quién debe elaborarlo, el proveedor o el responsable del despliegue? El proveedor, porque construye el sistema y tiene acceso al registro de modelos, a la cadena de entrenamiento y a la compilación. El responsable del despliegue lo solicita, lo lee y lo archiva junto a la ficha del sistema. Cuando el proveedor integra componentes de terceros en un sistema de alto riesgo, el artículo 25, apartado 4, le permite fijar por escrito la información que necesita. ¿Sustituye un AI BOM a la model card o a la documentación técnica? No. La model card explica en prosa cómo se comporta un modelo y cuáles son sus límites, y la lista del G7 remite a ella mediante un enlace. La documentación técnica del anexo IV incluye además la supervisión humana, las pruebas, la gestión de riesgos y la conformidad, que el AI BOM no recoge. Es una pieza del expediente, no el expediente.
Conclusión
El contenido de un AI BOM ya no es la opinión de un fabricante: son siete grupos y cincuenta elementos, firmados por siete agencias. Lo que la lista no dice es qué norma se aplica a su sistema ni qué más le pedirá una autoridad: la finalidad prevista, la supervisión humana, las pruebas y el expediente de riesgos viven en otra parte. Empiece por un solo sistema. Genere su lista desde la cadena de compilación, escriba «desconocido» con honestidad allí donde no tenga el dato y enlace el resto del expediente. AI Sigil mantiene cada sistema de IA como una ficha con sus modelos, conjuntos de datos, componentes, riesgos, controles y pruebas, de modo que el AI BOM tiene un lugar del que colgar y el resto del expediente queda a un clic.