Qui détient la décision quand un agent délègue ?

La délégation peut rendre un flux de travail IA plus performant sans le rendre plus responsable. La différence tient à ce que l'autorité, les preuves et le...

Qui détient la décision quand un agent délègue ?

Une passation ne vide pas le siège

Un agent délègue une tâche. Un autre agent rassemble des documents, compare des enregistrements, appelle un outil ou prépare une recommandation. Un troisième agent vérifie le résultat. Le travail se déplace, et ce déplacement peut être utile. Il peut aussi créer un très vieux problème de gestion sous une nouvelle forme : tout le monde a fait quelque chose, mais personne ne peut dire qui était habilité à prendre la décision.

La réponse tentante est l'agent qui a effectué le dernier appel. C'est aussi généralement la réponse la moins utile. Un composant logiciel peut sélectionner un itinéraire, demander plus de travail et soumettre une instruction à un système connecté. Aucune de ces actions n'établit qui a accepté l'objectif, qui a fixé les limites, qui aurait pu refuser l'action, ou qui devait être informé lorsque les conditions changeaient. Cela établit seulement qu'un programme faisait partie de la chaîne.

Cette distinction devient nette lorsqu'un flux de travail a des conséquences. Une réponse suggérée peut devenir une communication client. Une classification peut devenir la raison pour laquelle un dossier est placé dans une file d'attente particulière. Une comparaison peut devenir une recommandation d'achat. Une instruction de paiement rédigée peut devenir un paiement. Chaque étape peut être techniquement compétente et rester organisationnellement incomplète. Le système a fait le travail de délégation sans faire le travail d'autorité.

Il n'est pas nécessaire d'inventer une défaillance spectaculaire pour voir le problème. Prenons un flux de travail délibérément hypothétique. Un agent de tri reçoit une question, demande à un agent de recherche d'examiner les documents pertinents, envoie le résultat à un réviseur, puis prépare une action pour un système de gestion de dossiers. L'agent de recherche n'est pas autorisé à agir. Le réviseur n'est pas autorisé à rendre effective l'issue du dossier. L'agent de tri possède un identifiant d'outil. L'organisation n'a pas précisé si cet identifiant lui permet d'engager le résultat. Le flux de travail peut sembler ordonné sur un tableau de bord. Il a néanmoins atteint la question la plus importante sans réponse.

La délégation n'est pas la disparition de la responsabilité. C'est une responsabilité rendue plus difficile à voir. Une bonne conception opérationnelle la rend plus facile à voir à nouveau. Elle précise quelle est la décision initiale, ce qui peut être délégué, quelles conditions accompagnent la tâche, qui peut approuver une action irréversible ou lourde de conséquences, quelle trace subsiste après la passation, et comment une personne ou un système peut intervenir lorsque la voie n'est plus sûre. On ne demande pas à la technologie de posséder une agence morale. On lui demande de préserver l'agence de l'organisation.

C'est le sens pratique de la responsabilité dans un flux de travail multi-agents. Ce n'est pas une ligne décorative dans une politique, et ce n'est pas une chasse rétrospective au salarié le plus proche quand quelque chose tourne mal. C'est une propriété de la voie avant que le travail ne commence. La bonne personne peut examiner ce qui a été proposé, comprendre pourquoi cela a été proposé, exercer l'autorité qui lui a été assignée, et laisser une trace qui pourra être contestée par la suite.

Les règles européennes émergentes sur l'IA sont utiles ici car elles s'intéressent moins à un humain théâtral à la fin d'un flux qu'aux conditions dans lesquelles la supervision peut réellement fonctionner. Les dispositions de surveillance humaine de l'AI Act s'appliquent aux systèmes à haut risque, et non à chaque utilisation d'un agent. Cette limite est importante. Mais les questions opérationnelles de la loi se transposent bien : une personne physique désignée peut-elle comprendre les capacités et limites pertinentes, surveiller les anomalies et les performances inattendues, éviter la confiance excessive, interpréter les résultats, les ignorer ou les inverser, et interrompre le système dans un état sûr ? Un flux de travail avec de nombreux agents ne réduit pas ces questions. Il multiplie les endroits où la réponse peut se perdre.

La délégation peut transmettre le travail vers l’avant. Elle ne peut pas effacer le chemin par lequel l’autorité et la contestation reviennent vers l’arrière.

La délégation est une chaîne, pas un brouillard

Les gens délèguent constamment. Un gestionnaire demande à un collègue de préparer une note. Une équipe des achats demande à un expert d’examiner une clause contractuelle. Un clinicien demande un résultat à un laboratoire. La personne qui reçoit la tâche gagne un rôle défini dans le travail ; elle n’hérite pas automatiquement de chaque autorité détenue par la personne qui a demandé. Les bonnes organisations rendent cette distinction banale explicite grâce aux descriptions de poste, aux limites d’approbation, aux procédures, à la séparation des tâches et aux registres. Elles le font parce que la capacité et la permission sont deux choses différentes.

