Lista de materiales de IA (AI-BOM)

Una lista de materiales de IA (AI-BOM) es un inventario estructurado de cada componente que forma un sistema de IA: los modelos, los conjuntos de datos, las librerías, las dependencias y las fuentes de los datos de entrenamiento.

La idea se toma directamente de la lista de materiales de software (SBOM), que enumera los componentes de terceros y los de código disponible dentro de una pieza de software. Una SBOM responde a la pregunta "¿qué hay realmente en este producto?". La AI-BOM extiende esa pregunta a las partes propias del aprendizaje automático, donde los pesos del modelo y los datos importan tanto como el código.

Esto importa porque los sistemas de IA se ensamblan, no se escriben desde cero. Un despliegue típico cose un modelo base, varias librerías de Python, un conjunto de datos de ajuste fino, una base de datos vectorial y un puñado de APIs. Cuando algo sale mal, o cuando un regulador pregunta con qué lo construiste, necesitas un registro. Sin él, estás adivinando.

Para los equipos de gobernanza, riesgo y seguridad, la AI-BOM se está convirtiendo en la unidad básica de rendición de cuentas. No puedes gestionar lo que no puedes ver, y una AI-BOM hace visible la cadena de suministro.

Por qué la analogía con la SBOM encaja, y dónde se rompe

La SBOM cobró relevancia en parte por los ataques a la cadena de suministro, donde una sola dependencia comprometida se propagaba a miles de productos. Reguladores y compradores empezaron a exigir una lista de ingredientes para poder revisar rápido las vulnerabilidades conocidas.

Los sistemas de IA enfrentan el mismo problema de dependencias y algo más. Un modelo puede cargar riesgos que no tienen equivalente en el software ordinario: datos de entrenamiento con problemas de derechos de autor o privacidad, sesgos ocultos incrustados en los pesos, un modelo base con procedencia desconocida o un conjunto de datos envenenado que altera el comportamiento de forma sutil.

Así que la AI-BOM conserva el propósito central de la SBOM, conocer tus ingredientes, pero lo amplía. Las dependencias de código son solo una parte. Los datos y el linaje del modelo suelen ser las partes que cargan más peso legal y ético.

Qué debería contener una AI-BOM

Una AI-BOM útil va más allá de una lista plana de nombres de paquetes. Como mínimo debería registrar:

• Modelos. Cada modelo del sistema, incluyendo modelos base y variantes ajustadas, con versión, fuente, licencia y proveedor.

• Conjuntos de datos. Conjuntos de entrenamiento, validación y ajuste fino, con sus fuentes, licencias, fechas de recolección y cualquier restricción de uso conocida.

• Procedencia de los datos de entrenamiento. De dónde vinieron los datos, cómo se recolectaron, si incluyen material personal o protegido por derechos de autor, y qué consentimiento o licencia los cubre.

• Librerías y frameworks. Frameworks de aprendizaje automático, motores de inferencia y paquetes de apoyo, con versiones, igual que los lista una SBOM.

• Dependencias. Dependencias transitivas arrastradas por esas librerías, ya que una vulnerabilidad a tres niveles de profundidad sigue siendo una vulnerabilidad.

• Servicios externos. APIs, modelos alojados y endpoints de terceros que el sistema llama en tiempo de ejecución.

• Configuración y pesos. Referencias a los pesos del modelo, los puntos de control y los hiperparámetros clave que definen el artefacto desplegado.

El objetivo es que alguien que nunca ha visto el sistema pueda leer la AI-BOM y entender de qué está hecho, de dónde vino cada pieza y qué obligaciones la acompañan.

Por qué reguladores y equipos de seguridad la esperan

Varias presiones convergen para volver la AI-BOM una expectativa y no un extra deseable.

La regulación es una. La Ley de IA de la UE exige documentación técnica detallada para los sistemas de alto riesgo, incluida información sobre los datos y los componentes del sistema. Una AI-BOM es una forma natural de producir parte de esa documentación.

La seguridad es otra. A medida que la IA llega a producción, los atacantes sondean la cadena de suministro de IA: modelos maliciosos publicados en repositorios públicos, conjuntos de datos envenenados y librerías comprometidas. Los equipos de seguridad necesitan un inventario para evaluar la exposición cuando se divulga una nueva vulnerabilidad o un componente malicioso.

La adquisición es una tercera. Cada vez más, los compradores preguntan a los proveedores con qué están construidos sus sistemas de IA antes de firmar. Un proveedor que puede entregar una AI-BOM parece mucho más confiable que uno que no puede dar cuenta de su propia pila.

