Lista de materiales de IA (AIBOM): Guía completa

Una lista de materiales de IA (AIBOM) es un inventario estructurado de los conjuntos de datos, modelos y dependencias de un sistema de IA, que aporta transparencia a la cadena de suministro de IA.

¿Qué es una lista de materiales de IA (AIBOM)?

En mayo de 2026, un repositorio malicioso de Hugging Face que suplantaba una versión oficial de OpenAI alcanzó la posición número uno de tendencias de la plataforma antes de ser marcado y eliminado. Tras copiar la tarjeta del modelo auténtico casi línea por línea, el listado parecía legítimo, y cualquiera que ya lo hubiera descargado no tenía forma de saberlo, porque un análisis de dependencias de software inspecciona bibliotecas y paquetes, mientras que el compromiso residía en el propio modelo.

Una lista de materiales de IA (AIBOM) le ofrece lo que ese análisis no pudo: una forma de saber si un modelo comprometido o un conjunto de datos envenenado ya está en su entorno.

Una AIBOM es un inventario estructurado de los conjuntos de datos, modelos, marcos de trabajo y dependencias que componen un sistema de IA, con la procedencia de cada componente registrada. Cubre los activos cuyos orígenes, de otro modo, no están documentados: datos de terceros, modelos preentrenados y bibliotecas de código abierto.

Cómo se relaciona una AIBOM con una lista de materiales de software

Una lista de materiales de software enumera los componentes de software y las dependencias de una aplicación: bibliotecas, paquetes, identificadores de versión y licencias. Una AIBOM amplía esa práctica de inventario a activos específicos de IA, incluidos datos de entrenamiento, pesos del modelo, procedencia del modelo y líneas base de rendimiento. CycloneDX, el estándar BOM de OWASP, implementa esto al definir SBOM y AI/ML-BOM como tipos de BOM interoperables.

Componentes principales de una AIBOM

Una AIBOM registra el conjunto completo de componentes que definen la composición, el origen y el perfil operativo de un sistema de IA. La guía de mayo de 2026 del Grupo de Trabajo de Ciberseguridad del G7, publicada como elementos mínimos de AI SBOM de CISA, organiza estos componentes en siete grupos.

Grupo de componentes	Qué captura	Por qué pertenece
Metadatos	Autor de la AIBOM, fecha de creación, versión del esquema, identificador del documento	Establece la cadena de custodia del artefacto de inventario
Propiedades a nivel de sistema	Dependencias de software, marcos de trabajo, entornos de ejecución, lógica de procesamiento de datos	Se corresponde con el contenido tradicional de un SBOM; permite el seguimiento de CVE
Modelos	Identidad del modelo, arquitectura, cómo se produjeron los pesos (entrenado, ajustado o destilado), limitaciones documentadas	Los pesos del modelo no tienen equivalente en un gestor de paquetes; la procedencia permite identificar manipulaciones
Propiedades del conjunto de datos	Identidad, procedencia, licencias, metodología de recopilación y preprocesamiento aplicado de los conjuntos de datos de entrenamiento, validación y prueba	El envenenamiento de datos no puede identificarse mediante análisis de software; los registros de procedencia permiten rastrear si los datos de entrenamiento fueron manipulados
Indicadores clave de rendimiento	Referencias de exactitud, equidad y resiliencia adversaria registradas en el despliegue	Establece líneas base de comportamiento; la degradación puede indicar manipulación adversaria
Infraestructura	Infraestructura física y virtual, enlaces a Hardware BOM para hardware de IA especializado (GPUs, TPUs)	Documenta el entorno de cómputo que produjo y ejecuta el modelo
Estructura del documento y cadencia de actualización	Control de versiones del formato AIBOM, desencadenantes de actualización, registros de transición del ciclo de vida	Define cuándo y cómo se actualiza el inventario; vincula cada transición del ciclo de vida con los cambios requeridos en los grupos afectados

Estos siete grupos describen lo que contiene una AIBOM. Cuándo se completa cada uno depende del ciclo de vida del modelo: el registro se construye por etapas, no en una sola pasada.