Les systèmes d’agents tendent à brouiller cette distinction parce qu’un agent peut décrire, planifier et exécuter dans une seule surface conversationnelle. Un modèle peut être capable de générer un plan convaincant pour contacter un fournisseur. Un habillage d’outil peut être techniquement capable d’envoyer le message. Une couche d’orchestration peut être capable d’appeler cet habillage sans pause. Ces faits décrivent la capacité. Ils ne décident pas si le message doit être envoyé, si le destinataire proposé est dans le périmètre, si l’information est appropriée à divulguer, ou qui doit accepter la conséquence si l’action proposée est erronée.

Il est utile de séparer cinq questions souvent regroupées. Qui a donné son objectif à la tâche ? Qui peut effectuer le travail préparatoire ? Qui peut déléguer une sous-tâche ? Qui peut décider qu’une action proposée est acceptable ? Qui peut rendre cette action effective dans le monde extérieur ? Parfois, un seul rôle humain détient légitimement plusieurs de ces réponses. Parfois, elles doivent être séparées. Le but n’est pas de créer une cérémonie élaborée pour une note à faible risque. Le but est d’éviter de traiter silencieusement une capacité technique comme un transfert d’autorité institutionnelle.

Une délégation doit donc porter plus qu’une instruction. Elle doit porter un mandat. Le mandat identifie l’objectif, le contexte délimité, les intrants autorisés, le résultat attendu, les actions qui restent interdites, le budget ou la limite de temps le cas échéant, les conditions qui exigent une escalade, et la personne ou le rôle redevable du résultat. L’agent récepteur peut alors faire un travail utile dans une enveloppe visible. Il peut demander une analyse à un autre agent. Il ne peut pas élargir l’enveloppe simplement parce qu’une prochaine étape plausible lui vient à l’esprit.

Ce n’est pas un argument pour transformer chaque interaction en réunion d’approbation. C’est un argument pour choisir le point auquel l’organisation souhaite qu’une décision se produise. Un système peut rédiger une explication sans qu’un humain examine chaque phrase lorsque l’objectif, le public, la limite des sources et les règles de publication sont déjà fixés. Un système ne devrait pas acquérir le pouvoir de modifier le droit d’un client simplement parce que le même composant a accès à la base de données pertinente. La différence réside dans la conséquence, pas dans l’intelligence du modèle.

Cette conséquence est souvent répartie. Une tâche peut être sans danger à un stade et lourde de conséquences au suivant. Lire un fichier peut être une opération courante. La combiner avec une autre source peut modifier la sensibilité des données. Préparer une recommandation peut être une opération courante. Appuyer sur un bouton qui crée un résultat juridique, financier ou de service peut ne pas l'être. Une conception de gouvernance qui se demande seulement si un agent est autonome passe à côté de ce changement d'état. La question utile est plus étroite : autonome pour faire quoi, pour qui, sous quelles conditions, et avec quelle autorité ?

Il y a ici un instinct néerlandais modeste qui mérite d'être conservé. Si un processus exige une douzaine de signatures, de tampons et un organigramme plastifié pour établir qui peut appuyer sur un bouton, ce n'est peut-être pas un triomphe de la gouvernance. Mais la disposition inverse, où un identifiant d'outil est traité comme un règlement constitutionnel, n'est pas un triomphe non plus. L'objectif est une voie proportionnée qui rend claire l'autorité liée aux conséquences sans monter un petit opéra autour de chaque action de routine.

La supervision européenne est une exigence opérationnelle

L'AI Act donne l'expression juridique la plus claire de cette idée pour les systèmes d'IA à haut risque. L'article 14 exige qu'ils soient conçus et développés de manière à ce que des personnes physiques puissent les superviser efficacement pendant leur utilisation. L'objectif déclaré est de prévenir ou de minimiser les risques pour la santé, la sécurité et les droits fondamentaux lorsque ces risques peuvent subsister malgré d'autres exigences. Les mesures doivent être proportionnées au risque, à l'autonomie et au contexte d'utilisation. C'est une norme délibérément opérationnelle. Elle ne dit pas qu'une personne quelque part dans l'organisation s'intéresse généralement à l'IA.

La disposition va plus loin qu'une instruction générique visant à garder un humain dans la boucle. Selon ce qui est approprié et proportionné, la personne chargée de la supervision doit être en mesure de comprendre les capacités et les limites pertinentes, de surveiller le fonctionnement et de détecter les anomalies, les dysfonctionnements ou les performances inattendues, de rester consciente du biais d'automatisation, d'interpréter les résultats, de décider de ne pas utiliser un résultat ou de l'ignorer, de le remplacer ou de l'inverser, et d'intervenir ou d'interrompre le système pour le mettre dans un état sûr. La loi ne transforme pas ces éléments en une liste de contrôle universelle pour chaque système d'agents. Elle montre pourquoi un tampon de validation en fin de processus est un mauvais modèle de supervision.

