Les LLM ne savent pas ce qui est confidentiel
Les grands modèles de langage n’ont aucun concept de sensibilité des données. Donnez à un LLM un mélange de textes marketing publics et de procès-verbaux restreints du conseil d’administration, et il tissera joyeusement les deux dans une réponse. Il ne sait pas que l’un est partageable avec le monde entier et que l’autre est limité à trois dirigeants nommés.
C’est acceptable pour les assistants IA personnels. C’est un problème sérieux pour les workflows IA d’entreprise.
Quand les organisations connectent des bases de connaissances à l’IA — des agents de support client puisant dans la documentation interne, des assistants commerciaux référençant les stratégies de prix, des bots RH répondant aux questions de politique — chaque contenu récupéré devient une sortie LLM potentielle. Sans classification des données, il n’y a aucune frontière entre ce qu’une IA peut accéder et ce qu’elle devrait accéder.
La plupart des plateformes IA ignorent entièrement cela. Elles se connectent à vos sources de données et récupèrent tout ce qui est sémantiquement pertinent. La pertinence n’est pas la même chose que l’autorisation.
Les quatre niveaux de sensibilité
JieGou implémente un système de classification des données à quatre niveaux sur chaque base de connaissances, aligné avec les cadres de sécurité de l’information largement adoptés :
Public (Vert)
Contenu partageable avec tout le monde — clients, partenaires, grand public. Matériaux marketing, documentation publique, articles de blog publiés. Aucune restriction de récupération.
Interne (Bleu)
Contenu pour consommation à l’échelle de l’entreprise. Documentation de processus internes, manuels d’équipe, annonces générales. Tout utilisateur authentifié au sein de l’organisation peut y accéder via les workflows IA.
Confidentiel (Ambre)
Contenu restreint à des départements ou équipes spécifiques. Projections financières, analyses concurrentielles, feuilles de route produit, enquêtes RH. Seuls les utilisateurs avec un accès départemental correspondant peuvent récupérer des chunks des bases de connaissances Confidentielles.
Restreint (Rouge)
Contenu limité à des individus nommés. Matériaux du conseil d’administration, documents de fusions-acquisitions, données de rémunération des dirigeants, matériaux sous scellé juridique. L’accès est explicitement accordé par utilisateur. C’est le niveau de sensibilité le plus élevé, et la récupération exige à la fois la vérification de l’identité de l’utilisateur et l’appartenance explicite à la liste d’accès.
Application à la couche de récupération RAG
Voici la décision de conception critique : JieGou applique les étiquettes de sensibilité avant que le contenu n’atteigne le LLM, pas après.
La plupart des plateformes qui tentent la gouvernance des données l’appliquent comme un filtre de post-traitement — le LLM génère une réponse en utilisant tout le contexte disponible, puis un filtre vérifie si la sortie contient des informations sensibles. C’est fondamentalement défaillant. Une fois que le contenu restreint entre dans la fenêtre de contexte du LLM, il influence la réponse même si des phrases spécifiques sont supprimées. Le modèle a déjà « vu » les données.
L’approche de JieGou est différente. Quand une requête RAG s’exécute :
- L’identité de l’utilisateur est résolue — le rôle de l’utilisateur demandeur, son département et ses autorisations d’accès explicites sont chargés
- Les étiquettes de sensibilité des bases de connaissances sont vérifiées — chaque KB connectée a un niveau de classification
- Le filtrage pré-récupération se produit — les chunks des bases de connaissances au-dessus du niveau d’habilitation de l’utilisateur sont exclus de la recherche vectorielle entièrement
- Seul le contenu autorisé entre dans la fenêtre de contexte — le LLM ne voit jamais de données restreintes qu’il ne devrait pas voir
Cela signifie qu’un agent de support interrogeant la base de connaissances récupérera le contenu Public et Interne mais ne verra jamais les documents RH Confidentiels ou les matériaux Restreints du conseil — même si ces documents sont sémantiquement pertinents pour la requête.
Piste d’audit pour le filtrage de sensibilité
Chaque événement de filtrage de sensibilité est enregistré dans la piste d’audit immuable de JieGou :
- Quel utilisateur a initié la requête
- Quelles bases de connaissances ont été filtrées et pourquoi
- Le niveau de sensibilité qui a déclenché l’exclusion
- Horodatage et identifiant de corrélation de requête
C’est important pour la conformité. Quand les auditeurs demandent « comment vous assurez-vous que les workflows IA n’exposent pas de données restreintes ? », la réponse n’est pas un document de politique — c’est un journal interrogeable de chaque action d’application.
Comment les autres plateformes gèrent cela
| Capacité | Plateforme IA typique | JieGou |
|---|---|---|
| Étiquettes de classification des données | Aucune | 4 niveaux (Public, Interne, Confidentiel, Restreint) |
| Sensibilité par base de connaissances | Non disponible | Configurée par KB |
| Filtrage pré-récupération | Non — post-traitement uniquement | Oui — chunks exclus avant le contexte LLM |
| Correspondance d’habilitation utilisateur | Pas de contrôle d’accès aux données par utilisateur | Rôle + département + autorisations explicites |
| Piste d’audit de sensibilité | Pas de journalisation | Journal immuable par événement de filtrage |
| Listes d’accès nominatives | Non supporté | Supporté au niveau Restreint |
La plupart des plateformes traitent toutes les données connectées comme également accessibles. Certaines offrent un accès basé sur les rôles à des fonctionnalités entières, mais aucune n’applique la classification de sensibilité au niveau base-de-connaissances-vers-pipeline-RAG.
Partie de la pile de gouvernance à 10 couches
La classification des données est une couche dans l’architecture de gouvernance de JieGou. Elle fonctionne en complément — pas isolément — des neuf autres couches :
- Seuils de confiance — sorties à faible confiance escaladées avant d’atteindre les utilisateurs
- Portes d’approbation — actions sensibles en pause pour révision humaine
- Détection de PII — informations personnelles tokenisées avant le traitement LLM
- Escalade de confiance — agents gagnant en autonomie selon l’historique de performance
- Gouvernance de la voix de marque — sorties correspondant aux directives vocales de l’organisation
- RBAC par département — 6 rôles, 20 permissions, isolation départementale
- Classification des données — le système de sensibilité à 4 niveaux décrit ici
- Pistes d’audit — chaque décision enregistrée avec traçabilité complète
- Suivi de la qualité — scoring continu avec détection de dérive
- Contrôles de conformité — 412 politiques + 17 contrôles TSC
Ces couches se composent. Une requête peut passer les seuils de confiance mais être filtrée par la classification des données. Une sortie peut passer les vérifications de sensibilité mais être retenue à une porte d’approbation. La défense en profondeur signifie qu’aucune couche seule ne porte tout le fardeau.
Pourquoi c’est important maintenant
À mesure que les organisations étendent l’IA au-delà de simples chatbots vers des workflows départementaux — automatisant le tri du support, l’enablement commercial, les processus RH, l’analyse financière — les données traversant ces systèmes deviennent de plus en plus sensibles. L’écart entre « sémantiquement pertinent » et « autorisé pour cet utilisateur » devient une responsabilité.
La classification des données pour les workflows IA n’est pas un plus. C’est la différence entre une plateforme IA à laquelle vous pouvez confier de vraies données d’entreprise et une qui est limitée aux cas d’usage face au public.
Explorez la pile de gouvernance de JieGou | En savoir plus sur la gestion des bases de connaissances