Concevoir un assistant IA cadré par ses outils, ses droits et son contexte

La véritable limite d’un assistant IA est le contrat de service que l’organisation peut faire respecter, pas une interdiction formulée dans son prompt. Un modèle peut recevoir l’ordre de ne jamais envoyer de message tout en disposant d’un outil et d’un identifiant capables de le faire. Pour éviter ce décalage, il faut attribuer séparément à chaque capacité visible ses données admissibles, son identité agissante, ses droits, son plafond d’action, ses validations, ses traces et ses conditions d’arrêt.

Que doit-on réellement permettre à l’assistant ?

L’équipe doit d’abord rédiger une charte de service en une phrase, puis la décomposer en opérations observables. Une formule utile est la suivante : « Pour les utilisateurs admissibles, l’assistant peut accomplir telle famille de tâches avec tel périmètre d’information afin de produire tel résultat, mais il ne peut pas prendre telles décisions ni provoquer tels effets. » Cette méthode est une synthèse éditoriale inspirée des principes du NIST et d’OWASP, pas une exigence imposée par ces organismes.

Les verbes comme « aider », « gérer » ou « traiter » masquent des pouvoirs très différents. Rechercher, résumer, recommander, créer un brouillon, modifier un dossier, envoyer, supprimer et approuver doivent devenir des capacités séparées. Avant de connecter un outil, précisez les utilisateurs visés, le cadre de déploiement, les tâches prises en charge, les limites de connaissance, la supervision humaine, le propriétaire du risque et les résultats explicitement exclus.

• Nommer une demande utilisateur précise et le résultat qui compte comme réussite.
• Définir les données nécessaires sans accorder l’accès à tout un système par commodité.
• Séparer les opérations de lecture, de préparation et d’exécution.
• Inscrire les non-objectifs, notamment les décisions professionnelles ou engagements que le service ne doit jamais prendre.
• Attribuer à chaque capacité un responsable habilité à la suspendre, la réviser ou la retirer.

Quelles informations chaque capacité peut-elle utiliser ?

Une limite de contexte est une enveloppe d’information, et non simplement la taille technique de la fenêtre du modèle. Pour chaque capacité, elle précise les systèmes et types de dossiers admis, les classifications, les filtres d’objet, la période couverte, la fraîcheur attendue, les droits de l’utilisateur et les données exclues. Si une preuve nécessaire est inaccessible, absente ou périmée, l’assistant doit le signaler, restreindre sa réponse ou refuser de conclure.

Les documents récupérés, pièces jointes, messages externes et réponses d’API restent du contenu non fiable : ils ne peuvent pas devenir silencieusement des instructions de service. Il faut aussi distinguer l’historique de session de la mémoire persistante. Déterminez ce qui peut être conservé, comment les utilisateurs et sessions sont isolés, quelle validation précède la persistance, quand les éléments expirent ou sont supprimés, et quelles données ne doivent jamais être mémorisées.

• Sources, enregistrements, champs et plages temporelles admissibles.
• Droits effectifs de la personne sur chaque objet récupéré.
• Fraîcheur minimale définie par le service, sans seuil universel.
• Classe de confiance des contenus internes, externes et générés.
• Règles distinctes pour la session, la mémoire persistante et la suppression.
• Réponse prévue lorsque les éléments justificatifs manquent ou se contredisent.

Comment l’identité, les outils et les droits font-ils respecter la limite ?

L’authentification, l’autorisation et la validation doivent rester trois décisions distinctes. La première établit qui est l’utilisateur, le client ou la charge de travail. La deuxième détermine quelle opération cette identité peut effectuer sur quelle ressource protégée. La troisième accepte une action proposée précise. Un clic de validation ne crée donc pas un droit absent, et une instruction en langage naturel ne constitue jamais un contrôle d’autorisation.

Choisissez explicitement entre l’autorité déléguée de l’utilisateur et une identité de service étroitement contrôlée; n’empruntez pas silencieusement le compte privilégié d’un opérateur. La passerelle et le système destinataire doivent limiter les verbes, ressources, objets, champs, destinations, durées d’identifiant et audiences de jeton. Pour une intégration MCP protégée, les portées minimales et les jetons liés à une ressource offrent un modèle utile, sans constituer une règle universelle pour tous les outils.

• Exposer une opération structurée, par exemple créer un brouillon, plutôt qu’un accès général à une boîte de messagerie.
• Valider les paramètres et les objets au point d’exécution.
• Limiter taux, tentatives, profondeur de chaîne, lots, durée, dépenses et consommation selon le service.
• Prévoir l’idempotence, l’annulation possible et un coupe-circuit lorsque l’effet le justifie.
• Demander des droits supplémentaires seulement lorsqu’une capacité précise les exige.

La conversation peut être continue; son autorité, elle, doit rester divisée en petites capacités contrôlées séparément.

Jusqu’où une capacité peut-elle agir ?

Chaque capacité a besoin d’un plafond d’action explicite, avec des contrôles indépendants plus forts à mesure qu’elle modifie l’état extérieur. Une échelle éditoriale pratique distingue la réponse ou le résumé, la recommandation, le brouillon, l’écriture réversible et bornée, l’action externe conséquente, puis la décision interdite. Ce classement aide à séparer une proposition d’une décision responsable, un brouillon d’un envoi et une mise à jour réversible d’une suppression.