Ajoutons maintenant la délégation. Si un agent confie une tâche à un autre agent, le rôle de supervision doit pouvoir voir plus que la phrase finale produite par le dernier modèle. Il faut suffisamment de contexte pour comprendre quel agent a proposé la sous-tâche, quelles sources ou quels outils ont été utilisés, si une limite de politique a été rencontrée, si un résultat a été modifié par un réviseur et si un agent ultérieur a élargi le périmètre. Sinon, l'humain peut voir un résultat, mais pas le chemin qui l'a produit. Cela peut suffire pour un brouillon à faible enjeu. Ce n'est pas une base convaincante pour accepter une décision lourde de conséquences.

L'article 26 rend le point organisationnel encore plus clair pour les déployeurs de systèmes à haut risque. Il stipule que les déployeurs doivent confier la supervision humaine à des personnes physiques possédant les compétences, la formation, l'autorité et le soutien nécessaires. Ces termes vont ensemble. La compétence sans autorité crée un spectateur bien informé. L'autorité sans compétence crée un propriétaire formel qui ne peut pas contester le système. Les deux sans soutien créent une personne censée intervenir dans un processus qu'elle ne peut pas voir, à un rythme qu'elle ne peut pas suivre, en utilisant des informations qu'elle ne peut pas interpréter.

Pour un travail multi-agents, le support comprend la forme de l'interface et de l'enregistrement. Un opérateur n'a pas besoin de chaque jeton généré par un modèle ni de chaque nouvelle tentative interne. Il a besoin de l'action proposée, de l'objectif nommé, des preuves matérielles, de la politique et de la limite applicables, des modifications apportées depuis le dernier point de contrôle, de l'effet attendu, de la voie de retour possible et de la raison pour laquelle le cas a été escaladé. Il s'agit moins de rendre un tableau de bord rassurant que de réduire le risque qu'une personne approuve une réponse parce que le système a rendu l'alternative épuisante à trouver.

La Convention-cadre du Conseil de l'Europe sur l'intelligence artificielle et les droits de l'homme, la démocratie et l'État de droit établit le lien institutionnel plus large. Son objectif est de garantir que les activités du cycle de vie des systèmes d'IA sont conformes aux droits de l'homme, à la démocratie et à l'État de droit. Les articles 8 et 9 appellent à une transparence et à une supervision adaptées aux contextes et aux risques spécifiques, ainsi qu'à la responsabilité pour les effets négatifs. La Convention ne prescrit pas un modèle d'orchestration d'agents. Elle constitue toutefois un correctif utile à l'idée qu'une chaîne de composants logiciels peut dissoudre les responsabilités de l'autorité publique ou de l'acteur privé qui l'utilise.

Cette vision plus large importe parce qu'une décision déléguée peut affecter plus que la performance technique. Elle peut affecter la capacité d'une personne à comprendre une décision, à la contester, à obtenir réparation ou simplement à savoir quelle organisation est responsable. Un flux de travail peut être composé de composants provenant de plusieurs fournisseurs, de modèles provenant de plusieurs prestataires, d'outils exploités par une autre équipe et d'un service fourni dans le cadre d'un marché public. Le fait que la chaîne soit techniquement distribuée ne rend pas l'impact sur l'individu moins réel. En pratique, cela rend une répartition claire des rôles plus importante.

La protection des données adresse le même avertissement sous un angle différent. Les travaux du Comité européen de la protection des données sur les modèles d'IA soulignent que l'analyse de la protection des données reste contextuelle : les organisations doivent déterminer leur rôle, identifier le traitement concerné et appliquer les obligations pertinentes, plutôt que de considérer l'étiquette « modèle d'IA » comme une exemption de la responsabilité ordinaire. Lorsqu'un flux de travail multi-agents touche à des données personnelles, la délégation ne doit pas obscurcir qui détermine les finalités et les moyens du traitement, quel agent ou outil reçoit quelles données, et si la prochaine transmission est nécessaire à la tâche. Une sous-tâche reste une étape de traitement. L'appeler délégation ne la fait pas disparaître.

Aucun de ces éléments ne fournit une réponse magique à chaque cas difficile. Les obligations légales dépendent de l'utilisation, des acteurs, des données et du secteur. Un article ne peut pas classer un système particulier. Mais il peut énoncer un principe discipliné : si un flux de travail répartit le travail, il doit le répartir d'une manière qui préserve la capacité d'identifier l'autorité, d'intervenir à temps, de rendre compte du parcours et de répondre aux personnes affectées par le résultat.

