Un AIBOM es un inventario estructurado de lo que compone un sistema de IA: los modelos y cómo se produjeron sus pesos, los conjuntos de datos utilizados a lo largo del ciclo de vida del modelo, la infraestructura sobre la que se ejecuta, los controles de seguridad que lo rodean y las cifras de rendimiento con las que fue validado. Una lista de materiales de IA hace por una canalización de modelos lo que una lista de piezas hace por una máquina, y durante el último año pasó de los artículos de investigación a las compras corporativas. Ese cambio se refleja directamente en nuestro propio trabajo de desarrollo de modelos de lenguaje de gran tamaño, donde el inventario se construye cada vez más junto con el modelo en lugar de ensamblarse después de que un cliente lo solicite.
En mayo de 2026, las agencias de ciberseguridad del G7 publicaron una guía conjunta de elementos mínimos para exactamente este artefacto, que abarca 50 elementos con nombre repartidos en siete grupos. Esa lista es ahora el vocabulario al que recurre el equipo de seguridad de un comprador empresarial cuando pregunta qué contiene el producto que estás vendiendo. A continuación se explica de dónde provienen las solicitudes, cada campo que pertenece al registro, qué campos genera una canalización por sí sola y dónde deja de ser útil la analogía con el inventario de software.
De dónde provienen las solicitudes de AIBOM
El documento detrás de la ola actual es Software Bill of Materials for AI: Minimum Elements, publicado el 12 de mayo de 2026 por siete agencias nacionales de ciberseguridad junto con la Comisión Europea: la BSI de Alemania, la ACN de Italia, la ANSSI de Francia, el CSE de Canadá, la CISA de Estados Unidos, el NCSC del Reino Unido y el NCO de Japón. Surgió de un grupo de trabajo del Grupo de Trabajo de Ciberseguridad del G7 que se desarrolló entre agosto de 2025 y febrero de 2026.
Su propio planteamiento es inusualmente directo sobre sus límites, al afirmar que los elementos mínimos “no son obligatorios; no crean requisitos, normas ni legislación”. Esa advertencia explica la velocidad con la que se difundió: una lista de campos voluntaria que lleva la firma de siete gobiernos resulta casi gratuita para que un equipo de compras la pegue en un cuestionario. Llega a un proveedor por una de cuatro vías:
- Un cuestionario de seguridad durante el alta del proveedor, con una sección de IA añadida a una pregunta ya existente sobre el inventario de software.
- Un entregable contractual dentro de un acuerdo marco de servicios empresariales, formulado como la obligación de mantener un inventario de componentes de IA.
- Un programa interno de gobernanza en el cliente, donde alguien informa del uso de IA a una junta directiva, un auditor o un regulador.
- La diligencia debida durante una adquisición o una ronda de financiación, en la que el comprador pregunta si la procedencia de tu modelo resiste el escrutinio.
Dos de esas vías terminan en una revisión técnica de tu base de código y tu canalización de modelos en lugar de un intercambio de documentos, lo cual se parece mucho más a una auditoría de implementación de IA empresarial que a rellenar un formulario. La guía también señala que, en algunas jurisdicciones, sus elementos “pueden estar ya, o se puede esperar que estén, cubiertos por requisitos y obligaciones legales”, una frase que hace mucho trabajo para cualquiera que venda en la UE. Para un análisis más detallado de lo que realmente comprueba esa revisión técnica y por qué son los reguladores quienes la impulsan, consulta nuestro desglose de qué cubre una auditoría de IA y por qué le importa a los reguladores.
Qué contiene un AIBOM, campo por campo
A continuación tienes el conjunto completo, grupo por grupo, usando los nombres de elemento propios de la guía. Trátalo como tu plantilla de AIBOM y no elimines nada sin un motivo que puedas defender ante el responsable de seguridad de un cliente.
Metadatos (10 elementos) describe el registro en sí, no el sistema: autor del SBOM, versión del SBOM, nombre del formato de datos del SBOM, versión del formato de datos del SBOM, firma del autor del SBOM, nombre de la herramienta del SBOM, versión de la herramienta del SBOM, contexto de generación del SBOM, marca de tiempo del SBOM y relación de dependencia del SBOM. El elemento que la gente se salta es el contexto de generación, que registra si el inventario procede del código fuente, de la compilación o de un binario ya distribuido. Esos tres discrepan de formas predecibles, y el lector necesita saber cuál sostiene.
Propiedades a nivel de sistema (9 elementos) abarca el sistema en su conjunto: nombre del sistema, componentes del sistema, productor del sistema, versión del sistema, marca de tiempo del sistema, flujo de datos del sistema, uso de datos del sistema, propiedades de entrada/salida del sistema y área de aplicación prevista. El flujo de datos del sistema es donde se declaran los protocolos multiagente, las API de servicios externos y el tráfico bidireccional de anclaje web (web-grounding), así que este es el grupo que revela si tu producto llama discretamente al modelo de otra empresa en el momento de la inferencia. Esa es precisamente la capa que nuestros proyectos de transformación de la fuerza laboral con IA agéntica tienen que mapear primero, ya que un agente que llama a otros tres modelos en tu nombre significa tres entradas más que este grupo debe registrar.
Modelos (13 elementos) es el grupo más grande: nombre del modelo, identificador del modelo, versión del modelo, marca de tiempo del modelo, productor del modelo, descripción del modelo, valor hash del modelo, algoritmo hash del modelo, propiedades del modelo, propiedades de entrada-salida del modelo, propiedades de entrenamiento del modelo, licencia del modelo y referencias externas del modelo. El par de hash es lo que más peso tiene aquí, porque sin un valor hash y el algoritmo que lo generó, cualquier otra afirmación del grupo es una aseveración que el receptor no puede comprobar.
Propiedades de los conjuntos de datos (10 elementos) abarca el nombre del conjunto de datos, la descripción del conjunto de datos, el contenido del conjunto de datos, el identificador del conjunto de datos, el hash del conjunto de datos, la procedencia del conjunto de datos, las propiedades estadísticas del conjunto de datos, la sensibilidad del conjunto de datos, la relación de dependencia del conjunto de datos y la licencia del conjunto de datos. Este es el grupo que genera discusiones internas, ya que se aplica a todos los conjuntos de datos a lo largo del ciclo de vida del modelo, incluidos los conjuntos de evaluación y de ajuste fino. Desenredar ese linaje suele ser un problema de ingeniería de datos antes que de documentación, ya que no puedes registrar una procedencia que nunca rastreaste en primer lugar.
Infraestructura (2 elementos) abarca el software de infraestructura y el hardware de infraestructura, además de un enlace a una lista de materiales de hardware cuando exista una.
Propiedades de seguridad (4 elementos) abarca los controles de seguridad, el cumplimiento de seguridad, la información sobre políticas de ciberseguridad y las referencias a vulnerabilidades.
Indicadores clave de rendimiento (2 elementos) abarca las métricas de seguridad y los KPI de rendimiento operativo. Estos tres grupos breves son los que con más frecuencia se entregan vacíos, lo cual se percibe como un inventario que se rindió pronto.
Campos autogenerados frente a campos redactados por personas
Las guías sobre cómo crear registros de AIBOM tienden a presentar el archivo como un único entregable con un solo responsable. Cincuenta elementos que abarcan código, datos, infraestructura, seguridad y aspectos legales son, por construcción, multifuncionales, y dividirlos según quién puede producirlos convierte un proyecto estancado en dos proyectos manejables. Según nuestro recuento, 27 elementos salen directamente de herramientas que la mayoría de los equipos ya utilizan, y los 23 restantes requieren un juicio humano que ningún escáner puede emitir.
Campos que genera la canalización
Todo lo que tiene forma de identidad y todo lo que tiene forma de hash pertenece a la canalización. El grupo de Metadatos es casi por completo un subproducto del paso de generación, ya que la herramienta conoce su propio nombre y versión, la marca de tiempo, el formato de datos y la fase del ciclo de vida en la que se ejecutó. Los identificadores, versiones, marcas de tiempo y hashes de modelos y conjuntos de datos salen de tu registro de modelos y de tu almacenamiento de objetos, y el grupo de Infraestructura procede de las definiciones de infraestructura como código que ya aprovisionan tus aceleradores.
Los dos elementos de indicadores de rendimiento pertenecen aquí bajo una condición: que tu sistema de evaluación escriba los resultados en algún lugar duradero. Si los generas desde la integración continua (CI) en cada versión del modelo, son correctos por construcción, mientras que volver a escribirlos trimestralmente en una hoja de cálculo los deja desactualizados en la semana posterior al siguiente despliegue.
Campos que redacta una persona
Los elementos restantes son juicios, y un escáner no tiene base alguna para emitirlos. Cada uno necesita un responsable designado:
- Área de aplicación prevista. Declarar que un clasificador funciona en un contexto médico, financiero o de ciberseguridad es una decisión de alcance con consecuencias regulatorias, y ningún análisis estático la infiere.
- Procedencia y sensibilidad del conjunto de datos. La procedencia indica de dónde vinieron los datos y en qué condiciones, y la sensibilidad indica cuánto costaría una filtración. Ambas pertenecen a la gobernanza de datos y al área legal, y ambas son lo primero que examina un revisor serio.
- Propiedades y limitaciones de entrenamiento del modelo. La versión útil indica las condiciones bajo las cuales el modelo se degrada, precisamente el material que los proveedores suavizan por instinto.
- Controles de seguridad, cumplimiento e información de políticas. Estos hacen referencia a un marco de control ya existente, así que se copian de tu programa de seguridad en lugar de generarse a partir del código.
- La firma del autor. Una firma es una decisión de gestión de claves sobre qué entidad respalda el contenido, y convierte una descripción en un compromiso.
Los campos de este grupo se quedan obsoletos en silencio, porque nada se rompe en producción cuando dejan de ser correctos. Asigna a cada uno un responsable y un disparador de revisión vinculado al reentrenamiento del modelo en lugar de a una fecha del calendario.
La analogía con el SBOM y dónde termina
La comparación entre AIBOM y SBOM se sostiene bien a nivel de propósito y se desmorona a nivel de verificación. Ambos son listas de ingredientes que permiten a un consumidor razonar sobre el riesgo de algo que no construyó, y el documento del G7 es explícito al afirmar que los sistemas de IA también son sistemas de software, por lo que los grupos de IA se añaden sobre un inventario de software convencional.
Dónde el inventario de IA amplía un inventario de software clásico
Qué describe el campo
SBOM de software clásico
Lo que añade el SBOM para IA
Qué describe el campo
SBOM de software clásico
Componentes y paquetes de software
Lo que añade el SBOM para IA
Modelos, conjuntos de datos y el sistema que los compone
Qué describe el campo
SBOM de software clásico
Nombre del componente, versión, hash
Lo que añade el SBOM para IA
Valor hash del modelo más el algoritmo hash, hash e identificador del conjunto de datos
Qué describe el campo
SBOM de software clásico
Proveedor y relación de dependencia
Lo que añade el SBOM para IA
Procedencia del conjunto de datos a lo largo de todo el ciclo de vida del modelo
Qué describe el campo
Comportamiento en tiempo de ejecución
SBOM de software clásico
Lo que añade el SBOM para IA
Flujo de datos del sistema, propiedades de entrada/salida, área de aplicación prevista
Qué describe el campo
SBOM de software clásico
Lo que añade el SBOM para IA
Licencia del modelo y licencia del conjunto de datos, incluido el estado de pesos abiertos
Qué describe el campo
SBOM de software clásico
Lo que añade el SBOM para IA
Métricas de seguridad y KPI de rendimiento operativo
Qué describe el campo
El receptor puede verificarlo por sí solo
SBOM de software clásico
Normalmente, volviendo a calcular el hash del paquete
Lo que añade el SBOM para IA
Parcialmente: los pesos se hashean con limpieza, los datos de entrenamiento no
La verificación es donde termina la analogía. Una afirmación de dependencia es barata de comprobar: descargas el paquete, calculas su hash y comparas. Una afirmación sobre la procedencia de los datos de entrenamiento sigue siendo imposible de comprobar para un receptor que no tiene ni los datos ni la capacidad de cómputo para recrear los pesos. Sanchit Vir Gogia expresó el límite con precisión en CSO Online: “Los elementos mínimos crean visibilidad. No crean garantía. Le dicen al comprador lo que el proveedor afirma que existe”.
Los autores del G7 llegan al mismo punto desde la dirección opuesta, al afirmar que un inventario de este tipo “por sí solo no es suficiente para aumentar la ciberseguridad a lo largo de la cadena de suministro” y que solo funciona cuando se integra con herramientas de escaneo de vulnerabilidades y gestión. Para un comprador, eso convierte el documento en un punto de partida para hacer preguntas, y el siguiente paso natural es una revisión independiente de la base de código y la canalización de modelos que respalde las afirmaciones. Para un proveedor, los campos que puedes respaldar con un hash o un artefacto firmado valen mucho más en una negociación que los campos que solo puedes afirmar.
Del papeleo al artefacto de producto
Los equipos que dejan de temer esta solicitud son los que integran el artefacto en la compilación. La mecánica no tiene nada de extraordinario: elige un formato legible por máquina, genera los campos automáticos en la CI en cada versión del modelo, mantén los campos redactados por personas en el control de versiones junto al código para que pasen revisión, y publica el resultado como un artefacto firmado en la versión.
La elección de formato ya está lo bastante asentada como para resultar aburrida. CycloneDX, de OWASP, incorpora un tipo de componente de modelo de aprendizaje automático y una referencia externa a la ficha de modelo (model card) creados específicamente para este fin, y la versión 1.7 de la especificación se publicó en octubre de 2025, así que las herramientas ya existen hoy en lugar de estar en una hoja de ruta. SPDX es la alternativa creíble, y la guía del G7 señala los campos de SPDX y CycloneDX como lugares aceptables para la información de licencias del modelo.
Dos decisiones de diseño hacen la mayor parte del trabajo. Genera el inventario por cada versión en lugar de por trimestre, porque un inventario cuya marca de tiempo va por detrás de tu modelo desplegado le dice a un revisor que tu proceso es decorativo. Trata los campos redactados por personas como código sometido a revisión, de modo que degradar una clasificación de sensibilidad requiera la aprobación de alguien responsable de ello.
Esto es una automatización ordinaria de artefactos de versión, y por eso a los equipos de ingeniería que añaden funciones de IA a un producto existente les conviene diseñar el paso de generación junto con la ruta de inferencia. Los equipos que tienen dificultades son aquellos en los que nadie es dueño del registro de modelos, y eso es una brecha organizativa disfrazada de problema de documentación.
La demanda de este artefacto no deja de crecer, y la lista de campos ya es lo bastante estable como para construir sobre ella con confianza. Genera el inventario una sola vez como subproducto de tu proceso de versión, y una pregunta incómoda se convierte en un enlace que pegas en un cuestionario. Si quieres ayuda para integrar ese paso de generación en una canalización que ya utilizas, contáctanos y empezaremos a partir de lo que ya tienes en lugar de una página en blanco.
Preguntas frecuentes
Es un inventario estructurado de los componentes de un sistema de IA: los modelos y cómo se produjeron sus pesos, los conjuntos de datos utilizados a lo largo del ciclo de vida del modelo, la infraestructura sobre la que se ejecuta, los controles de seguridad que se le aplican y sus indicadores de rendimiento. La guía de elementos mínimos del G7 lo organiza en siete grupos que contienen 50 elementos con nombre, uno que describe el propio documento y seis que describen el sistema.
¿Cuál es la diferencia entre SBOM y AIBOM?
Un inventario de software enumera componentes, versiones y relaciones de dependencia. La versión para IA añade grupos para modelos, conjuntos de datos, infraestructura, propiedades de seguridad e indicadores clave de rendimiento, que la guía del G7 trata como adiciones y no como un reemplazo. La diferencia práctica es la verificabilidad: quien recibe un hash de un paquete puede volver a comprobarlo, mientras que una afirmación sobre la procedencia de los datos de entrenamiento normalmente no se puede comprobar.
¿Qué debe incluir un AIBOM?
Como mínimo, los siete grupos de la guía del G7: Metadatos, Propiedades a nivel de sistema, Modelos, Propiedades de los conjuntos de datos, Infraestructura, Propiedades de seguridad e Indicadores clave de rendimiento. Los campos que más pesan en la revisión de un comprador son el valor hash del modelo y el algoritmo hash, la procedencia y sensibilidad del conjunto de datos, el flujo de datos del sistema, el área de aplicación prevista y la firma del autor.
¿Es obligatorio un AIBOM?
Los elementos mínimos del G7 son voluntarios y afirman directamente que no crean requisitos, normas ni legislación. La obligación llega, en cambio, por vía contractual, a través de cuestionarios de seguridad, condiciones de compra y programas de riesgo de proveedores, y la guía señala que, en algunas jurisdicciones, esos mismos elementos ya pueden estar incluidos en requisitos legales existentes.
Lo que realmente se descubre al analizar a fondo: más de 80 mejoras y riesgos de seguridad en una tienda de aplicaciones móviles
