Un AI bill of materials n’est utile que s’il peut répondre à deux questions : qu’est-ce qui a été déclaré avant le déploiement, et qu’est-ce qui s’exécutait réellement lorsqu’une décision, un incident ou un audit a eu lieu. Un fichier JSON valide qui ne peut pas répondre aux deux relève de la mise en scène de l’inventaire.
La conception pratique repose sur un inventaire en deux volets. Générez un enregistrement fondé sur des standards pendant la compilation ou l’approvisionnement, observez le système actif à l’exécution, conservez les preuves pour chaque champ et comparez les deux. Bloquez une version lorsqu’un modèle, un jeu de données, un runtime, une API, un outil d’agent ou une licence critique n’est pas résolu.
Niveau de lecture : Avancé. Ce guide s’adresse aux ingénieurs, aux équipes de sécurité, aux responsables de plateformes et aux responsables de la gouvernance technique qui exploitent des systèmes reposant sur des modèles.
Sommaire
À quelles questions un AI bill of materials doit-il répondre ?
Un AI bill of materials, généralement abrégé en AIBOM ou AI BOM, est un inventaire lisible par machine des composants et des preuves qui sous-tendent un système d’AI. Il étend un software bill of materials classique au-delà des packages et des bibliothèques.
L’inventaire doit permettre à un évaluateur de répondre aux questions suivantes :
CycloneDX décrit sa capacité AI/ML-BOM comme un moyen de représenter les modèles, les jeux de données, les configurations, la provenance et les dépendances. SPDX 3.0.1 définit également un profil AI pour les métadonnées propres à l’AI. Il s’agit de modèles de données interopérables, et non de substituts aux preuves manquantes elles-mêmes.
Une model card répond à une question plus restreinte : à quoi ce modèle est-il destiné, comment a-t-il été évalué et dans quels cas peut-il échouer ? L’article original sur les Model Cards proposait une documentation couvrant l’usage prévu, les conditions d’évaluation et les performances pour les groupes concernés. Une data card documente l’origine d’un jeu de données, sa collecte et son annotation, son usage prévu ainsi que les décisions qui façonnent les performances en aval ; l’article sur les Data Cards rapporte les enseignements tirés de plus de 20 déploiements.
Conservez les deux. Une model card ou une data card fournit le contexte humain. Un AIBOM relie ces documents à un inventaire versionné du système.
Pourquoi des fichiers AIBOM valides peuvent-ils tout de même contenir des preuves faibles ?
Une étude de juillet 2026 a testé cette distinction à grande échelle. Les auteurs ont collecté un instantané de 2 942 466 enregistrements publics de modèles Hugging Face, conservé 97 940 modèles comptant plus de 100 téléchargements et généré des AIBOM CycloneDX avec l’OWASP AIBOM Generator. Ils ont vérifié un échantillon de 100 artefacts par rapport aux rapports du générateur, puis mesuré la présence des champs sur l’ensemble du corpus.
Le score moyen de complétude rapporté était de 54,31 sur 100. Les champs structurels obligatoires étaient présents dans 100 % des artefacts générés. La documentation des model cards atteignait en moyenne 19,51 %.
Cet écart constitue le résultat important. Le fichier peut être structurellement valide alors que les informations nécessaires à une décision sont absentes.
Les résultats au niveau des champs étaient encore plus révélateurs :
| Champ dans l’AIBOM généré | Présent |
|---|---|
| --- | ---: |
| Licence | 73,14 % |
| Jeu de données | 39,35 % |
| Hyperparamètres | 25,40 % |
| Limitations techniques | 16,74 % |
| Évaluation des risques de sécurité | 9,76 % |
| Description significative | 0,22 % |
| Consommation énergétique | 0,02 % |
Le champ de description apparaissait dans presque tous les artefacts, mais seules 211 descriptions sur 97 940 contenaient des informations allant au-delà d’un texte de remplacement. Un contrôle de présence dans le schéma compterait les autres descriptions comme complètes.
Ce que les auteurs ont mesuré : la couverture des champs et des catégories dans les AIBOM générés à partir d’un instantané public filtré de Hugging Face.
Ce qu’ils ont inféré : la documentation des model cards et les références externes expliquent une grande partie de la différence entre les artefacts faibles et les artefacts plus solides.
Ce qu’ils n’ont pas établi : qu’un modèle était sûr, équitable, performant, légalement utilisable ou adapté à un déploiement particulier.
Les auteurs avertissent également que leurs résultats dépendent de l’API Hugging Face, de la logique d’extraction du générateur et d’un instantané qui exclut les modèles comptant 100 téléchargements ou moins. Les registres privés, les modèles soumis à autorisation, les autres plateformes d’hébergement et les modifications ultérieures des dépôts peuvent présenter un profil différent. Leur résultat justifie une validation sémantique. Il ne fixe pas de seuil universel de score.
L’inventaire à la compilation et l’inventaire à l’exécution résolvent des problèmes différents
Un AIBOM à la compilation enregistre l’intention. Un inventaire à l’exécution enregistre l’observation.
| Question | Preuves à la compilation | Preuves à l’exécution |
|---|---|---|
| --- | --- | --- |
| Quel modèle doit être livré ? | Lockfile, manifeste, enregistrement d’approvisionnement, digest du modèle | ID du modèle chargé, endpoint, digest de l’image, configuration de serving |
| Quelles données doivent être disponibles ? | Déclarations d’entraînement et d’évaluation, sources de retrieval approuvées | Vector stores connectés, jeux de données montés, services de données actifs |
| Quels outils un agent peut-il appeler ? | Registre des outils, politique, serveurs MCP et API déclarés | Endpoints découverts, intégrations actives, configuration observée |
| Quels logiciels prennent en charge l’inférence ? | SBOM des packages et du conteneur | Image en cours d’exécution, runtime, drivers, accélérateurs |
| Quelles restrictions s’appliquent ? | Licence, model card, data card, référence contractuelle | Fournisseur actuel, région, route, version de la politique |
| Le système approuvé a-t-il dérivé ? | Référence de comparaison | Preuves à comparer à la référence |
Les seules preuves de compilation ne détectent pas les changements d’urgence, les déploiements fantômes, les tags mutables, le reroutage du fournisseur ni la dérive de configuration. L’observation à l’exécution peut, à elle seule, voir un nom de processus ou un endpoint sans connaître son objectif approuvé, sa licence, sa provenance d’entraînement ou sa limite d’évaluation.
Google a publié en open source k8s-aibom le 14 juillet 2026 pour explorer le volet de l’exécution. Le contrôleur surveille l’état des workloads et des pods Kubernetes, applique des règles de détection et émet des documents ML-BOM CycloneDX 1.6. Sa couverture documentée inclut les runtimes d’inférence, les frameworks d’agents, les bases vectorielles, les jobs d’entraînement et les harnais d’évaluation. Il fonctionne sans DaemonSet privilégié ni accès au kernel.
Le projet met en évidence un point d’architecture utile : les AIBOM à la compilation et à l’exécution sont complémentaires. Il s’agit également d’un logiciel encore précoce. Le dépôt qualifie la v1.0 d’alpha et la destine à des cas d’observation non critiques. Il ne fournit ni image hébergée ni dépôt Helm, et son `NoopVerifier` actuel ne peut pas marquer une identité comme vérifiée cryptographiquement.
Un mainteneur de NVIDIA AICR a proposé une intégration entre k8s-aibom et AICR qui relierait les observations d’exécution de k8s-aibom à l’intention de déploiement et aux attestations signées d’AICR. L’auteur décrit l’objectif comme la preuve que ce qu’une équipe a déployé correspond à ce que le système exécute. L’issue ne comporte aucune implémentation, aucun responsable ni jalon associé. Considérez-la comme une proposition de praticien, et non comme une feuille de route officielle ou une conception achevée.
Ne transformez pas un nouveau contrôleur en recommandation universelle de produit. Utilisez le modèle suivant : associer l’état déclaré à l’état observé, conserver les preuves et rendre l’incertitude visible.
_Un AI bill of materials utile relie l’intention de compilation aux preuves d’exécution, aux contrôles sémantiques et à une décision versionnée._
Les sept couches qui méritent d’être enregistrées
Le schéma exact dépend de votre standard et de votre déploiement. Les couches suivantes constituent un minimum pratique pour un inventaire de production.
1. Identité du modèle
Enregistrez le fournisseur, la famille du modèle, la révision ou le digest immuable, le format, le modèle de base, les adaptateurs, la quantification, le tokenizer et la route de serving. Un alias convivial tel que `support-model` est utile pour les personnes, mais insuffisant pour la traçabilité.
Pour une API externe, enregistrez l’identifiant stable du modèle fourni par le fournisseur ainsi que la route du gateway qui l’a sélectionné. Si le fournisseur peut mettre à jour silencieusement le modèle derrière un alias, marquez la révision comme non résolue au lieu d’inventer une précision.
2. Dépendances de données et de retrieval
Enregistrez les jeux de données d’entraînement, de fine-tuning, d’évaluation et de calibration déclarés lorsque ces informations existent. Pour un système RAG, ajoutez les collections sources, le modèle d’embedding, la version du découpage, le service de vector store, la politique d’accès et la limite de fraîcheur.
Stockez les identifiants, versions, hashes, contrats ou références contrôlées du catalogue des jeux de données. Ne copiez pas les enregistrements bruts des clients ni les exemples d’entraînement privés dans l’AIBOM.
Lorsqu’une équipe construit des systèmes de données personnalisés avec Next.js et des agents AI→, la version du schéma, la limite de migration et les services connectés appartiennent au contexte du système, même lorsqu’il ne s’agit pas d’artefacts de modèle.
3. Runtime et logiciels
Reliez l’inventaire AI au SBOM ordinaire. Enregistrez le digest du conteneur, le moteur d’inférence, le framework, les bibliothèques pertinentes, la classe de driver et d’accélérateur ainsi que la configuration susceptible de modifier le comportement du modèle.
Cela compte, car les mêmes poids peuvent se comporter différemment après une modification du tokenizer, du backend d’attention, du chemin de quantification ou du moteur de serving. L’analyse de la raison pour laquelle davantage de tokens AI modifient la facture de calcul→ montre pourquoi un enregistrement de déploiement doit inclure le budget du runtime et la configuration, et pas seulement un nom de modèle.
4. Outils, API et permissions des agents
Répertoriez les outils auxquels un agent peut accéder, et non tous les outils installés quelque part dans l’entreprise. Incluez les model gateways, les serveurs MCP, les outils de navigateur ou d’exécution de code, les API externes et la référence de la politique qui régit chaque action.
L’inventaire n’applique pas l’autorisation. Associez-le à des contrôles déterministes. L’article sur les permissions des agents AI→ explique pourquoi la retenue d’un modèle ne constitue pas une frontière de contrôle d’accès.
5. Évaluation et limites opérationnelles
Référencez le jeu d’évaluation exact, la version de l’évaluateur, les seuils, la date et les conditions utilisés pour l’approbation. Enregistrez les modes d’échec connus, les usages prévus et exclus, le comportement de repli, le responsable de la supervision et la date d’expiration de la décision.
N’écrivez pas « évaluation réussie » sans l’identité du test. Un modèle modifié associé à une chaîne de résultat inchangée constitue une preuve faible.
6. Droits, politique et provenance
Enregistrez les licences des modèles et des jeux de données, les restrictions d’utilisation, les conditions de redistribution, les dépôts sources, les model cards, les data cards, les articles, les approbations et les attestations. Stockez les références et les hashes lorsque la source est soumise à un contrôle d’accès.
Cette couche facilite la revue. Elle ne tranche pas une question juridique. Les informations manquantes ou contradictoires sur les droits doivent être transmises à la personne responsable de cette décision.
7. Responsabilité et cycle de vie
Chaque enregistrement doit comporter un responsable, l’objectif du système, l’environnement, la date de création, la date d’observation, la version remplacée et la règle de conservation. Sans responsable, un inventaire devient une archive de faits abandonnés.
Incluez un ID de système stable qui survive aux redéploiements. Un AIBOM versionné doit montrer l’historique de ce qui a changé, qui l’a accepté et quelles preuves ont étayé cette décision.
Étiquetez chaque fait comme déclaré, inféré, vérifié ou non résolu
Un AIBOM doit porter le statut de preuve au niveau de chaque champ. Une seule étiquette pour l’ensemble du document masque trop d’informations.
Les trois premières étiquettes décrivent des niveaux de preuve différents. « Déclaré » n’est pas une autre façon d’écrire « vérifié ». Une déclaration de fournisseur peut être la seule source disponible pour les données d’entraînement, tandis qu’un digest d’image peut être vérifié mécaniquement.
Le projet k8s-aibom implémente actuellement `declared`, `inferred` et `unresolved`, avec des localisateurs de preuves pour les attributs. Son README place le statut cryptographique `verified` sur la feuille de route au lieu de prétendre qu’il est déjà disponible. Préservez cette honnêteté dans votre propre système.
Un enregistrement conceptuel pourrait ressembler à ceci :
{ "system_id": "customer-support-prod", "component": { "type": "machine-learning-model", "name": "provider/model-family", "version": "immutable-revision", "hashes": ["sha256:..."] }, "evidence": { "status": "verified", "source": "signed-build-attestation", "observed_at": "2026-07-29T08:00:00Z" }, "depends_on": [ "runtime:inference-engine@version", "dataset:retrieval-corpus@revision", "api:model-gateway@policy-version" ] }
Il s’agit d’une esquisse de conception, et non d’un document CycloneDX ou SPDX conforme. Utilisez le schéma et le validateur du standard choisi pour l’artefact réel.
Un workflow AIBOM reproductible
Étape 1 : définir la frontière du système
Nommez l’application, les environnements, les responsables et les décisions visibles par les utilisateurs qui sont concernées. Décidez si l’inventaire couvre un endpoint de modèle, un workflow d’agent ou un produit complet.
Une frontière telle que « toute l’AI » ne peut pas être testée. « L’agent de support en production et chaque service pouvant modifier sa réponse ou ses actions » peut l’être.
Étape 2 : collecter les preuves de compilation et d’approvisionnement
Générez le SBOM ordinaire, résolvez les identifiants des modèles et des jeux de données, capturez les digests immuables et reliez les model cards, data cards, licences, évaluations et approbations.
L’OWASP AIBOM Generator peut extraire les métadonnées Hugging Face dans CycloneDX 1.6 et signaler les champs manquants. Traitez sa sortie comme un inventaire initial. L’étude à grande échelle montre pourquoi un champ rempli automatiquement nécessite encore un contrôle de contenu.
Étape 3 : émettre un document standard
Choisissez un format que vos consommateurs peuvent analyser. CycloneDX fournit une capacité AI/ML-BOM ainsi qu’un guide d’implémentation. SPDX 3 fournit des profils AI et dataset.
Le choix du format doit suivre les systèmes récepteurs, le moteur de politiques, le pipeline d’attestations et les exigences des clients. Évitez de maintenir deux formats sauf si un véritable consommateur a besoin des deux.
Étape 4 : enrichir ce que l’automatisation ne peut pas connaître
Attribuez des responsables pour renseigner l’usage prévu, les limitations, la provenance des jeux de données, les conditions d’évaluation, les droits et les décisions de risque. Rejetez les valeurs de remplacement telles que « N/A », « modèle standard » ou un texte marketing copié lorsque le champ est critique pour une décision.
Exigez une raison explicite pour les valeurs inconnues. « Le fournisseur ne divulgue pas les données d’entraînement » constitue une meilleure preuve qu’un tableau vide, car cela distingue le travail manquant de l’information indisponible.
Étape 5 : observer le déploiement actif
Collectez les IDs des modèles à l’exécution, les digests d’images, les endpoints, les stores connectés, les outils d’agents et la configuration au moyen du mécanisme le moins privilégié disponible. Dans Kubernetes, il peut s’agir d’un contrôleur surveillant l’API. Dans une stack d’API managée, il peut s’agir de la configuration du gateway, des manifestes de déploiement, des réponses du fournisseur et des journaux d’audit.
Ne prétendez pas à une vérification à l’exécution lorsque le scanner s’est contenté de faire correspondre une chaîne de caractères. Marquez-la comme inférée et conservez la preuve de correspondance.
Étape 6 : valider la syntaxe, la sémantique et la dérive
Exécutez trois contrôles distincts :
Le premier contrôle est automatisé. Le deuxième nécessite des règles métier et, pour certains champs, une revue humaine. Le troisième nécessite des enregistrements versionnés et une frontière de comparaison stable.
Étape 7 : signer, stocker, comparer et faire expirer
Hachez l’artefact, liez-le à la compilation ou au déploiement, stockez-le dans un système de preuves append-only ou contrôlé et produisez une comparaison lisible par un humain. AIBoMGen est un prototype de recherche qui associe la capture du modèle et de l’environnement à des hashes, des signatures et des attestations in-toto pendant l’entraînement.
Les signatures protègent l’intégrité après la création. Elles ne rendent pas vraie une déclaration incomplète ou fausse.
Définissez une date d’expiration ou de revue. Un inventaire parfait du trimestre dernier ne décrit pas aujourd’hui un système de production mutable.
Transformez l’inventaire en barrière de validation de version
Un inventaire devient utile lorsqu’il modifie une décision. Définissez la politique avant la fenêtre de mise en production.
| Condition | Action par défaut | Justification |
|---|---|---|
| --- | --- | --- |
| L’identité d’un modèle ou d’un runtime critique n’est pas résolue | Bloquer | Le composant déployé ne peut pas être tracé |
| L’exécution contient un modèle, une API, un outil ou un data store non déclaré | Bloquer et enquêter | La frontière approuvée a dérivé |
| La révision du modèle a changé, mais pas la référence d’évaluation | Bloquer | Les preuves d’approbation ne couvrent pas le candidat |
| Une licence ou une restriction d’utilisation requise est manquante | Transmettre à la revue du responsable ; bloquer lorsque la politique l’exige | Les droits ne peuvent pas être déduits de la disponibilité |
| Une inférence heuristique contredit une déclaration | Bloquer ou mettre les preuves en quarantaine | Au moins une source est erronée ou obsolète |
| Une description non critique manque de détails | Créer une action corrective limitée dans le temps | L’écart ne justifie peut-être pas l’arrêt du service |
| L’AIBOM a changé uniquement parce que l’heure d’observation a changé | Autoriser | Aucune dérive matérielle du système n’a eu lieu |
Adaptez la gravité au système. Un assistant de rédaction et un outil d’aide à la décision médicale ne doivent pas partager un seuil universel.
Suivez quatre mesures opérationnelles :
N’optimisez pas le nombre de champs remplis. Vous recréeriez exactement l’échec révélé par l’étude de complétude.
Le même principe systémique apparaît dans l’analyse de l’activité des code-agents et de l’infrastructure→ : la capacité du modèle ne constitue qu’une partie du système déployé. Le runtime, les outils, le routage et les contrôles opérationnels déterminent ce que les utilisateurs reçoivent réellement.
Gardez les secrets et les données personnelles à l’écart
Un AIBOM est susceptible de circuler entre les équipes d’ingénierie, de sécurité, les auditeurs, les clients et les systèmes automatisés. Traitez-le comme un inventaire, et non comme un coffre-fort à secrets.
N’incluez pas :
Référencez les secrets par le chemin du secret manager ou par un identifiant logique sans inclure la valeur. Référencez les jeux de données sensibles au moyen d’un ID de catalogue gouverné, d’une version, d’une classification, d’un responsable et d’un hash d’intégrité. Appliquez un contrôle d’accès à l’artefact complet lorsque même ses métadonnées sont sensibles.
Ce qu’un AIBOM ne peut pas prouver
Un AI bill of materials améliore la traçabilité. Il ne prouve pas :
L’étude de complétude de juillet mesure la couverture documentaire, et non la qualité du modèle. Le dépôt k8s-aibom indique explicitement que sa sortie ne certifie pas la conformité. Ces deux limites sont importantes.
Utilisez l’AIBOM comme une carte reliant une décision à des preuves inspectables. Associez-le à l’évaluation, à l’autorisation, à la supervision, à la réponse aux incidents, aux contrôles de confidentialité et à une revue responsable. La carte accélère ces processus, car elle indique à chaque évaluateur quel système il examine.
Questions fréquemment posées
Qu’est-ce qu’un AI bill of materials ?
Un AI bill of materials est un inventaire lisible par machine des modèles, jeux de données, logiciels, runtimes, outils, éléments de provenance, restrictions et preuves qui sous-tendent un système d’AI. Un AIBOM utile identifie les versions immuables, les responsables, les faits non résolus et les changements entre l’état approuvé et l’état actif.
Un AI BOM est-il identique à un SBOM ?
Non. Un SBOM inventorie les composants logiciels et leurs dépendances. Un AI BOM relie cet inventaire logiciel aux composants propres à l’AI, tels que les modèles, les jeux de données, les adaptateurs, les évaluations, les usages prévus, les limitations et les routes d’exécution. Un système d’AI de production a généralement besoin des deux.
Dois-je utiliser CycloneDX ou SPDX pour un AIBOM ?
Utilisez le format pris en charge par vos outils en aval et les consommateurs de preuves. CycloneDX dispose d’une capacité AI/ML-BOM documentée ; SPDX 3 possède des profils AI et dataset. Validez d’abord un format canonique. N’en ajoutez un second que lorsqu’une politique, un client ou une intégration l’exige.