Repenser le contrôle d'accès pour le RAG avec Amazon Quick et Amazon Bedrock
Les organisations adoptent massivement la génération augmentée par récupération (RAG) pour exploiter leurs sources de connaissances internes, comme Microsoft SharePoint, Google Drive ou Atlassian Confluence. Or ces sources sont soumises à des structures de permissions complexes, et garantir que les réponses d'une IA respectent ces droits reste l'un des défis les plus difficiles de l'IA d'entreprise. Amazon Web Services affirme y répondre avec Amazon Quick et Amazon Bedrock Knowledge Bases grâce à un contrôle des listes de contrôle d'accès (ACL) en temps réel. Au moment de la requête, le système interroge directement la source faisant autorité pour vérifier les droits de l'utilisateur. Cette vérification vient s'ajouter au filtrage des ACL déjà appliqué avant la récupération, et s'appuie sur une architecture hybride qui combine la performance de la recherche sémantique et une sécurité vérifiée en direct.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de AWS ML Blog. Lire l'article original →
L'enjeu est considérable pour les entreprises. Prenons le cas d'un responsable de site SharePoint qui crée une base de connaissances utilisée par des équipes de plusieurs départements via un assistant IA : chaque collaborateur ne doit recevoir que des réponses issues de documents qu'il est autorisé à consulter. Un seul document non autorisé cité dans une réponse pourrait exposer une stratégie confidentielle, des données financières non publiées ou des informations sensibles de ressources humaines. Les organisations veulent démocratiser l'accès aux analyses produites par l'IA sans affaiblir leur posture de sécurité existante. Le contrôle en temps réel supprime le risque de s'appuyer sur des permissions périmées ou mal traduites, et permet de déployer ces assistants à plus grande échelle avec davantage de confiance.
L'approche dominante jusqu'ici consiste à répliquer puis filtrer. Un connecteur récupère les ACL lors d'une synchronisation périodique, les stocke comme attributs dans un index, puis associe l'utilisateur connecté à ces attributs pour filtrer les résultats. AWS identifie trois faiblesses fondamentales. D'abord, le système d'IA n'est pas la source de vérité : les connecteurs doivent reproduire fidèlement la logique de permissions propre à chaque source, avec ses hiérarchies d'héritage, ses appartenances à des groupes, ses politiques d'accès conditionnel et ses règles de refus, ce qui est source d'erreurs sur des dizaines de connecteurs. Ensuite, les permissions deviennent obsolètes : les ACL ne reflètent que l'état de la dernière synchronisation, et certaines sources comme Confluence n'émettent pas d'événement lors d'un changement d'appartenance à un groupe. Entre deux synchronisations, un utilisateur dont l'accès a été révoqué peut donc encore recevoir des réponses tirées de documents qu'il ne devrait plus voir. Enfin, les sources évoluent : une nouvelle fonction de permission dans SharePoint ou une modification du modèle de partage de Google Drive peut créer des trous dans la logique de correspondance, exposant du contenu jusqu'à la mise à jour du connecteur. En interrogeant l'autorité d'origine à chaque requête, AWS entend contourner ces trois problèmes à la racine.
Les entreprises européennes déployant des assistants RAG sur SharePoint ou Confluence peuvent mieux respecter leurs exigences de confidentialité des données, sans régulation ni acteur européen directement concernés.