Contexte encadré et écritures des agents d’IA en entreprise

Un agent d’IA interne ne devrait pas décider qui peut consulter de l’information ni autoriser une modification ayant des conséquences significatives. Placez deux contrôles à l’extérieur du modèle : appliquez les autorisations avant la récupération afin que seul le contenu autorisé entre dans son contexte, puis acheminez les écritures ayant des conséquences significatives vers un plan de modification proposé qu’une personne examine et approuve explicitement avant son exécution.

Ce modèle ne remplace pas un système fiable de gestion des identités, des autorisations ou des changements. Il attribue au modèle un rôle délimité : rechercher dans les limites autorisées, synthétiser le contenu qu’il est autorisé à recevoir et préparer des modifications concrètes que des personnes responsables peuvent évaluer.

Le contexte désigne le texte, les enregistrements, les résultats d’outils et les instructions accessibles à un modèle de langage pour une tâche. Une fois qu’un contenu se trouve dans le contexte, le modèle peut l’utiliser dans une réponse ou une action proposée. L’accès doit donc être déterminé avant que le modèle ne voie ce contenu, et non laissé au modèle pour qu’il l’infère à partir des circonstances sociales.

Utiliser un point de contrôle des politiques pour les lectures et une validation humaine pour les écritures

Un flux pratique se présente ainsi :

Demande de l’utilisateur
  → contexte de demande authentifié
  → point d’application des politiques
  → récupération filtrée selon les autorisations
  → contexte de travail de l’agent
  → plan de modification proposé
  → examen humain et approbation explicite
  → exécuteur d’écriture à portée limitée
  → journal d’audit

Un point d’application des politiques est un service ou une couche qui applique des règles d’autorisation à la frontière d’un système protégé. Il reçoit un contexte de demande authentifié — par exemple, l’utilisateur ou l’utilisatrice à l’origine de la demande, son rôle ou ses attributs, l’espace de travail ou le projet concerné et l’opération demandée — et ne renvoie que les enregistrements et les champs permis par la politique.

Le choix de conception important est que l’agent utilise une interface de récupération qui a déjà appliqué ces vérifications. Il ne devrait pas recevoir un vaste corpus et classer lui-même les passages pouvant être partagés. De même, il ne devrait pas disposer d’un outil qui revient en pratique à dire : « récupérez n’importe quoi, puis décidez si vous pouvez le divulguer ». Le modèle peut aider à interpréter une demande, mais il ne devrait pas établir l’admissibilité à des données protégées.

Pour les écritures, l’agent produit une proposition structurée plutôt que d’appeler directement un outil général de modification. Une personne examine les changements demandés, les enregistrements touchés, les opérations, la justification, les hypothèses et les résultats de validation, puis effectue une action d’approbation distincte. Un exécuteur déterministe n’effectue que l’opération approuvée et délimitée.

Ces contrôles répondent à des risques différents. Les contrôles de lecture limitent ce que l’agent connaît dans une interaction. Les contrôles d’écriture rendent les modifications ayant des conséquences significatives visibles et attribuables avant qu’elles ne prennent effet.

Considérer l’autorisation comme partie intégrante de la construction du contexte

Les personnes s’appuient souvent sur le contexte social pour décider si elles doivent répéter une information : qui la demande, où se déroule la conversation, qui d’autre peut la voir et si le contenu est privilégié ou sensible. Les agents n’appliquent pas de façon fiable ces jugements humains. De l’information privilégiée peut donc se retrouver dans des contextes où elle ne devrait pas être.

La réponse architecturale ne consiste pas simplement à donner une instruction plus ferme au modèle. Rendez le constructeur de contexte sensible aux autorisations. Un constructeur de contexte est le composant qui sélectionne et prépare le contenu pour le modèle. Il ne devrait récupérer que le contenu autorisé par la couche de politiques pour la demande précise.

Lier la récupération à des entrées explicites

Les décisions d’autorisation devraient être explicites et structurées. À tout le moins, liez la récupération aux éléments suivants :

• Mandant : L’identité humaine ou de service au nom de laquelle la demande est exécutée.
• Tenant ou espace de travail : La limite organisationnelle pertinente pour la demande.
• Portée de la conversation ou du canal : L’endroit où le résultat apparaîtra et les personnes qui peuvent le recevoir.
• Ressource et champ : Le document, l’enregistrement, la pièce jointe ou l’attribut individuel demandé.
• Opération : Habituellement read pour la récupération, plutôt qu’une autorisation générale imprécise.
• Objectif ou contexte de tâche, lorsqu’il est pris en charge : Une raison d’accès délimitée que la politique peut évaluer de manière cohérente.

