Transparencia para la cadena de suministro de IA

Una SBOM clásica inventaría componentes de software y sus dependencias: bibliotecas, versiones, licencias. Sin embargo, el comportamiento de un sistema de IA está determinado en gran medida por artefactos que esa retícula no captura: el propio modelo, sus pesos, los conjuntos de datos de entrenamiento y evaluación, así como su procedencia y preprocesamiento. Un modelo puede cambiar radicalmente mediante un reentrenamiento o un fine-tuning sin que se mueva una sola línea de código ni una versión de paquete. Por eso, una AI-SBOM amplía el inventario precisamente con estos componentes, como requisito previo para poder evaluar siquiera la procedencia, la integridad y los riesgos de un sistema de IA.

CycloneDX soporta la ML-BOM desde la versión 1.5 (junio de 2023): los tipos de componente «machine-learning-model» y «data» sitúan a modelos y conjuntos de datos en pie de igualdad con las bibliotecas de software. Un objeto «modelCard» documenta la finalidad de uso, las limitaciones, los sesgos, los parámetros de entrenamiento, los conjuntos de datos utilizados, las métricas de rendimiento y las consideraciones éticas; los componentes de datos recogen, entre otros aspectos, contenidos, clasificación, datos sensibles y gobernanza. La especificación se publicó por primera vez como estándar internacional ECMA-424 en junio de 2024; la actual 2.ª edición (diciembre de 2025) se corresponde con CycloneDX 1.7 (octubre de 2025).

SPDX, el segundo gran formato de SBOM, está organizado de forma modular en perfiles desde la versión 3.0 (abril de 2024, actualmente 3.0.1 de diciembre de 2024), entre ellos un perfil AI y un perfil Dataset propios. El perfil AI describe paquetes de IA («AIPackage») con propiedades como el tipo de modelo, la información de entrenamiento, el consumo energético y una calificación del riesgo de seguridad; el perfil Dataset documenta conjuntos de datos («DatasetPackage») con su tamaño, tipo, disponibilidad, preprocesamiento, información sensible contenida y sesgos conocidos. Una versión 3.1 solo existe por ahora como release candidate, es decir, todavía en fase de borrador.

Las model cards se remontan al artículo «Model Cards for Model Reporting» (Mitchell et al., conferencia FAT* 2019): una documentación breve y estandarizada por modelo con la finalidad de uso, los resultados de evaluación en distintas condiciones —por ejemplo, entre grupos demográficos— y las limitaciones conocidas. Hoy son práctica habitual en los hubs de modelos, aunque casi siempre como texto libre sin un esquema vinculante. Con el campo «modelCard», CycloneDX traslada el concepto a un formato legible por máquina y lo hace así utilizable para comprobaciones automatizadas, decisiones de compra y evaluaciones de riesgos.

Los riesgos están documentados: en febrero de 2024, JFrog identificó unos 100 modelos maliciosos en Hugging Face cuyo código dañino se ejecuta al cargarlos, algo posible por el formato pickle, que puede ejecutar código Python arbitrario durante la deserialización y que fue durante mucho tiempo el formato estándar de los pesos de PyTorch; como contramedidas se consideran safetensors, el escaneo de imports y los artefactos firmados. El nivel de los frameworks también está afectado: mediante dependency confusion, en diciembre de 2022 se colocó en PyPI el paquete «torchtriton», que exfiltraba de las instalaciones nightly de PyTorch, entre otros, claves SSH y datos del sistema. Por ello, OWASP recoge la cadena de suministro de IA como riesgo propio de su Top 10 (LLM03:2025 Supply Chain) y recomienda explícitamente un inventario de componentes actualizado mediante SBOM o AI-BOM.

El Cyber Resilience Act (Reglamento (UE) 2024/2847) obliga a los fabricantes de productos con elementos digitales a identificar y documentar vulnerabilidades y componentes, incluida una SBOM «en un formato de uso común y legible por máquina» que cubra como mínimo los niveles superiores de dependencias (anexo I, parte II, punto 1); las obligaciones de notificación se aplican desde el 11.09.2026 y las obligaciones principales desde el 11.12.2027. El AI Act (Reglamento (UE) 2024/1689) exige para los sistemas de IA de alto riesgo una documentación técnica conforme al art. 11 y al anexo IV, entre otros aspectos sobre los conjuntos de datos (procedencia, alcance, características principales) y sobre el recurso a sistemas preentrenados o herramientas de terceros. Con arreglo al art. 53, los proveedores de modelos GPAI deben facilitar desde el 02.08.2025 una documentación técnica (anexo XI), información para los proveedores posteriores (anexo XII) y un resumen suficientemente detallado de los contenidos de entrenamiento; en lo esencial, el Reglamento se aplica a partir del 02.08.2026. Una AI-SBOM bien mantenida proporciona la base de datos para ambos actos legislativos.