Nomenclature de l'IA (AI-BOM)

Une nomenclature de l'IA (AI-BOM, pour AI bill of materials) est un inventaire structuré de chaque composant qui constitue un système d'IA : les modèles, les jeux de données, les bibliothèques, les dépendances et les sources de données d'entraînement.

L'idée s'inspire directement de la nomenclature logicielle (SBOM), qui répertorie les composants open source et tiers contenus dans un logiciel. Une SBOM répond à la question « qu'y a-t-il réellement dans ce produit ? ». L'AI-BOM étend cette question aux éléments propres à l'apprentissage automatique, où les poids du modèle et les données comptent autant que le code.

Cela importe parce que les systèmes d'IA sont assemblés, et non écrits à partir de zéro. Un déploiement type assemble un modèle de fondation, plusieurs bibliothèques Python, un jeu de données d'affinage, une base de données vectorielle et une poignée d'API. Lorsqu'un problème survient, ou lorsqu'un régulateur demande à partir de quoi vous l'avez construit, il vous faut un relevé. Sans cela, vous avancez à l'aveugle.

Pour les équipes de gouvernance, de risque et de sécurité, l'AI-BOM devient l'unité de base de la responsabilité. On ne peut pas gérer ce qu'on ne voit pas, et une AI-BOM rend la chaîne d'approvisionnement visible.

Pourquoi l'analogie avec la SBOM tient, et où elle se rompt

La SBOM s'est imposée en partie à cause des attaques sur la chaîne d'approvisionnement, où une seule dépendance compromise se répercutait sur des milliers de produits. Régulateurs et acheteurs ont commencé à exiger une liste d'ingrédients pour vérifier rapidement la présence de vulnérabilités connues.

Les systèmes d'IA font face au même problème de dépendances, et à davantage encore. Un modèle peut comporter des risques qui n'ont pas d'équivalent dans un logiciel ordinaire : des données d'entraînement posant des problèmes de droit d'auteur ou de vie privée, un biais dissimulé inscrit dans les poids, un modèle de base à la provenance inconnue, ou un jeu de données empoisonné qui modifie subtilement le comportement.

L'AI-BOM conserve donc l'objectif central de la SBOM, connaître ses ingrédients, mais l'élargit. Les dépendances de code n'en sont qu'une partie. Les données et la lignée du modèle sont souvent les éléments qui portent le plus de poids juridique et éthique.

Ce que doit contenir une AI-BOM

Une AI-BOM utile va au-delà d'une simple liste de noms de paquets. Au minimum, elle doit consigner :

• Les modèles. Chaque modèle du système, y compris les modèles de base et les variantes affinées, avec leur version, leur source, leur licence et leur fournisseur.

• Les jeux de données. Les jeux de données d'entraînement, de validation et d'affinage, avec leurs sources, leurs licences, leurs dates de collecte et toute restriction d'usage connue.

• La provenance des données d'entraînement. D'où proviennent les données, comment elles ont été recueillies, si elles incluent des données à caractère personnel ou protégées par le droit d'auteur, et quel consentement ou quelle licence les couvre.

• Les bibliothèques et frameworks. Les frameworks d'apprentissage automatique, les moteurs d'inférence et les paquets associés, avec leurs versions, comme une SBOM les répertorie.

• Les dépendances. Les dépendances transitives entraînées par ces bibliothèques, car une vulnérabilité située trois niveaux plus bas reste une vulnérabilité.

• Les services externes. Les API, les modèles hébergés et les points de terminaison tiers que le système appelle à l'exécution.

• La configuration et les poids. Les références vers les poids du modèle, les points de sauvegarde et les hyperparamètres clés qui définissent l'artefact déployé.

L'objectif est qu'une personne n'ayant jamais vu le système puisse lire l'AI-BOM et comprendre de quoi il est fait, d'où vient chaque pièce et quelles obligations l'accompagnent.

Pourquoi régulateurs et équipes de sécurité l'attendent

Plusieurs pressions convergent pour faire des AI-BOM une attente plutôt qu'un agrément.

La réglementation en est une. Le règlement européen sur l'IA (EU AI Act) exige une documentation technique détaillée pour les systèmes à haut risque, y compris des informations sur les données et les composants du système. Une AI-BOM est un moyen naturel de produire une partie de cette documentation.

La sécurité en est une autre. À mesure que l'IA passe en production, les attaquants sondent la chaîne d'approvisionnement de l'IA : modèles malveillants publiés sur des plateformes publiques, jeux de données empoisonnés, bibliothèques compromises. Les équipes de sécurité ont besoin d'un inventaire pour évaluer leur exposition lorsqu'une nouvelle vulnérabilité ou un composant malveillant est divulgué.