L’agent peut formuler des requêtes de recherche, mais le service de récupération devrait appliquer ces entrées avant de renvoyer des résultats candidats. Les index sémantiques, les caches, les dépôts de résumés et les dépôts d’embeddings doivent relever de la même frontière d’autorisation. Autrement, un système source protégé pourrait être compromis par un dépôt dérivé moins protégé.

Une règle utile : chaque voie par laquelle du texte peut entrer dans le contexte du modèle doit avoir un mécanisme d’autorisation. Cela comprend les consultations directes, les résultats de recherche, les extraits, l’historique des conversations, les fichiers téléversés, les résultats mis en cache, les résumés générés et les sorties d’outils.

Préserver la provenance et la portée de diffusion

Lorsque cela est possible, associez à chaque élément récupéré une provenance lisible par machine : son identifiant de ressource, son système source, la décision de politique ou la portée qui a permis son accès et le contexte de destinataires pour lequel il a été récupéré. Ces métadonnées n’ont pas à être affichées à l’utilisateur final, mais elles peuvent aider l’orchestrateur à éviter de mélanger du contenu récupéré pour une portée avec du contenu destiné à une autre.

Par exemple, une demande formulée dans un canal partagé devrait être évaluée en fonction de l’audience autorisée de ce canal, et non seulement de l’identité de la personne qui a saisi l’invite. Récupérer du contenu pour une personne demandeuse et le publier dans un contexte plus large franchit une seconde limite de divulgation. La couche de politiques devrait évaluer le contexte de diffusion, ou l’application devrait refuser de placer des résultats sensibles dans une portée qu’elle ne peut pas représenter.

Gérer les résumés et la mémoire comme des données dérivées

Les résumés, les faits extraits et la mémoire maintenue par l’agent peuvent sembler moins sensibles que leurs sources, mais ils peuvent conserver du contenu sensible tout en rendant son origine moins visible. Traitez les connaissances dérivées comme des données régies :

1. Consignez les sources et les portées utilisées pour les créer.
2. Attribuez une règle de visibilité qui ne soit pas plus large que les règles applicables à leurs données d’entrée, à moins qu’un processus autorisé ne modifie délibérément cette classification.
3. Appliquez de nouveau les vérifications d’autorisation lors de la récupération de l’artefact dérivé.
4. Faites expirer, recalculez ou examinez les résumés stockés lorsque les autorisations des sources changent.

Cela peut réduire le taux de rappel lorsque les métadonnées d’autorisation sont incomplètes ou que les systèmes utilisent des modèles d’autorisation incompatibles. Ce compromis est réel : l’utilité d’un agent partagé ne peut être aussi large que l’information qu’il peut recevoir légitimement. Améliorer les autorisations et la taxonomie des ressources est généralement préférable à permettre au modèle de combler les lacunes par intuition.

Faire des écritures des modifications proposées, et non des décisions du modèle

Une écriture ayant des conséquences significatives est une modification qui change un enregistrement faisant autorité, touche le travail d’une autre personne, modifie l’accès, envoie une communication externe ou produit un effet opérationnel significatif. Ce seuil devrait être défini à l’extérieur du modèle.

Dans ce modèle, l’agent peut analyser les données et préparer un plan, tandis qu’une personne décide si l’action devrait avoir lieu. Le plan devrait être suffisamment structuré pour que l’examen porte sur un diff concret plutôt que sur un récit persuasif.

Inclure l’information nécessaire à l’examen

Un plan de modification proposé devrait comprendre les éléments suivants :

Pour les travaux en lot, les personnes chargées de l’examen ont besoin à la fois d’une vue agrégée et de détails. Un résumé peut présenter les comptes par opération, les catégories touchées et les exceptions, tandis que les modifications individuelles et des échantillons représentatifs restent consultables. Un plan qui dit seulement « mettre à jour 500 enregistrements » demande de la confiance plutôt que de permettre un véritable examen.

L’exécuteur d’écriture devrait accepter un plan approuvé immuable, et non des instructions non structurées du modèle. Il devrait vérifier que l’approbation s’applique à la version soumise du plan, qu’elle n’a pas expiré et qu’elle couvre chaque opération. Il devrait aussi revérifier les conditions préalables pertinentes avant chaque modification. Si un enregistrement a changé depuis l’examen, l’exécuteur devrait interrompre cet élément ou exiger une nouvelle proposition plutôt que de deviner comment fusionner les changements.

Appliquer la séparation par les identifiants et les interfaces

La séparation devrait exister dans les identifiants d’accès et les interfaces, et pas seulement comme convention d’interface utilisateur. L’agent peut recevoir la capacité de créer des propositions sans disposer d’un identifiant permanent permettant des modifications en production. Le service d’exécution détient la capacité d’écriture et ne l’utilise qu’après avoir validé un artefact d’approbation explicite.

