Le savoir a une frontière d’accès

Une citation renvoie vers un contrat, mais celui-ci appartient à un autre client. Dans cet exemple, un assistant de support cherche une date de renouvellement dans les dossiers de deux clients. Il trouve un contrat similaire appartenant à l’autre client, l’ajoute au contexte et répond avec assurance.

Il ne s’agit pas d’un incident rapporté. La citation donne à la réponse une apparence de prudence tout en révélant les données du mauvais client. Le défaut s’est produit avant la rédaction de la phrase.

Une conférence retranscrite sur l’emplacement du savoir utilisé par l’IA avance un principe d’architecture utile : les connaissances qui varient selon l’utilisateur doivent passer par une recherche contrôlée par les accès. Les conseils de Microsoft sur l’accès au niveau des documents décrivent des vérifications de permission associées aux documents indexés et à l’identité de la requête. La règle générale est plus simple que tout produit de recherche : seul le contenu autorisé doit parvenir au parcours de réponse.

Placez la frontière avant la réponse

Un prompt peut demander à l’assistant d’être concis, de citer ses sources ou de solliciter une précision. Il ne peut pas dire sans risque « n’utilise pas les documents du mauvais client » tout en transmettant ces documents au modèle. Si la recherche a déjà franchi la frontière, on demande au prompt de réparer un défaut d’accès.

L’application doit établir l’identité de la personne. La requête de recherche doit porter le périmètre associé : compte, rôle ou autorisation documentaire selon le domaine. Les résultats candidats doivent être filtrés ou autorisés avant que leur texte ne soit transmis au modèle. Si une réponse peut déclencher une écriture, le parcours d’écriture doit revérifier les autorisations sur la fiche cible.

Ce n’est pas seulement un problème de recherche vectorielle. La recherche par mots-clés, les résumés en cache, la mémoire de conversation et les résultats d’outils peuvent aussi contenir des données privées. Un résumé dérivé du document d’un client reste privé même si le texte source a été raccourci.

Notre guide de connexion des outils métier demande qui détient chaque fiche et quel système fait autorité. Pour un assistant, ajoutez cette question : qui a le droit de savoir que cette fiche existe ?

Un petit exemple révèle l’ordre des opérations

Imaginons un index de quatre documents : deux articles d’aide publics, un contrat du compte A et un contrat du compte B. Une personne du compte A demande les conditions de facturation. La correspondance sémantique la plus proche est le contrat du compte B.

Une recherche sans périmètre le renvoie. Une consigne ultérieure comme « répondez uniquement pour le compte A » ne peut garantir la sécurité : le contenu est déjà entré dans le contexte du modèle. Une recherche limitée écarte le document du compte B avant le classement ou ne renvoie que les documents autorisés. L’assistant peut alors répondre à partir du contrat du compte A ou indiquer qu’il ne dispose pas de la source nécessaire.

La mise en œuvre précise dépend de la plateforme. Le modèle de filtrage de sécurité d’Azure AI Search associe des identifiants de groupe aux documents et applique un filtre à chaque requête. La documentation avertit également que masquer un champ d’autorisation dans la réponse ne constitue pas un contrôle d’accès. Le mécanisme applicable est le filtre, associé à l’identité de la personne qui appelle le service.

Cette distinction compte lorsque les droits changent. Si une personne perd un accès, un ancien cache ou un index périmé ne doit pas continuer à fournir le document. L’équipe a besoin d’un processus de mise à jour défini et de tests de révocation, pas seulement de tests d’octroi initial. Si le service de recherche ne peut pas respecter le modèle d’accès de la source, copier cette source dans l’index peut être une mauvaise architecture.

L’autorisation et la pertinence sont deux tests distincts

Un document autorisé peut être hors sujet ou obsolète. Une réponse exacte peut être non autorisée. Ce sont des modes d’échec différents, à évaluer séparément.

Testez d’abord la frontière : une personne d’un compte peut-elle récupérer, citer ou déduire le contenu privé d’un autre ? Incluez les questions directes, les paraphrases et les résumés. Testez ensuite la qualité de réponse dans le périmètre autorisé : l’assistant choisit-il la politique actuelle et reconnaît-il l’absence de preuve ? Les recommandations de Microsoft sur le RAG conseillent explicitement de contrôler l’accès au moment de la recherche et de traiter le contenu récupéré comme non fiable.

Cela a un coût. L’indexation tenant compte des autorisations exige des métadonnées, la correspondance des identités et un traitement des révocations. Certains résultats de recherche disparaîtront après filtrage. C’est normal lorsque la personne ne dispose pas de preuves. Combler le vide par une supposition assurée transformerait une mesure de protection en problème d’exactitude.

Cette frontière met aussi à l’épreuve la règle sur les exceptions d’automation : que doit-il se passer si l’ensemble des résultats autorisés est vide ? Une bonne conception peut répondre « Je ne peux pas accéder à une source pour cette réponse » et proposer la bonne voie d’escalade. Elle ne doit ni élargir la recherche à un autre compte, ni réutiliser une ancienne réponse, ni déduire des informations privées du titre d’un document. Traitez ce résultat vide comme un état normal et vérifiable du workflow. L’autorisation fait partie de l’exactitude ; ce n’est pas un cas particulier à corriger après le lancement.

Un assistant utile ne connaît pas tout ce que contient l’entreprise. Il trouve les bonnes preuves dans le périmètre autorisé et indique quand cette limite ne permet pas de répondre.