AI-BOM: el inventario de componentes de IA que hay que pedir

El inventario de componentes de IA (AI-BOM, por AI Bill of Materials) es la lista, con fecha de corte, de todos los modelos, bibliotecas de inferencia y terceros que participan en un servicio con inteligencia artificial, con su proveedor, nombre, versión fijada, naturaleza (pesos abiertos o cerrados), función, país y alcance del acceso a datos. Es la primera hoja que hay que pedirle a un proveedor porque las tres preguntas que un comprador regulado necesita responder —¿mis datos salen del país?, ¿alguien los retiene o entrena con ellos?, ¿estoy expuesto a esta vulnerabilidad recién publicada?— no tienen respuesta sin ella. En Innova y Cree lo entregamos como un documento de dos páginas con cuatro tablas, y en este artículo explicamos cómo debe construirse, en qué se parece y en qué difiere de un SBOM, por qué la versión fijada importa y cómo leerlo como comprador. La plantilla en formato de hoja de cálculo se descarga al final. Este artículo forma parte de la serie sobre cómo evaluar a un proveedor de IA en Chile y acompaña a la política de IA responsable.

Qué es un AI-BOM

Un AI-BOM es un inventario estructurado de los componentes de inteligencia artificial de un sistema en producción: qué modelos se ejecutan, con qué versión, de quién son, dónde corren, qué bibliotecas los sirven y qué terceros ven datos en el camino. Su propósito es hacer evaluable el sistema desde fuera: un comprador que lo lee debe poder responder, sin preguntar nada más, quién controla cada pieza y qué datos toca.

La idea deriva del SBOM, la «lista de ingredientes» del software que CISA describe como un inventario anidado de los componentes que forman un producto¹. El AI-BOM aplica el mismo principio a lo que el SBOM no captura: un modelo no es un paquete con número de versión semántico, puede vivir detrás de una API en otro país, puede cambiar sin que cambie ninguna dependencia local, y puede o no usar los datos que recibe para entrenar. Por eso el AI-BOM añade columnas que un SBOM no tiene —naturaleza de los pesos, condición de no entrenamiento, país de ejecución, alcance del acceso— y una tabla entera dedicada a los terceros.

En qué se parece y en qué difiere de un SBOM

Los elementos mínimos de un SBOM, según el informe de la NTIA de 2021, son siete: nombre del proveedor, nombre del componente, versión, otros identificadores únicos, relación de dependencia, autor del inventario y marca de tiempo². CISA mantiene la iniciativa y publicó en 2025 un borrador actualizado de esos elementos mínimos¹. Un AI-BOM conserva los siete —en particular la marca de tiempo, que se convierte en la fecha de corte del inventario— y los extiende.

Las diferencias son cuatro. Primera: la unidad principal es el modelo, no el paquete, y un modelo se identifica por proveedor, nombre y versión oficial del proveedor, no por un número de release del integrador. Segunda: la naturaleza importa —pesos abiertos ejecutados en infraestructura propia y pesos cerrados consumidos por API tienen implicaciones distintas de residencia y retención—. Tercera: se registra la condición de uso de datos (excluido de entrenamiento por defecto, por contrato, ambas). Cuarta: los terceros son parte del inventario, con país y alcance del acceso, porque en un servicio con IA el tercero no es un proveedor de hosting genérico sino quien ejecuta la inferencia. Para el intercambio automatizado existe un formato abierto, el ML-BOM de OWASP CycloneDX, que añade al SBOM la descripción de modelos y conjuntos de datos³; el documento legible por personas y la versión máquina se complementan.

Por qué es la primera hoja que hay que pedir

Sin el inventario, ninguna de las preguntas de fondo del comprador se puede evaluar: la transferencia internacional depende de saber en qué país corre cada modelo y qué recibe; la retención y el no entrenamiento, de saber quién es el proveedor del modelo y bajo qué términos se le llama; la exposición ante una vulnerabilidad publicada, de saber qué bibliotecas y con qué versión están en la cadena de inferencia; y la continuidad, de saber si existe un modelo alterno y cómo se conmuta.

Muchos productos comerciales son una capa sobre el modelo de un tercero, y la negativa a declararlo es en sí una respuesta. OWASP incluye la cadena de suministro entre los diez riesgos principales de las aplicaciones con modelos de lenguaje: modelos de terceros, pesos descargados sin verificación de integridad, licencias, dependencias y servicios externos que el integrador no controla⁴⁵⁶. Y la función MAP del NIST AI RMF pide precisamente establecer el contexto y los componentes del sistema antes de medir o gestionar nada⁷. Un comprador que empieza por el AI-BOM ordena el resto de su cuestionario: cada control posterior remite a una fila de este documento.

Tabla 1: la cadena de modelos

