Un agent d’IA ne doit réaliser que des actions explicitement autorisées dans un processus défini. Répondre à une question, préparer une proposition et engager l’entreprise sur une promesse impliquent des responsabilités différentes. Les systèmes connectés doivent faire respecter ces limites, et des résultats observables doivent confirmer qu’elles fonctionnent.
Un assistant peut paraître sûr de lui tout en ignorant un fait essentiel. Une formulation assurée ne peut pas tenir lieu de validation commerciale. Les questions utiles sont précises : que peut lire le système, que peut-il modifier et qui est responsable de ce changement ?
Partir de l’action
Dans un scénario hypothétique de showroom, le même assistant pourrait expliquer les horaires d’ouverture, préparer une demande de visite et proposer un rendez-vous disponible. Chaque action a des conséquences différentes.
Lire les horaires publics ne demande pas l’accès à toutes les fiches clients. Proposer un créneau ne le réserve pas. Confirmer une visite demande une opération réussie dans le système de réservation, dans les conditions acceptées par l’utilisateur.
Nous définirions les autorisations pour chaque étape. Si le processus n’a pas besoin d’une fonction, le système ne doit pas y avoir accès simplement parce qu’une intégration la propose.
| Action possible | Condition de conception |
|---|---|
| Expliquer une information publique | Utiliser une source validée et à jour |
| Préparer une synthèse | Séparer les faits indiqués des inconnues |
| Enregistrer une demande | Recueillir les informations nécessaires, vérifier l’accès et éviter les doublons |
| Confirmer un rendez-vous | L’utilisateur l’a choisi et le système de réservation l’a confirmé |
| Proposer une remise exceptionnelle | Obtenir la validation du rôle commercial désigné |
| Modifier un contrat | Suivre un processus distinct d’autorisation et de relecture |
C’est une répartition possible des responsabilités. Les limites finales dépendent du service, des conséquences d’une erreur et du fonctionnement de l’entreprise.
L’autorisation doit exister au-delà de la conversation
Une consigne d’éviter les remises est utile, mais le système connecté doit aussi restreindre les opérations disponibles. Si un outil peut appliquer n’importe quelle remise sans vérification indépendante, la conversation devient le seul filtre d’une décision commerciale.
L’OWASP traite de l’autonomie excessive (en anglais) sous l’angle des fonctions, des autorisations et de l’autonomie dont dispose un système. Nous répondrions à ce risque par un accès limité aux opérations nécessaires et des vérifications proportionnées à leurs conséquences.
L’identité compte aussi. Une question sur un produit peut recevoir une réponse publique. Une demande sur une commande doit être reliée à un client vérifié avant d’afficher des détails privés. Connaître un numéro de commande ne doit pas être considéré automatiquement comme une preuve suffisante.
Et les instructions contenues dans les documents ?
Un document envoyé pour un devis peut contenir des exigences techniques à côté d’un texte demandant au système d’ignorer ses règles ou de divulguer d’autres informations. Le contenu reçu est un matériau à analyser. Il n’acquiert pas l’autorité de modifier les autorisations du processus.
C’est un type de problème couvert par les recommandations de l’OWASP sur l’injection de prompt (en anglais). Dans notre exemple, un document peut alimenter la synthèse, tandis que la validation des actions relève d’un mécanisme d’autorisation distinct.
La personne qui valide a besoin d’assez d’informations pour décider
Une validation est utile lorsque la personne peut voir ce qui va se passer : le destinataire, les informations utilisées, l’engagement proposé et les questions non résolues. Un bouton de validation à côté d’une synthèse incomplète peut transférer la responsabilité sans améliorer la décision.
Nous montrerions aussi les sources pertinentes, les changements par rapport à la demande d’origine et l’étape suivante. Pour les opérations sensibles, nous établirions qui peut les valider, comment la décision est consignée et comment le processus peut être arrêté.
Comment tester les limites ?
Incluez des demandes que le système doit refuser ou transmettre : la commande d’un autre client, une remise non autorisée, des informations contradictoires, une intégration indisponible ou un envoi répété. Vérifiez l’état du système qui en résulte, et pas seulement la réponse affichée.
Chez NOT MORE., nous pouvons définir ces responsabilités avec votre équipe, puis concevoir et mettre en œuvre le processus convenu. Plus d’autonomie devient utile lorsque le processus, les autorisations et l’évaluation le permettent.
Quelle action laisseriez-vous le système réaliser seul, et que voudriez-vous voir avant de la valider ?