Respuesta directa
En pocas palabras
Un AI/ML-BOM es un inventario versionado y legible por máquinas de los componentes que forman una solución de inteligencia artificial: modelos, datasets, software, frameworks, servicios, configuraciones y relaciones de dependencia. Para un AI Sales Copilot debe vincular cada elemento con una identidad estable, versión o hash, proveedor, licencia, procedencia, entorno, uso y release del sistema. No sustituye una SBOM, model card, data card, system card, contrato ni evaluación de riesgos; las conecta. Tampoco demuestra por sí solo seguridad, privacidad, cumplimiento o ausencia de componentes desconocidos. Su valor aparece cuando producto, seguridad, datos, compras y operaciones pueden responder con evidencia qué cambió, qué está expuesto y qué debe probarse de nuevo.
Define la decisión que debe sostener el AI/ML-BOM
Empieza por una decisión concreta: liberar un release, evaluar un proveedor, investigar un incidente, preparar una sustitución o demostrar qué componentes atendían a una cuenta en una fecha. Un archivo que solo enumera nombres pierde valor cuando varios modelos comparten alias, un servicio cambia detrás de una API o una dependencia aparece en desarrollo pero no en producción.
Fija sistema, release, ambiente, región, organización, periodo y recorridos cubiertos. Separa lo declarado por desarrollo de lo observado durante build y runtime. Una lista incompleta puede seguir siendo útil si declara cobertura, método, fecha y pendientes; una lista presentada como completa sin evidencia produce falsa confianza.
Separa AI/ML-BOM, SBOM, model card, data card y system card
Cada artefacto responde una pregunta distinta. La SBOM inventaría software y dependencias; el AI/ML-BOM añade modelos, datasets y metadatos propios del ciclo de IA; la model card describe uso, evaluación y límites de un modelo; la data card explica un dataset; y la system card presenta el comportamiento del sistema integrado. Ninguno debe absorber silenciosamente a los demás.
Relaciona los documentos mediante identificadores y versiones. El BOM puede apuntar a una model card, licencia, evaluación o ficha del proveedor sin copiar todo su contenido. Así conserva una estructura consumible por herramientas y permite que una persona abra la evidencia detallada cuando toma una decisión.
| Criterio | Pregunta principal | Artefacto adecuado |
|---|---|---|
| Componentes | ¿Qué piezas exactas forman el release? | AI/ML-BOM más SBOM o SaaSBOM |
| Modelo | ¿Para qué sirve y cómo fue evaluado? | Model card |
| Datos | ¿De dónde viene el dataset y qué límites tiene? | Data card |
| Sistema | ¿Cómo se comporta el recorrido completo? | System card |
| Decisión | ¿Qué riesgo se acepta y bajo qué controles? | Registro de riesgos y aprobación |
Dibuja la frontera antes de recolectar componentes
Parte del recorrido real: interfaz, identidad, API, orquestación, prompt, RAG, índices, modelo, validadores, herramientas, persistencia, telemetría y revisión humana. Marca componentes propios, open source, servicios administrados y recursos de clientes. Incluye build, despliegue y runtime cuando puedan cambiar el resultado o la superficie de riesgo.
No todo cabe en un solo tipo de componente. Un modelo alojado puede representarse junto con el servicio que lo expone; un dataset puede enlazar su versión sin revelar registros; un prompt o política puede conservarse como configuración versionada o evidencia externa según el formato elegido. Documenta extensiones y evita inventar campos que otra herramienta interpretará como estándar.
Asigna identidad estable, versión y evidencia de integridad
Cada elemento necesita un identificador que no dependa de su posición en una hoja. Registra nombre, tipo, proveedor, versión, release, origen y una referencia local única. Cuando el artefacto sea descargable o construido por la empresa, conserva un hash verificable. Cuando una API use un alias mutable, registra el alias observado, la fecha y cualquier versión o aviso que el proveedor realmente exponga.
No fabriques precisión. Si el proveedor no revela el snapshot servido, marca versión no observable y crea una prueba que detecte cambios de comportamiento o metadatos. Un hash confirma igualdad de bytes, no que el componente sea seguro, correcto o autorizado. Firma o atestación también necesita identidad del firmante, alcance, tiempo y proceso de verificación.
Describe modelos y datasets sin convertir el BOM en una ficha narrativa
Para modelos registra tipo, proveedor, versión, ubicación, propósito dentro del sistema, parámetros relevantes, entrada, salida, limitaciones enlazadas y datasets relacionados cuando esa información exista. Para datasets conserva identidad, versión, procedencia, licencia, finalidad, estructura, transformación y relación con entrenamiento, evaluación, RAG o feedback.
SPDX separa perfiles de AI, Dataset, Software, Security, Build y Licensing; conformar con uno no implica soportar automáticamente los demás. CycloneDX permite representar modelos y datasets dentro de una familia más amplia de BOM. Elige un formato y una versión explícitos, valida contra su esquema y documenta qué información queda en artefactos enlazados.
Incluye software, servicios y dependencias de runtime
El comportamiento de un Copilot también depende de bibliotecas, contenedores, parsers, bases de datos, servicios de identidad, almacenamiento, colas, observabilidad y APIs externas. Enlaza la SBOM del software con el AI/ML-BOM en lugar de mantener listas divergentes. Registra dependencias directas y transitivas cuando la herramienta pueda resolverlas.
Separa el componente empaquetado de la instancia operativa. La misma imagen puede ejecutarse con otra configuración, región, permiso o proveedor. Un BOM de build no demuestra qué estaba activo en runtime; un inventario observado no explica necesariamente cómo se construyó. Conserva ambos puntos y una relación verificable con el release.
Modela relaciones para responder el impacto de un cambio
Una lista plana no permite saber qué dataset alimentó un índice, qué modelo atendió un recorrido o qué servicio consume una biblioteca. Registra relaciones como contiene, depende de, usa, genera, fue entrenado con, fue evaluado con, sirve a y reemplaza. Cada relación debe usar identificadores existentes y tener una dirección inequívoca.
Prueba consultas de impacto. Si cambia un modelo, el equipo debe encontrar recorridos, evaluaciones, system cards, proveedores y controles afectados. Si se retira un dataset, debe identificar índices, derivados, respaldos y releases relacionados. Las relaciones desconocidas se registran como pendientes con dueño; no se cierran con una suposición.
Conserva procedencia, licencias y términos sin afirmar más de lo comprobado
Registra quién suministró cada componente, de qué repositorio, contrato o catálogo provino, cuándo fue obtenido y qué transformaciones sufrió. En modelos y datasets, la procedencia puede incluir repositorio, revisión, versión, checksum y documentación del proveedor. Distingue fuente declarada, verificada y desconocida.
Anota licencias, términos de servicio, restricciones de uso, atribución y fecha de revisión. Una etiqueta de licencia no prueba que todos los archivos o datos estén cubiertos ni resuelve derechos de terceros. Enlaza el análisis correspondiente y evita incluir material protegido, credenciales o datos personales dentro del BOM.
Registra señales de privacidad sin exponer los datos
El BOM puede indicar si un componente trata datos personales, categorías generales, región, finalidad, retención, responsable, encargado y artefactos relacionados. No debe contener nombres de clientes, prompts reales, tokens, rutas internas sensibles ni muestras de datasets personales. Usa referencias controladas hacia el inventario de tratamiento, aviso, contrato, evaluación de impacto y procedimiento de derechos.
Para empresas privadas en México, la LFPDPPP vigente es una referencia para revisar principios, información, seguridad y responsabilidad del tratamiento. La ley no impone por sí misma un formato AI/ML-BOM. El archivo ayuda a localizar componentes y proveedores, pero la licitud y las obligaciones dependen del tratamiento real y de la revisión aplicable.
Compara el BOM declarado con lo observado
Genera información desde manifiestos, lockfiles, registros de modelos, catálogos de datos, infraestructura, imágenes, configuración y contratos. Después contrástala con el build reproducible y el runtime: llamadas externas, imágenes activas, endpoints, regiones y versiones observables. Declara la cobertura de cada colector y los componentes que no puede ver.
Trata la diferencia como señal operativa. Un componente observado y no declarado puede ser una integración no autorizada, una dependencia transitiva o una limitación del escáner. Un componente declarado y no observado puede pertenecer a otro ambiente o estar retirado. Investiga antes de borrar, asigna dueño y conserva resolución y evidencia.
Valida esquema, completitud, consistencia y actualidad
Valida el documento contra la versión exacta de SPDX o CycloneDX que declaras. Comprueba identificadores únicos, referencias resolubles, relaciones sin nodos ausentes, formatos de versión, hashes, licencias, timestamps y serialización. Añade reglas del producto: cada release debe tener sujeto, propietario, componentes críticos, enlace a system card y resultado de conciliación.
Mide cobertura con denominadores. Reportar noventa por ciento no sirve si no se explica el universo: imágenes, servicios, modelos, datasets o recorridos. Separa faltantes críticos de campos opcionales y fija un gate. Una herramienta que genera JSON válido no garantiza que haya descubierto la arquitectura real ni que la información del proveedor sea cierta.
Integra generación, diff y aprobación en el release
Genera el BOM de forma repetible durante build y despliegue, guarda el artefacto inmutable y asócialo con commit, imagen y release. Calcula un diff contra la versión aprobada: componentes añadidos, retirados, actualizados, renombrados, sin versión o con cambios de proveedor, licencia, región y relación. Evita regenerar el archivo después de liberar sin conservar el original.
Clasifica el diff por impacto y abre las revisiones necesarias. Un parche de biblioteca puede requerir vulnerabilidades y regresión; un nuevo modelo puede reabrir evaluación, privacidad, costo y fallback; un dataset distinto puede afectar procedencia y derechos. La aprobación registra quién revisó, qué evidencia vio, qué excepción aceptó y cuándo expira.
Usa el BOM en vulnerabilidades, incidentes, cambios y retiro
Conecta el BOM con alertas de dependencias, avisos de proveedores, licencias, incidentes y registros de riesgo. Cuando aparece una vulnerabilidad o un cambio de modelo, consulta qué releases y recorridos están afectados antes de priorizar. Mantén la decisión separada del hallazgo: presencia no siempre implica explotabilidad, y ausencia en una base no demuestra seguridad.
Durante un incidente, conserva el BOM del momento afectado y evita sustituirlo por el actual. Para continuidad, localiza concentraciones y alternativas; para retiro, comprueba identidades, datos, índices, credenciales, servicios y respaldos dependientes. Un BOM útil reduce el tiempo para encontrar alcance, pero no reemplaza pruebas, runbooks, contratos ni comunicación.
Distribuye vistas por audiencia y protege detalles sensibles
La vista interna puede contener dependencias, hashes, regiones, relaciones y rutas hacia evidencia restringida. Una vista para clientes puede compartir componentes relevantes, proveedores, versiones, cambios y responsabilidades acordadas. La pública debe limitarse a información útil que no revele secretos, configuraciones explotables, datos personales o propiedad de terceros.
Todas las vistas necesitan la misma identidad de release y una política de actualización. Firmar un archivo no obliga a publicarlo; publicarlo no demuestra que sea completo. Define quién puede producir, aprobar, consultar y exportar el BOM, cuánto tiempo se conserva y cómo se revoca una versión errónea sin perder historial.
Aplica el AI/ML-BOM a Cerravi sin inventar componentes
Un BOM de Cerravi debe construirse desde el release real y la configuración autorizada, no desde una lista genérica. Debe enlazar aplicación, imágenes, bibliotecas, base de datos, servicios externos configurados, modelos efectivamente usados, fuentes de RAG, catálogos, evaluaciones y regiones observables. La información no publicada por un proveedor se marca como no observable y se gestiona mediante contrato, monitoreo o prueba, sin adivinarla.
Cerravi organiza contexto comercial y propone siguientes pasos para revisión humana; los recorridos públicos no envían mensajes ni cambian etapas automáticamente. Las propuestas usan productos y precios disponibles y solicitan confirmación cuando falta un importe. Forecast usa reglas transparentes del CRM, no se presenta como un modelo predictivo entrenado y no garantiza cierres. El BOM documenta piezas de un despliegue; no certifica el producto ni sustituye revisión técnica, de seguridad, privacidad o jurídica.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Qué es un AI/ML-BOM?
Es un inventario versionado y legible por máquinas de modelos, datasets, software, servicios, configuraciones y relaciones que forman una solución de IA. Vincula cada componente con identidad, versión, procedencia, licencia, evidencia y release, sin certificar por sí solo seguridad o cumplimiento.
¿Cuál es la diferencia entre un AI/ML-BOM y una SBOM?
Una SBOM se concentra en componentes de software y sus dependencias. Un AI/ML-BOM añade elementos propios de IA, como modelos, datasets, entrenamiento, evaluación y metadatos relacionados. Normalmente se enlazan: el AI/ML-BOM no debe ocultar las dependencias de software ya documentadas en la SBOM.
¿Un AI/ML-BOM sustituye la model card o la system card?
No. El BOM responde qué componentes forman el release. La model card describe uso, evaluación y límites de un modelo; la data card explica un dataset; y la system card documenta el comportamiento integrado. El BOM debe enlazarlas mediante versiones e identificadores.
¿Debe publicarse el AI/ML-BOM completo?
No necesariamente. Puede existir una versión interna detallada, otra contractual para clientes y una pública limitada. Todas deben compartir identidad y fecha, pero ninguna debe revelar secretos, datos personales, configuraciones explotables o información de terceros sin autorización.
¿SPDX o CycloneDX hacen que un AI/ML-BOM sea completo?
No. Ambos ofrecen estructuras estandarizadas para intercambiar información, pero la completitud depende de la frontera, los colectores, los datos del proveedor y la conciliación con build y runtime. Un archivo válido puede seguir omitiendo componentes o contener afirmaciones no verificadas.