Parámetros de un AIBOM: checklist campo a campo

Un AIBOM (AI Bill of Materials, o lista de materiales de IA) es tan útil como los campos que recoge. Un documento que dice «usamos un LLM» es teatro; uno que nombra cada modelo, dataset, dependencia, licencia y riesgo conocido es un activo que puedes auditar, entregar a un cliente o presentar ante un regulador. Este es el checklist campo a campo de lo que hay que poner en uno (y por qué cada parámetro se gana su sitio), relacionado con los dos estándares que importan: CycloneDX ML-BOM y el SPDX 3.0 AI Profile.

¿Eres nuevo en esto? Empieza por qué es un AIBOM y por qué importa, y por la distinción entre SBOM, AIBOM y MLBOM. Este artículo es el complemento de «qué campos» de nuestra guía sobre cómo construir un AIBOM.

Por qué importan los parámetros

Los AIBOM han pasado de ser un artefacto de investigación a un requisito de compra: los compradores empresariales ya los piden en la diligencia debida, y la documentación de los sistemas de alto riesgo en regímenes como la Ley de IA de la UE espera un contenido equivalente. Todo el valor está en los campos. La falta de un campo de licencia es la forma en que una licencia de modelo no comercial o copyleft acaba en silencio en un producto de pago. La falta de un campo de procedencia del dataset es la forma en que unos datos de entrenamiento que no puedes usar legalmente acaban incorporados a un modelo. La falta de un campo de versión es la forma en que no puedes responder a «¿estamos afectados?» cuando se revela una vulnerabilidad en un modelo o en una biblioteca. Cada parámetro de este artículo existe porque su ausencia ya ha quemado a alguien.

Los parámetros, campo a campo

1. Modelos: todos, como componentes de primer nivel

Cada modelo base y cada fine-tune es un componente propio. Recoge:

• Nombre y versión: el modelo y la revisión o el commit exactos, para que «¿estamos afectados?» tenga respuesta.
• Fuente / registro: de dónde procede (repositorio de Hugging Face, registro interno, API de un proveedor), la señal de procedencia más importante.
• Licencia: la licencia del modelo y cualquier condición de uso aceptable. Es el campo que detecta la trampa silenciosa de las licencias.
• Model card / uso previsto: propósito, usos previstos y usos fuera del alcance.
• Arquitectura y tamaño: familia, número de parámetros y modalidad.
• Relación: en un fine-tune, de qué modelo base deriva. Identidad, procedencia y linaje en el AIBOM explica cómo registrarlo.

2. Datasets: de entrenamiento y de evaluación

• Nombre y fuente: cada dataset de entrenamiento y de evaluación y de dónde procede.
• Licencia y derechos de uso: si puedes usarlo del modo en que lo estás usando.
• Procedencia: origen y método de recogida; sintético, extraído por scraping o con licencia.
• Indicadores de sensibilidad: datos personales, contenido regulado o protegido por derechos de autor presente en los datos. La sección de datos del AIBOM rellena cada uno de ellos en un ejemplo práctico.

3. Dependencias de código de IA/ML: la capa SBOM

Un AIBOM sigue conteniendo debajo un SBOM normal: los frameworks y las bibliotecas (la pila de ML, la capa de servicio, la orquestación) fijados a versiones y licencias, para que las comprobaciones de vulnerabilidades conocidas y de licencias funcionen exactamente igual que con cualquier software. Nuestro AI Dependency Scanner → las lee de un manifiesto.

4. Configuración y ejecución

• Configuración de entrenamiento: método (preentrenamiento, fine-tune, LoRA, RAG) y los hiperparámetros clave cuando puedan revelarse.
• Configuración de inferencia: configuración de servicio, límites de contexto y el acceso a herramientas o funciones que se concede al modelo. La sección de seguridad y ejecución del AIBOM cubre las herramientas, los servidores MCP y los índices RAG.
• Contexto de despliegue: dónde se ejecuta realmente (nube, local, edge), porque un modelo con acceso a herramientas en producción supone un riesgo distinto al de los mismos pesos en un portátil.

5. Metadatos de riesgo y de aseguramiento

