Gouvernance du shadow AI : comment les équipes sécurité détectent le risque sans bloquer l'innovation

Le shadow AI, c'est ce qui arrive quand les collaborateurs adoptent des outils d'IA plus vite que l'organisation ne peut les encadrer. Le scénario est familier, car il s'agit d'une nouvelle version du shadow IT : une équipe découvre un service utile, s'inscrit avec une adresse professionnelle, y téléverse des données, installe une extension de navigateur ou accorde une autorisation OAuth. L'outil résout un vrai problème de productivité. La sécurité l'apprend plus tard, souvent via les logs, une note de frais ou un incident de fuite de données.

La différence tient à la sensibilité de ce que les gens collent dans les systèmes d'IA. Les prompts peuvent contenir des dossiers clients, du code source, des identifiants, des documents stratégiques, des rapports d'incident, des projets d'actes juridiques, des jeux de données propriétaires et des données personnelles réglementées. Les recommandations de Microsoft Learn sur la fuite de données via le shadow AI résument clairement l'enjeu : un usage non autorisé de l'IA peut créer des fuites et des angles morts de gouvernance avant même que l'entreprise sache quels outils sont utilisés.

Les équipes sécurité ne doivent pas répondre en tentant d'interdire la curiosité. Cela fonctionne rarement. La meilleure réponse repose sur la visibilité, la politique, les alternatives approuvées, la formation et la surveillance.

Le shadow AI ne se limite pas aux chatbots

Beaucoup de programmes démarrent en listant les interfaces conversationnelles les plus connues, mais le shadow AI est bien plus large. Il peut inclure :

• des chatbots grand public utilisés avec des données professionnelles ;
• des extensions de navigateur qui résument des pages ou des e-mails ;
• des outils de transcription de réunions et de prise de notes ;
• des assistants de code IA hors des plans approuvés ;
• des services d'automatisation documentaire ;
• des API de modèles utilisées par des développeurs avec des clés personnelles ;
• des plugins connectés à des comptes SaaS ;
• des agents autonomes disposant d'un accès aux fichiers, à la messagerie ou aux dépôts ;
• des fonctionnalités d'IA intégrées à des produits déjà en place.

Certains de ces outils peuvent être suffisamment sûrs avec le bon contrat, la bonne configuration et les bons contrôles de données. D'autres sont inacceptables pour des données réglementées. Le défi sécurité n'est pas « l'IA, c'est mal ». C'est « quel outil, quelles données, quelle identité, quelle politique de rétention, quelle intégration et quel processus métier ? »

C'est d'abord un problème d'inventaire, avant d'être un problème de formation.

La découverte commence par les signaux réseau et identité

On ne gouverne pas ce qu'on ne voit pas. Commencez par la télémétrie dont l'organisation dispose déjà :

• les logs DNS ;
• les logs de passerelle web sécurisée ;
• les logs de proxy et de pare-feu ;
• les découvertes CASB ;
• les autorisations d'applications du fournisseur d'identité ;
• les enregistrements de consentement OAuth ;
• les extensions de navigateur sur les postes ;
• les données de notes de frais et d'achats ;
• les secrets développeurs et l'usage des clés d'API ;
• les logs d'audit SaaS.

L'intelligence sur les domaines et les URL aide à donner du sens à ces données. Si des collaborateurs consultent un nouveau service d'IA, la sécurité doit savoir si le domaine est légitime, récemment enregistré, parqué, s'il usurpe l'identité d'un éditeur connu ou s'il est associé à une infrastructure à risque. Utilisez les vérifications de réputation de domaine, le scan d'URL et l'historique DNS pour valider les services avant de transformer des logs bruts en décisions de politique.

C'est également utile face au phishing. Les attaquants exploitent l'engouement pour l'IA avec de fausses pages de connexion, des extensions malveillantes, des outils clonés et des leurres de consentement OAuth. La gouvernance du shadow AI et la défense anti-phishing se recouvrent désormais.

La formation est nécessaire mais pas suffisante

La sensibilisation à la sécurité reste un problème non résolu parce qu'on lui demande souvent de compenser des contrôles manquants. On dit aux collaborateurs « ne collez pas de données sensibles dans les outils d'IA », mais on ne leur fournit ni workflow approuvé clair, ni outil sûr, ni exemples correspondant à leur métier.