La primera tabla lista cada modelo que participa en la inferencia productiva, una fila por modelo, con seis columnas: proveedor; nombre; versión fijada (el identificador oficial del proveedor, con fecha); naturaleza (pesos abiertos con su licencia y lugar de ejecución, o pesos cerrados consumidos por API con el país del servicio); función dentro del sistema (generación de respuestas, vectorización del corpus y las consultas, reconocimiento óptico de caracteres, clasificación, reordenamiento); y condición de uso de datos (excluido de entrenamiento por defecto según los términos del proveedor, reforzado por contrato, o ambos).

Dos observaciones. Un modelo de embeddings de pesos abiertos ejecutado en infraestructura propia significa que los documentos no salen a terceros para indexarse: solo los fragmentos pertinentes a cada consulta viajan al modelo generador; es una decisión de arquitectura con efecto directo en la transferencia internacional, y la tabla la hace visible. Y todo componente de pesos abiertos debe declarar verificación de integridad en el despliegue (suma de verificación y versión fijada), porque descargar pesos sin verificarlos es una de las formas más simples de introducir un componente manipulado.

Tabla 2: modelos alternos y conmutación

La segunda tabla declara si existe un modelo de reserva y cómo se activa. Columnas: proveedor y versión del alterno; garantías equivalentes (no entrenamiento, país, retención) o diferencias declaradas; disparador de la conmutación (indisponibilidad del proveedor principal, degradación medida, decisión del cliente); quién la autoriza; y si el alterno fue medido contra la misma línea base que el principal.

Ese último punto une esta tabla con la política de IA responsable: un alterno que nunca se midió con el mismo conjunto de evaluación no es una garantía de continuidad, es una incógnita que se activa en el peor momento. Un comprador serio pregunta si la conmutación conserva las mismas condiciones de datos —un alterno con términos distintos de retención convierte una contingencia técnica en un incidente de cumplimiento— y si el sistema opera en modo degradado (lectura y búsqueda sin generación) mientras no hay ningún modelo disponible. La existencia de una capa de proveedor conmutable es una fortaleza; declararla con sus condiciones es lo que la hace evaluable.

Tabla 3: bibliotecas de la cadena de inferencia, con versión

La tercera tabla es la más parecida a un SBOM clásico: cada biblioteca o componente que participa en la cadena de inferencia, con versión exacta y rol. Suelen aparecer el entorno de ejecución, el marco de la API, los clientes oficiales de los proveedores de modelos, la base vectorial, las bibliotecas que ejecutan modelos locales, el acceso a datos y la validación de esquemas, el cifrado en reposo, la limitación de tasa, la base de datos y la caché.

Su función es una sola: cuando se publica una vulnerabilidad sobre cualquiera de esos componentes, el inventario permite saber en minutos si el servicio está expuesto, en qué versión y con qué rol. Sin la versión exacta la tabla no sirve para eso, y sin el rol no se puede priorizar. Aquí conviene ser claros con el comprador: esta tabla describe superficie de ataque, y por eso es razonable que el proveedor la entregue bajo acuerdo de confidencialidad y no la publique. Lo que no es razonable es que no exista, o que exista sin fecha de corte.

Tabla 4: subprocesadores con país y alcance del acceso

La cuarta tabla lista a todo tercero con participación en la inferencia o con acceso a datos del cliente: nombre, país de operación, rol y alcance exacto del acceso, condición de retención y de no entrenamiento, y cómo se notifica un cambio de subprocesador. Debe cerrar con una frase que el evaluador busca: «no existe ningún otro tercero con acceso a datos ni con participación en la cadena de inferencia».

El alcance del acceso es la columna decisiva: no es lo mismo un tercero que recibe únicamente los fragmentos de contexto pertinentes a cada consulta —nunca expedientes completos ni el corpus íntegro— que uno que aloja la base de datos entera. El país es la columna legal: si los fragmentos enviados al modelo pueden contener datos personales, ejecutar la inferencia fuera de Chile es un tratamiento en el extranjero, aunque los datos «vivan» en el país. La Ley 21.719 regula la transferencia internacional de datos personales y exige ampararla en un mecanismo válido⁸; el AI-BOM no resuelve esa obligación, pero es el documento que la hace visible y permite mitigarla por diseño (minimizar lo que sale, indexar en infraestructura propia).

No entrenamiento: por defecto, por contrato y verificable

La columna «condición de uso de datos» de la tabla 1 merece explicación, porque la respuesta varía por proveedor y por modalidad de servicio. Los tres proveedores de modelos por API más usados publican políticas de no entrenamiento para sus servicios comerciales: OpenAI declara que los datos enviados a su API no se usan para entrenar ni mejorar sus modelos salvo opción explícita del cliente⁹; Anthropic establece en sus términos comerciales que no entrena modelos con el contenido de sus clientes y confirma que, por defecto, no usa entradas ni salidas de sus productos comerciales para entrenar¹⁰¹¹; Google distingue entre servicios de pago, en los que no usa las solicitudes ni respuestas para mejorar sus productos, y servicios sin pago, en los que revisores humanos pueden leer y anotar la entrada y salida de la API¹².