Cómo se genera y mantiene una AIBOM a lo largo del ciclo de vida del modelo

Un registro AIBOM toma forma a lo largo de cuatro etapas del ciclo de vida, y cada etapa completa grupos específicos de la taxonomía de componentes anterior.

1. Obtención y preparación de datos. La AIBOM comienza aquí con las Propiedades del conjunto de datos: se captura la identidad, procedencia, licencias e integridad de cada conjunto de datos de entrenamiento, validación y prueba antes de que comience el entrenamiento del modelo. Actualice este grupo en la recopilación inicial y en cada evento de reentrenamiento o ajuste fino.
2. Entrenamiento y ajuste fino del modelo. Durante el entrenamiento, se registra la vinculación entre los conjuntos de datos de entrada, el código de entrenamiento, las configuraciones de hiperparámetros y los pesos del modelo resultantes. Los eventos de ajuste fino requieren actualizaciones tanto del grupo de modelos como del grupo de conjuntos de datos.
3. Compilación y despliegue. En el despliegue, se completa por completo el grupo de Propiedades a nivel de sistema con dependencias de software, marcos de trabajo y detalles del entorno de ejecución. Se registran los valores de referencia de KPI. Los componentes de infraestructura se documentan o se vinculan mediante un HBOM.
4. Supervisión y mantenimiento continuos. El mantenimiento de la AIBOM está impulsado por eventos. Los cambios en cualquier componente de los siete grupos desencadenan actualizaciones, incluidos modelos reentrenados, dependencias corregidas, versiones de conjuntos de datos y cambios de infraestructura. Las herramientas de descubrimiento autónomo y los formatos legibles por máquina mantienen la precisión del registro al actualizarlo cuando se producen cambios.

A lo largo de estas cuatro etapas, una AIBOM solo sigue siendo fiable cuando su formato y sus reglas de actualización se fijan de antemano, que es lo que especifican los estándares actuales.

Estándares y marcos de trabajo de AIBOM

Cuatro estándares interrelacionados forman la base autorizada actual para la implementación de AIBOM. Cada uno aborda una capa diferente de la pila de gobernanza.

1. Marco de Gestión de Riesgos de IA de NIST. El Marco de Gestión de Riesgos de IA de NIST establece la trazabilidad y la responsabilidad como propiedades fundamentales para una IA confiable. Su primera versión, AI RMF 1.0, estableció esa línea base en enero de 2023, y el Perfil de IA generativa la amplió a los sistemas generativos en julio de 2024. El informe de abril de 2025 de NIST AI 100-5e2025 vincula explícitamente las cadenas de suministro de IA con los mecanismos SBOM, haciendo referencia a tarjetas de modelos y datos junto con listas de materiales de software como instrumentos de transparencia.
2. OWASP CycloneDX ML-BOM. La capacidad ML-BOM, introducida en CycloneDX v1.5 y ampliada en versiones posteriores, representa conjuntos de datos, modelos y configuraciones para sistemas de IA/ML, incluida la documentación de procedencia y consideraciones éticas para los conjuntos de datos.
3. Perfiles de IA y conjuntos de datos de SPDX 3.0. SPDX, un estándar ISO/IEC, añadió perfiles de IA y conjuntos de datos en la versión 3.0. Estos perfiles documentan modelos de IA, datos de entrenamiento, plantillas de prompts, agentes de IA y licencias.
4. Elementos mínimos de CISA y G7. CISA publicó los elementos mínimos de SBOM que cubren software de IA en agosto de 2025. En mayo de 2026, agencias de ciberseguridad de todos los estados miembros del G7 más la UE publicaron una guía conjunta que define siete grupos de elementos potenciales para AI SBOM, establecidos en la guía conjunta del G7.

La adopción de AIBOM sigue siendo temprana, y las implementaciones actuales suelen ser incompletas o inexactas. Pero los estándares le proporcionan una base sobre la que construir.

Por qué una AIBOM importa para la seguridad, el cumplimiento y la auditabilidad