Cómo la construyen y mantienen los equipos

Una AI-BOM solo vale si se mantiene actualizada. El enfoque práctico es generarla como parte del pipeline de construcción y entrenamiento, en lugar de armarla a mano después de los hechos.

Empieza por capturar lo que ya rastreas. Los gestores de paquetes conocen las versiones de tus librerías. Los registros de modelos conocen las versiones de tus modelos. Los catálogos de datos conocen tus conjuntos de datos. Buena parte de una AI-BOM puede armarse a partir de sistemas que ya operas.

Cubre los vacíos que la automatización omite, sobre todo la procedencia de los datos. De dónde vino un conjunto de datos y qué licencia lo cubre suele ser lo más difícil de reconstruir, así que regístralo en el momento de la recolección.

Versiona la AI-BOM junto con el sistema. Cada cambio significativo, un nuevo modelo base, un ajuste fino, una librería reemplazada, debería producir una nueva AI-BOM para que puedas rastrear exactamente qué se desplegó y cuándo.

Guárdala donde quienes la necesitan puedan encontrarla: seguridad, legal y cumplimiento, no solo el equipo de ingeniería que la produjo.

Preguntas frecuentes

¿En qué se diferencia una AI-BOM de una SBOM?

Una SBOM enumera los componentes de software de un producto, principalmente librerías de código y sus dependencias. Una AI-BOM incluye esos, pero agrega las piezas propias del aprendizaje automático: modelos, conjuntos de datos, fuentes de datos de entrenamiento, pesos y procedencia del modelo. Puedes pensar en la AI-BOM como un superconjunto que cubre las partes de un sistema de IA que un inventario de software ordinario pasaría por alto.

¿La AI-BOM es obligatoria por ley?

Ninguna ley usa ese término exacto ni lo exige, pero la información subyacente se requiere cada vez más. La Ley de IA de la UE exige documentación técnica para los sistemas de alto riesgo que cubra datos y componentes, y los estándares de adquisición y seguridad empujan en la misma dirección. Una AI-BOM es un formato práctico para cumplir esas expectativas.

¿Quién es responsable de producir la AI-BOM?

Por lo general, el equipo que construye o ensambla el sistema de IA, trabajando con seguridad, legal y gobernanza de datos. Los proveedores de modelos pueden aportar parte de ella para sus propios modelos, y quienes despliegan la extienden para cubrir cómo ajustaron, configuraron e integraron el sistema.

¿Qué es lo más difícil de capturar en una AI-BOM?

La procedencia de los datos. Las versiones de librerías y de modelos las rastrean las herramientas, pero el origen, la licencia y el estado de consentimiento de los datos de entrenamiento suelen estar mal documentados, sobre todo en conjuntos antiguos o en fuentes extraídas de la web. Capturar esto en el momento de la recolección es mucho más fácil que reconstruirlo después.

¿Una AI-BOM ayuda con los incidentes de seguridad?

Sí. Cuando se divulga una vulnerabilidad en una librería, se encuentra un modelo malicioso en un repositorio público o se demuestra que un conjunto de datos está envenenado, una AI-BOM te permite responder rápido si tus sistemas están afectados. Sin ella, tienes que investigar cada sistema a mano, lo que es lento y propenso a errores.

¿Debería compartir mi AI-BOM con los clientes?

Depende de la sensibilidad. Muchos proveedores comparten una versión con los compradores durante la adquisición para demostrar transparencia, a veces censurando detalles propietarios. De forma interna, una versión más completa apoya el trabajo de seguridad y cumplimiento. El nivel de divulgación es una decisión de negocio y de riesgo.

Resumen

Una lista de materiales de IA es la lista de ingredientes de un sistema de IA, que extiende el concepto de la lista de materiales de software para cubrir modelos, conjuntos de datos, procedencia de los datos de entrenamiento, librerías y dependencias. Reguladores, equipos de seguridad y compradores la esperan cada vez más, porque los sistemas de IA se ensamblan a partir de muchas partes de terceros, cada una con su propia carga legal, ética y de seguridad. Las AI-BOM más confiables se generan de forma automática como parte del pipeline de construcción y entrenamiento, se mantienen versionadas junto con el sistema y se ponen a disposición de las funciones de seguridad, legal y cumplimiento, que dependen de saber con exactitud de qué está hecho un sistema de IA.