La question de l’autonomie des agents est en réalité une question d’autorité
Exiger une approbation humaine pour chaque achat de cinq centimes peut rendre un agent d’IA transactionnel inefficace. Donner au même agent l’autorisation d’acheter un rapport d’analyste à 2 000 $ crée une exposition financière plus importante. La question clé est de savoir quel niveau d’autorité un agent doit recevoir au regard du jugement dont il a fait preuve.
Les agents peuvent être conçus pour payer des API, des données, des ressources de calcul et du contenu. AWS présente AgentCore Payments comme un moyen permettant aux agents de découvrir et de payer des API, des serveurs Model Context Protocol et du contenu sous paywall au cours d’une tâche. LangChain décrit un middleware offrant la même capacité.
Déplacer de l’argent est simple dès lors qu’un accès au paiement existe. Déléguer la décision de dépenser crée un problème de gouvernance distinct.
Capacité, jugement et autorité sont trois choses différentes
Les dirigeants qui évaluent des agents doivent distinguer trois concepts. La capacité correspond à ce qu’un agent peut techniquement faire. Le jugement correspond à la fiabilité avec laquelle il décide quoi faire. L’autorité correspond à ce que les systèmes environnants l’autorisent à faire.
Une application traditionnelle peut exécuter un paiement lorsque des conditions écrites par des développeurs sont remplies. Un agent peut avoir un rôle plus large : choisir un service, évaluer sa valeur par rapport à un objectif, évaluer le prix, puis proposer ou initier un achat. L’agent dispose alors d’une marge de manœuvre sur des décisions que la logique applicative pourrait autrement spécifier à l’avance.
La capacité seule ne constitue pas une preuve suffisante de la qualité des décisions. Un système peut exécuter une action tout en ne reconnaissant pas des conséquences importantes pour son opérateur.
L’autorité est distincte parce qu’une organisation peut restreindre ce qui se passe après que le modèle a pris une décision. Un agent peut décider qu’un achat coûteux en vaut la peine alors que l’infrastructure de paiement le rejette. Il peut aussi rester dans les limites de son budget autorisé et mal dépenser ce budget.
Cette distinction change la manière dont l’autonomie doit être gouvernée. Les améliorations de la capacité du modèle exigent des preuves distinctes de jugement. L’accès à un système établit une permission, tandis que l’infrastructure environnante détermine dans quelle mesure les décisions d’un agent peuvent avoir des conséquences dans le monde réel.
Un projet en tête ?
Planifiez un appel de 30 minutes avec nous.
Des experts senior pour vous aider à avancer plus vite : produit, tech, cloud & IA.
Placez des limites strictes en dehors du modèle
Prenons le cas d’un agent de recherche préparant une analyse concurrentielle. Il découvre un rapport sectoriel payant, une API de données de marché et plusieurs articles sous paywall. Exiger une approbation pour chaque petite transaction peut absorber une partie du temps gagné grâce à la délégation. Des achats sans restriction peuvent exposer l’organisation à des dépenses incontrôlées.
Une troisième conception donne à l’agent une autorité déléguée mais encadrée. L’instruction pourrait être : dépenser jusqu’à 10 $ pour cette tâche, ne pas dépenser plus de 2 $ auprès d’un même fournisseur, n’acheter que des services liés à la recherche, s’arrêter lorsque l’autorisation expire et renvoyer les reçus.
AWS indique qu’AgentCore Payments prend en charge cette architecture. AWS a un intérêt commercial à l’adoption d’AgentCore Payments ; il s’agit donc d’une affirmation d’un fournisseur. AWS décrit la session de dépense d’un agent comme ayant un montant maximal et une date d’expiration, avec des limites appliquées de manière déterministe en dehors du modèle. AWS indique également que les transactions produisent des journaux et des pistes d’audit.
Ici, « de manière déterministe » signifie qu’une règle fixe décide si une action est autorisée, au lieu de laisser cette décision au modèle de langage. Le modèle peut proposer une action en fonction de son contexte et de son objectif. Une couche de politique distincte décide si cette action entre dans le cadre de l’autorisation de l’organisation.
Cette séparation est également importante face au prompt injection, une attaque dans laquelle une entrée malveillante ou non fiable manipule les instructions suivies par un agent. Une injection pourrait modifier ce que le modèle tente d’acheter. Une limite de transaction appliquée indépendamment peut malgré tout rejeter un achat en dehors de son autorisation configurée, à condition que ce contrôle reste hors de portée du modèle.
Les politiques de dépense déléguée peuvent couvrir un montant total, des finalités autorisées, des fournisseurs approuvés, une date d’expiration et des exigences en matière de justificatifs. Elles créent aussi des exigences en matière d’identité, d’autorisation, de révocation et de registres d’audit. Dans le cadre de ces permissions, l’agent conserve une marge de manœuvre sur ce qu’il achète.
Le principe s’étend au-delà des paiements. Lorsque la conséquence d’une action peut être mécaniquement bornée, l’infrastructure peut faire respecter cette limite indépendamment du raisonnement du modèle. Un meilleur prompting peut influencer le comportement. L’application déterministe des règles définit quelles actions proposées le système environnant autorisera.
Les garde-fous limitent l’échec ; le jugement exige des preuves distinctes
Un agent peut rester dans toutes les limites de ressources et malgré tout prendre de mauvaises décisions. Le respect d’une limite de dépense montre que la limite a fonctionné. Des décisions d’achat utiles exigent des preuves distinctes.
Jack Clark d’Anthropic décrit une limite des systèmes actuels : « There’s a certain absence of valuable, intuitive creativity in today’s AI systems. » Il ajoute : « Though they’re extraordinarily capable engineers, they [also] seem to have a certain property of rote, formulaic thinking that might prevent them [from] being good researchers. »
L’observation de Clark illustre la distinction entre capacité technique et jugement. Anthropic développe des systèmes d’IA et a donc un intérêt commercial dans la manière dont les capacités et les limites de ces systèmes sont comprises. La caractérisation de Clark doit être lue dans ce contexte.
Les métriques de sécurité et les métriques de performance répondent à des questions différentes. Un plafond de dépense peut établir si un agent a dépassé son autorisation financière, et une piste d’audit peut enregistrer ce qu’il a acheté. Les évaluations doivent déterminer si l’agent a identifié des opportunités utiles, sélectionné des ressources appropriées et effectué des arbitrages efficaces.
Les garde-fous bornent les dimensions qu’ils sont conçus pour contraindre. Le jugement exige des preuves distinctes. Une organisation doit tester si un agent utilise efficacement sa marge de manœuvre dans le travail qu’elle prévoit de lui déléguer.
Les mesures générales de la capacité d’un modèle constituent donc une base incomplète pour accorder de l’autorité. La performance en ingénierie démontre une performance en ingénierie. Le jugement en recherche exige des preuves issues de tâches de recherche. L’autorité doit découler de preuves provenant du contexte dans lequel des décisions à conséquences seront prises.
Adaptez l’autorité aux conséquences d’une erreur
Une approche pratique de gouvernance classe les actions selon leurs conséquences. Une organisation peut accorder une marge de manœuvre plus large lorsque les actions sont peu coûteuses, observables et faciles à annuler. Les contrôles peuvent se resserrer à mesure que les actions deviennent plus coûteuses, moins observables ou plus difficiles à défaire. L’approbation humaine peut rester une partie de l’exécution lorsque les conséquences dépassent les limites déléguées de l’organisation.
Cela crée une trajectoire de déploiement fondée sur des preuves plutôt que sur une étiquette binaire comme « autonome ». Un agent de recherche pourrait commencer avec un petit budget par tâche et des permissions limitées à certains fournisseurs. L’organisation pourrait élargir ces permissions après que les évaluations et les résultats en production ont montré que l’agent sélectionne des ressources utiles, respecte la finalité prévue et produit des résultats qui justifient le coût.
La même logique s’applique au-delà des achats. Pour un appel API, un changement d’infrastructure, une communication sortante ou une décision d’accès, la question pertinente est de savoir quelles conséquences l’agent peut produire avant qu’un contrôle indépendant n’intervienne. Les organisations peuvent modifier ces permissions sans changer le modèle sous-jacent.
Cette séparation est utile sur le plan opérationnel. Une mise à niveau du modèle peut modifier la capacité, tandis que l’autorité reste contrôlée indépendamment. Les organisations peuvent l’ajuster en fonction des performances observées et des conséquences qu’elles sont prêtes à autoriser.
Points clés à retenir pour les dirigeants
- Distinguez capacité, jugement et autorité : La capacité d’un agent à exécuter une action ne prouve pas qu’il peut prendre de bonnes décisions sur le moment d’agir. Les dirigeants doivent accorder de l’autorité sur la base d’un jugement démontré dans le contexte précis où les décisions auront des conséquences.
- Placez des limites strictes en dehors du modèle : Utilisez une infrastructure déterministe pour faire respecter les limites de dépense, les finalités approuvées, les restrictions sur les fournisseurs, l’expiration et les autres règles d’autorisation. Cela permet aux agents d’exercer une marge de manœuvre sans compter sur le modèle lui-même pour appliquer des garde-fous critiques.
- Évaluez le jugement séparément des garde-fous : Rester dans une limite de dépense montre que le contrôle a fonctionné, pas que la dépense était utile. Les dirigeants doivent utiliser des évaluations spécifiques aux tâches pour déterminer si les agents font des choix et des arbitrages efficaces dans le cadre de leur autorité déléguée.
- Adaptez l’autorité aux conséquences d’un échec : Donnez aux agents une plus grande marge de manœuvre lorsque les actions sont peu coûteuses, observables et réversibles, et resserrez les contrôles à mesure que les conséquences augmentent. Étendez progressivement l’autorité à mesure que les évaluations et les résultats en production démontrent un jugement fiable.
Un projet en tête ?
Planifiez un appel de 30 minutes avec nous.
Des experts senior pour vous aider à avancer plus vite : produit, tech, cloud & IA.