Para la seguridad, una AIBOM registra la procedencia del conjunto de datos y las sumas de verificación de los pesos del modelo para que los equipos puedan investigar si los modelos fueron entrenados con datos manipulados. Cuando las vulnerabilidades o los componentes comprometidos afectan a la infraestructura de IA, la AIBOM le indica qué sistemas están afectados.

Para el cumplimiento, la Ley de IA de la UE incluye obligaciones de transparencia y documentación para determinados sistemas y modelos de IA, incluida la documentación técnica y los resúmenes del contenido de entrenamiento. Una AIBOM respalda esas obligaciones al crear un registro estructurado de composición.

Para la auditabilidad, la AIBOM ofrece a los auditores y a los equipos de respuesta a incidentes una respuesta trazable y versionada cuando preguntan de qué se construyó un sistema de IA específico. El registro muestra qué conjuntos de datos lo entrenaron, qué pesos del modelo están desplegados y qué marcos de trabajo y dependencias lo respaldan. Sin este registro, su respuesta a cualquier pregunta de auditoría sobre la composición de IA es, en el mejor de los casos, un esfuerzo de reconstrucción.

Cada uno de esos resultados supone que el registro es preciso y actual. Alcanzar ese estado a escala empresarial se enfrenta a restricciones estructurales que el esfuerzo por sí solo no elimina.

Desafíos en la implementación de una AIBOM

Las restricciones estructurales dificultan la implementación de AIBOM independientemente de la madurez organizativa o de los recursos disponibles.

• Inmadurez de estándares y herramientas. CycloneDX ML-BOM, los perfiles de IA de SPDX 3.0 y la guía del G7 llegaron recientemente, por lo que las prácticas y herramientas aún se están asentando.
• Modelos opacos de terceros. Los modelos fundacionales propietarios a los que se accede mediante API de inferencia revelan poco sobre sus componentes internos. Puede registrar nombre, versión, endpoint, controles de acceso y certificaciones del proveedor, pero la composición completa de los modelos cerrados sigue fuera de alcance.
• Procedencia de los datos de entrenamiento. En el caso de modelos entrenados externamente, es posible que la procedencia nunca se revele. En el caso de modelos internos, debe capturarla durante el entrenamiento, porque la reconstrucción posterior no es fiable.
• Versionado rápido de modelos. Cada reentrenamiento o cambio de parámetros crea una nueva versión efectiva con su propio perfil de riesgo, lo que produce una proliferación de versiones que ningún proceso manual puede seguir a escala.
• Entornos heterogéneos. La IA empresarial abarca proveedores de nube, infraestructura local, herramientas de IA SaaS, IA integrada en aplicaciones de terceros, sistemas agénticos y bases de datos vectoriales.

Estas restricciones son externas, por lo que lo máximo que puede hacer es diseñar en torno a ellas. Los fallos de la siguiente sección son lo contrario, y está en sus manos prevenirlos.

Errores comunes en la implementación de AIBOM

Error	Consecuencia
Tratar la AIBOM como un documento único producido para una auditoría	La respuesta a incidentes toma decisiones a partir de un registro que ya no refleja la producción
Mantener el inventario manualmente	La velocidad de cambio de modelos, conjuntos de datos y API supera cualquier proceso operado por humanos, por lo que el registro queda desactualizado
Registrar nombres y versiones de modelos sin procedencia	El envenenamiento de datos y modelos sigue sin poder identificarse, porque la identificación depende del linaje del entrenamiento, las sumas de verificación de los pesos y los metadatos de ejecución que no pueden reconstruirse posteriormente
Ejecutar la AIBOM como un archivo de cumplimiento independiente desconectado de las herramientas de ingeniería	Se forman dos inventarios y divergen; la guía SBOM de CISA define la lista de materiales como un inventario anidado para el riesgo de la cadena de suministro, y ejecutar la AIBOM fuera de la cadena de herramientas SBOM rompe ese vínculo
Limitar el alcance del inventario a la IA aprobada por TI y omitir la IA en la sombra	Permanece un punto ciego sistemático en el registro