La personne dans la boucle a besoin d'une vraie boucle

La supervision humaine est facilement réduite à un écran avec un bouton d'approbation. Cet écran peut être utile. Il peut aussi être un objet cérémoniel. La question est de savoir si la personne qui l'utilise a un choix significatif. Un choix n'est pas significatif simplement parce que l'interface affiche deux boutons. Il dépend du fait que la personne dispose de suffisamment de temps, d'informations, de compétences et de permission institutionnelle pour décider autrement.

Le temps est la partie la moins glamour de la conception et souvent la plus décisive. Si le système envoie des centaines de propositions dans une période où un seul examinateur ne pourrait raisonnablement en inspecter qu'une fraction, l'organisation a créé une file d'attente, pas une surveillance. Si la proposition expire avant que l'examinateur ne puisse obtenir le contexte, le système a fait de la rapidité le décideur effectif. Si une équipe n'est récompensée que pour le débit, elle a reçu une instruction discrète sur le bouton à presser. Le logiciel ne peut pas guérir ces arrangements en ajoutant un score de confiance dans une nuance de vert différente.

L'information doit être proportionnée, pas exhaustive. Un examinateur qui ne reçoit qu'une conclusion ne peut pas la contester. Un examinateur qui reçoit une transcription brute de chaque interaction d'agent ne peut généralement pas la contester non plus. Le juste milieu utilisable est un dossier de décision. Il identifie quelle action est proposée, pourquoi elle est dans le but énoncé, quelles preuves matérielles la soutiennent, quelle incertitude demeure, quelle politique ou règle est pertinente, quel est l'effet proposé, et ce qui se passerait si l'action n'est pas approuvée. Le dossier doit renvoyer à des preuves plus approfondies, mais il ne doit pas exiger une expédition archéologique pour le cas ordinaire.

La compétence signifie plus qu'un cours générique sur l'IA. Pour la tâche à accomplir, l'examinateur doit comprendre le type de sortie, les limitations connues qui pourraient compter, la façon dont le flux de travail est censé se comporter, et les signes qui appellent à une escalade. Une personne qui peut reconnaître une facture fournisseur défectueuse peut être bien placée pour examiner une proposition liée à une facture. La même personne peut ne pas être bien placée pour évaluer la couverture linguistique d'un modèle ou une implication en matière de protection des données. Attribuer la surveillance est donc aussi une décision de dotation.

La permission institutionnelle est le test que de nombreuses conceptions échouent discrètement. L'examinateur doit pouvoir refuser, suspendre ou modifier la route proposée sans être traité comme la source d'un défaut système. Il a besoin d'accéder à une personne ou à un rôle qui peut décider de la suite. Il a besoin d'un moyen d'enregistrer que la question a été escaladée. Et le système a besoin d'un état sûr dans lequel le travail peut attendre sans être accidentellement engagé par une nouvelle tentative, un délai d'attente ou un autre agent prenant l'instruction originale comme une affaire inachevée.

L'ingénierie de la sécurité a longtemps traité la performance humaine comme faisant partie du système, plutôt que comme une dernière couche de vernis. Le Health and Safety Executive du Royaume-Uni décrit les facteurs humains comme la tâche, l'individu et l'organisation ensemble, et met en garde contre leur examen isolé. C'est un cadre sensé pour la surveillance des agents. Un examinateur n'est pas un bouchon humain abstrait pour une lacune logicielle. Il accomplit une tâche particulière, avec des informations et des outils particuliers, dans une organisation particulière avec des pressions et des limites particulières. La qualité du contrôle dépend de tout cela.

Pour cette raison, une bonne conception avec un humain dans la boucle commence avant l'apparition du bouton. Elle définit quelles décisions nécessitent une porte humaine, qui tiendra la porte, quelles preuves ils recevront, combien de temps la tâche permet, ce qui se passe quand ils sont absents, et si la porte a autorité sur l'action elle-même ou seulement sur une explication de l'action. Si l'organisation ne peut pas répondre à ces questions un mardi calme, cela ne deviendra pas plus clair quand un cas à haute conséquence arrivera. Et il ne devrait pas avoir besoin d'une crise imaginaire pour le remarquer.

Les permissions doivent décrire la conséquence d'une action, et non pas seulement la portée technique d'un identifiant.

Une tâche, plusieurs formes d'autorité

Un modèle d'autorité compact peut rendre un flux d'agent plus facile à exploiter. Il n'a pas besoin d'être grandiose. Commencez par la différence entre lire, proposer, déléguer, engager et arrêter. Un rôle autorisé à lire peut consulter le matériel nécessaire à une tâche. Un rôle autorisé à proposer peut préparer une action possible. Un rôle autorisé à déléguer peut confier un travail délimité à un autre acteur. Un rôle autorisé à engager peut rendre effective une action conséquente. Un rôle autorisé à arrêter peut suspendre ou interrompre un parcours lorsque ses conditions ne sont plus remplies.