Cette frontière est testable :

• L’agent peut-il récupérer un enregistrement protégé sans mandant autorisé ni portée de destinataires autorisée? Il ne le devrait pas.
• L’agent peut-il modifier un système faisant autorité en utilisant seulement ses identifiants d’exécution? Il ne le devrait pas.
• Un plan approuvé peut-il être modifié entre l’examen et l’exécution? L’exécuteur devrait le refuser.
• Une personne peut-elle approuver une intention générale sans voir le diff réel? Le flux de travail ne devrait pas considérer cela comme une approbation de modifications précises.

Faire de l’examen un contrôle réel

L’approbation humaine n’est pas automatiquement protectrice. À mesure que la confiance envers un agent augmente, les personnes chargées de l’examen peuvent commencer à approuver mécaniquement les modifications proposées. L’examen n’est significatif que lorsque le flux de travail aide une personne à exercer son jugement.

Voici des recommandations pour éviter les approbations superficielles :

• Présentez clairement les modifications significatives. Affichez les valeurs avant et après, et pas seulement une description en prose.
• Faites ressortir l’incertitude et les exceptions. Ne dissimulez pas les éléments à faible niveau de confiance dans un lot par ailleurs réussi.
• Orientez selon le risque. Appliquez un examen plus attentif aux modifications ayant des répercussions plus élevées, inhabituellement volumineuses ou sensibles aux politiques.
• Limitez les lots. Des lots plus petits et cohérents facilitent la détection d’erreurs systématiques.
• Exigez une reconnaissance active des risques définis. L’approbation peut exiger la confirmation que les suppressions signalées ou les modifications liées aux accès ont été examinées.
• Échantillonnez et auditez les modifications effectuées. Vérifiez si les plans approuvés étaient exacts et si les personnes chargées de l’examen ignorent les avertissements.
• Consignez les motifs de refus. Utilisez-les pour améliorer les instructions, la validation ou la qualité des données, sans traiter les commentaires comme une autorisation automatique.

Ces mesures ajoutent de la friction, et un schéma de proposition rigoureux peut ralentir les tâches simples. Toutefois, les écritures autonomes ayant des conséquences significatives éliminent le moment où une personne responsable peut examiner et remettre en question l’interprétation de l’agent. Les équipes peuvent ajuster l’examen selon les répercussions, mais devraient le faire au moyen de politiques explicites plutôt que de laisser des invites ignorées et des clics habituels s’installer progressivement.

Liste de vérification de la mise en œuvre

Limite de lecture

• [ ] Chaque demande est liée à un mandant authentifié et à une portée définie de destinataires ou de conversation.
• [ ] La récupération applique les autorisations avant de renvoyer à l’agent des documents, enregistrements, champs, extraits ou résultats d’outils.
• [ ] Les index de recherche, les caches, l’historique des conversations et les résumés suivent des vérifications d’autorisation équivalentes.
• [ ] L’agent ne peut pas élargir l’accès en sélectionnant une autre identité, un autre espace de travail ou une autre portée de destinataires.
• [ ] Les éléments récupérés conservent leurs métadonnées de provenance et de portée durant l’assemblage du contexte.
• [ ] La mémoire dérivée et les résumés sont gérés comme des données lorsqu’ils sont récupérés ultérieurement.
• [ ] Le contenu refusé par les politiques n’est pas envoyé au modèle à des fins de caviardage ou de jugement.

Limite d’écriture

• [ ] Les catégories d’écritures ayant des conséquences significatives sont définies à l’extérieur du modèle.
• [ ] L’agent produit un plan de modification proposé et versionné, avec des diffs explicites, une portée, des conditions préalables, des exceptions et une validation.
• [ ] L’agent ne possède pas d’identifiants permettant des modifications directes en production.
• [ ] Une personne approuve la version exacte du plan au moyen d’une action distincte.
• [ ] L’exécuteur vérifie l’approbation, la portée, l’expiration et les conditions préalables de l’état actuel avant toute modification.
• [ ] Les journaux d’exécution relient la demande, la base récupérée, le plan, la personne approbatrice, le résultat et les échecs.
• [ ] Les écrans d’examen font ressortir les modifications à fort impact et l’incertitude plutôt que d’optimiser uniquement l’approbation rapide.

Le principe central est simple : laissez l’agent raisonner et proposer à l’intérieur de limites établies par des systèmes et des personnes responsables. L’autorisation appartient à la frontière de récupération, où l’information protégée est sélectionnée. La responsabilité des modifications ayant des conséquences significatives appartient à la frontière d’approbation, où une personne peut examiner un plan concret avant que quoi que ce soit ne change.