Ce que la norme ISO 42001 exige, et ce qu'elle ne peut pas vous donner
La norme vous dit d'évaluer la performance de votre système d'IA et de conserver des registres de son comportement. Elle reste muette sur une question plus difficile : quand quelqu'un demande ce que le modèle a réellement fait sur une décision précise, que lui remettez-vous ?
Si vous mettez en œuvre un système de gestion de l'IA conforme à ISO/IEC 42001, vous passez beaucoup de temps dans la seconde moitié de la norme. La clause 9 vous demande de surveiller, de mesurer, d'analyser et d'évaluer votre système d'IA, et de planifier comment vous le ferez. La clause 8 vous demande de conserver les registres opérationnels qui montrent que le système s'est exécuté comme vos contrôles l'exigent. Les annexes vous poussent vers des preuves documentées de la performance tout au long du cycle de vie.
C'est une bonne discipline, et les entreprises qui bâtissent de véritables pratiques ISO 42001 font un travail sérieux. Mais une hypothèse discrète se cache sous les clauses d'évaluation de la performance, et il vaut la peine de la nommer directement, car presque tout le monde, dans la conversation sur la gouvernance, passe par-dessus.
L'hypothèse, c'est qu'un registre de ce que votre IA a fait est la même chose qu'une preuve de ce que votre IA a fait. Ce n'est pas le cas.
Ce que les clauses produisent réellement
Examinons ce que la surveillance et la mesure vous donnent en pratique. Vous journalisez les entrées et les sorties. Vous suivez des métriques de qualité sur une population de décisions : exactitude, dérive, taux d'erreur, variations de distribution. Vous conservez des artefacts qui montrent que le pipeline était correctement configuré et que les contrôles étaient en place. Quand un auditeur se présente, vous lui montrez les journaux, les tableaux de bord et les registres conservés.
Chacun de ces artefacts est produit par le système même qui a fait le travail, ou par des outils qui font confiance à ce système. Le journal indique que le modèle a renvoyé une sortie donnée parce que le modèle l'a dit au journaliseur. Le tableau de bord indique que la qualité est restée stable parce que le pipeline de métriques a lu les propres sorties du système. Le registre indique que la bonne version du modèle a été chargée parce que la configuration de déploiement l'affirme.
C'est un compte rendu autodéclaré. Il est cohérent en interne, souvent réellement utile, et exactement ce que la norme demande. Mais il répond à la question « qu'est-ce que notre système dit avoir fait » plutôt qu'à « qu'a-t-il réellement fait, sous une forme qu'un tiers peut vérifier sans nous faire confiance ».
L'organisation doit déterminer ce qui doit être surveillé et mesuré, les méthodes à employer, et quand les résultats doivent être analysés et évalués. La norme exige que la performance soit évaluée. Elle n'exige pas que cette évaluation soit vérifiable de façon indépendante.
Ce n'est pas un défaut de la norme. Une norme de système de gestion établit ce que vous devez gouverner, pas la forme cryptographique que vos preuves doivent prendre. ISO 27001 fait la même chose pour la sécurité de l'information : elle vous dit de contrôler les accès, pas quel chiffrement déployer. La norme définit l'obligation. Elle vous laisse le soin de la force de la preuve.
Où l'écart commence à se faire sentir
Pendant la majeure partie de l'histoire du logiciel d'entreprise, les registres autodéclarés suffisaient, parce que les questions portaient sur le processus. Aviez-vous un contrôle ? L'avez-vous suivi ? A-t-il été révisé ? Vous pouvez répondre à cela à partir de vos propres registres, et un auditeur qui vérifie le processus se satisfait d'un compte rendu honnête du processus.
L'IA change la question posée. Quand un système automatisé refuse une réclamation, décline un prêt, signale un candidat ou résume un dossier qui éclaire une décision clinique, le différend ne porte pas sur la présence d'un contrôle de surveillance. Il porte sur ce que le modèle a fait sur cette entrée précise. Un régulateur, un avocat de la partie adverse ou un client d'entreprise qui mène sa propre vérification ne demande pas à voir votre tableau de bord. Il vous demande de démontrer qu'un modèle précis a produit une sortie précise à partir d'une entrée précise, et de plus en plus, il préférerait ne pas avoir à vous croire sur parole.
C'est la jointure que je trouve la plus intéressante, et la raison pour laquelle je pense que les gens qui font du travail ISO 42001 et ceux qui construisent l'infrastructure de vérification regardent deux moitiés du même problème. Le praticien de la gouvernance a correctement reconnu que le comportement de l'IA doit être mesuré et étayé par des preuves. La primitive de vérification fournit la partie que le système de gestion n'a jamais été conçu pour porter : une preuve qui tient quand la personne qui l'examine n'a aucune raison de faire confiance à l'exploitant.
Ce que la preuve ajoute à un registre
Réfléchissez à ce qu'il faudrait pour monter d'un échelon sur l'échelle de la preuve, de « nous l'avons enregistré » à « nous pouvons le prouver ». Trois propriétés doivent être réunies.
Premièrement, la sortie doit être liée à ses entrées : un lien infalsifiable rattachant une identité de modèle précise à l'entrée exacte qu'elle a reçue et à la sortie exacte qu'elle a produite, de sorte qu'aucune des trois ne puisse être discrètement modifiée après coup. Deuxièmement, ce lien doit être vérifiable par quelqu'un d'autre que l'exploitant, ce qui signifie que la partie qui a exécuté le calcul ne peut pas être aussi la seule source de l'assurance qu'il s'est exécuté correctement. Troisièmement, la vérification doit être indépendante de la confiance dans l'environnement d'exécution : le vérificateur ne devrait pas avoir à présumer que l'exécuteur était honnête, parce qu'une partie distincte peut confirmer le résultat par elle-même.
Rien de tout cela ne remplace ISO 42001. Cela s'inscrit à l'intérieur. Les clauses d'évaluation de la performance vous disent que vous devez des preuves de la façon dont votre IA se comporte. Un reçu cryptographique est simplement la forme la plus solide de cette preuve pour la seule question que les registres gèrent le moins bien : ce qui s'est passé sur cette décision précise. Le système de gestion définit l'obligation. La preuve s'acquitte de sa partie la plus difficile.
Pourquoi c'est un partenariat, pas une concurrence
Je tiens à être précis sur cette relation, car elle est facile à mal interpréter. La vérification ne concurrence pas la gouvernance, et elle ne concurrence pas les entreprises qui la mettent en œuvre. Un système de gestion sans primitive probante est un ensemble de promesses bien géré. Une primitive probante sans système de gestion est un outil affûté sans programme autour. Aucun n'est suffisant à lui seul, et ils sont les plus forts lorsqu'ils sont superposés : la gouvernance définit ce qui devrait être vrai, et la preuve montre que ça l'était.
La version honnête de l'argumentaire ISO 42001, celle que les praticiens sérieux disent déjà à demi-mot à leurs clients, c'est qu'on peut bâtir un excellent système de gestion et rester incapable de prouver, à un lecteur hostile, ce que votre modèle a fait mardi dernier. Combler ce dernier écart n'est pas un échec de gouvernance. C'est la prochaine couche naturelle, et c'est un problème cryptographique plus qu'un problème de procédure.
Si vous passez vos journées à aider des entreprises à mettre en place des systèmes de gestion de l'IA, vous en avez senti la limite. La clause demande des preuves de performance. Votre client vous remet des journaux. Vous les acceptez, parce que c'est ce que la norme envisage et ce que les outils produisent. Mais quelque part dans un coin de votre tête se trouve la question de ce qui arrive quand un registre est contesté par quelqu'un qui ne fait pas confiance au système qui l'a écrit. Cette question a une réponse maintenant. Elle se trouve simplement une couche sous la norme, dans la partie pour laquelle personne n'a écrit de clause, parce qu'au moment de la rédaction de la norme, la preuve n'existait pas encore.