Il ne s'agit pas simplement de niveaux hiérarchiques. Un réviseur de conformité peut être en mesure d'arrêter un flux sans pouvoir engager un résultat client. Un agent spécialisé peut proposer un parcours sans pouvoir déléguer de nouvelles tâches hors de son domaine. Un responsable peut être redevable de la finalité d'un service sans être la personne habilitée à libérer un paiement particulier. La propriété utile n'est pas une hiérarchie pour elle-même. C'est que le système puisse évaluer si un acteur donné dispose de l'autorité pertinente pour une action donnée dans le contexte actuel.

Le contexte fait une grande partie du travail. La même action proposée peut être ordinaire dans une circonstance et conséquente dans une autre. Envoyer un modèle déjà approuvé à une adresse interne connue peut relever d'un mandat de communication courant. Envoyer un message nouvellement rédigé avec des données personnelles à un nouveau destinataire est différent. Un remboursement sous un seuil défini peut être délégué à un processus bien testé. Une modification d'un droit, une suppression de données ou un engagement externe peut nécessiter une décision humaine nominative. La politique doit exprimer cette distinction avant que le modèle ne soit invité à planifier en conséquence.

Il existe également une différence importante entre une approbation et un accusé de réception. Un accusé de réception enregistre que quelqu'un a vu un message. Une approbation enregistre qu'une personne habilitée a accepté une action définie, avec le contexte pertinent, à un point défini du parcours. Dans un système conversationnel, ces deux éléments peuvent sembler similaires. L'enregistrement ne devrait pas l'être. Si un réviseur ultérieur ne peut pas dire quelle action a été approuvée et quel effet était attendu, l'organisation a consigné une conversation plutôt que capturé une décision.

La délégation elle-même a besoin de limites. Un agent qui reçoit la tâche de comparer trois propositions existantes peut être autorisé à demander à un agent de recherche d'extraire les termes pertinents. Il ne devrait pas traiter cette permission comme une invitation à contacter des fournisseurs, à acquérir de nouvelles données ou à redéfinir l'objectif d'achat. La frontière peut être exprimée dans la politique, dans la portée des outils, dans un contrat de tâche structuré ou dans les trois. Ce qui importe, c'est qu'elle soit suffisamment applicable pour contraindre le parcours plutôt que de simplement décrire le comportement souhaité après coup.

La profondeur de délégation est une autre limite qui mérite d'être nommée. Un humain peut confier une tâche à un agent tout en gardant une vision claire de sa première transmission. Après plusieurs transmissions imbriquées, l'objectif initial peut être techniquement présent dans les métadonnées mais pratiquement invisible. Les organisations peuvent fixer une profondeur de délégation maximale pour une catégorie de travail, exiger une revue à une profondeur particulière, ou interdire à un délégataire de créer d'autres délégataires sans une nouvelle validation. Ce sont des choix de conception, pas des exigences universelles. Ils sont surtout utiles lorsqu'une chaîne plus longue rend difficile l'identification de l'acteur qui a introduit une nouvelle hypothèse ou modifié le périmètre effectif.

L'autorité sur les outils doit également être distincte de l'autorité du modèle. Un modèle peut choisir un outil en fonction d'un plan. L'intégration de l'outil doit néanmoins vérifier que l'action demandée, la cible, la catégorie de données, la limite de ressources et l'état du flux de travail autorisent l'appel. Ce n'est pas une méfiance morale envers le modèle. C'est une conception ordinaire des limites. Un plan bien formé peut rester inapproprié pour le cas présent, et un plan mal formé ne devrait pas devenir réel simplement parce qu'il a atteint un identifiant disposant d'un accès étendu.

Il en va de même pour la récupération. Une nouvelle tentative n'est pas toujours inoffensive. Réessayer une demande de lecture d'un document public diffère de réessayer une demande qui envoie un message ou effectue un débit. Lorsqu'une tâche déléguée échoue, un flux de travail doit proposer un choix explicite entre nouvelle tentative, réacheminement, escalade, pause et échec contrôlé. Les traiter comme un seul gestionnaire d'erreurs générique, c'est laisser une décision opérationnelle se prendre silencieusement par les paramètres par défaut. L'environnement d'exécution de l'agent peut rendre les options disponibles. L'organisation doit décider quelle option s'applique à quelle catégorie d'action.

L'échec est souvent une décision manquante