L'approvisionnement en est une troisième. Les acheteurs demandent de plus en plus aux fournisseurs à partir de quoi leurs systèmes d'IA sont construits avant de signer. Un fournisseur capable de remettre une AI-BOM paraît bien plus digne de confiance que celui qui ne peut rendre compte de sa propre pile technique.

Comment les équipes en construisent et en assurent la maintenance

Une AI-BOM n'a de valeur que si elle reste à jour. L'approche pratique consiste à la générer dans le cadre du pipeline de construction et d'entraînement plutôt que de l'assembler à la main après coup.

Commencez par capturer ce que vous suivez déjà. Les gestionnaires de paquets connaissent vos versions de bibliothèques. Les registres de modèles connaissent vos versions de modèles. Les catalogues de données connaissent vos jeux de données. Une grande partie d'une AI-BOM peut être assemblée à partir de systèmes que vous exploitez déjà.

Comblez les lacunes que l'automatisation laisse, en particulier la provenance des données. L'origine d'un jeu de données et la licence qui le couvre sont souvent les plus difficiles à reconstituer, alors consignez-les au moment de la collecte.

Versionnez l'AI-BOM en parallèle du système. Chaque changement notable, un nouveau modèle de base, un affinage, une bibliothèque remplacée, devrait produire une nouvelle AI-BOM afin de retracer exactement ce qui a été déployé et quand.

Rangez-la là où les personnes qui en ont besoin peuvent la trouver : la sécurité, le juridique et la conformité, et pas seulement l'équipe d'ingénierie qui l'a produite.

FAQ

En quoi une AI-BOM diffère-t-elle d'une SBOM ?

Une SBOM répertorie les composants logiciels d'un produit, principalement les bibliothèques de code et leurs dépendances. Une AI-BOM les inclut, mais ajoute les éléments propres à l'apprentissage automatique : modèles, jeux de données, sources de données d'entraînement, poids et provenance du modèle. On peut voir l'AI-BOM comme un sur-ensemble qui couvre les parties d'un système d'IA qu'un inventaire logiciel ordinaire laisserait de côté.

Une AI-BOM est-elle exigée par la loi ?

Aucune loi unique n'emploie ce terme exact et ne l'impose, mais les informations sous-jacentes sont de plus en plus exigées. Le règlement européen sur l'IA réclame une documentation technique pour les systèmes à haut risque couvrant les données et les composants, et les normes d'approvisionnement et de sécurité vont dans le même sens. Une AI-BOM est un format pratique pour répondre à ces attentes.

Qui est chargé de produire l'AI-BOM ?

Habituellement l'équipe qui construit ou assemble le système d'IA, en collaboration avec la sécurité, le juridique et la gouvernance des données. Les fournisseurs de modèles peuvent en fournir une partie pour leurs propres modèles, et les déployeurs l'étendent pour couvrir la façon dont ils ont affiné, configuré et intégré le système.

Quel est l'élément le plus difficile à capturer dans une AI-BOM ?

La provenance des données. Les versions de bibliothèques et de modèles sont suivies par l'outillage, mais l'origine, la licence et le statut de consentement des données d'entraînement sont souvent mal documentés, surtout pour les jeux de données anciens ou les sources extraites du web. Capturer cela au moment de la collecte est bien plus simple que de le reconstituer plus tard.

Une AI-BOM aide-t-elle lors des incidents de sécurité ?

Oui. Lorsqu'une vulnérabilité est divulguée dans une bibliothèque, qu'un modèle malveillant est repéré sur une plateforme publique, ou qu'un jeu de données se révèle empoisonné, une AI-BOM vous permet de répondre rapidement à la question de savoir si vos systèmes sont touchés. Sans elle, vous devez enquêter sur chaque système manuellement, ce qui est lent et source d'erreurs.

Dois-je partager mon AI-BOM avec mes clients ?

Cela dépend de la sensibilité. De nombreux fournisseurs en partagent une version avec les acheteurs lors de l'approvisionnement pour démontrer leur transparence, en masquant parfois des détails propriétaires. En interne, une version plus complète soutient le travail de sécurité et de conformité. Le niveau de divulgation est une décision d'affaires et de risque.

Résumé

Une nomenclature de l'IA est la liste d'ingrédients d'un système d'IA, qui étend le concept de nomenclature logicielle pour couvrir les modèles, les jeux de données, la provenance des données d'entraînement, les bibliothèques et les dépendances. Régulateurs, équipes de sécurité et acheteurs en attendent une de plus en plus, car les systèmes d'IA sont assemblés à partir de nombreuses pièces tierces, chacune portant son propre bagage juridique, éthique et de sécurité. Les AI-BOM les plus fiables sont générées automatiquement dans le cadre du pipeline de construction et d'entraînement, versionnées en parallèle du système et mises à disposition des fonctions de sécurité, juridiques et de conformité qui dépendent de la connaissance exacte de ce dont un système d'IA est fait.