Avant qu’un agent d’IA puisse agir, déterminez ce qu’il ne doit en aucun cas toucher

J’ai tendance à me méfier d’une réponse trop simple lorsque le système réel est complexe. Un modèle qui propose une réponse peut se tromper. Un modèle qui déploie du code ou modifie un enregistrement de paiement peut transformer cette erreur en problème opérationnel. La question pertinente est de savoir ce qu’une personne est capable de démontrer lorsque la décision compte, et non pas à quel point la présentation était convaincante lorsque tout allait bien.

Les conseils et les actions sont deux choses différentes

Un modèle qui rédige une réponse peut se tromper. Un modèle qui déploie du code ou modifie un enregistrement de paiement peut transformer cette erreur en incident opérationnel.(Autio et al., 2024) Je souhaite savoir à qui revient le contrôle, comment le système se comporte en cas de défaillance du processus normal, et quelles preuves pourraient modifier la décision. La réponse doit provenir du système réel plutôt que d’une diapositive décrivant l’architecture prévue.

Attribuez une identité à l’agent

Un agent s’exécutant via un compte de service général hérite de ses privilèges, quelle que soit la précision avec laquelle son invite décrit ses intentions(Rose et al., 2020). Il existe une différence entre une politique et une capacité. Je demanderais à l’équipe de mettre en évidence cette distinction importante, d’expliquer le cheminement des exceptions et d’identifier la personne habilitée à autoriser l’action qui en découle.

Placer l’approbation à la frontière de conséquence

Je ne souhaite pas recevoir de demandes de validation pour chaque action anodine. Je souhaite qu’elles interviennent lorsque l’erreur peut s’avérer coûteuse, irréversible ou difficile à détecter.(Temoshok et al., 2025) Je souhaite savoir à qui appartient le contrôle, comment il se comporte en cas de défaillance du processus normal, et quelles preuves pourraient modifier la décision. La réponse doit provenir du système réel plutôt que d’une diapositive décrivant l’architecture prévue.

L'outil applique la règle

Un texte non fiable peut influencer le modèle. La décision d’autorisation doit résider dans l’outil et le service, et non dans une phrase demandant au modèle de se comporter d’une certaine manière.(Souppaya et al., 2022) Il existe une différence entre une politique et une capacité. Je demanderais à l’équipe de mettre en évidence la limite importante, d’expliquer le parcours d’exception et d’identifier la personne habilitée à autoriser l’action qui en découle.

Contenir la surprise

L’objectif n’est pas de promettre que l’autonomie ne vous prendra jamais au dépourvu. Il s’agit de limiter ce qu’une surprise peut atteindre, modifier et dissimuler. (Joint Task Force Transformation Initiative, 2012). Je souhaite savoir qui détient le contrôle, comment celui-ci se comporte en cas de défaillance du processus normal, et quelles preuves pourraient modifier la décision. La réponse doit provenir du système lui-même plutôt que d’une diapositive décrivant l’architecture prévue.

La décision que je prendrais en premier lieu

Pour un agent, je répertorierais chaque appel d’outil comme une action métier potentielle : lire un document, modifier un ticket, déployer une version, envoyer un e-mail ou transférer des fonds. Chaque action nécessite ses propres limites d’autorisation ainsi qu’un enregistrement de ce que l’agent a demandé et de ce que l’outil a effectivement fait.

Je testerais également ce qui se passe lorsque le contenu récupéré contient des instructions destinées à l’agent plutôt que des informations destinées à l’utilisateur. La protection ne se limite pas à une invite système plus stricte. Il s’agit d’un service qui refuse les actions non autorisées, même lorsque le modèle en fait la demande avec assurance.

Si vous mettez en production des agents d’IA, je peux vous aider à définir les limites qui permettront de maintenir leur autorité proportionnée à la tâche.