Quand les gens entendent le mot échec, ils imaginent souvent un agent produisant une déclaration fausse ou un outil qui expire. Les deux peuvent avoir de l'importance. Les échecs les plus révélateurs dans le travail délégué sont souvent plus discrets. La tâche a été assignée sans propriétaire clair. La proposition a franchi une limite que personne n'avait modélisée. Le relecteur voyait la conclusion mais pas les preuves. Une nouvelle tentative s'est poursuivie après une pause. Un humain a remarqué un problème mais n'avait pas l'autorité d'arrêter l'action. Une décision a été prise, mais l'enregistrement n'a conservé que le résultat final et non la condition qui le rendait acceptable.

Ce ne sont pas des affirmations sur un incident précis. Ce sont des modes de défaillance dérivés de la structure même de la délégation. On les retrouve aussi dans les processus humains. Dans les logiciels, cependant, ils peuvent se propager à la vitesse de l'automatisation et se répéter de manière très cohérente. Cette cohérence n'est pas une raison de désespérer. C'est une raison de considérer la conception du flux de travail comme partie intégrante du contrôle, plutôt que de supposer que les tests de précision d'un seul composant du modèle règlent la question.

Considérons une autre conception explicitement hypothétique. Un agent est chargé de préparer un résumé de dossier. Il délègue l'extraction de documents à un composant et la normalisation linguistique à un autre. Un troisième composant voit un champ incomplet et utilise une source de connaissances connectée pour combler le vide. Le résumé final se lit de manière fluide. Si le flux de travail n'a pas enregistré le champ manquant, la source utilisée pour le combler, la confiance ou l'incertitude qui l'accompagnait, et le fait que la tâche initiale n'autorisait que le résumé, un relecteur ne peut pas dire s'il approuve un résumé ou une assertion factuelle nouvellement créée. Le problème n'est pas que la dernière phrase semble étrange. Le problème est que le sens de la tâche a changé à l'intérieur du parcours.

Une réponse saine ne consiste pas à interdire la délégation. Elle consiste à inscrire les points de changement dans l’historique. Une nouvelle source, un nouvel outil, une nouvelle catégorie de données, une nouvelle classe d’action, un changement important dans la confiance, un contrôle défaillant, une chaîne de délégation plus longue que permise, ou une proposition de franchir une limite externe peuvent chacun devenir un motif pour soumettre le travail à un examen. Les déclencheurs exacts varieront selon le contexte. Le principe est stable : un changement qui importerait au propriétaire responsable ne devrait pas rester invisible parce qu’il s’est produit entre composants.

C’est un domaine où la réflexion sur le dossier de sécurité est utile. Un dossier de sécurité n’est pas une promesse que rien ne peut mal tourner. C’est un argument structuré expliquant pourquoi un système est acceptable pour un objectif défini dans des conditions définies, avec les preuves, les hypothèses, les contrôles et les risques résiduels visibles. Appliqué avec soin à un flux de travail d’agents, cela signifie que l’affirmation n’est pas que les agents sont généralement sûrs. L’affirmation est plus étroite : cette voie peut être utilisée à cette fin, avec ces limites, parce que ces contrôles et ces dispositifs de surveillance existent, et elle doit être reconsidérée lorsque les hypothèses énoncées ne tiennent plus.

Le flux de travail est alors plus facile à contester. Un opérateur peut demander si la classe d’action a été correctement attribuée. Un propriétaire de risque peut demander si le relecteur dispose encore de suffisamment de temps. Un ingénieur peut demander si une nouvelle tentative pourrait créer un effet en double. Un spécialiste de la protection des données peut demander si la sous-tâche reste nécessaire et proportionnée. Une personne affectée par un résultat peut, lorsque le cadre applicable l’exige, se voir offrir une voie pour contester la décision. Ces questions ne sont pas une bureaucratie ajoutée après le travail technique intéressant. Elles constituent le travail qui rend le système technique redevable au sein d’une organisation.

Les indicateurs devraient suivre la même discipline. Compter le nombre de tâches déléguées nous renseigne sur le volume, pas sur le fonctionnement responsable. Des mesures plus utiles peuvent inclure le taux auquel un flux de travail remonte parce qu’une limite a changé, le temps qu’une décision attend à un point de contrôle, la proportion d’actions importantes accompagnées d’un dossier de décision complet, le nombre d’annulations réussies, ou le nombre de cas où un contrôle de politique a refusé un appel d’outil. De telles mesures nécessitent encore une définition et un contexte. Elles ne devraient jamais être inventées pour une brochure. Mais concevoir les enregistrements pour qu’ils puissent être mesurés est un signe que la responsabilité est traitée comme une propriété opérationnelle.

L’historique est ce qui permet à la responsabilité de survivre

