Divulgation de la version du modèle IA : ce que votre conseil doit savoir

Quand un conseil approuve une analyse générée par IA, la version du modèle qui l'a produite fait partie de la base de preuves de la décision. Ce guide énonce un standard de divulgation en une ligne, un test de matérialité pour déterminer quand une mise à jour du modèle d'une plateforme impose d'en informer le conseil, et les questions à poser aux fournisseurs pour rendre la traçabilité des versions opposable.

Trois choses que le conseil doit comprendre, et une qu'il n'a pas besoin de comprendre : il doit savoir que la version est figée, consignée et récupérable ; il a besoin d'un test de matérialité pour savoir quand prêter attention à une mise à jour ; et il doit poser les bonnes questions aux fournisseurs. Il n'a pas besoin de comprendre le fonctionnement du modèle.

L'analyse générée par IA est discrètement devenue une donnée de routine dans les dossiers du conseil d'administration. La supervision formelle n'a pas suivi le même rythme. Quand ISS-Corporate a examiné les déclarations de procuration des entreprises du S&P 500, il a constaté que seulement 15 % environ des entreprises fournissaient une quelconque information sur la supervision du conseil en matière d'IA, et seulement 1,6 % révélaient une supervision explicite du conseil plénier ou au niveau d'un comité.^[1]

• Seulement environ 15 % des entreprises du S&P 500 divulguent un quelconque niveau de supervision du conseil en matière d'IA dans leurs déclarations de procuration.
• Seulement 1,6 % divulguent une supervision explicite du conseil plénier ou au niveau d'un comité.
• Les obligations de transparence de l'article 50 de l'AI Act européen s'appliquent à compter du 2 août 2026, imposant la divulgation du caractère généré par IA des contenus et le marquage lisible par machine des résultats génératifs.^[2]

La question plus précise, largement non résolue, est la suivante : quelle version du modèle a produit l'analyse, et que se passe-t-il pour la responsabilité quand la plateforme met silencieusement à jour ce modèle après que le conseil a donné son accord ? Les conseils incapables de répondre à cette question ne peuvent pas reconstituer ce qu'ils ont approuvé, même en principe.

Le modèle est un paramètre structurant de l'analyse elle-même : il détermine comment les problèmes sont posés, quels cadrages émergent, comment les preuves sont pondérées et dans quel langage les conclusions sont rédigées. Relancer le même brief sur une version différente du modèle peut produire un document substantiellement différent.

Des recherches sur les tests de régression pour les systèmes d'IA générative ont constitué un référentiel de 80 cas de test par langue dans huit catégories de tâches et ont constaté que les modèles plus récents améliorent généralement la justesse en moyenne, mais que les améliorations peuvent être modestes et inégales, et qu'une version plus récente peut s'améliorer globalement tout en se dégradant de manière inattendue sur des entrées ou des tâches spécifiques.^[3]

Trois propriétés qui dépendent de la connaissance de la version :

• Reproductibilité : si la version n'est pas consignée, personne ne peut reconstituer ultérieurement quel système a produit le résultat approuvé.
• Responsabilité : la personne qui présente l'analyse, et non le fournisseur, répond de son contenu. Cette responsabilité repose sur un état spécifique du système.
• Détection de dérive : le comportement du modèle change selon les versions. Les recommandations d'IBM sur la dérive des modèles identifient la détection de dérive comme une composante centrale d'une bonne gouvernance de l'IA, qui commence par la connaissance de la version de référence.^[4]

Trois éléments en une seule ligne de page de garde suffisent à rendre une analyse assistée par IA reconstituable. Le format exact importe moins que la discipline : tout document assisté par IA soumis au conseil porte cette ligne.

1. Le nom de la plateforme ou de l'outil, afin que l'artefact soit attribuable à un système spécifique.
2. La version du modèle ou la plage de versions, afin que l'état exact du système soit identifiable.
3. La date de génération, reliée à l'historique des versions du fournisseur.

Une ligne utilisable : « Analyse générée sur [Plateforme], version du modèle [X], le [date]. » Cela donne au conseil, à la fonction d'audit et à tout examinateur futur les trois coordonnées nécessaires pour localiser l'analyse dans l'historique des versions du fournisseur.

La même discipline doit s'étendre à toute mise à jour significative. Si une analyse est actualisée à une date ultérieure, la page de garde porte la ligne de divulgation de la version actualisée – et si la version du modèle a changé entre l'original et l'actualisation, ce changement est mentionné.

Si la plateforme met à jour son modèle sous-jacent après que le conseil a approuvé l'analyse, l'artefact approuvé n'est pas affecté, à condition que la version sur laquelle il a été généré soit figée, consignée et récupérable. La validation est attachée à l'artefact, non à la version actuelle du fournisseur.

Le changement devient significatif quand l'analyse doit être relancée, actualisée ou utilisée pour une décision en cours. Les fournisseurs déprécient fréquemment les versions plus anciennes selon leur propre calendrier, et les mises à jour des modèles sous-jacents peuvent modifier silencieusement le comportement.^[5]

Trois questions à poser quand un fournisseur annonce un changement de modèle :

