Comment Slack AI s’est construit sur la base de données privées et sécurisées

Note de l’éditeur : cet article de blog a d’abord été publié sur le blog des ingénieurs Slack.

Chez Slack, nous avons toujours été des technologistes prudents : à chaque fois que nous nous lançons dans l’exploitation d’une nouvelle catégorie d’infrastructure, un cadre rigoureux est mis en place. Cette approche est la nôtre depuis le lancement, en 2016, de nos fonctionnalités reposant sur le machine learning (ML), et nous avons mis en place un processus fiable ainsi qu’une équipe compétente dans ce domaine.

Malgré cela, nous sommes stupéfaits des progrès réalisés l’année dernière par les grands modèles de langage (LLM) disponibles sur le marché. Plus encore, par les solutions qu’ils proposent face aux problèmes majeurs que rencontrent nos utilisateurs. Trop d’informations à lire ? Des recherches trop complexes ? Plus maintenant : 90 % de nos utilisateurs qui ont opté pour l’IA rapportent une meilleure productivité que ceux ne l’ayant pas adoptée.

Cependant, comme avec toutes les nouvelles technologies, lancer un produit embarquant l’IA ne peut se faire sans une mise en œuvre qui répond aux normes strictes de Slack en matière de gestion des données client. Nous avons donc décidé de créer des fonctionnalités avec IA non seulement formidables, mais également fiables.

Le secteur des modèles génératifs est encore jeune, et il se concentre pour la majeure partie sur la recherche plutôt que sur les entreprises et leurs clients. Lorsque nous avons commencé à développer l’architecture de la nouvelle fonctionnalité Slack AI, les schémas de sécurité et de confidentialité adaptés aux entreprises étaient rares.

C’est pourquoi nous nous sommes appuyés sur des principes fondamentaux pour créer Slack AI, en commençant par nos propres exigences : conserver le niveau de sécurité et de conformité de nos solutions existantes ainsi que nos principes de confidentialité tels que « Les données client sont inaliénables ». Ensuite, notre équipe a tiré parti de l’IA générative pour élaborer un nouvel ensemble de principes spécifiques à Slack AI pour nous orienter.

• Les données client ne quittent jamais Slack.
• Les données client ne sont pas utilisées pour entraîner les grands modèles de langage (LLM).
• Slack AI exploite uniquement des données déjà visibles par l’utilisateur.
• Slack AI répond à toutes les exigences de Slack en matière de sécurité et de conformité pour les entreprises.

Ces principes ont à la fois clarifié et complexifié la conception de notre architecture : nous vous expliquons le rôle qu’a joué chacun d’eux dans l’élaboration de la version actuelle de Slack AI.

Les données client ne quittent jamais Slack

La première décision que nous avons dû prendre (et peut-être la plus importante de toutes) a été de savoir comment utiliser un modèle de fondation de haut niveau sans jamais permettre aux données client de quitter les VPC contrôlés par Slack. Dans le secteur des modèles génératifs, la plupart des clients des modèles de fondation appelaient directement les services hébergés, et peu d’autres options étaient disponibles.

Nous savions que cette approche ne nous conviendrait pas, car les attentes de Slack et de ses clients en matière de propriété des données sont très élevées. Slack est homologué FedRAMP Moderate, une certification qui s’accompagne d’exigences de conformité spécifiques interdisant notamment l’envoi de données client hors de notre espace de confiance. Nous voulions nous assurer que nos données ne quittent pas notre cloud privé virtuel AWS (VPC) afin de garantir qu’aucun tiers ne puisse les conserver ou les utiliser à des fins d’entraînement.

Nous avons donc recherché des solutions innovantes qui nous permettraient d’héberger un modèle de fondation sur notre propre infrastructure. Toutefois, la plupart de ces modèles sont propriétaires, leurs créateurs ne souhaitant pas que leurs utilisateurs les déploient sur leur propre matériel.

Heureusement, AWS a proposé une offre qui lui a permis de devenir un intermédiaire de confiance entre le fournisseur du modèle de fondation et son client : AWS SageMaker. Ce produit nous a aidés à héberger et à déployer des grands modèles de langage (LLM) propriétaires sur un VPC d’entiercement, et nous avons ainsi pu contrôler le cycle de vie de nos données client et en interdire l’accès au fournisseur du modèle. Lisez cet article du blog AWS pour en savoir plus sur la façon dont Slack utilise SageMaker.

Nous avions trouvé la solution idéale : l’accès à un modèle de fondation de pointe hébergé dans notre propre VPC AWS, qui protégeait nos données client.

Les données client ne sont pas utilisées pour entraîner les grands modèles de langage (LLM)

La décision suivante était tout aussi cruciale : nous avons choisi d’utiliser des modèles standard plutôt que d’entraîner ou d’affiner des modèles. Nous avions mis en place nos principes de confidentialité dès le début de l’utilisation de modèles de machine learning plus classiques dans Slack, comme ceux qui classent les résultats de recherche. Ces principes interdisent notamment la fuite de données entre différents espaces de travail et donnent aux clients le choix vis-à-vis de ces pratiques. Nous avons admis que compte tenu de l’émergence récente du secteur et de la technologie, nous ne pouvions pas offrir suffisamment de garanties quant à ces pratiques si nous entraînions des modèles d’IA générative avec les données client de Slack.

