AI BOM : la nomenclature de l’IA en 50 éléments du G7

Un AI BOM (nomenclature logicielle de l’IA) est l’inventaire structuré, lisible par machine, de ce dont un système d’IA est fait : modèles, jeux de données, dépendances logicielles, infrastructure, et les relations qui les lient. Jusqu’en 2026, son contenu dépendait de ce qu’un éditeur d’outils avait décidé d’y mettre. Depuis le 12 mai 2026, il existe un socle officiel, publié par les agences de cybersécurité du G7 : 7 familles, 50 éléments selon notre décompte, d’application volontaire. Ce guide lit cette liste comme le ferait un auditeur : ce qu’elle consigne, ce qu’elle laisse de côté, quels textes rendent son contenu exigible, et comment produire le document.

L’essentiel

• Un AI BOM étend le SBOM aux modèles, aux données, à l’infrastructure et à leur lignée ; il s’y ajoute sans le remplacer.
• Le guide du G7 du 12 mai 2026 liste 7 familles et 50 éléments minimaux selon notre décompte ; volontaire, il ne cite aucune loi.
• Aucun texte européen n’exige un « AI BOM », mais l’annexe IV, l’article 25(4) et les annexes XI et XII du règlement sur l’IA (AI Act) et l’annexe I du règlement sur la cyberrésilience en exigent l’essentiel.
• Ni risque lié à la destination, ni supervision humaine, ni tests, ni dossier de risques : une liste d’ingrédients, pas un dossier technique.
• Dates : modèles à usage général depuis le 2 août 2025, signalements CRA depuis le 11 septembre 2026, haut risque et SBOM du CRA en décembre 2027.

Qu’est-ce qu’un AI BOM ?

Le G7 en donne une définition sobre : un enregistrement structuré, autrement dit un inventaire, des détails et des relations de chaîne d’approvisionnement concernant les composants utilisés pour construire un système d’IA. Le texte parle lui-même d’une « liste d’ingrédients ». Pourquoi la nomenclature logicielle classique (SBOM) ne suffit-elle pas ? Parce qu’un modèle n’est pas une bibliothèque : son comportement vient de poids et de données d’entraînement qu’aucun manifeste de paquets ne décrit. Un jeu de données a une provenance, une licence et un niveau de sensibilité. Enfin, un système d’IA appelle des services externes qui n’apparaissent dans aucun fichier de build. Selon le guide du G7, les systèmes d’IA sont aussi des systèmes logiciels, le SBOM reste donc valable pour eux, et les éléments propres à l’IA viennent en supplément.

AI BOM, AIBOM, ML-BOM, SBOM for AI : un seul objet, plusieurs noms

Le vocabulaire est moins stable que l’objet :

• AIBOM ou AI BOM (pour AI bill of materials) : l’usage de l’industrie et de l’OWASP ;
• ML-BOM : le nom que CycloneDX donne à l’objet ;
• SBOM for AI : le nom retenu par le G7 et les agences ;
• AI SBOM : le nom de l’initiative de l’OWASP consacrée au sujet.

Deux voisins ne doivent pas être confondus avec lui. La model card est une documentation rédigée, destinée à des lecteurs humains, qui décrit un seul modèle ; la liste du G7 y renvoie par un lien. L’inventaire des systèmes d’IA, ou registre, est la liste des systèmes à l’échelle de l’organisation : sous chaque fiche d’inventaire vient se ranger un AI BOM par version du système.

Ce que contient un AI BOM : les 50 éléments minimaux du G7