Avant une action conséquente, l’utilisateur doit voir un aperçu vérifiable. La validation doit être liée à l’acteur, à l’outil, à la ressource cible, aux paramètres normalisés, au moment et à l’échéance, puis être contrôlée à nouveau lors de l’exécution. Si le destinataire, le contenu ou un autre paramètre change, une nouvelle validation est nécessaire. Les paiements, droits d’accès, suppressions, changements de production et engagements matériels restent sous contrôle humain qualifié et politique déterministe.

• Répondre ou résumer sans modifier un système externe.
• Recommander une suite en indiquant qu’il s’agit d’une proposition.
• Créer un objet modifiable dans un espace marqué comme brouillon.
• Écrire dans des champs autorisés au sein d’un processus réversible.
• Exécuter une action externe seulement avec autorisation et validation liées à l’action.
• Refuser toute décision que le service a déclarée interdite, même si un utilisateur la demande.

Que se passe-t-il lorsque l’assistant atteint une limite ?

Le refus, l’aide partielle sûre, la transmission à une personne et l’escalade de sécurité doivent être conçus comme des résultats explicites du service. Le message indique simplement la limite sans révéler de règle sensible et ne prétend jamais qu’une source, un appel d’outil, une validation ou une écriture a réussi. L’assistant peut encore fournir la partie sûre, par exemple un brouillon, une liste de contrôle ou une demande d’information manquante.

La transmission doit contenir l’objectif initial, le contexte non sensible utile, la capacité tentée, le motif, les preuves disponibles ou manquantes, l’étape proposée et un identifiant de trace. Elle est dirigée vers le bon propriétaire : support ordinaire, décideur métier ou équipe de sécurité. Ces chemins n’ont ni la même urgence ni la même responsabilité. L’exécution reste arrêtée pendant le traitement, et toute action modifiée exige une nouvelle vérification.

• Tâche hors périmètre ou information non admissible.
• Autorisation insuffisante ou validation encore requise.
• Preuve absente, contradictoire ou trop ancienne pour l’usage prévu.
• Jugement spécialisé ou décision responsable nécessaire.
• Outil indisponible, limite opérationnelle atteinte ou dépendance en panne.
• Signal de sécurité tel qu’une tentative d’exfiltration, d’élévation de privilèges ou de contournement.

Comment transformer ces limites en dispositif opérationnel ?

Les équipes doivent remplir une ligne de canevas par opération visible, puis relier chaque ligne à des contrôles exécutables, des traces, des tests, des indicateurs et un propriétaire. La ligne précise l’acteur admissible, l’authentification, l’enveloppe d’information, la mémoire, l’outil étroit, l’identité agissante, les ressources autorisées, le plafond d’action, la validation, les limites opérationnelles, le refus, les scénarios d’évaluation et la destination d’escalade.

Prenons un assistant interne destiné au personnel d’un service clients. Il aide à retrouver un dossier, à préparer une réponse et, séparément, à envoyer une réponse déjà validée. La même interface conversationnelle peut desservir ces trois capacités sans leur donner les mêmes données, identifiants, outils ou droits. Les décisions sur les compensations, les droits du client et les questions réglementaires restent hors de ce service et suivent un processus gouverné distinct.

Quelles preuves faut-il avant la mise en service et pendant l’exploitation ?

La mise en service exige des preuves que les demandes permises réussissent et que les demandes hors limite sont refusées dans des conditions proches de l’exploitation. Les essais couvrent les tâches normales, l’accès au compte d’autrui, l’outil non autorisé, la preuve périmée, le contenu récupéré empoisonné, la donnée interdite, le contournement de validation, le changement de paramètres, la répétition d’une action, la panne de dépendance, l’exfiltration et les chaînes incontrôlées.

Les journaux doivent permettre de reconstruire qui a demandé quoi, quelle capacité et quelle politique s’appliquaient, quelles classes de sources et d’outils ont été utilisées, quelles décisions d’autorisation et de validation ont eu lieu, quel résultat a suivi et quelles versions étaient actives. Cette traçabilité ne justifie ni la conservation de secrets ni l’accumulation illimitée de contexte sensible; son contenu, ses accès et sa durée suivent les exigences de confidentialité et d’archivage.

• Surveiller les usages inattendus d’outils, refus répétés, erreurs d’autorisation et validations modifiées.
• Observer les séquences d’action anormales, la dérive, les pannes, la latence et les ressources consommées par capacité.
• Nommer séparément les responsables du service, des droits d’accès, des transmissions métier et des incidents.
• Donner à ces responsables l’autorité de suspendre, corriger ou retirer une capacité.
• Rouvrir les tests touchés après un changement matériel de modèle, prompt, récupération, mémoire, outil, droit, politique, donnée, fournisseur ou contexte d’exploitation.

Commencez par la capacité utile la plus petite et n’élargissez son autorité qu’au moyen d’un changement examiné, jamais par une simple retouche du prompt. Associez dès la conception les responsables de la sécurité, de l’identité, de la protection des données, de l’archivage, du risque et du service lorsque des informations sensibles, une mémoire persistante, des accès privilégiés ou des effets externes sont concernés. Les jugements juridiques, réglementaires et autres décisions à fort enjeu reviennent à des spécialistes qualifiés dans un processus distinct.