La machine à états derrière l'IA responsable
Le formulaire qui n'a pas servi
Le premier atelier sur l'IA responsable se termine souvent par un formulaire. Ce formulaire est généralement soigné, de la manière dont les formulaires internes peuvent l'être lorsqu'un comité a découvert l'espacement. Il interroge sur la finalité, l'impact, les données, les risques, les biais, la supervision humaine, la dépendance aux fournisseurs, la conservation et la remontée des problèmes. Les personnes le remplissent avec soin. Une case est cochée. Un comité de revue approuve. Un projet avance. Quelque part, un dossier reçoit un document de plus et devient légèrement plus convaincu de lui-même.
Trois mois plus tard, le système est en production et le formulaire n'est plus là où se joue l'action. Une demande d'assistance arrive avec des champs manquants. Un modèle renvoie une réponse assurée avec des preuves faibles. Un appel d'outil mettrait à jour un dossier client. Une politique change entre le brouillon et l'action finale. Le relecteur humain est malade. L'index de récupération est obsolète. Une nouvelle source de données est proposée parce qu'elle serait pratique, et c'est ainsi que beaucoup de mauvaises idées se présentent poliment.
À ce moment-là, l'IA responsable n'est pas un principe. C'est une transition d'état. Le système est dans un état et veut passer à un autre. Du brouillon à la décision. De la suggestion à l'action. D'un impact faible à un impact élevé. De l'aide interne à la communication externe. De la revue à l'exécution. D'autorisé à bloqué. D'une exception temporaire à une voie permanente, si personne ne surveille. La question est de savoir si la transition dispose d'un garde-fou, d'une trace, d'un responsable et d'une voie de sortie.
C'est la machine à états qui se cache derrière l'IA responsable. Non pas parce que l'éthique peut se réduire à des cases et des flèches. Ce serait une chose étrange à croire et une chose encore plus étrange à se procurer. Le point est plus simple. Les systèmes sérieux passent déjà par des états. Si ces états ne sont pas nommés, le modèle se déplacera quand même, le flux de travail avancera quand même, et l'organisation découvrira sa gouvernance par accident. Nommer les états n'est pas du formalisme bureaucratique. C'est ainsi que la responsabilité prend une forme opérationnelle.
Pourquoi les principes ont besoin de limites
Les principes sont utiles au début parce qu'ils donnent une direction. Équité, transparence, responsabilité, confidentialité, sécurité, agentivité humaine, robustesse, contestabilité. Ces mots ne sont pas vides. Ils ne sont pas non plus exécutables par eux-mêmes. Un système ne peut pas appeler un principe à l'exécution et demander si l'action suivante est autorisée. Un développeur peut écrire une invite qui dit soyez équitable, mais le flux de travail doit toujours savoir quand s'arrêter, quand demander, quand enregistrer et quand refuser.
Les bords sont l'endroit où les principes deviennent utiles. Un principe d'équité devient une exigence selon laquelle une certaine catégorie de décisions doit passer une évaluation au niveau du groupe avant sa publication et doit produire des codes de motif au niveau du cas après la publication. Un principe de transparence devient un reçu qui nomme les sources, la version du modèle, la version de la politique et le rôle humain. Un principe de confidentialité devient une barrière qui refuse la récupération en dehors de la finalité, de la conservation, du consentement ou de la base légale. La responsabilité devient un état qui ne peut pas avancer sans un propriétaire. La contestabilité devient une voie de recours qui existe avant la première plainte, et non après le premier appel à un journal.
Sans bords, l'IA responsable devient un ensemble d'adjectifs autour d'un système qui se comporte toujours comme le flux de travail le permet. Une équipe peut honnêtement croire qu'elle dispose d'une supervision humaine parce qu'une personne peut examiner les résultats. Mais si le système peut agir avant que cette personne n'ait vu les preuves, la supervision est décorative. Une équipe peut croire qu'elle dispose de la transparence parce que le modèle s'explique lui-même. Mais si l'explication ne peut pas être liée aux sources et à l'état, la transparence a dérivé vers le théâtre. Une équipe peut croire qu'elle est en sécurité parce que le modèle refuse les invites dangereuses. Mais si la passerelle d'outils accorde une large autorité, le refus n'est qu'une porte dans une maison avec des fenêtres très enthousiastes.
La machine à états ne remplace pas le jugement. C'est une façon de faire atterrir le jugement quelque part. Elle oblige l'équipe à répondre à des questions pratiques. Dans quel état se trouve ce cas. Quelles transitions sont possibles à partir d'ici. Quelles preuves sont requises. Quel rôle peut approuver. Quelle transition est irréversible. Quelle transition crée un enregistrement. Quelle transition crée une obligation de notifier, conserver, supprimer ou escalader. Ces questions sont moins poétiques que les déclarations de valeurs. Elles sont aussi plus difficiles à éluder.
La machine cachée existe toujours
Chaque flux de travail d'IA a déjà une machine à états, même si personne ne l'a dessinée. La version cachée vit dans les statuts de tickets, les colonnes de feuilles de calcul, les files d'attente de nouvelles tentatives, les branches d'invites, les habitudes des réviseurs, les messages Slack, les indicateurs de base de données, les tables d'exceptions et la mémoire de la seule personne que tout le monde interroge parce qu'elle était là lorsque le pilote a eu lieu. Ce n'est pas une architecture distribuée charmante. C'est un folklore institutionnel avec de la latence.
La machine cachée est dangereuse parce qu'elle donne l'apparence du contrôle tout en déplaçant la responsabilité vers des endroits qui ne peuvent pas être examinés. L'invite peut dire que les cas sensibles doivent être escaladés, mais la file d'attente peut ne pas préserver le motif. Le système de cas peut afficher approuvé, mais pas si l'approbation s'appliquait à la réponse du modèle, à l'appel d'outil ou à la communication externe. Un réviseur peut rejeter une sortie, mais le rejet peut ne jamais entrer dans l'ensemble d'évaluation. Un cas peut être fermé, mais les données dérivées peuvent encore vivre dans un magasin de caractéristiques. Un modèle peut être remplacé, mais les cas en attente peuvent encore porter la sortie de l'ancienne version. Le système bouge; l'enregistrement boite derrière lui en portant une cravate.
Rendre la machine à états explicite ne nécessite pas de transformer l'organisation en laboratoire de méthodes formelles. Cela nécessite suffisamment de discipline pour séparer les états qui ont des devoirs différents. Brouillon n'est pas examiné. Examiné n'est pas exécuté. Exécuté n'est pas fermé. Fermé n'est pas effacé. Effacé n'est pas archivé. Bloqué par la politique n'est pas échoué par l'infrastructure. Nécessite un jugement humain n'est pas une faible confiance. Incident suspecté n'est pas incident confirmé. Ces distinctions semblent ordinaires jusqu'à ce qu'un audit demande lequel s'est produit, quand et pourquoi.
Les états nommés stoppent aussi une défaillance courante de l’automatisation : la glissade insensible de l’assistance vers la décision. Un système commence comme un outil de rédaction. Les gens lui font confiance. Le brouillon devient une valeur par défaut. La valeur par défaut devient une recommandation. La recommandation devient une action. Personne n’a voté pour une automatisation complète. Personne n’a conçu la nouvelle surface de responsabilité. La transition s’est faite par commodité, qui est le lobbyiste le plus efficace du logiciel. Une machine à états peut forcer ce passage à devenir visible.
Les garde-fous ne sont pas des impressions
Une transition a besoin d’un garde-fou. Un garde-fou est la condition qui doit être vraie avant que le système puisse se déplacer. Dans un logiciel ordinaire, il peut s’agir d’un contrôle booléen, d’une évaluation de politique, d’une frontière de permission, d’un résultat de validation ou d’une approbation humaine. Dans l’IA responsable, c’est aussi l’endroit où les promesses institutionnelles deviennent opérationnelles. Le garde-fou demande si la finalité est autorisée, si les données sont dans le périmètre, si la sortie a suffisamment de preuves, si le modèle est approuvé pour cet usage, si l’action est réversible, si la personne a l’autorité, si le coût est borné et si l’utilisateur concerné a un chemin de retour.
L’astuce pratique est de garder les garde-fous près de la transition qu’ils protègent. Si un garde-fou ne vit que dans un document de politique, l’exécution l’oubliera à une vitesse impressionnante. S’il ne vit que dans une invite, il sera difficile à tester et facile à contourner. S’il ne vit que dans une habitude humaine, il échouera les jours de maladie, les vacances, les réorganisations et la semaine où tout le monde essaie de livrer. Un bon garde-fou est assez explicite pour être testé et assez local pour compter.
Cela ne signifie pas que chaque garde-fou doit être automatisé. Certains garde-fous sont humains parce que la question est réellement contextuelle. Mais même les garde-fous humains ont besoin d’un état. Le réviseur doit voir les preuves, la politique applicable, la classification des risques, l’action proposée et les conséquences de l’approbation. Le système doit enregistrer la décision comme une transition, pas comme un commentaire que la future archéologie découvrira peut-être ou non. La supervision humaine sans changement d’état n’est souvent qu’une réunion avec une interface utilisateur.
Il y a aussi un point ennuyeux mais important sur les garde-fous négatifs. L’IA responsable ne consiste pas seulement à dire oui de manière responsable. Elle consiste à dire non clairement. Non parce que la finalité manque. Non parce que la source est périmée. Non parce que le modèle est hors de son domaine approuvé. Non parce que l’utilisateur manque d’autorité. Non parce qu’une revue humaine est requise. Non parce que l’action est trop conséquente pour les preuves disponibles. Un refus avec une raison est un meilleur état système qu’un échec vague qui invite à réessayer jusqu’à ce que quelque chose bouge.
Les états rendent la responsabilité assignable
Une des raisons pour lesquelles la responsabilité en matière d'IA devient floue est que la responsabilité est discutée au niveau du système entier. L'organisation est responsable. Le fournisseur est responsable. Le propriétaire du produit est responsable. Le délégué à la protection des données est responsable. Le modèle est responsable, une phrase qui devrait faire fixer le plafond à un avocat pour trouver la force. Au moment de l'exécution, la responsabilité a besoin d'une prise plus petite.
Les états créent cette prise. Lors de l'admission, le propriétaire du service peut être responsable de la finalité et de la portée. Lors de la récupération, le propriétaire des données peut être responsable de la qualité et de l'autorisation des sources. Lors de la génération du modèle, le propriétaire technique peut être responsable des versions et des paramètres approuvés. Lors de la révision, un rôle humain peut être responsable du jugement. Lors de l'action, le propriétaire du flux de travail peut être responsable des effets externes. Lors de la clôture, la gestion des dossiers peut être responsable de la conservation et de la suppression. La carte exacte différera, mais le principe demeure : la responsabilité s'attache mieux aux transitions qu'au brouillard.
Cela importe quand quelque chose tourne mal. Si une sortie était mauvaise parce que la source était obsolète, la machine à états devrait montrer où la fraîcheur a été vérifiée ou manquée. Si un humain a approuvé une action risquée, le dossier devrait montrer quelles preuves il a vues. Si une politique a changé, les cas en attente devraient révéler quelle version les régissait. Si un modèle a été mis à niveau, les transitions à travers la frontière de version devraient être inspectables. Le but n'est pas de trouver quelqu'un à blâmer plus vite. Le but est de rendre la réparation possible sans prétendre que le système entier a échoué dans un haussement d'épaules indifférencié.
La responsabilité assignable améliore aussi le travail quotidien. Les équipes savent quel état elles possèdent. Les métriques deviennent moins théâtrales. Au lieu d'annoncer que le programme d'IA responsable est mature, l'organisation peut mesurer les blocages de sources obsolètes, les refus de finalité manquante, les dérogations de révision, les résultats d'appel, les transitions d'incident et les retards de clôture. Cela convient moins à une diapositive brillante. C'est bien plus adapté pour faire fonctionner un système.
Les mauvais états méritent des noms propres
La plupart des échecs de l'IA responsable ne sont pas malveillants. Ce sont des états ordinaires avec de mauvais noms ou pas de noms. Une réponse provisoire est traitée comme une réponse finale. Une exception temporaire devient une voie. Une sortie à faible confiance devient une action à fort impact parce que le flux de travail n'avait pas d'état intermédiaire. Un modèle voit des données qu'il n'aurait pas dû voir parce que l'état de récupération ne portait pas la finalité. Un réviseur humain devient un tampon en caoutchouc parce que l'état appelé révision n'exigeait pas de preuve ou de capture de désaccord.
Donner aux mauvais états des noms propres est inconfortable et utile. Brouillon silencieux. Dérapage de portée. Source obsolète. Propriétaire manquant. Acte non révisé. Pas de sortie. Ce ne sont pas des causes racines en soi, mais ce sont des endroits où placer des contrôles. Un système peut détecter un brouillon silencieux lorsque du texte généré est copié dans une communication externe sans approbation. Il peut détecter un dérapage de portée lorsqu'un flux de travail demande une source en dehors de la finalité déclarée. Il peut détecter une source obsolète lorsqu'une citation est plus ancienne que la politique ne le permet. Il peut détecter une absence de sortie lorsque des cas bloqués restent indéfiniment parce que personne n'a conçu le refus humain.
Cette habitude prévient aussi la surréaction morale. Tous les échecs ne sont pas une crise éthique. Parfois, c'est un état de file d'attente sans propriétaire. Parfois, c'est un état de conservation que personne n'a relié à la suppression. Parfois, c'est un seuil de confiance qui se fait passer pour un jugement. Nommer l'état permet à l'équipe de réparer le mécanisme. Sans noms, chaque incident devient un débat sur la culture. La culture compte, mais elle remplace mal la connaissance de quelle transition a fui.
Il y a une comédie sèche à regarder des organisations craindre le mot machine à états parce qu'il semble trop technique, tout en exploitant joyeusement un labyrinthe d'e-mails d'approbation, de statuts de feuilles de calcul et d'exceptions connues seulement de trois personnes et d'une invitation de calendrier. La version formelle est souvent plus simple. Elle a juste l'impolitesse d'être visible.
La preuve doit se trouver sur la transition
Si la machine à états doit avoir de l'importance, elle a besoin de preuves. L'enregistrement ne doit pas simplement indiquer qu'un cas est approuvé. Il doit indiquer ce qui a déclenché la transition, quelle garde a été évaluée, quelles données ont été utilisées, quelles versions du modèle et de la politique ont été appliquées, qui ou quoi a approuvé, quel effet a suivi, et comment le cas peut être rejoué ou contesté. La preuve n'est pas une décoration après l'action. Elle fait partie de l'action qui devient responsable.
C'est particulièrement important pour l'IA, car les sorties peuvent être plausibles alors que leur chemin est fragile. Un résumé peut être correct mais fondé sur une source à laquelle l'utilisateur n'avait pas le droit d'accéder. Une recommandation peut être raisonnable mais en dehors de l'usage approuvé du modèle. Une classification peut être exacte mais produite après une échéance de politique. Un refus peut être sûr mais juridiquement inutile s'il n'offre aucune voie de réparation. La réponse seule ne peut pas vous apprendre ces choses. L'enregistrement de la transition le peut.
De bonnes preuves donnent aussi aux équipes le courage d'automatiser là où l'automatisation est appropriée. L'IA responsable n'est pas une excuse permanente pour utiliser des machines. Si une tâche a un faible impact, est bien délimitée, réversible, correctement testée et correctement enregistrée, l'automatisation peut être la voie responsable. Si une tâche a un impact élevé, est contestée, nouvelle ou irréversible, la machine à états doit la ralentir. Le but n'est pas de vénérer la revue humaine. Le but est d'acheminer le travail selon le risque, la preuve et le remède.
La preuve rend cet acheminement moins politique. Une équipe peut montrer qu'un état est sûr pour l'automatisation parce que les transitions précédentes étaient exactes, les appels étaient rares, les corrections étaient intégrées et les contrôles attrapaient les bons cas. Ou elle peut montrer qu'un état a besoin de plus de jugement humain parce que les schémas d'erreur restent difficiles, que les personnes concernées contestent les résultats ou que la qualité des données est faible. C'est un meilleur argument que le théâtre habituel où un camp dit innovation et l'autre dit risque jusqu'à ce que tout le monde ait besoin de café.
La revue humaine est un état, pas un geste
La revue humaine est souvent invoquée comme si sa seule existence réglait la question de la responsabilité. Un humain est dans la boucle. Très bien. Quelle boucle. À quel état. Avec quelles preuves. Avec quelle autorité. L'humain peut-il être en désaccord. Le désaccord modifie-t-il le système. La revue est-elle par échantillonnage, obligatoire, déclenchée par le risque, ou cosmétique. Le relecteur voit-il la source ou seulement la prose soignée du modèle. A-t-il le temps de réfléchir. Est-il formé. Y a-t-il une trace. L'expression humain dans la boucle doit être traitée comme une question d'ouverture, pas comme un argument de clôture.
Une machine à états rend la revue humaine concrète. Elle peut distinguer revue requise de revue facultative, revue en attente de revue terminée, sortie modifiée par l'humain de sortie confirmée par l'humain, escalade nécessaire d'escalade effectuée. Elle peut aussi distinguer le type de jugement en jeu. Certaines revues vérifient l'usage factuel des sources. Certaines vérifient la conformité aux politiques. Certaines vérifient l'empathie et le ton. Certaines vérifient l'autorité légale. Certaines vérifient si une exception est justifiée. Une simple case approuvé est rarement assez riche pour un travail sérieux.
Concevoir la revue comme un état protège aussi les humains d'être utilisés comme rembourrage moral. Si le système envoie chaque cas délicat à une personne sans preuves, sans priorisation, ni retour d'information, la personne devient une décharge pour l'incertitude. Ce n'est pas de la supervision. C'est un modèle de dotation avec de la culpabilité attachée. Un état de revue responsable conditionne le dossier, nomme la décision requise, préserve la dissidence, et réinjecte les résultats dans l'évaluation. Il donne à l'humain un travail digne d'un humain.
L'inverse est aussi vrai. Certains systèmes utilisent la revue humaine là où une meilleure garde serait plus humaine. Si un dossier manque de base légale, ne l'envoyez pas à un relecteur pour qu'il le découvre manuellement. Bloquez-le. Si la source est périmée, actualisez ou refusez. Si l'utilisateur n'a pas l'autorité, dites-le. Les humains devraient gérer le jugement, pas compenser une tuyauterie manquante. Nous avons passé des décennies à inventer des machines. Ce serait mal élevé de faire se comporter les gens comme des scripts de validation.
L'irréversibilité change la machine
Toutes les transitions ne se valent pas. Certaines sont réversibles. Un brouillon peut être modifié. Un itinéraire peut être changé. Une recommandation peut être retirée. D'autres transitions sont plus difficiles à défaire : un message est envoyé, une prestation est refusée, un drapeau de risque change une file d'attente, un enregistrement est mis à jour, une personne est signalée, un paiement est effectué, un client est verrouillé dehors. Une IA responsable doit savoir quelles transitions franchissent le seuil vers le monde réel.
L'irréversibilité devrait changer de garde. Le système devrait exiger davantage de preuves, une autorité plus solide, un jugement humain plus clair, un meilleur préavis et une voie de recours plus visible avant les effets irréversibles. Il devrait également privilégier les transitions par étapes lorsque c'est possible. Rédiger avant d'envoyer. Recommander avant de décider. Suspendre avant de rejeter. Notifier avant d'exécuter. Examiner avant de signaler. Ce n'est pas de la lenteur pour elle-même. C'est la différence entre un système qui peut se corriger et un système qui crée du travail de nettoyage avec un air assuré.
La machine à états aide aussi à gérer la réversibilité partielle. Certains préjudices peuvent être réparés techniquement, mais pas socialement. Un résumé interne erroné peut être corrigé. Une accusation externe injuste peut persister même après correction. Un bénéfice différé peut être versé plus tard, mais le loyer était dû plus tôt. Un enregistrement supprimé peut parfois être restauré, mais la confiance, elle, ne l'est pas toujours. La machine devrait traiter ces transitions avec le sérieux de leur effet humain, et non pas seulement de leur restauration en base de données.
C'est là que l'IA responsable échappe au fantasme selon lequel l'éthique serait séparée des opérations. Le détail opérationnel est la surface éthique. La conception de la file d'attente affecte l'équité. La politique de relance affecte la duplication. Le comportement en cas de délai d'attente affecte l'accès. La conservation des données affecte la vie privée. La charge de travail d'examen affecte la dignité. Les transitions d'états ne sont pas de la plomberie neutre. C'est ainsi que le système rencontre les personnes.
L'évaluation comme preuve de transition
L'évaluation se situe souvent en dehors du flux de travail, comme s'il s'agissait d'un examen scolaire passé avant que le système n'obtienne son diplôme. Dans une machine à états responsable, l'évaluation devient une preuve continue de transition. Chaque transition peut produire des signaux : la fréquence à laquelle la garde a bloqué, la fréquence à laquelle les humains ont outrepassé, la fréquence à laquelle les recours ont abouti, la fréquence à laquelle les sources étaient obsolètes, la fréquence à laquelle le jugement du modèle était en désaccord avec le jugement humain, la fréquence à laquelle une voie supposée à faible impact a généré des plaintes.
Ces signaux devraient alimenter la machine. Une transition qui produit des recours répétés peut nécessiter une garde plus solide ou un préavis plus clair. Un état d'examen humain avec un taux d'accord élevé et un faible impact peut être éligible à davantage d'automatisation, à condition que le recours reste réel. Un état de refus qui piège les utilisateurs peut nécessiter une voie de réparation. Une garde politique qui bloque trop de cas légitimes peut révéler une mauvaise politique, et non un mauvais modèle. La machine n'est pas responsable parce qu'elle est statique. Elle est responsable parce qu'elle peut apprendre sans cacher le passé.
Cet apprentissage exige un versionnage. Les états, les gardes, les seuils, les invites, les modèles, les politiques, les sources de données et les instructions d'examen changent. L'enregistrement doit indiquer quelle version s'appliquait à quelle transition. Sinon, l'organisation ne peut évaluer qu'une soupe de choix passés. La soupe a des usages culinaires. Ce n'est pas une méthode de gouvernance, quel que soit le nombre de tableaux de bord qui flottent à sa surface.
La preuve de transition versionnée maintient aussi l'amélioration honnête. Une équipe peut dire qu'une nouvelle garde a réduit les actions non examinées mais augmenté les délais. Elle peut dire qu'une nouvelle source a amélioré la précision mais accru les frictions en matière de vie privée. Elle peut dire qu'une mise à niveau du modèle a amélioré les résumés mais affaibli la discipline de refus. Les compromis ne sont pas des échecs. Les compromis cachés sont des échecs qui attendent une invitation à une réunion de calendrier.
La leçon
La machine à états derrière l'IA responsable n'est pas un appel à des systèmes plus froids. C'est un appel à des systèmes qui savent ce qu'ils font pendant qu'ils le font. Un état nommé n'est pas une réussite morale. Une garde n'est pas la justice. Un reçu n'est pas la confiance. Mais sans ces choses, l'IA responsable reste au niveau de l'intention, et l'intention a un mauvais bilan de disponibilité.
Une IA responsable exige un but, une autorité, des preuves, des limites, un jugement humain, un recours, une réparation, une conservation et un apprentissage. Ces mots deviennent opérationnels par le biais d'états et de transitions. Ils déterminent quand un dossier avance, quand il s'arrête, qui le possède, quel enregistrement est créé, quel recours existe et ce que le système doit retenir pour la prochaine fois. Ce n'est pas là toute l'éthique. C'est la partie qui peut empêcher une mauvaise action de devenir un regret très bien documenté.
Le formulaire au début a toujours de la valeur. Il pose les bonnes questions d'ouverture. Mais le formulaire doit mener à une machine qui fonctionne : des états nommés, des garde-fous explicites, des preuves durables, un examen réel et des sorties pour les personnes concernées par le système. Une IA responsable ne se prouve pas par l'existence d'une politique. Elle se prouve, ou se réfute, à la transition où le système décide de la suite.