Comment reconnaître une tâche adaptée à un premier pilote ?
Choisissez un processus dont les étapes et les exceptions sont décrites. Les entrées doivent être accessibles dans un environnement autorisé et le résultat doit pouvoir être contrôlé par une personne. Classer des demandes fictives et préparer un brouillon permet de tester une méthode sans déclencher d’action externe.
Distinguez l’interprétation confiée au modèle des règles qui peuvent être définies autrement. Un contrôle d’autorisation ou une limite de montant n’a pas à dépendre de la formulation d’une réponse générée.
Définir l’entrée, la sortie et le motif d’arrêt
Le brief du pilote doit préciser ce que l’agent reçoit, ce qu’il produit et les cas où il doit s’arrêter ou demander une validation.
Comment examiner autonomie, permissions et portée ?
Ces trois dimensions forment une grille de discussion : que peut décider l’agent, à quoi a-t-il accès et quelles conséquences ses actions peuvent-elles avoir ? Elles aident à préparer les contrôles.
Leur multiplication ne constitue pas une formule validée de calcul du risque. Le rapport AISB propose une manière de raisonner ; la grille ne donne ni probabilité d’incident ni score de conformité.
Une permission technique ne vaut pas une décision métier
Définissez les actions autorisées dans les systèmes et les rôles responsables. L’agent ne doit pas inventer sa propre autorisation à partir d’un texte rencontré.
| Dimension | Question de cadrage | Contrôle possible |
|---|---|---|
| Autonomie | Quelles décisions sans intervention ? | Sortie en brouillon et validation |
| Permissions | Quels outils et données accessibles ? | Accès limité à la tâche |
| Portée | Quelles personnes et systèmes affectés ? | Périmètre de test limité |
| Reprise | Que se passe-t-il en cas d’erreur ? | Arrêt, journal et reprise contrôlée |
Où placer une validation humaine ?
Placez une validation avant les actions dont les conséquences justifient une décision explicite : message externe engageant l’entreprise, paiement, modification sensible ou suppression. Le responsable doit voir l’action proposée et les informations qui la justifient.
OWASP recommande notamment de limiter les fonctions et permissions d’un agent et de faire approuver les actions à fort impact. Ce cadre technique doit être adapté au processus et aux responsabilités de votre organisation.
Que tester avant d’élargir le pilote ?
Introduisez des données manquantes, une demande ambiguë et une panne d’un service. Vérifiez que l’agent s’arrête, transmet ou réessaie selon les règles prévues, sans dupliquer une action. Prévoyez un moyen d’interrompre le fonctionnement.
Mesurez la qualité des résultats acceptés et le temps de contrôle. Un prototype qui réussit un exemple ne prouve pas qu’il peut traiter un volume réel de façon autonome.