Le document s’intitule « Software Bill of Materials for AI, Minimum Elements ». Il a été publié le 12 mai 2026 par sept agences : le BSI (Allemagne), l’ACN (Italie), l’ANSSI (France), le CSE (Canada), la CISA (États-Unis), le NCSC (Royaume-Uni) et le NCO (Japon), en collaboration avec la Commission européenne. Le groupe de travail était copiloté par l’ACN et le BSI, sous les présidences canadienne (2025) puis française (2026) du G7. Il prolonge la « vision partagée » de juin 2025, a été rédigé entre août 2025 et février 2026 et tient en 26 pages, disponibles sur le site du BSI. Voici la répartition, selon notre décompte : <table header-row= »true »> <tr> <td>Famille</td> <td>Nombre d’éléments</td> <td>Ce qu’elle consigne</td> </tr> <tr> <td>Métadonnées</td> <td>10</td> <td>Le document lui-même : auteur, version, nom et version du format, signature numérique de l’auteur, outil et sa version, contexte de génération (avant, pendant ou après le build), horodatage, relation de dépendance</td> </tr> <tr> <td>Propriétés du système</td> <td>9</td> <td>Le système dans son ensemble : nom, composants (modèles, bases de données, autres logiciels), producteur, version, horodatage, flux de données entre composants et vers les services externes, usage des données, entrées et sorties, domaine d’application prévu</td> </tr> <tr> <td>Modèles</td> <td>13</td> <td>Chaque modèle : nom, identifiant, version, horodatage, producteur, description (capacités, limites connues, lignée), empreinte et algorithme de hachage, architecture et nombre de paramètres, entrées et sorties (longueur de contexte, modalité), propriétés d’entraînement, licence, références externes (model card, article)</td> </tr> <tr> <td>Jeux de données</td> <td>10</td> <td>Chaque jeu de données : nom, description (pré-entraînement, affinage ou évaluation), contenu, identifiant, empreinte, provenance (origine, mode de collecte, traitement et annotation, données synthétiques), propriétés statistiques, sensibilité (données personnelles, contenus protégés par le droit d’auteur, données financières ou médicales), relation de dépendance, licence</td> </tr> <tr> <td>Infrastructure</td> <td>2</td> <td>Logiciels nécessaires à l’exécution (micrologiciels, bibliothèques, frameworks, environnements d’exécution, outils) et matériel, par renvoi à une nomenclature matérielle (HBOM)</td> </tr> <tr> <td>Propriétés de sécurité</td> <td>4</td> <td>Contrôles de sécurité généraux et propres à l’IA (injection de prompt, filtres d’entrée et de sortie), conformité de sécurité (certifications, normes), politique de cybersécurité (lien vers le security.txt du producteur), référencement des vulnérabilités</td> </tr> <tr> <td>Indicateurs de performance</td> <td>2</td> <td>Mesures de sécurité (résistance à la manipulation par un tiers) et performance opérationnelle (disponibilité, délai de résolution des incidents, latence, débit)</td> </tr> </table> Soit 7 familles et 50 éléments, et trois constats. Le centre de gravité est le couple modèle et données. 23 des 50 éléments décrivent les modèles et les jeux de données ; 2 seulement décrivent l’infrastructure, et le matériel est traité par un simple lien vers une nomenclature matérielle. La rubrique sur la sensibilité des données recoupe les questions que pose le RGPD appliqué à l’IA. L’intégrité est intégrée à la liste. Une empreinte et son algorithme pour chaque modèle, une empreinte pour chaque jeu de données, et une signature numérique de l’auteur sur le document lui-même. Lorsque l’auteur ne dispose pas d’une information, le guide demande d’indiquer qu’elle est inconnue plutôt que de laisser le champ vide. La model card n’est pas remplacée. Les éléments « propriétés d’entraînement » et « références externes » du modèle y renvoient par un lien. L’AI BOM pointe vers la documentation rédigée, il ne la recopie pas.

Formats d’un AI BOM : CycloneDX et SPDX

Deux formats ouverts portent aujourd’hui l’artefact. CycloneDX, projet de l’OWASP normalisé sous la référence ECMA-424, propose une nomenclature d’apprentissage automatique (ML-BOM) depuis sa version 1.5. SPDX 3.0, porté par la Linux Foundation, a ajouté un profil AI et un profil Dataset, décrits dans un rapport de mise en œuvre. La comparaison la plus utile vient d’une présentation donnée au NIST le 19 mai 2026 par Cassie Crossley et Allan Friedman : <table header-row= »true »> <tr> <td>Format</td> <td>Point fort</td> <td>Limite</td> </tr> <tr> <td>CycloneDX ML-BOM (versions 1.5 à 1.7)</td> <td>Types natifs pour l’apprentissage automatique, large prise en charge par les outils</td> <td>Moins de champs de métadonnées IA ; pas de champ natif pour les données personnelles sensibles, l’explicabilité, l’autonomie ou le risque de sûreté</td> </tr> <tr> <td>SPDX 3.0.1, profil AI</td> <td>Les métadonnées IA les plus riches (explicabilité, énergie, données personnelles sensibles, risque de sûreté), relations formelles « entraîné sur » et « testé sur »</td> <td>Outillage encore en maturation, format JSON-LD moins commode dans les pipelines de build</td> </tr> </table> La même présentation signale l’OWASP AIBOM Generator, outil open source présenté à RSAC 2025, qui produit des documents CycloneDX 1.6 pour les modèles hébergés sur Hugging Face. La correspondance avec le profil AI de SPDX était encore en cours en mai 2026. Le guide du G7 ne prescrit aucun format : sa famille « Métadonnées » demande seulement d’en indiquer le nom et la version. Règle pratique : choisissez le format que votre outillage SBOM produit déjà. Le règlement sur la cyberrésilience demandera le SBOM dans la même chaîne de build, et maintenir deux formats n’apporte rien à la sécurité de l’IA.

