Deux preuves, une décision
Quand un système d'IA prend une décision que quelqu'un remet plus tard en question, trois questions distinctes sont posées. Elles se ressemblent dans une réunion et on les confond sans cesse, mais elles ont des réponses différentes, des preuves différentes et des personnes responsables différentes.
L'organisation avait-elle un programme ? Politiques, évaluation des risques, rôles définis, supervision humaine. C'est la gouvernance.
Cette action précise était-elle permise sous la politique en vigueur à ce moment-là ? C'est l'autorisation.
Le calcul derrière la décision s'est-il réellement déroulé de la façon dont vous le dites ? C'est l'exécution.
La plupart des organisations peuvent répondre à la première par de la documentation. Presque aucune ne peut répondre à la deuxième ou à la troisième autrement que par ses propres journaux, rédigés par la partie sous examen.
Les cadres décrivent l'intention. La preuve décrit ce qui est arrivé.
Un système de management ISO 42001, un alignement sur le NIST AI RMF, un rapport SOC 2 et une fiche de modèle font tous quelque chose de réel : ils établissent qu'un programme existe, que des contrôles ont été conçus et que quelqu'un est responsable. Ce n'est pas de la paperasse pour elle-même. C'est le socle sur lequel tout le reste repose.
Mais aucun d'eux ne peut répondre à la question qu'un examinateur pose réellement après qu'un problème survient, et qui porte toujours sur un cas précis. Reproduisez ce que votre IA a fait pour cette décision, et prouvez-le. La documentation établit le programme. Elle ne peut pas prouver l'acte individuel.
Deux preuves différentes, et elles ne sont pas interchangeables
Nous échangeons depuis quelque temps avec IronProof, une entreprise montréalaise fondée par Dominik Blain qui travaille sur la deuxième question. Leur approche est la vérification formelle : avant le déploiement, ils prouvent mathématiquement que les règles implémentées dans un système correspondent au modèle de politique qu'elles sont censées représenter, sur l'ensemble de l'espace d'états modélisé. Puis, au moment de la décision, une action est évaluée par rapport à la politique, à l'autorité et à l'état de la transaction en vigueur, et chaque approbation ou refus laisse un artefact scellé qu'un auditeur peut revérifier des mois plus tard.
Cyberian travaille sur la troisième question. Chaque inférence d'IA produit un reçu cryptographique liant le modèle exact, l'entrée exacte et la sortie exacte. Le reçu est émis par un vérificateur qui n'a pas exécuté la tâche, et n'importe qui peut le vérifier ensuite, hors ligne, sans refaire le travail et sans faire confiance à l'exploitant. Notre règle architecturale est absolue : la partie qui exécute n'est jamais la partie qui atteste.
Les modes de défaillance qu'ils traitent sont réellement différents. Une preuve de politique ne détecte pas un modèle discrètement remplacé, un changement de version silencieux, ou une sortie qui n'a jamais été produite par le modèle auquel on l'attribue. Un reçu d'exécution ne vous dit pas si l'action était permise au départ. Un système d'IA qui prend des décisions conséquentes dans un environnement réglementé a besoin des deux, et il a besoin d'un programme de gouvernance au-dessus d'eux pour dire pourquoi l'un ou l'autre importe.
Pourquoi cela relève des praticiens de la GRC
Presque toutes les conversations que nous avons à ce sujet commencent avec un professionnel de la gouvernance, du risque et de la conformité (GRC), pas avec un ingénieur. Ce n'est pas un hasard.
Les praticiens de la GRC sont les personnes à qui on demande de produire des preuves, et ce sont eux qui découvrent, généralement au pire moment, que ce qu'ils ont est une description d'un contrôle plutôt que la preuve que le contrôle a fonctionné. Ce sont aussi les personnes qui traduisent une réglementation en quelque chose qu'une organisation peut réellement faire. Quand une nouvelle forme de preuve devient disponible, ce sont eux qui savent quelle obligation elle satisfait et quel client en a besoin en premier.
La relation de travail que nous recherchons avec les cabinets-conseils est donc simple. Vous détenez la couche de gouvernance, le système de management, l'évaluation des risques, la relation client. Nous nous plaçons en dessous et fournissons la preuve. La gestion des risques liés aux tiers, en particulier, gagne quelque chose qu'elle n'a jamais eu : au lieu de demander à un fournisseur d'IA de décrire ses contrôles, un évaluateur peut demander une preuve que le fournisseur n'aurait pas pu fabriquer.
Ce que la preuve ne fait pas
Être précis sur la limite fait partie de l'enjeu.
Un reçu ne vous dit pas que le modèle était le bon modèle pour la tâche. Il ne vous dit pas que la sortie était sage, équitable ou commercialement correcte. Il ne dit rien sur des données que personne n'a divulguées. Une vérification formelle d'une logique de politique ne vous dit pas que la politique elle-même était une bonne politique. Ni l'un ni l'autre ne remplace le jugement professionnel, et tout fournisseur qui prétend le contraire vend quelque chose qui n'existe pas.
Ce que les deux font, c'est éliminer un type de doute précis et de plus en plus coûteux : celui de savoir si l'histoire qu'une organisation raconte sur sa propre IA peut être vérifiée par quelqu'un qui n'a aucune raison de la croire sur parole.
Les tribunaux ont commencé à ordonner la production de dossiers de décisions d'IA en communication de la preuve. Les examinateurs en assurance pilotent des outils d'évaluation de l'IA. Le règlement européen sur l'IA s'applique désormais. La question n'est plus de savoir si les organisations seront invitées à prouver ce que leur IA a fait. C'est ce qu'elles remettront quand on le leur demandera.
Cyberian et IronProof sont des entreprises indépendantes qui explorent le point de rencontre de leurs couches de preuve respectives. Si vous conseillez des clients réglementés en matière de gouvernance de l'IA et souhaitez voir à quoi ressemble un reçu en pratique, écrivez à philippe@cyberiansystems.ai.