Un système multi-agents produit une forme d’histoire maladroite. Il contient des messages, des appels d’outils, des sorties intermédiaires, des contrôles de politique, des versions de modèles, des informations de synchronisation, des nouvelles tentatives, des affectations modifiées et peut-être des approbations humaines. Conserver chaque octet pour toujours n’est ni nécessaire ni souvent approprié. Ne conserver que la réponse finale est généralement trop peu. L’historique doit préserver les décisions et les preuves qui expliquent comment le flux de travail est passé d’une demande à un résultat.

Pour une action importante, cet historique devrait normalement permettre à un relecteur de reconstituer quelques faits de base. Quel était l’objectif ? Quelle politique ou quel mandat rendait le travail permissible ? Qui ou quoi a reçu chaque affectation ? Qu’est-ce qui a été proposé à chaque point de contrôle important ? Quelles informations ont été utilisées pour étayer la proposition ? Quelles limites, avertissements ou défaillances ont été rencontrés ? Qui détenait l’autorité d’approuver, d’arrêter ou d’annuler l’action ? Quelle action est devenue effective, et que s’est-il passé ensuite ? Ce ne sont pas des questions exotiques. Ce sont les questions qu’une organisation se pose lorsqu’elle veut savoir si une décision était bien la sienne.

The record should distinguish an operational fact from an explanation produced later. If a system says a reviewer approved an action, the event should record the identity or role of the reviewer, the action they were shown, the relevant context and the time at which the approval bound to that action. If the system says a model selected a delegate, the record should preserve the selection rule, candidates or criteria at the level appropriate for the use, and the resulting assignment. A later narrative can help a reader, but it should not replace the event that occurred.

Versioning matters here. An agent's output may be regenerated. A policy may be updated. A tool schema may change. A model endpoint may be swapped. If a decision depends on a particular version of a prompt, policy, model, knowledge source or integration, the record needs a stable reference to that version. Otherwise replay becomes a performance: it reproduces whatever the organisation happens to have now and calls the result an explanation of what happened then.

Reversibility deserves equal attention. The AI Act expressly refers, in the high-risk oversight context, to the ability to disregard, override or reverse an output and to interrupt a system so it comes to a halt in a safe state. In a multi-agent route, the safe state is not necessarily a stopped model process. It may mean no external communication is sent, a queued action is held, a downstream system is not updated, temporary credentials are no longer usable for the task, and the evidence needed to decide what happens next is retained. That is an operational inference from the oversight requirement, not a quotation of the law. It is also a useful design test.

Safe does not mean frozen forever. A halted workflow needs a controlled resumption path. Someone must decide whether to amend the task, discard the proposal, rerun a bounded part of the work, use a different tool, seek further evidence or abandon the route. A clean record makes that choice easier because it tells the next person what is known, what was attempted, why the work stopped and which effects have and have not occurred. Without that record, recovery becomes another unstructured delegation, usually undertaken under more pressure than the first one.

This is why retention and access need their own decisions. Not every actor should be able to read every trace. A record may contain personal data, commercially sensitive material or security-relevant details. But controlled access is not the same as no record. The Council of Europe Convention's emphasis on transparency, oversight, accountability and responsibility is a useful reminder that the boundary should be designed rather than assumed. An organisation can preserve an accountable route while limiting access to the detail that a particular reviewer genuinely needs.

What a delegation contract should make visible

A delegation contract can be a data structure, a workflow schema, a signed approval packet or a combination of these. Its form matters less than its content. It should tell the receiving actor what it is allowed to do, what it is not allowed to do and how the work will be judged. When these constraints are absent, agents tend to compensate with increasingly elaborate instructions. That may improve a particular run. It does not create an organisational boundary that a tool, reviewer or auditor can enforce.

Begin with the intended purpose. A purpose should be concrete enough to exclude nearby tasks. Compare the terms in the supplied proposals is different from find the best supplier. Summarise the received documents is different from establish the missing facts. Draft a reply for review is different from communicate a decision. The contrast can sound fussy until an agent uses a broad instruction to take a reasonable but unauthorised next step. Then it is the difference between useful initiative and an unbounded mandate.

Indiquez les classes d'actions autorisées et interdites. Un agent peut être autorisé à lire un dossier, à en extraire des champs nommés, à le comparer à une politique et à préparer un projet. Il peut lui être interdit de modifier un enregistrement source, de contacter une partie externe, de sélectionner une nouvelle source ou d'engager une transaction. Il ne s'agit pas simplement d'instructions données à l'invite. La couche d'outils et de flux de travail doit les appliquer lorsque cela est pratique. Une politique qui ne peut pas être vérifiée au moment de l'action reste utile comme orientation, mais elle est plus faible en tant que contrôle.

