Claude et Copilot explorent votre système de fichiers. Qui décide de ce qu’ils peuvent consulter ?
Au cours des douze derniers mois, des assistants IA ont fait leur apparition dans les systèmes de fichiers de votre organisation. Peut-être que l’IT l’a validé. Peut-être qu’une business unit a déployé Microsoft Copilot dans le cadre d’un projet M365. Peut-être que des employés ont eux-mêmes connecté Claude ou un autre outil d’IA à leurs espaces de travail.
Quelle que soit la façon dont cela s’est produit, le résultat est le même : les systèmes basés sur l’IA accèdent désormais aux fichiers de l’entreprise pour le compte des employés, et dans la plupart des organisations, personne n’a explicitement décidé ce que ces systèmes IA sont autorisés à voir. Les contrôles d’accès qui régissent l’accès humain aux fichiers n’ont pas été conçus pour des acteurs IA. Les journaux d’audit qui suivent l’accès humain aux fichiers n’ont pas été configurés pour enregistrer les accès IA avec le niveau d’attribution exigé par la conformité. Les règles qui définissent qui peut accéder à quoi ont été rédigées pour les employés, pas pour des systèmes IA agissant en leur nom.
Cet article s’adresse aux RSSI et aux responsables conformité qui doivent répondre à une question devenue urgente sur le plan opérationnel : qui décide réellement de ce que les assistants IA peuvent voir dans votre système de fichiers ?
Résumé Exécutif
À retenir : Les assistants IA accèdent aux systèmes de fichiers d’entreprise selon des modèles d’autorisation conçus pour des utilisateurs humains — avec des droits d’accès, des limites de session et des pistes d’audit structurellement inadaptés aux acteurs IA. L’écart entre ce que les organisations pensent couvrir avec leurs contrôles d’accès IA et ce qu’elles couvrent réellement est important, largement invisible et expose directement à des risques de conformité.
Pourquoi c’est important : Si un régulateur ou un auditeur demande quels fichiers votre IA a consultés, qui a autorisé chaque accès et comment vous prouvez que les classifications de sensibilité ont été respectées — vous ne pourrez répondre que si votre intégration IA a été conçue pour fournir ces informations. Ce n’est généralement pas le cas. Il faut découvrir ce manque avant le contrôle, pas pendant.
5 points clés à retenir
- Les assistants IA qui accèdent aux systèmes de fichiers d’entreprise fonctionnent généralement avec des comptes de service dotés d’autorisations supérieures à celles de tout utilisateur individuel — ce qui signifie que l’IA peut récupérer des documents auxquels l’employé à l’origine de la requête n’a pas accès par d’autres moyens.
- L’autorisation au niveau de la session n’équivaut pas à une application RBAC et ABAC à chaque requête. Il s’agit d’un unique point de contrôle suivi d’un accès non surveillé à la vitesse de la machine.
- La plupart des journaux d’audit d’accès IA aux fichiers enregistrent l’identité du compte de service, pas celle de l’utilisateur humain à l’origine de la requête. Ce n’est pas seulement un manque de journalisation — c’est un problème de conformité HIPAA, un problème de conformité RGPD et un problème pour les enquêtes forensiques.
- Les classifications et labels de sensibilité appliqués aux fichiers n’ont aucun effet sur les accès IA, sauf si l’intégration IA les évalue explicitement au niveau de la récupération. Un assistant IA peut extraire un document marqué Confidentiel ou Restreint aussi facilement qu’un document non classifié.
- La vraie question de gouvernance n’est pas de savoir s’il faut autoriser l’accès IA aux fichiers — les employés sont plus productifs avec ces outils, et les bloquer favorise l’IA fantôme. La question est de savoir si l’accès IA aux fichiers est régi par les mêmes règles, avec la même application et la même traçabilité, que tout autre accès aux données dans l’organisation.
Un modèle d’accès que personne n’a validé
Lorsqu’une organisation déploie un assistant IA avec accès au système de fichiers, elle configure généralement un compte de service pour authentifier l’IA auprès du référentiel de fichiers. Ce compte de service reçoit des autorisations suffisamment larges pour servir l’ensemble des utilisateurs — car l’IA doit pouvoir récupérer tout fichier dont un utilisateur pourrait légitimement avoir besoin. Résultat : un identifiant unique avec accès à tout le périmètre, partagé entre tous les utilisateurs qui interagissent avec l’IA.
Aucune organisation ne créerait volontairement un compte utilisateur humain avec un tel profil d’autorisations. Un compte partagé avec accès à tous les fichiers sensibles du référentiel, utilisable par n’importe quel employé, sans restriction d’accès par utilisateur — cela échouerait à toute revue de gestion des identités et des accès, à toute analyse de risques et à tout audit de conformité.
Mais lorsque la même structure d’autorisations est mise en place pour un compte de service IA, elle passe souvent les contrôles car elle ressemble à de l’infrastructure, pas à une politique d’accès. L’IA est considérée comme un système, pas comme un acteur qui prend des décisions d’accès aux données pour le compte des utilisateurs. Cette distinction ne résiste pas à l’analyse — et certainement pas à une enquête réglementaire.
Conséquence concrète : un assistant IA connecté à un système de fichiers d’entreprise via un compte de service peut récupérer des documents auxquels l’employé à l’origine de la question n’a jamais eu accès. Un analyste junior qui demande à Claude de résumer le paysage concurrentiel peut recevoir une réponse basée sur des documents classés au-delà de son habilitation. Un chargé de clientèle qui demande à Copilot de récupérer l’historique d’un compte peut, sans le vouloir, afficher des fichiers d’autres comptes. L’IA ne dysfonctionne pas — elle fait exactement ce pour quoi elle a été configurée. Le modèle d’accès n’a tout simplement jamais été conçu pour éviter cela.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
L’autorisation au niveau de la session n’est pas du Zero Trust. C’est un périmètre avec une seule porte.
La réponse de gouvernance la plus courante face aux préoccupations liées à l’accès IA aux fichiers consiste à mettre en avant l’authentification : l’IA est authentifiée avant de se connecter, l’accès est vérifié, la session s’établit dans l’architecture Zero Trust de l’organisation. C’est exact, mais cela ne va pas assez loin.
L’authentification au niveau de la session vérifie que le système IA est autorisé à se connecter au référentiel de fichiers au moment où la session s’établit. Elle ne vérifie pas que l’utilisateur qui dirige l’IA pour une requête précise est autorisé à accéder au fichier spécifique que l’IA s’apprête à récupérer. Une fois la session ouverte, toutes les opérations suivantes héritent de l’autorisation établie à la connexion — l’IA peut récupérer tout ce que le compte de service peut atteindre, pour n’importe quel utilisateur, à n’importe quelle fin, sans contrôle d’autorisation supplémentaire.
Cela revient à vérifier l’identité d’un visiteur à l’entrée du bâtiment puis à lui donner un accès illimité à tous les bureaux, salles serveurs et espaces dirigeants pendant toute la durée de sa visite. La vérification initiale a eu lieu. Tout ce qui suit repose sur une confiance implicite — exactement ce que les principes du Zero Trust visent à éliminer.
Pour les utilisateurs humains, les contrôles au niveau de la session sont une approximation raisonnable de la vérification continue, car le rythme opérationnel humain limite le comportement en session. Pour un système IA capable d’exécuter des milliers d’opérations sur les fichiers en une seule session, l’autorisation au niveau de la session n’est qu’un point de contrôle suivi d’un accès non surveillé à la vitesse de la machine. C’est un modèle périmétrique. Ce n’est pas du Zero Trust.
L’application RBAC et ABAC à chaque requête signifie que chaque opération sur un fichier — chaque récupération, chaque recherche, chaque téléchargement — est évaluée selon les droits d’accès réels de l’utilisateur demandeur au moment où elle a lieu. L’IA n’hérite pas de l’autorisation de session ; elle hérite des autorisations spécifiques de l’utilisateur dont elle exécute la requête, pour cette requête uniquement. Si cet utilisateur n’est pas autorisé à voir un document, l’IA ne peut pas le récupérer — quels que soient les droits du compte de service, l’état de la session ou la formulation de la requête.
Vos labels de sensibilité ne vous protègent pas de l’IA — sauf si l’IA les vérifie
La plupart des organisations dotées de programmes de gouvernance des données matures ont investi dans des cadres de classification — des labels de sensibilité appliqués aux fichiers qui définissent leur traitement, qui peut y accéder et ce qu’on peut en faire. Microsoft Information Protection, systèmes de classification natifs, workflows de classification manuelle — ces dispositifs représentent un vrai investissement de gouvernance et fonctionnent bien pour l’accès humain aux fichiers.
Ils n’ont aucun effet sur les accès IA, sauf si l’intégration IA les évalue explicitement. Un document marqué Confidentiel n’est pas plus difficile à récupérer pour une IA qu’un document non classifié. Le label de sensibilité est une métadonnée attachée au fichier. Le fait que cette métadonnée soit évaluée avant que le fichier ne soit retourné à une IA — ou ignorée — dépend entièrement de l’architecture de l’intégration IA. Dans la plupart des intégrations IA aux systèmes de fichiers, les labels de sensibilité ne sont pas évalués au niveau de la récupération. L’IA récupère les documents les plus pertinents selon la requête, et la pertinence ne tient pas compte de la classification de sensibilité.
Conséquence directe pour les responsables conformité : les contrôles de gouvernance des données dans lesquels vous avez investi ne s’appliquent pas à l’accès IA, sauf si votre intégration IA a été explicitement conçue pour les faire respecter. Chaque décision de classification, chaque label de sensibilité, chaque restriction d’accès appliquée à un fichier de votre référentiel — rien de tout cela ne limite l’accès IA si l’intégration IA ne l’évalue pas au niveau de la récupération. Une organisation qui pense que son cadre de classification protège ses fichiers sensibles d’une exposition non autorisée par l’IA se berce d’une illusion qui ne résistera pas à un audit.
Cinq failles de contrôle d’accès — et leur manifestation concrète
| Faille de contrôle d’accès | Ce qui manque | Ce qui se passe réellement |
|---|---|---|
| Compte de service surdimensionné | L’assistant IA fonctionne avec un compte de service ayant accès à tous les partages de fichiers ; tout utilisateur peut interroger n’importe quel fichier accessible par le compte | Un analyste junior demande à Claude de résumer le pipeline M&A. Claude récupère des documents de niveau conseil d’administration auxquels l’analyste n’a pas accès. |
| Autorisation au niveau de la session uniquement | Autorisation IA vérifiée à la connexion ; toutes les opérations suivantes héritent de cette autorisation, quel que soit l’objet de la demande | Un prestataire s’authentifie pendant les heures ouvrées ; sa session IA reste active. Après la fermeture, l’IA continue de récupérer des documents sans nouvelle vérification. |
| Pas d’application des labels de sensibilité | L’IA récupère les documents selon la pertinence du contenu sans évaluer les labels de classification | Un employé demande à Copilot une analyse concurrentielle. Il récupère des documents marqués Confidentiel — dont un projet de lettre d’intention d’acquisition. |
| Absence d’attribution par utilisateur | Tous les accès IA aux fichiers sont enregistrés sous le compte de service ; aucune trace de l’utilisateur à l’origine de chaque requête | Une enquête sur une fuite de données révèle des milliers d’accès par « AI-service-account ». Impossible d’identifier qui a initié les requêtes. |
| Pas de limitation du volume de récupération | L’IA peut exécuter un nombre illimité de récupérations de fichiers par session ; aucun contrôle de volume au niveau des données | Une session IA compromise récupère 40 000 documents en 90 minutes avant que l’alerte SIEM ne soit traitée. |
Les questions auxquelles vous ne pouvez pas répondre — jusqu’à ce que vous le puissiez
Pour les responsables conformité, la gouvernance de l’accès IA aux fichiers se résume à une question précise et inconfortable : si un régulateur ou un auditeur vous demande ce que vos assistants IA ont consulté, qui a autorisé chaque accès et comment vous prouvez le respect de vos obligations de protection des données — pouvez-vous répondre ?
La réponse dépend entièrement de ce que votre intégration IA a été conçue pour journaliser et appliquer. La plupart des pistes d’audit d’accès IA aux fichiers enregistrent qu’un compte de service a récupéré un fichier. Elles n’indiquent pas quel employé a initié la requête, si la récupération était conforme à ses droits d’accès, si la classification de sensibilité du fichier a été évaluée, ni ce qui a été fait du contenu.
Ce n’est pas un simple problème de configuration des logs — c’est un problème d’architecture. Le niveau de détail requis pour répondre aux questions de conformité doit être capturé au moment de la récupération ; il ne peut pas être reconstitué a posteriori.
La règle du minimum nécessaire de la HIPAA impose de limiter l’accès aux informations médicales protégées au strict nécessaire pour accomplir la tâche. Quand une IA récupère des PHI pour répondre à une requête, prouver la conformité au minimum nécessaire suppose de savoir précisément ce qui a été récupéré, en réponse à quelle requête, par quel utilisateur.
Le RGPD impose que le traitement des données personnelles repose sur une base légale documentée — ce qui, pour la récupération IA, suppose d’identifier l’utilisateur à l’origine de la requête et la finalité du traitement. SOX exige des enregistrements complets des accès aux données financières.
La conformité FedRAMP impose la journalisation de toutes les opérations dans les systèmes d’information autorisés, y compris les opérations IA, avec un niveau d’attribution permettant d’identifier l’acteur humain responsable.
Ce que demanderont les auditeurs — et ce qu’il faut pour y répondre
| Question d’un auditeur ou régulateur | Cadre applicable | Ce qu’il faut pour y répondre |
|---|---|---|
| Quels employés ont utilisé un assistant IA pour accéder à des fichiers contenant des PHI ou des informations personnelles identifiables au cours des 90 derniers jours ? | HIPAA, RGPD | Nécessite une attribution par utilisateur dans les logs IA — la journalisation du seul compte de service ne suffit pas |
| Quels documents précis l’IA a-t-elle récupérés en réponse à une requête utilisateur donnée ? | HIPAA Minimum Necessary, minimisation des données RGPD | Nécessite une journalisation au niveau de la requête, reliant chaque récupération à la demande qui l’a déclenchée |
| L’IA a-t-elle été empêchée d’accéder à des documents que l’utilisateur demandeur n’était pas autorisé à consulter ? | Tous les cadres réglementaires | Nécessite une application RBAC/ABAC à chaque requête avec journalisation des décisions de politique — pas seulement l’authentification de session |
| Pouvons-nous prouver que l’accès IA aux données était conforme aux classifications de sensibilité applicables ? | RGPD, SOX, FedRAMP | Nécessite l’évaluation des labels de sensibilité au niveau de la récupération et la documentation de leur application |
| Quel est l’historique complet d’accès pour un fichier spécifique qui a pu être récupéré par l’IA ? | HIPAA, RGPD droit d’accès, eDiscovery | Nécessite une piste d’audit au niveau du fichier incluant les récupérations IA avec le même niveau d’attribution que l’accès humain |
Bloquer l’IA n’est pas la solution. La gouverner, oui.
La réaction instinctive face aux risques d’accès IA aux fichiers — bloquer les outils IA, révoquer l’accès, attendre que le cadre de gouvernance évolue — crée un autre problème. Les employés qui trouvent l’IA réellement utile pour leur travail y accéderont autrement. Comptes personnels, outils IA accessibles via navigateur, applications grand public sans aucun lien avec la gouvernance d’entreprise ni accès aux données officielles.
Ce n’est pas une hypothèse : l’IA fantôme est déjà présente dans la plupart des organisations, et restreindre les outils IA officiels accélère plutôt que de réduire l’usage non gouverné de l’IA.
La question de gouvernance n’est pas de savoir s’il faut autoriser l’accès IA aux fichiers. Il s’agit de savoir si cet accès est régi par les mêmes règles, avec la même application et la même traçabilité, que tout autre accès aux données dans l’organisation. Un employé qui accède à un fichier via une application de bureau est soumis à des contrôles d’accès, une surveillance de session et une journalisation d’audit.
Ce même employé qui accède au même fichier via un assistant IA doit être soumis à des contrôles identiques — autorisation à chaque requête, application des labels de sensibilité, journalisation à double attribution. Si la voie IA contourne l’un de ces contrôles, cela crée une faille de gouvernance qui finira par être exploitée, découverte, ou les deux.
Comment Kiteworks garantit que l’IA ne voit que ce qu’elle doit voir
Les organisations qui réussiront à adopter l’IA sans créer de risques de conformité ne sont pas celles qui la bloquent le plus longtemps — ce sont celles qui étendent le plus vite leur gouvernance à l’IA. Cela suppose une architecture où la réponse à « qui décide de ce que l’IA peut voir » est la même que pour tout autre acteur : le moteur de politique, évalué à chaque requête individuelle, selon les droits d’accès réels de l’utilisateur concerné.
Kiteworks applique cela via RBAC et ABAC à chaque requête au niveau des opérations IA — pas à l’établissement de la session. Chaque récupération de fichier, chaque recherche, chaque opération sur un dossier exécutée par Claude, Copilot ou tout assistant IA compatible MCP via le Réseau de données privé Kiteworks est évaluée selon les droits d’accès en vigueur de l’utilisateur authentifié avant restitution des données.
L’IA hérite des autorisations de l’utilisateur — pas de celles du compte de service — pour chaque opération individuelle. Si l’utilisateur ne peut pas voir un document, l’IA ne peut pas le récupérer, quel que soit l’état de la session, la formulation de la requête ou les droits du compte de service.
L’application des labels de sensibilité s’effectue au niveau de la récupération : les classifications Microsoft Information Protection et les politiques de classification Kiteworks sont évaluées avant restitution des données à l’IA. Les documents confidentiels ne sont pas affichés en réponse à des requêtes d’utilisateurs non autorisés — non parce que l’IA reçoit l’ordre de ne pas les mentionner, mais parce que la couche de gouvernance ne les retourne pas.
Chaque opération IA sur un fichier est enregistrée avec une double attribution — identité du système IA et utilisateur humain authentifié — alimentant le journal d’audit Kiteworks et s’intégrant en temps réel au SIEM. Les questions de conformité du tableau ci-dessus trouvent ainsi des réponses — car l’architecture a été conçue pour les générer.
Pour les RSSI qui doivent prouver que l’accès IA aux fichiers est gouverné avec la même rigueur que l’accès humain, et pour les responsables conformité qui ont besoin d’une documentation prête pour l’audit sur ce que l’IA a consulté et qui l’a autorisé, Kiteworks fournit la couche de données gouvernée qui rend tout cela possible. Pour découvrir son fonctionnement, réservez votre démo sans attendre !
Foire aux questions
La plupart des assistants IA d’entreprise accèdent aux systèmes de fichiers via des comptes de service configurés avec des autorisations suffisamment larges pour servir tous les utilisateurs. Cela signifie que l’IA peut récupérer n’importe quel fichier accessible par le compte de service — même si l’employé qui dirige l’IA n’est pas autorisé à voir ce fichier. Combiné à une autorisation au niveau de la session qui accorde un accès implicite pendant toute la durée de la session, ce modèle d’accès permet à l’IA de contourner les contrôles d’accès qui régissent l’accès humain aux fichiers. Le risque n’est pas théorique : des employés peuvent recevoir par inadvertance des réponses IA basées sur des documents auxquels ils n’auraient jamais dû avoir accès.
Uniquement si l’intégration IA a été explicitement conçue pour les évaluer. Les labels de classification et de sensibilité appliqués aux fichiers sont des métadonnées — ils n’ont aucun effet sur la récupération IA sauf si l’intégration les évalue au niveau de la récupération avant de restituer les données. Dans la plupart des intégrations IA aux systèmes de fichiers, la pertinence par rapport à la requête détermine ce qui est récupéré ; la classification de sensibilité n’entre pas en ligne de compte. Les organisations qui pensent que leur cadre de classification protège les fichiers sensibles de l’exposition IA doivent vérifier si leur intégration IA l’applique réellement.
L’autorisation au niveau de la session vérifie le système IA à la connexion et accorde un accès implicite pendant toute la durée de la session. L’application RBAC et ABAC à chaque requête évalue les droits d’accès réels de l’utilisateur pour chaque opération IA — chaque récupération de fichier, chaque recherche, chaque navigation dans un dossier — au moment où elle est demandée. Concrètement : avec l’autorisation de session, tout fichier accessible au compte de service peut être récupéré pour n’importe quel utilisateur ; avec l’application à chaque requête, seuls les fichiers que l’utilisateur demandeur est spécifiquement autorisé à consulter peuvent être récupérés, et uniquement pour cette demande.
Les deux cadres exigent une documentation d’attribution permettant d’identifier la personne responsable de chaque événement d’accès aux données. Pour l’accès IA aux fichiers, cela signifie une journalisation à double attribution : chaque récupération doit enregistrer à la fois l’identité du système IA et l’utilisateur humain authentifié à l’origine de la requête, ainsi que le fichier récupéré, l’horodatage et l’action effectuée. La conformité HIPAA exige en plus que l’accès aux PHI respecte le principe du minimum nécessaire, ce qui suppose de savoir précisément ce qui a été récupéré en réponse à quelle requête. Une journalisation limitée au compte de service — qui indique simplement « l’IA a accédé à un fichier » sans identifier l’utilisateur demandeur — ne satisfait pas aux exigences documentaires de ces cadres.
L’objectif est d’étendre les règles de gouvernance des données existantes aux acteurs IA — pas de créer des règles spécifiques à l’IA, ni de bloquer des outils IA réellement utiles aux employés. Cela implique de déployer une architecture d’intégration IA qui applique l’autorisation à chaque requête selon les mêmes politiques RBAC et ABAC que pour l’accès humain, évalue les labels de sensibilité au niveau de la récupération et génère des logs d’audit à double attribution pour chaque opération IA. Les organisations qui y parviennent offrent à leurs employés un accès IA gouverné, à la fois plus performant et plus sécurisé que les alternatives non gouvernées qu’ils utiliseraient sinon.
Ressources complémentaires
- Article de blog
Stratégies Zero Trust pour une protection abordable de la vie privée face à l’IA - Article de blog
Comment 77 % des organisations échouent sur la sécurité des données face à l’IA - eBook
AI Governance Gap : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025 - Article de blog
Il n’existe pas de « –dangerously-skip-permissions » pour vos données - Article de blog
Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent des preuves concrètes.