Une meilleure formation doit être concrète :

• quelles données peuvent être utilisées avec les outils d'IA approuvés ;
• quelles données ne doivent jamais être saisies ;
• comment repérer les faux outils d'IA et les extensions malveillantes ;
• comment demander l'évaluation d'un nouveau service d'IA ;
• que faire si des données sensibles ont été soumises par erreur ;
• comment les développeurs doivent gérer les clés d'API d'IA et le code généré ;
• pourquoi les données clients et réglementées exigent un traitement particulier.

Mais la formation ne rattrapera pas tout. Les gens font des erreurs. Les outils évoluent. De nouveaux services apparaissent chaque semaine. C'est pourquoi la formation doit s'accompagner de surveillance, de processus d'approbation et de contrôles techniques.

Pour les fondamentaux plus larges du shadow IT, voir la gestion du risque shadow IT.

Construire une politique d'outils d'IA par niveaux

Une politique binaire autoriser-ou-bloquer échouera. Raisonnez par niveaux.

Niveau 1 : outils d'IA d'entreprise approuvés. Ils bénéficient d'une revue juridique, de clauses de traitement des données, d'une intégration à l'identité, de journalisation, de contrôles de rétention et de consignes pour les utilisateurs.

Niveau 2 : outils publics approuvés à faible risque. Ils peuvent être autorisés pour du contenu non sensible, de la recherche ou de l'information publique, avec des restrictions claires.

Niveau 3 : outils soumis à évaluation. On y trouve les services qui traitent des documents, du code, des données clients, des enregistrements de réunions, ou qui s'intègrent à des systèmes SaaS.

Niveau 4 : outils bloqués ou interdits. On y trouve les domaines d'usurpation, les services liés à des malwares, les extensions de navigateur dangereuses, les outils dont les politiques de données sont inacceptables et les infrastructures malveillantes connues.

La threat intelligence appuie ce classement par niveaux. Elle ne décidera pas de la validation juridique, mais elle peut identifier des domaines malveillants, des hébergements suspects, des sosies récemment enregistrés, des URL à risque et des infrastructures associées à des abus. Utilisez l'API isMalicious pour automatiser ces vérifications au sein de vos workflows d'évaluation.

Surveiller des schémas de risque, pas seulement des noms d'outils

Bloquer une liste de domaines d'IA ne suffit pas. De nouveaux services apparaissent en permanence, et des éditeurs légitimes ajoutent des fonctions d'IA sous des domaines existants. Surveillez des schémas de risque :

• un service d'IA inconnu consulté par de nombreux collaborateurs ;
• des téléversements vers des outils non approuvés ;
• des autorisations OAuth accordées à des plugins d'IA ;
• des extensions de navigateur aux permissions très larges ;
• de nouveaux domaines imitant des éditeurs approuvés ;
• des clés d'API commitées dans des dépôts ;
• des outils d'IA utilisés depuis des postes d'administration privilégiés ;
• des redirections suspectes depuis des pages de phishing sur le thème de l'IA ;
• des accès répétés à des domaines récemment enregistrés.

Surveillez les domaines, URL et certificats liés aux éditeurs approuvés et aux sosies à haut risque. Si le domaine d'un éditeur change de DNS, de certificat ou de statut de réputation, alertez la bonne équipe avant que les utilisateurs ne soient touchés.

Pour les volumes d'analyse importants, branchez l'enrichissement sur votre SIEM. Un SOC doit pouvoir interroger l'activité des outils d'IA en même temps que la réputation des domaines, les résultats de scan d'URL, les événements d'identité et les signaux DLP.

Shadow AI et réponse aux fuites de données

Lorsque des données sensibles ont pu être soumises à un outil d'IA, traitez le cas comme une investigation d'exposition de données circonscrite. La réponse doit documenter :

• quel type de données a été soumis ;
• quel outil ou domaine l'a reçu ;
• quel utilisateur et quelle identité étaient impliqués ;
• si l'outil est approuvé ;
• si des protections contractuelles existent ;
• si une rétention ou une suppression est possible ;
• si des identifiants, des secrets ou des enregistrements réglementés étaient inclus ;
• quelles notifications ou revues juridiques sont requises.