• Métricas de rendimiento y de evaluación: cómo se midió y sobre qué. Consulta evaluación, uso previsto, limitaciones y riesgo en el AIBOM.
• Consideraciones de sesgo y de seguridad: limitaciones documentadas y modos de fallo conocidos.
• Vulnerabilidades conocidas (CVE): del modelo, de su cargador y de sus dependencias.
• Procedencia e integridad: firma o atestación y un hash de los pesos, para que puedas demostrar lo que publicaste. Combínalo con un análisis: nuestro Model Risk Scanner → evalúa un modelo de Hugging Face frente a políticas de riesgo antes de que entre en tu entorno.

6. Metadatos y formato del documento

• Autor, fecha y versión del propio AIBOM, y el proveedor al que describe.
• Un estándar legible por máquina: CycloneDX ML-BOM (tipos de componente machine-learning-model + data; habitual en las herramientas de seguridad y de CI/CD) o el SPDX 3.0 AI Profile (tipo de modelo, métodos de entrenamiento, tratamiento de datos, explicabilidad, limitaciones, consumo de energía; con raíces en la Linux Foundation y en ISO, a menudo preferido para las presentaciones regulatorias). Un PDF no es un AIBOM: tus herramientas no pueden leerlo.

El checklist de AIBOM listo para copiar

Pásalo por cualquier AIBOM que produzcas o recibas:

• ☐ Cada modelo base y cada fine-tune figura como componente propio (nombre + versión + fuente)
• ☐ Una licencia en cada modelo y en cada dataset
• ☐ Procedencia de cada modelo (registro o repositorio) y de cada dataset (origen + método de recogida)
• ☐ Indicadores de datos sensibles en los datasets (datos personales / regulados / protegidos por derechos de autor)
• ☐ Dependencias de código de IA/ML fijadas a versiones y licencias
• ☐ Configuración de entrenamiento y de inferencia, y dónde se ejecuta el modelo
• ☐ Métricas de evaluación y limitaciones documentadas de sesgo y de seguridad
• ☐ CVE conocidos del modelo, del cargador y de las dependencias
• ☐ Integridad: un hash de los pesos y una firma o atestación
• ☐ Metadatos del documento (autor, fecha, proveedor) en CycloneDX ML-BOM o SPDX 3.0 AI Profile, no en un PDF

Genera y comprueba un AIBOM en PlayCISO

No necesitas la licencia de una plataforma para empezar. Estas herramientas de AIBOM forman parte de PlayCISO Pro, y una cuenta gratuita incluye 3 usos de herramientas Pro:

• Generador de AI BOM →: convierte un package.json o un manifiesto de modelos y datasets en un inventario al estilo CycloneDX con una lectura del riesgo de licencia por componente.
• AIBOM Template →: una estructura de partida correcta para que no se olvide ningún campo.
• AIBOM Validator →: comprueba que un AIBOM es estructuralmente válido y está completo.
• ML-BOM Converter →: produce un CycloneDX ML-BOM a partir de tus datos de modelos y datasets.
• AIBOM Diff →: muestra exactamente qué cambió entre dos AIBOM de una versión a otra.
• Model License Checker →: señala la licencia no comercial o copyleft antes de que se publique.

Ejemplos de código abierto de los que aprender (GitHub)

Si quieres referencias reales y funcionales de los campos anteriores:

• OWASP AIBOM Generator: extrae metadatos de modelos de Hugging Face a un AIBOM en CycloneDX y puntúa lo completo que está (un buen modelo de qué campos rellenar).
• cdxgen (CycloneDX): genera BOM para muchos ecosistemas y se integra en CI/CD y en Dependency-Track.
• CycloneDX Tool Center y SPDX: las propias especificaciones, que definen con precisión cada campo.

Un AIBOM sin estos campos es un documento; un AIBOM con ellos es un control. Recoge los parámetros, emítelos en un estándar legible por máquina y podrás responder a cualquier pregunta sobre la cadena de suministro que un cliente, un auditor o un incidente te planteen alguna vez sobre tu IA. Siguiente paso: compara las herramientas y los proveedores de AIBOM que los producen, y lee qué es un ML-BOM para la capa específica de los modelos.

Crea el primero ahora con el generador de AI BOM, valídalo con el AIBOM Validator y mantente al día de la seguridad de la cadena de suministro de IA en PlayCISO AI Labs.