Ce qu’un AI BOM ne prouve pas

Le texte du G7 précise qu’il ne crée ni exigence, ni norme, ni législation. Nous avons vérifié en plein texte : ses 26 pages ne nomment aucun règlement. C’est un document de cybersécurité. Sur les 14 pages les mieux classées que nous avons analysées sur cette requête, aucune ne reproduit la liste du G7, une seule rapproche l’artefact de l’annexe IV du règlement sur l’IA, une seule cite le règlement sur la cyberrésilience, aucune ne mentionne les annexes XI ou XII. Le tableau ci-dessous est notre lecture, pas une correspondance établie par le G7 ou par la Commission. <table header-row= »true »> <tr> <td>Ce que demande l’annexe IV</td> <td>Dans l’AI BOM ?</td> <td>Où se trouve la preuve</td> </tr> <tr> <td>Destination, fournisseur, versions (point 1)</td> <td>En partie : nom du système, producteur, version, domaine d’application prévu</td> <td>Notice d’utilisation, fiche de classification</td> </tr> <tr> <td>Systèmes pré-entraînés et outils tiers utilisés, et leur intégration (point 2, a)</td> <td>Oui : famille Modèles, lignée, composants du système</td> <td>AI BOM et accords fournisseurs</td> </tr> <tr> <td>Architecture du système et articulation des composants (point 2, c)</td> <td>Oui : composants du système, flux de données</td> <td>AI BOM et description d’architecture</td> </tr> <tr> <td>Données d’entraînement : provenance, portée, mode d’obtention, étiquetage, nettoyage (point 2, d)</td> <td>En grande partie : famille Jeux de données</td> <td>Fiches de données, dossier de gouvernance des données (article 10)</td> </tr> <tr> <td>Mesures de supervision humaine (point 2, e)</td> <td>Non</td> <td>Conception et attribution de la supervision (article 14)</td> </tr> <tr> <td>Validation et tests : métriques, journaux de tests, rapports signés (point 2, g)</td> <td>À la marge : deux indicateurs de performance</td> <td>Rapports de tests, métriques d’exactitude (article 15)</td> </tr> <tr> <td>Système de gestion des risques (point 5)</td> <td>Non</td> <td>Dossier de gestion des risques (article 9)</td> </tr> <tr> <td>Normes appliquées, déclaration UE de conformité, plan de surveillance après commercialisation (points 7, 8, 9)</td> <td>Non (certifications de sécurité uniquement)</td> <td>Dossier de conformité</td> </tr> </table> La documentation d’un système d’IA au sens de l’annexe IV reste donc un travail distinct, et les campagnes de tests et de red teaming n’y laissent que deux indicateurs. L’omission délibérée. Le groupe du G7 a discuté d’un élément portant sur le niveau de prise de décision ou d’autonomie du système. Il en a reconnu la pertinence, compte tenu de l’IA agentique, puis a choisi de ne pas en faire un élément distinct, en notant que les juridictions peuvent traiter la question différemment, y compris par des exigences de sûreté. C’est exactement l’objet de l’article 14 (supervision humaine) et de la qualification de système d’IA à haut risque. Cette trace doit donc exister ailleurs. La conclusion du G7 elle-même. Un AI BOM ne suffit pas à lui seul : il doit être relié aux outils de cybersécurité, c’est-à-dire à l’analyse et à la gestion des vulnérabilités, aux avis et aux bulletins de sécurité. Il ne dispense pas davantage de l’évaluation de la conformité.

Quels textes rendent le contenu d’un AI BOM exigible

Aucun texte européen n’emploie le terme, mais le règlement sur l’IA et le règlement sur la cyberrésilience en réclament la substance.