L'enrichissement technique aide à vérifier le service et l'infrastructure environnante. Si le domaine est suspect, récemment créé ou lié à une activité malveillante connue, escaladez en incident de sécurité. Si le service est légitime mais non approuvé, orientez le dossier vers les processus de conformité, juridiques et de gouvernance.

L'objectif est de distinguer une exposition malveillante d'un usage légitime mais non maîtrisé. Les deux comptent, mais la réponse diffère.

Aider les collaborateurs à choisir la voie sûre

La gouvernance fonctionne mieux quand la voie sûre est plus rapide que la voie risquée. Fournissez des outils approuvés, des exemples clairs et un processus de demande léger. Si une évaluation prend trois mois, les collaborateurs la contourneront. Si les outils approuvés ne couvrent pas les usages courants, le shadow AI reviendra sous un autre nom.

Les équipes sécurité devraient publier un guide de décision court :

• Utiliser l'IA d'entreprise approuvée pour les brouillons internes et les classes de données autorisées.
• N'utiliser les outils publics que pour du contenu public ou non sensible.
• Ne jamais coller d'identifiants, de secrets, de dossiers clients, de données juridiques, de code source ou de données d'incident dans des outils non approuvés.
• Demander une évaluation avant de connecter un outil d'IA à des SaaS, des dépôts, la messagerie ou du stockage.
• Signaler rapidement toute soumission accidentelle.

Ces consignes doivent être renforcées par la détection, et non remplacées par elle.

Un sprint de 30 jours pour gouverner le shadow AI

Le shadow AI peut sembler trop vaste pour savoir par où commencer. Un sprint court garde le travail concret.

En semaine une, construisez l'inventaire initial. Extrayez les données DNS, proxy, CASB, identité et notes de frais pour les catégories connues de services d'IA. N'essayez pas de tout classer parfaitement. L'objectif est d'identifier les services les plus utilisés, les services inconnus, les sosies suspects et les outils qui touchent à des workflows sensibles.

En semaine deux, enrichissez et hiérarchisez les services. Appuyez-vous sur la réputation de domaine, l'historique DNS, le scan d'URL, le contexte de propriété et le statut de revue juridique. Séparez les outils approuvés des outils non approuvés mais légitimes et des infrastructures suspectes. Cette distinction préserve la crédibilité du programme auprès des équipes métier.

En semaine trois, publiez la politique et les alternatives sûres. Donnez aux collaborateurs une courte liste d'outils approuvés, de classes de données autorisées, de classes de données interdites et le point d'entrée pour demander un nouvel outil. Rendez la politique assez pratique pour qu'un chef de produit, un analyste, un développeur et une équipe commerciale la comprennent tous.

En semaine quatre, reliez la surveillance à la réponse. Créez des alertes SIEM pour les schémas d'usage à risque, les autorisations OAuth, les domaines suspects et les téléversements vers des services non approuvés. Définissez qui reçoit l'alerte et ce qu'il doit en faire. Une alerte shadow AI ne doit pas devenir un ticket de sécurité générique sans propriétaire.

Ce sprint ne résoudra pas tous les enjeux de gouvernance, mais il donne à l'organisation de la visibilité, un vocabulaire commun et un rythme opérationnel reproductible.

Répétez le sprint chaque trimestre. L'usage des services d'IA évolue vite, et l'exception d'hier peut devenir le processus métier non maîtrisé de demain.

En résumé

Le shadow AI n'est pas une raison de bloquer tous les outils d'IA. C'est une raison de bâtir de la visibilité et de la gouvernance avant que la fuite de données ne devienne routinière. Les équipes sécurité ont besoin de découverte, d'intelligence sur les domaines, de revue des identités, de formation, d'alternatives approuvées, de surveillance et de processus de réponse à incident.

Utilisez isMalicious pour valider les domaines et URL liés à l'IA, connectez l'enrichissement à votre SIEM/SOAR et surveillez les infrastructures suspectes autour des outils que votre organisation utilise réellement. Soutenir l'innovation est plus simple quand le risque est visible.