Le problème de l'heure d'or : les chaînes d'escalade ne peuvent pas vérifier ce qu'un agent d'IA a fait
Deux heures du matin. Un modèle de fraude d'une entreprise de paiements bloque une transaction. Le client est au téléphone en moins d'une heure, et l'horloge de l'ombudsman a déjà démarré.
L'ingénieur de garde ouvre les journaux du système. Les journaux indiquent que le modèle a signalé un score de risque au-dessus du seuil et que l'agent a refusé automatiquement. C'est ce que le système dit de lui-même. L'ingénieur escalade au responsable ML, qui lit les mêmes journaux et confirme qu'ils semblent normaux. Le responsable ML escalade au responsable de la conformité, qui n'a pas été alerté et doit maintenant faire confiance à deux personnes qui ont chacune fait confiance à un fichier journal. Si le calcul a tourné sur l'infrastructure d'un fournisseur, le prochain appel du responsable de la conformité est à ce fournisseur, pour lui demander de se porter garant de son propre dossier.
Quatre personnes, une heure, et personne à l'extérieur de la chaîne ne peut vérifier quoi que ce soit de façon indépendante. Chaque barreau de l'échelle ne fait que répéter la question vers le haut et ajouter un nom au fil.
Ce que l'exigence de paperasse néglige
C'est le coût opérationnel qu'une lecture de conformité de la tenue de registres et de la journalisation automatique tend à négliger. Ces obligations sont réputées satisfaites dès qu'un journal existe quelque part. La vraie question opérationnelle pendant un incident est plus étroite et plus difficile : quelqu'un qui n'était pas dans la pièce peut-il confirmer ce que l'agent a fait, sans demander à une personne de la chaîne de s'en porter garante une fois de plus.
Les chaînes d'escalade existent parce que personne, à aucun palier, ne peut vérifier de façon indépendante le palier inférieur. La solution n'est pas une chaîne plus longue ni une rotation de garde plus rapide. C'est supprimer le besoin de gravir tout court.
La séparation exécutant-prouveur
Les reçus cryptographiques y parviennent en gardant la partie qui exécute l'inférence distincte de la partie qui prouve ce qui a tourné. Celui qui exécute la tâche n'est jamais celui qui certifie qu'elle s'est déroulée correctement. Un reçu généré au moment de l'inférence est vérifiable de façon indépendante, reproductible et inviolable, de sorte que le responsable de la conformité, l'ombudsman ou un auditeur externe peut vérifier la même preuve directement, au lieu de demander au responsable ML de se porter garant une fois de plus de l'ingénieur de garde qui s'est déjà porté garant d'un fichier journal.
Pour les charges de travail de plongement (embedding), ce reçu est jumelé au rejeu probabiliste aujourd'hui, en service, pas une promesse de feuille de route. Pour les modèles exportables en ONNX, la même preuve est disponible au moyen d'un téléversement « apportez votre propre ONNX ». Ni l'un ni l'autre ne referme l'heure d'or en bâtissant un meilleur tableau de bord. Ils la referment en rendant la chaîne d'escalade inutile pour la seule question qui compte vraiment à deux heures du matin : qu'a fait l'agent, et puis-je le vérifier moi-même.
Avant que le téléavertisseur sonne
Les équipes d'ops d'IA vivent déjà cela. Toute entreprise de fintech, de santétech et d'assurance qui exécute de l'inférence sur une infrastructure qu'elle ne contrôle pas entièrement finit par recevoir l'appel où un journal ne suffit pas et où une chaîne de personnes qui se portent garantes n'est pas assez rapide. La question qui vaut la peine d'être posée à votre propre pile, avant que cet appel n'arrive, est simple : quand il sonne, qui doit réellement faire confiance à qui, et sur combien de barreaux.