Cada error anterior es una elección de proceso, por lo que cada uno tiene una corrección de proceso. Las prácticas siguientes convierten el inventario de un archivo estático en un control operativo.

Mejores prácticas de AIBOM

Las siguientes acciones llevan su programa AIBOM de documentación estática a un instrumento operativo de gobernanza.

• Implemente descubrimiento y generación autónomos. Intégrelo en registros de modelos, puertas de enlace de API e inventarios de servicios de IA en la nube.
• Estandarice en un formato legible por máquina. Genere CycloneDX ML-BOM o perfiles de IA de SPDX 3.0. Las hojas de cálculo legibles por humanos no pueden alimentar los flujos de trabajo que operacionalizan el valor de seguridad del inventario.
• Capture la procedencia en el origen. Registre identificadores de conjuntos de datos de entrenamiento y ajuste fino, sumas de verificación de pesos del modelo, metadatos de ejecuciones de entrenamiento y fijaciones de versión de API de inferencia. Para modelos internos, instrumente el seguimiento de procedencia en la canalización de ML en el momento del entrenamiento.
• Condicione CI/CD a la AIBOM. Genere la AIBOM al crear artefactos de entrenamiento, en eventos de envío al registro y en cambios de configuración de despliegue, y trate una AIBOM ausente o desactualizada como un fallo de la canalización que detiene la promoción al siguiente entorno.
• Supervise la deriva de forma continua. Compare los hashes de los artefactos de modelos desplegados con los hashes registrados en la AIBOM en cada evento de despliegue. Una cadencia impulsada por eventos es lo que separa un registro de gobernanza de un documento obsoleto.
• Encuentre la IA en la sombra mediante descubrimiento activo. Identifique conexiones a endpoints de inferencia de IA conocidos y añada los activos descubiertos a la AIBOM con una clasificación explícita de riesgo no gobernado.

Estas prácticas convierten su AIBOM de un artefacto de auditoría en un registro vivo. Ejecutarlas a escala de nube requiere herramientas, y ahí es donde entra en juego la AI Security Posture Management de SentinelOne.

Mejore la gobernanza de AIBOM con SentinelOne

Una AIBOM es tan buena como el descubrimiento que la alimenta. Singularity Cloud Security, la Cloud-Native Application Protection Platform de SentinelOne, crea y mantiene una AIBOM en entornos de nube mediante su capacidad de AI Security Posture Management (AI-SPM), con Data Security Posture Management (DSPM) integrada para la capa de datos.

• Descubrimiento que completa el inventario. AI-SPM encuentra las canalizaciones de IA, los modelos de ML y las dependencias que se ejecutan en su entorno, incluidos trabajos en servicios como Amazon SageMaker. Como cubre tanto la IA aprobada como la IA en la sombra, cada componente que enumera se convierte en una posible entrada de AIBOM sin puntos ciegos silenciosos.
• Contexto de riesgo sobre el registro. Las comprobaciones de configuración y Verified Exploit Paths muestran qué componentes catalogados están mal configurados o son explotables, y DSPM mantiene los datos de alto riesgo fuera de las canalizaciones de IA mediante una compuerta segura para entrenar. Prompt Security inspecciona prompts y respuestas y gobierna la IA agéntica, ampliando la gobernanza de su AIBOM a la capa de ejecución.
• Validación en toda la plataforma. La Singularity Platform unifica la telemetría de endpoint, nube e identidad en un único lago de datos, para que pueda confirmar que el entorno desplegado sigue coincidiendo con su AIBOM. Cuando se desvía, Purple AI interviene, un analista en lenguaje natural que investiga de forma autónoma en esos mismos datos. Según IDC, los clientes de Purple AI observaron una identificación de amenazas un 63 % más rápida y una reducción del 55 % en el tiempo medio de respuesta (MTTR). 

Reserve una demostración de SentinelOne para evaluar el riesgo de su cadena de suministro de IA y crear un programa de gobernanza de IA defendible en todos sus entornos de nube.

Conclusiones clave