• Règlement sur l’IA, article 11 et annexe IV. La documentation technique d’un système à haut risque est établie avant la mise sur le marché et tenue à jour. Le point 2 de l’annexe IV demande notamment les systèmes pré-entraînés ou outils tiers utilisés et leur mode d’intégration, l’architecture du système, et des fiches décrivant les données d’entraînement et leur provenance. Elle est conservée 10 ans (article 18). Depuis l’omnibus numérique, règlement (UE) 2026/1744, ces obligations s’appliquent aux systèmes de l’annexe III à partir du 2 décembre 2027 et aux systèmes intégrés à des produits de l’annexe I à partir du 2 août 2028.
• Règlement sur l’IA, article 25(4). Le fournisseur d’un système à haut risque et le tiers qui lui fournit un système, un outil, un service, un composant ou un processus utilisé dans ce système précisent, par accord écrit, les informations, les capacités, l’accès technique et l’assistance nécessaires. L’exception vise les outils et composants autres que les modèles à usage général publiés sous licence libre et ouverte. C’est la base juridique pour demander un AI BOM à un fournisseur.
• Règlement sur l’IA, article 53 et annexes XI et XII. Les fournisseurs de modèles d’IA à usage général tiennent une documentation technique pour le Bureau de l’IA et remettent des informations aux fournisseurs en aval : architecture et nombre de paramètres, modalité et format des entrées et sorties, licence, type et provenance des données d’entraînement. Applicable depuis le 2 août 2025.
• Règlement sur l’IA, article 15. Exactitude, résilience et cybersécurité des systèmes à haut risque, y compris des mesures contre l’empoisonnement des données et des modèles.
• Règlement sur la cyberrésilience, règlement (UE) 2024/2847. L’annexe I, partie II, impose aux fabricants de produits comportant des éléments numériques d’établir une nomenclature logicielle dans un format couramment utilisé et lisible par machine, couvrant au minimum les dépendances de premier niveau. Elle figure dans la documentation technique, est remise aux autorités de surveillance du marché sur demande et n’a pas à être publiée. Le signalement des vulnérabilités activement exploitées s’applique depuis le 11 septembre 2026, le règlement dans son ensemble à partir du 11 décembre 2027. Selon son article 12, un système d’IA à haut risque qui est un produit comportant des éléments numériques et satisfait aux exigences essentielles du CRA est réputé satisfaire à l’exigence de cybersécurité de l’article 15 du règlement sur l’IA.
• NIS2. La sécurité de la chaîne d’approvisionnement fait partie des mesures de gestion des risques de l’article 21.

Les juristes font le même rapprochement. Dans une analyse du 16 juin 2026, le cabinet Morgan Lewis relève que la liste du G7 recoupe les articles 11 et 13 et l’annexe IV, et s’attend à ce que les lignes directrices européennes reprennent certains de ses éléments. C’est leur lecture, pas une position officielle. En France, l’ANSSI figure parmi les sept agences signataires, et la liste a été publiée sous la présidence française du G7 de 2026. Le socle qu’une autorité française reconnaîtra existe donc déjà. Pour le règlement sur l’IA, la surveillance du marché est répartie entre plusieurs autorités selon le secteur.

Comment construire un AI BOM : une méthode en sept étapes

1. Délimiter. Un AI BOM par système d’IA et par version, rattaché à la fiche du système dans l’inventaire des systèmes d’IA (c’est le rôle d’un registre des systèmes d’IA).
2. Générer, ne pas saisir. Extrayez les informations du registre de modèles, du pipeline d’entraînement et du build, dans le format de votre outillage SBOM. Un document tapé à la main est périmé au prochain réentraînement.
3. Remplir les sept familles, et écrire « inconnu » quand vous ne savez pas. C’est particulièrement vrai pour les modèles tiers.
4. Hacher et signer. Les fichiers de modèles, les fichiers de données, puis le document lui-même.
5. Relier ce que l’AI BOM ne contient pas. Model card, dossier de gestion des risques, mesures de supervision, rapports de tests.
6. L’inscrire dans les contrats. Demandez un AI BOM aux fournisseurs à l’entrée en relation et à chaque nouvelle version du modèle, sur le fondement de l’article 25(4) lorsque le système est à haut risque. Voir la due diligence des fournisseurs d’IA.
7. Le maintenir en vie. Régénérez-le à chaque réentraînement, affinage, changement de dépendance ou d’outil, par exemple après la correction d’une dérive du modèle. Alimentez la gestion des vulnérabilités et le circuit de signalement des incidents d’IA. Conservez les versions 10 ans lorsque le règlement sur l’IA ou le CRA s’applique.

Chaque étape laisse une trace datée.

AI BOM des modèles tiers et des agents IA

