IA cybersécurité : pourquoi nous refusons un assistant interne sans règle écrite sur les données

Faut-il encadrer un assistant IA interne avant de le déployer ?

Réponse courte : oui, et c'est une question d'IA cybersécurité avant d'être une question d'outil. Sans règle écrite sur les données que les employés peuvent saisir dans leurs requêtes, nous refusons de mettre un assistant en production, même quand le modèle lui-même est fiable et que le fournisseur coche toutes les cases contractuelles.

La demande revient souvent de la même façon. Une direction veut un assistant IA interne, un chatbot connecté aux courriels, aux tickets de support ou à la base documentaire, et le projet est cadré en semaines, pas en mois. Le choix du modèle est fait. L'intégration technique est prête. Ce qui manque presque toujours, c'est un document d'une page qui dit à un employé ce qu'il a le droit d'écrire dans la boîte de requête. Sans ce document, nous ne démarrons pas le déploiement, même si tout le reste est en place. Ce n'est pas une posture de prudence excessive, c'est une condition de travail.

Ce qu'on refuse, concrètement

Ce qu'on refuse n'est pas l'IA. C'est l'IA sans classification préalable des données qu'elle va manipuler. Dans la pratique, trois situations reviennent et nous les bloquons systématiquement avant mise en production :

Dans les trois cas, le problème n'est pas que le modèle soit mauvais. Le problème est qu'on ne sait pas ce qu'on lui a donné à voir, et qu'on ne pourra pas le dire à un assureur, à la Commission d'accès à l'information ou à un enquêteur forensique le jour où ça compte.

L'IA fantôme existe déjà dans votre organisation

Voici ce qu'on constate presque chaque fois qu'on arrive dans une organisation qui n'a jamais formalisé sa gouvernance IA : des employés utilisent déjà un assistant public, avec leur compte personnel, pour reformuler un courriel sensible, résumer un contrat ou traduire une plainte de client. Personne ne l'a autorisé, personne ne l'a interdit non plus, parce que personne n'a jamais écrit la règle.

C'est ça, l'IA fantôme. Elle ne se présente pas comme un projet technologique qu'il faut approuver. Elle se présente comme un geste individuel, répété des centaines de fois, qui fait sortir des données de l'entreprise vers des serveurs qu'on ne contrôle pas, sous des conditions d'utilisation qu'on n'a jamais lues. Refuser de déployer un assistant officiel sans règle écrite ne règle pas ce problème, mais le reconnaître est la seule façon honnête d'aborder le dossier. Un gestionnaire de risques qui présente son programme de sécurité à un assureur sans mentionner cet usage informel présente un dossier incomplet, pas un dossier solide.

Ce qu'on déploie, et à quelles conditions

Ce qu'on accepte de mettre en production suit toujours la même séquence, documentée avant le premier déploiement, pas après. Sur ce point, notre fiche de service le dit sans détour : nous établissons la classification des données, les évaluations des facteurs relatifs à la vie privée pour les projets d'IA, les règles d'usage pour les employés et les contrôles techniques associés.

Concrètement, ça veut dire quatre choses distinctes, dans cet ordre :

Ce dernier point est celui qu'on voit le plus souvent sauté. Une politique écrite que personne ne peut faire respecter techniquement reste une déclaration d'intention, pas un contrôle.

Ce que ça change pour votre posture défendable

Pour un gestionnaire de risques ou un RSSI, l'intérêt de cette séquence n'est pas philosophique. C'est un dossier qu'on peut montrer. Quand un incident touche un système où tourne un assistant IA, la première question d'un enquêteur ou d'un assureur est simple : qu'est-ce que ce modèle avait le droit de voir, et comment le savez-vous ? Une organisation qui répond avec une classification documentée et des règles signées répond en minutes. Une organisation qui répond « on suppose que personne n'a rien envoyé d'important » répond avec un trou dans son dossier, exactement au moment où elle en a le moins besoin.

C'est le même raisonnement qui sous-tend nos audits et nos évaluations de posture en général : l'objectif n'est pas seulement de réduire le risque technique, mais de produire un dossier qui tient la route face à un tiers. Un assistant IA déployé sans cette base n'ajoute pas seulement un risque de fuite de données, il ajoute une zone d'ombre dans un dossier qui, par ailleurs, peut être très bien tenu.

Ce qu'il reste à faire, et dans quel ordre

Un assistant IA mal cadré ne cause pas nécessairement un incident visible demain. Il crée plutôt un flux de données qu'on ne documente pas, qui s'accumule, et qui devient difficile à expliquer six mois plus tard, quand la question se pose dans un contexte de notification de violation ou de réclamation d'assurance. Le coût de cette absence de cadre ne se voit pas dans un budget, il se voit dans la qualité des réponses qu'on peut donner le jour où quelqu'un les exige.

Si un projet d'assistant IA interne est en discussion dans votre organisation, la question à poser avant le choix du fournisseur n'est pas technique, elle est documentaire : qui a classifié les données, qui a évalué les facteurs de vie privée, et qui signera les règles d'usage avant le premier employé connecté. Groupe ITCS construit ce cadrage de gouvernance IA, de la classification des données jusqu'aux contrôles techniques qui l'appliquent, avant que le projet n'entre en production, pas après.

Sources