• Cette analyse sera-t-elle relancée ou actualisée sur la nouvelle version ? Si oui, les résultats peuvent différer et le comité devrait voir les deux versions côte à côte.
• Une décision en cours s'appuiera-t-elle encore sur elle ? Une utilisation en temps réel signifie que c'est l'état actuel du modèle qui fait le travail, non l'artefact figé.
• Le fournisseur a-t-il donné un préavis suffisant ? Le préavis détermine si l'équipe a eu le temps de tester la nouvelle version avant de s'y fier.

Règle pratique : informer le conseil quand un relancement sur la nouvelle version changerait vraisemblablement une conclusion significative. Ne pas informer le conseil à chaque changement de numéro de version.

Trois questions transforment la préoccupation relative à la version du modèle en engagements opposables au moment de la signature du contrat, plutôt qu'après que l'analyse est déjà dans un dossier du conseil.

1. La version du modèle est-elle journalisée dans la piste d'audit de chaque résultat généré, et peut-elle être exportée dans le cadre d'un dossier de reproductibilité comprenant les sources et les requêtes ?
2. Que dit l'accord de service sur les changements de modèles, les dépréciations et les délais de préavis ?
3. Un bon de commande entreprise peut-il renforcer les conditions de préavis et de gel de version à la signature ?

Les délais de préavis des fournisseurs varient considérablement. L'analyse des conditions en vigueur chez les fournisseurs indique qu'OpenAI s'engage à 14 jours de préavis pour les changements de modèles, Anthropic et Google à 30 jours, et certains fournisseurs ne s'engagent sur aucun délai.^[6] Ces clauses par défaut constituent souvent des planchers plutôt que des plafonds ; les délais de préavis et les engagements de gel de version sont véritablement négociables à la signature pour les clients entreprises.

Le conseil n'a besoin de presque aucun détail technique. Trois propriétés qu'un administrateur non technique peut vérifier suffisent :

1. La version du modèle est-elle consignée pour chaque analyse assistée par IA qui nous parvient ?
2. Ce registre est-il conservé sous une forme que nous pourrions récupérer dans un an, si une décision était contestée ?
3. La version derrière un document donné est-elle figée, de sorte qu'un relancement aujourd'hui serait effectué sur un état de système connu et nommé ?

Les détails techniques – architecture du transformateur, nombre de paramètres, scores de référence – appartiennent au niveau inférieur, celui du secrétaire général ou de la fonction d'audit. Les conseils s'appuient déjà sur des modèles de valorisation, des hypothèses actuarielles et des méthodes d'échantillonnage statistique dont la plupart des administrateurs ne peuvent pas reconstituer les mécanismes. La version du modèle est le même type d'entrée : un état de système nommé et daté auquel on peut se référer ultérieurement, et non un mécanisme que le conseil doit comprendre.

La mission du secrétaire général ou de la fonction d'audit est de confirmer, une fois par an, que la discipline de journalisation des versions est appliquée et qu'au moins une analyse significative de l'année écoulée peut être reproduite sur la version sur laquelle elle a été générée.

Cet exemple est illustratif. Un comité d'investissement d'une société de private equity approuve une analyse de transaction assistée par IA au premier trimestre. La page de garde porte la ligne de divulgation : nom de la plateforme, version du modèle et date de génération. Un dossier de reproductibilité est archivé avec le dossier de la transaction.

Au deuxième trimestre, la plateforme met à jour son modèle sous-jacent. La revue de gouvernance effectue trois vérifications :

1. L'analyse du T1 approuvée est-elle encore reproductible sur la version figée ? Si le fournisseur l'a déjà dépréciée, le dossier de reproductibilité devient le seul enregistrement de ce qui a été approuvé.
2. Un relancement au T2 sur le nouveau modèle change-t-il une conclusion significative ? Si oui, l'élément est signalé pour ré-approbation avec les anciens et nouveaux résultats côte à côte.
3. Les conditions de préavis du fournisseur ont-elles laissé à l'équipe suffisamment de temps pour tester la nouvelle version avant toute utilisation ? Si non, les conditions contractuelles devront être revues au renouvellement.

Le résultat est l'une de deux courtes notes au comité : soit l'analyse approuvée n'est pas affectée et l'artefact du T1 est archivé, soit l'élément est signalé pour ré-approbation. Aucune ne nécessite que le comité comprenne les détails techniques du changement de modèle.

Les plateformes conçues pour le travail stratégique au niveau du conseil, telles que Decisity, traitent la traçabilité des sources et l'auditabilité comme des exigences de conception fondamentales, de sorte que la version jointe et le dossier de reproductibilité sont produits dans le cadre du flux de travail standard plutôt que comme une tâche de documentation rétrospective.

Lectures associées :

• Qui est responsable quand une stratégie générée par IA se révèle erronée ?
• Clauses de confidentialité à exiger d'un fournisseur de plateforme IA
• Documents confidentiels et outils IA : que vérifier
• Présenter une analyse stratégique assistée par IA à un conseil sceptique

• ISS-Corporate via Harvard Law School Forum on Corporate Governance : AI Governance Appears on Corporate Radar (avril 2024)
• AI Act européen : article 50, Obligations de transparence
• GPR-bench : tests de régression pour les systèmes d'IA générative
• IBM : Qu'est-ce que la dérive des modèles ?
• The Neural Base : Comment les mises à jour des modèles modifient le comportement de l'IA
• Digital Applied : Grilles tarifaires IA et engagements implicites dans les achats