La lección para el inventario es doble. Primera: la condición depende de la modalidad contratada, no del logotipo, y la columna debe decir cuál es. Segunda: la política del proveedor del modelo es la capa por defecto; el contrato entre el proveedor de la solución y el cliente debe reforzarla y extenderla a todos los subprocesadores. Un opt-out en una consola de administración no es un compromiso contractual.

Por qué la versión fijada importa: un alias no es una versión

Los proveedores de modelos publican dos tipos de identificadores: versiones con fecha, que no cambian, y alias comerciales que apuntan a «la versión recomendada» y que el proveedor mueve cuando publica una nueva. Una configuración que usa el alias parece estable —el texto no cambia— mientras el modelo debajo sí cambia, y con él el comportamiento medido. Afirmar «versión fijada» con un alias flotante es una afirmación falsa aunque el comportamiento de hoy sea idéntico.

El AI-BOM debe registrar el identificador de versión oficial con fecha, y la política de IA responsable del proveedor debe describir qué pasa cuando esa versión se retira: re-medición contra la línea base con el mismo conjunto de evaluación, prueba estadística pareada, aviso previo al cliente. La forma de comprobarlo como comprador es sencilla: pedir que se muestre el identificador de versión tal como aparece en la configuración de producción y contrastarlo con la lista de versiones que publica el proveedor del modelo. La lección de fondo, aprendida en nuestra propia operación, es que antes de entregar un inventario cada afirmación se audita contra el sistema, y si difieren, se corrige el sistema, no el texto.

Las herramientas de ingeniería con IA se declaran igual

Un proveedor moderno usa asistentes de IA para desarrollar, revisar y probar su software. Esos modelos no participan de la inferencia productiva ni acceden a datos del cliente, y por eso muchos inventarios los omiten. Es un error: el evaluador que los descubre por otra vía concluye que el inventario está incompleto, y ya no confía en el resto.

La forma correcta es una nota bajo la tabla 1: «el desarrollo y aseguramiento de la plataforma se apoya en herramientas de ingeniería con IA de terceros; esos modelos no participan de la inferencia productiva ni acceden a datos del cliente». La nota separa dos cosas que el comprador necesita separadas —la cadena que toca sus datos y las herramientas que tocan el código— y responde por adelantado a la pregunta sobre código generado por IA, licencias y revisión humana del código. Si el proveedor además tiene una política de revisión de código asistido, es el lugar para citarla.

Cómo se mantiene: fecha de corte, vulnerabilidades y disponibilidad

Un AI-BOM sin fecha de corte no describe nada: describe un momento que nadie conoce. El documento debe declarar «este inventario se corta al [fecha]» y tres reglas. Primera, se reemite ante cualquier cambio de modelo, de tercero o de biblioteca crítica, con la fecha del cambio y el aviso previo que corresponda por contrato. Segunda, ante una vulnerabilidad publicada sobre cualquiera de los componentes listados, el inventario permite identificar la exposición de inmediato, y el proveedor comunica al cliente si el servicio está afectado y qué se hizo. Tercera, se mantiene actualizado y disponible bajo solicitud durante toda la vigencia del contrato.

Conviene añadir versión del propio documento —número, fecha, responsable— y un registro de cambios corto. El comprador debería poder pedir el inventario en cualquier momento y recibir la versión vigente, no una copia del día de la firma.

Cómo leerlo como comprador: 5 señales

Cuando el inventario llega al evaluador, cinco señales separan un documento útil de una lista para cumplir.

Una nota de cierre. El AI-BOM no sustituye a la política de IA responsable ni al acuerdo de encargado de tratamiento: los tres se leen juntos. La política dice qué pasa cuando una fila del inventario cambia; el acuerdo dice qué obligaciones asume cada tercero listado; el inventario dice qué hay. Con los tres, y con una medición pública de fiabilidad que declare qué versión se midió, el comprador tiene la parte de cadena de suministro de su cuestionario respondida con evidencia y no con adjetivos.

La plantilla contiene las cuatro tablas descritas —cadena de modelos, modelos alternos y conmutación, bibliotecas de la cadena de inferencia, subprocesadores— con las columnas exactas de este artículo, una hoja «Cómo usar» con la fecha de corte, la regla de actualización y la nota sobre herramientas de ingeniería, y la licencia. Se entrega también en CSV para quien prefiera integrarla a su propio sistema. Todas nuestras plantillas descargables se reúnen en /recursos/plantillas/. Licencia CC BY-ND 4.0: se puede redistribuir citando la fuente, sin obras derivadas.