Nommez le propriétaire et la voie d'escalade. Le propriétaire n'est pas nécessairement la personne qui cliquera sur « approuver » pour chaque action. C'est le rôle responsable du résultat et de la décision sur ce qui se passe lorsque la voie atteint une question non résolue. La voie d'escalade identifie l'autorité suivante lorsque l'agent détecte une violation de limite, des preuves insuffisantes, un conflit entre sources, une inadéquation de politique ou une condition que le système n'est pas autorisé à résoudre. Une file d'attente sans propriétaire de décision nommé n'est qu'un délai avec une étiquette optimiste.

Joignez une règle de preuve. La règle peut indiquer quelles sources sont faisant autorité, si l'agent peut rechercher au-delà de celles-ci, comment l'incertitude est représentée, ce qui doit être cité dans la proposition et quand une source contradictoire nécessite un examen. Ceci est particulièrement important pour les systèmes qui génèrent une prose fluide. La fluidité peut faire paraître une violation de limite comme une réalisation utile. Une règle de preuve rend disponible la bonne question : le flux de travail est-il resté dans le matériel qu'il était autorisé à utiliser ?

Fixez une limite de temps, de ressources et de délégation là où elles comptent. Une tâche qui peut se poursuivre indéfiniment peut créer des coûts, une congestion opérationnelle ou une pression pour engager un résultat obsolète. Une tâche qui peut déléguer à plusieurs reprises peut créer une chaîne qu'aucun propriétaire ne peut facilement inspecter. Une conception bornée indique combien de temps la tâche reste valide, combien de ressources elle peut consommer, si elle peut créer une sous-tâche, quelle profondeur maximale est autorisée et ce qui se produit lorsqu'une limite est atteinte. La réponse peut être une pause automatique, une escalade ou un échec contrôlé. L'important est que cela soit décidé avant que la limite ne soit franchie.

Enfin, définissez la condition d'achèvement. Terminé ne signifie pas toujours que l'agent a produit du texte. Cela peut signifier qu'un réviseur a reçu un dossier complet, qu'une porte de politique a accepté une action spécifique, qu'un système en aval a confirmé une mise à jour réversible, ou qu'un propriétaire responsable a choisi de ne pas poursuivre. Les conditions d'achèvement maintiennent l'honnêteté du flux de travail. Elles empêchent un agent de traiter le fait de proposer une décision comme si l'organisation en avait pris une.

Ces modèles sont utiles que le flux de travail contienne un seul agent basé sur un modèle ou une équipe plus large de composants spécialisés. Plus d'agents ne nécessitent pas automatiquement plus de processus. Ils exigent que les limites entre les rôles soient exprimées plutôt qu'impliquées. Le coût de cette expression est généralement bien inférieur au coût de tenter de reconstruire l'autorité après que plusieurs systèmes ont échangé des instructions partielles et que l'un d'eux a touché le monde extérieur.

La délégation devrait rendre l'organisation plus capable, pas moins responsable

Les systèmes d'agents sont souvent décrits comme si leur valeur résidait dans le fait de retirer l'organisation du travail. La perspective la plus intéressante est l'inverse. Un système soigneusement conçu peut rendre les engagements organisationnels plus clairs : une tâche a un propriétaire, une délégation a une limite, une action conséquente a une autorité, un examen a des preuves, une halte a un état sûr et un enregistrement peut être rejoué. Ce n'est pas un obstacle à l'automatisation utile. C'est ce qui permet à l'automatisation d'assumer un travail significatif sans demander aux gens de faire confiance à une chaîne invisible.

Nous avons conçu Dweve Nexus autour de cette distinction. Sa documentation produit locale décrit des tâches durables, une autorité évaluée par rapport au contexte d'exécution avant toute action, des structures de collaboration explicites incluant la délégation, et un enregistrement rédigé au fil du travail. La revendication concernée est volontairement modeste. Ce sont des propriétés de conception destinées à rendre une voie déléguée inspectable. Elles ne constituent pas une preuve qu'un déploiement particulier est licite, sûr ou adapté, et elles ne suppriment pas la nécessité pour une organisation de décider elle-même de son objectif, de son autorité et de sa supervision humaine.

La leçon plus large ne dépend pas d'un seul produit. Un modèle peut décider comment diviser une tâche. Un agent peut demander du travail à un autre agent. Un outil peut exécuter une action. L'organisation doit toujours décider où réside l'autorité. Elle doit le faire avant que la délégation ne commence, et non après qu'un résultat final a été poli au point de devenir difficile à remettre en question.

Voilà la réponse au titre. Le propriétaire d'une décision n'est pas l'agent qui a parlé en dernier. C'est la personne ou le rôle auquel l'organisation a attribué l'autorité d'accepter la conséquence de la décision, avec suffisamment d'informations et de pouvoir pour la refuser. La délégation est utile lorsqu'elle rend cette personne plus capable. Elle devient dangereuse lorsqu'elle la rend introuvable.

Qui détient la décision quand un agent délègue ?