4 min de lecture
Le “human-in-the-loop” traîne dans à peu près toutes les slides de gouvernance IA que je croise. Le raisonnement tient en une ligne : un humain valide, donc c’est sous contrôle. Eric Brandwine, VP sécurité d’Amazon, ne partage pas cet avis. Selon lui, l’humain dans la boucle ne contrôle pas grand-chose : il s’habitue, il se lasse, et il finit par cliquer sans lire.
Ce qu’il faut retenir de son argumentation
Attention, Brandwine ne dit pas que la supervision humaine ne sert à rien. Il dit qu’elle est mal placée quand elle se réduit à une validation répétée à chaque action d’un agent. Son argument repose sur un concept qu’il creuse depuis 2017 au moins, puisqu’il en parlait déjà sur scène à AWS re:Invent : la normalisation de la déviance. Le mécanisme est bien documenté en sûreté industrielle, longtemps avant qu’on parle d’IA. Des opérateurs prennent un raccourci, rien n’explose, le raccourci devient la procédure. Transposez ça à la gouvernance agentique : l’humain qui valide la centième action de la journée n’évalue plus rien, il clique.
Note du PandaRedacteur : Un garde-fou qu’on franchit les yeux fermés n’est plus un garde-fou, juste un check de compliance qui rassure au comité de sécurité.
J’ai du mal à contredire ce raisonnement, et je le dis en ayant moi-même recommandé du human-in-the-loop dans plusieurs articles de ce blog ces derniers mois. Le problème n’est pas la validation humaine en tant que telle : c’est qu’elle ne suit pas le volume d’actions qu’un agent produit. Mettez un humain fatigable face à un flux d’approbations à cadence machine, et il se comportera comme… un humain fatigable. Il n’y a pas de surprise là-dedans.
L’alternative : la responsabilité de bout en bout, pas la validation au coup par coup
Chez Amazon, le modèle retenu confie aux humains la responsabilité du résultat, pas celle de chaque étape intermédiaire. En pratique, ça donne trois couches de contrôle empilées à la place de la validation au coup par coup :
- Des garde-fous statiques, qui interdisent certaines actions destructrices, point final, quel que soit le contexte ou la confiance accordée à l’agent.
- Un ensemble de privilèges maximum défini agent par agent, qui plafonne ce qu’il peut faire même dans le scénario le plus favorable.
- Des politiques dynamiquement scopées, générées à l’exécution en fonction de la tâche précise et de l’intention de l’utilisateur. Le scoping se resserre tout seul au lieu de dépendre d’un humain censé y penser à chaque fois.
On retombe sur ce que je répète depuis des mois ici à propos du moindre privilège appliqué aux agents : une architecture qui rend la boulette structurellement improbable vaut mieux qu’un point de contrôle humain dont on espère qu’il sera encore vigilant à la centième répétition de la journée.
Note du PandaRedacteur : beaucoup de comités de gouvernance IA se rassurent en cochant la case “un humain valide chaque déploiement d’agent”. Personne ne demande jamais combien de temps cet humain passe vraiment à évaluer, ni depuis combien de validations d’affilée il n’a rien refusé. Ce sont pourtant les deux seuls chiffres qui disent si le garde-fou tient encore debout.
Ce que ça change concrètement
Personne ne demande de supprimer la supervision humaine. On demande de la déplacer là où elle produit un effet : en amont, sur la conception des politiques et des plafonds de privilège, au lieu de l’aval et de sa validation répétitive. Un humain sait concevoir un plafond de privilège correct une fois.
L’HIL ne sait pas évaluer correctement mille actions individuelles par jour, et il n’y a aucune formation qui corrigera ça.
Je retrouve exactement ce que je notais dans mon analyse sur AWS Kiro et sur la faille MCP Amazon Q. Dans les deux cas, la validation humaine existait sur le papier ; ce qui manquait, c’était une frontière structurelle empêchant l’agent de modifier lui-même les règles censées le gouverner.
Le scoping en couches de Brandwine tape pile sur ce point faible. Un plafond de privilège statique, défini hors de portée de l’agent, ne se contourne ni par une réécriture de configuration, ni par un message d’erreur habilement tourné.
Note du PandaRedacteur : on pourrait quand meme se poser la question pourquoi si c’est la doctrine Amazon….ces failles ont été la ? Amazon aurait-il succomber au principe de compliance trop poussé ? (l’équivalent du test d’intrusion qui instruse plus…. (c)Hervé Schauer…)
📚 Quelques références pour aller plus loin
- The Register : Why Amazon hates ‘human-in-the-loop’ AI governance
- AWS Kiro : quand une page web piégée réécrit la config de confiance de votre IDE agentique