Una AIBOM inventaría los conjuntos de datos, modelos, marcos de trabajo y dependencias detrás de un sistema de IA y registra de dónde proviene cada componente. Amplía la práctica establecida de SBOM a activos específicos de IA, como datos de entrenamiento, pesos del modelo y procedencia del modelo. 

Los estándares de NIST, OWASP CycloneDX, SPDX y el G7 definen lo que registra una AIBOM. El inventario importa para la seguridad, el cumplimiento y la auditabilidad, pero requiere descubrimiento autónomo, formatos legibles por máquina, captura de procedencia e integración con CI/CD para seguir siendo preciso a medida que cambian los modelos. Si se hace bien, la AIBOM deja de ser papeleo y se convierte en un control sobre el que puede actuar.

Preguntas frecuentes

¿Qué es una lista de materiales de IA?

Una lista de materiales de IA, o AIBOM, es un inventario legible por máquina de los componentes de un sistema de IA: sus conjuntos de datos, modelos, marcos de trabajo, dependencias de software y metadatos como la procedencia y las licencias. Su propósito es operativo.

Cuando se descubre que un modelo está comprometido o se demuestra que un conjunto de datos ha sido envenenado, el AIBOM es lo que le permite responder, con evidencia, cuáles de sus sistemas contienen ese componente y cuándo ingresó en ellos. Sin él, esa respuesta se convierte en un esfuerzo de reconstrucción bajo presión de tiempo.

¿Se puede crear un AIBOM para un modelo cerrado o de terceros?

En parte. Para un modelo fundacional cerrado al que se accede mediante una API de inferencia, no puede registrar la composición interna completa, porque el proveedor no divulga sus datos de entrenamiento ni sus pesos. Aun así, puede capturar y fijar lo que se puede conocer: nombre del modelo, versión, endpoint de API, controles de acceso y cualquier certificación del proveedor. 

Registre esos elementos como una entrada AIBOM de primera clase y marque explícitamente los campos no divulgados, para que el inventario muestre dónde termina la transparencia y no deje ningún vacío silencioso.

¿Qué debe incluir un AIBOM?

La guía de mayo de 2026 del G7 organiza el contenido del AIBOM en siete grupos: metadatos, propiedades del software a nivel de sistema, identidad del modelo y procedencia de los pesos, propiedades del conjunto de datos, indicadores clave de rendimiento, documentación de la infraestructura y estructura del documento con registros de la cadencia de actualización. 

En conjunto, esos grupos documentan cómo se creó un sistema de IA, sobre qué se ejecuta y cómo cambia el inventario a lo largo del ciclo de vida.

¿Qué estándares se aplican a los AIBOM?

Cuatro estándares y marcos sustentan la práctica actual de AIBOM. El Marco de Gestión de Riesgos de IA del NIST establece expectativas de gobernanza y trazabilidad. OWASP CycloneDX ML-BOM y perfiles de IA de SPDX 3.0, un estándar ISO/IEC, proporcionan especificaciones de formato legibles por máquina para modelos y conjuntos de datos. 

Los elementos mínimos de SBOM de CISA y la guía de siete grupos del G7 definen lo que debe abarcar la transparencia de los sistemas de IA. En conjunto, amplían los enfoques establecidos de SBOM hacia modelos de inventario de IA.

¿Cómo se mantiene un AIBOM actualizado a medida que cambian los modelos?

Trate el AIBOM como un registro impulsado por eventos vinculado a su canalización de ML. Active actualizaciones en la creación de artefactos de entrenamiento del modelo, eventos de envío al registro, reentrenamiento, ajuste fino y cambios en la configuración de implementación. Compare los hashes de los modelos implementados con los hashes registrados y genere alertas sobre nuevos endpoints de inferencia o entradas del registro sin un registro AIBOM correspondiente.

Las herramientas de gestión de la postura de seguridad de la IA pueden ejecutar estas comprobaciones de forma continua y señalar la deriva a medida que ocurre. Cuando la generación es un paso obligatorio de CI/CD, los inventarios desactualizados detienen la promoción antes de que un modelo sin gobernanza llegue a producción.