Les modèles consommés par API. Sans accès aux poids, pas d’empreinte. L’entrée honnête est « inconnu », accompagnée de la documentation du fournisseur. Pour les modèles à usage général, ce fournisseur doit aux fournisseurs en aval les informations de l’annexe XII, qui remplissent l’essentiel de la famille Modèles. Les agents. L’élément « flux de données du système » du G7 nomme déjà les API de services externes, les protocoles de communication entre agents et l’ancrage sur le web. La présentation du NIST de mai 2026 esquisse une « nomenclature de système agentique » qui ajoute les outils, les serveurs MCP, les prompts, les politiques, la mémoire et les liaisons d’identité, ainsi que des preuves d’exécution (appels d’outils, approbations, actions refusées). Aucun format ne normalise aujourd’hui cette couche : consignez les outils et leurs périmètres dans les familles « Propriétés du système » et « Infrastructure », et conservez les journaux d’exécution à part, dans l’esprit des pratiques de sécurité de l’IA agentique et des lignes directrices du NCSC. Un déployeur rédige rarement un AI BOM : il le demande. Il y lit trois choses (quel modèle et quelle version, quelle sensibilité des données, quels services externes), puis le classe avec la fiche du système.

Questions fréquentes

Qu’est-ce qu’un AI BOM, en termes simples ? C’est la liste d’ingrédients d’un système d’IA, dans un fichier lisible par machine. On y trouve les modèles utilisés et leur version, les jeux de données qui ont servi à les entraîner ou à les évaluer, les bibliothèques et services dont le système dépend, et les liens entre ces éléments. Le document est signé et daté. Il sert à savoir vite quels systèmes sont touchés quand une vulnérabilité est annoncée. Quelle est la différence entre un AI BOM et un SBOM ? Le SBOM recense les composants logiciels : bibliothèques, frameworks, dépendances et leurs versions. L’AI BOM y ajoute ce qu’un manifeste de paquets ne voit pas : les modèles (poids, architecture, lignée), les jeux de données (provenance, licence, sensibilité), les flux vers les services externes et quelques propriétés de sécurité propres à l’IA. Pour le G7, un système d’IA reste un logiciel : le SBOM demeure nécessaire, et les éléments IA viennent en plus. Un AI BOM est-il obligatoire au titre du règlement sur l’IA ? Pas sous ce nom. Son contenu, en revanche, est largement exigé. L’annexe IV impose de documenter les modèles pré-entraînés, l’architecture et les données d’entraînement des systèmes à haut risque, et les annexes XI et XII imposent des informations comparables aux fournisseurs de modèles à usage général. Le règlement sur la cyberrésilience, lui, impose bel et bien un SBOM aux fabricants de produits numériques. Quel format choisir pour un AI BOM ? Celui que votre outillage produit déjà. CycloneDX, avec son ML-BOM, est le mieux pris en charge par les outils et s’insère facilement dans une chaîne de build. SPDX 3.0 offre les métadonnées les plus riches, avec un outillage encore en maturation. Le guide du G7 ne tranche pas : il demande seulement que le document indique le nom et la version du format. Qui doit produire l’AI BOM, le fournisseur ou le déployeur ? Celui qui construit le système, donc le plus souvent le fournisseur : lui seul connaît les modèles, les données et les dépendances réellement utilisés. Le tiers dont il intègre le modèle lui doit les informations nécessaires (article 25(4) ou annexe XII). Le déployeur, lui, demande le document, le lit et le conserve avec la fiche du système. Un déployeur n’a donc pas à le rédiger, mais il doit savoir le lire. Un AI BOM remplace-t-il une model card ou la documentation technique ? Non. La model card décrit en prose un modèle, ses usages prévus et ses limites ; l’AI BOM y renvoie par un lien. La documentation technique de l’annexe IV couvre en plus la supervision humaine, la gestion des risques, les tests et la conformité, que la liste du G7 ne traite pas. Les trois pièces se complètent, aucune ne remplace les autres.

Conclusion

Le contenu d’un AI BOM n’est plus l’opinion d’un éditeur : sept familles, cinquante éléments, signés par sept agences. Ce que la liste ne dit pas, c’est quelle loi s’applique à votre système et ce qu’une autorité demandera en plus : la destination, le niveau de risque, la supervision humaine, les tests. Commencez par un seul système. Générez le document plutôt que de le rédiger, écrivez « inconnu » là où vous ne savez pas, puis reliez le reste du dossier. AI Sigil conserve chaque système d’IA sous forme de fiche, avec ses modèles, ses jeux de données, ses composants, ses risques, ses contrôles et ses preuves : l’AI BOM y trouve sa place, et le reste du dossier est à un clic.