Nous avons donc opté pour des modèles standard sans état, utilisés avec la génération augmentée de récupération (RAG). Ce processus fournit tout le contexte nécessaire pour effectuer la tâche propre à chaque demande, afin que le modèle ne conserve pas de données. Par exemple, pour résumer un canal, une demande contenant les messages à résumer ainsi que des instructions sur la façon d’effectuer cette tâche est envoyée au LLM. La nature sans état de la RAG présente des avantages non négligeables pour la confidentialité, mais aussi pour le produit : l’ensemble des résultats de Slack AI provient de la base de connaissances de l’entreprise, et non pas de l’Internet public, ce qui rend les résultats plus précis et plus pertinents. Le client profite de l’intégration de ses ensembles de données propriétaires et distincts sans craindre leur conservation par le modèle.

L’utilisation de la RAG peut réduire les ensembles de modèles pouvant être utilisés, car leurs fenêtres de contexte doivent être suffisamment importantes pour contenir toutes les données devant être utilisées dans le cadre de la tâche à effectuer. En outre, plus le LLM reçoit de contexte, plus l’exécution de la demande sera longue, puisque le modèle doit traiter davantage de données. La création d’un résumé de tous les messages d’un canal est donc une tâche impliquant une quantité de données colossale.

Ce volume a posé un autre problème : il fallait trouver un modèle de haut niveau, avec une fenêtre de contexte suffisamment importante et une latence relativement faible. Nous avons évalué plusieurs modèles et choisi celui qui était le mieux adapté à nos premiers cas d’utilisation, la création de résumés et la recherche. Il restait cependant beaucoup de travail à accomplir pour l’améliorer, et nous avons entamé un long travail d’affinage des demandes et de création de connexions entre les modèles de machine learning plus classiques et les modèles génératifs en vue d’obtenir de meilleurs résultats.

La RAG devient plus facile et plus rapide à chaque itération de modèles ; les fenêtres de contexte s’élargissent à mesure que la capacité des modèles à synthétiser des données au sein d’une grande fenêtre de contexte s’améliore. Nous sommes persuadés que cette approche nous permettra d’atteindre la qualité que nous visons tout en nous aidant à assurer la protection de nos données client.

Slack AI exploite uniquement des données déjà visibles par l’utilisateur

Slack AI voit uniquement les données visibles par l’utilisateur à l’origine de la demande : c’est là un autre de nos principes clés. Par exemple, la fonctionnalité de recherche de Slack AI ne présentera jamais des résultats différents de ceux d’une recherche standard, et les résumés ne reprendront jamais de contenu autrement invisible pour l’utilisateur dans les canaux.

Pour ce faire, nous utilisons la liste de contrôle d’accès de l’utilisateur à l’origine de la demande lors de la récupération des données à résumer ou à rechercher, et recourons à nos bibliothèques existantes qui récupèrent les données à afficher dans le canal ou sur la page des résultats de recherche.

D’un point de vue technique, ce processus est relativement facile à mettre en œuvre, mais il fallait le proposer sous forme d’un choix explicite. La meilleure manière de procéder était de réutiliser les ensembles de fonctionnalités principales de Slack tout en y ajoutant des caractéristiques propres à l’IA.

Il est important de souligner également que seul l’utilisateur qui fait appel à Slack AI peut voir les résultats générés par IA, ce qui renforce la confiance accordée à Slack en tant que partenaire d’IA fiable. La fonctionnalité a uniquement accès aux données visibles par son utilisateur, et seul cet utilisateur peut voir les résultats demandés.

Slack AI répond à toutes les exigences de Slack en matière de sécurité et de conformité pour les entreprises

Sans Slack, Slack AI n’existerait pas : nous avons donc veillé à y intégrer l’ensemble de nos solutions de conformité et de sécurité pour les entreprises. Nous appliquons le principe de moindres données, en stockant uniquement les données indispensables pour réaliser la tâche et sans dépasser la durée nécessaire.

Parfois, il n’y a aucune donnée indispensable : lorsque c’est possible, les résultats de Slack AI sont éphémères. Les résumés de conversations et les recherches de réponses génèrent des réponses ponctuelles non stockées sur disque.

Là où cette approche n’était pas possible, nous avons réutilisé au maximum l’infrastructure de conformité existante de Slack et avons créé de nouveaux supports dès que nécessaire. Bon nombre de nos solutions de conformité intègrent notre infrastructure existante, comme le produit de gestion des clés de chiffrement ou celui de résidence des données à l’international. Pour d’autres, nous avons conçu des supports spéciaux qui garantissent que le contenu dérivé, tel que les résumés, est conscient des messages qu’il a reçus. Par exemple, si un message est masqué en raison de la protection contre la perte des données (DLP), tous les résumés dérivés de ce message sont invalidés. La DLP et les autres contrôles administratifs en sont ainsi renforcés dans Slack AI : déjà appliqués sur le contenu des messages de Slack, ils le sont également sur les résultats de Slack AI.

Le chemin parcouru a été long ! Et je ne vous ai même pas parlé de la création de nos demandes, de l’évaluation de nos modèles ou encore de la gestion des pics de demandes : ce sera pour un prochain article. Néanmoins, la sécurité et la confidentialité sont de bons points de départ : nous tenons à ce que nos clients sachent que nous prenons la sécurité de leurs données très au sérieux, et que nous les protégeons à chaque étape.