Detection du shadow AI : comment trouver, evaluer et gouverner l'utilisation non autorisee de l'IA

Vos employes utilisent deja l'IA. La question est de savoir si vous le savez.

Un developpeur colle du code source proprietaire dans ChatGPT. Un analyste marketing telecharge des donnees clients vers un outil de generation d'images. Un membre de l'equipe financiere achemine des requetes sensibles via un point de terminaison LLM non approuve. Aucune de ces interactions n'apparait dans un registre de logiciels approuves.

C'est le shadow AI : l'utilisation d'outils d'IA au sein d'une organisation sans l'approbation du service informatique, de la securite ou de la conformite. Il apparait non pas dans les inventaires logiciels mais dans les journaux reseau. Et l'ecart entre l'adoption et la gouvernance ne cesse de se creuser. Au moment ou une organisation decouvre un outil non approuve, des donnees sensibles ont peut-etre deja ete envoyees a un fournisseur dont les politiques de conservation et d'entrainement sont inconnues.

Les consequences sont concretes. Les donnees envoyees aux fournisseurs d'IA peuvent etre conservees, utilisees pour l'entrainement ou exposees lors de violations. Cela cree une exposition a la conformite au titre du RGPD, de HIPAA, de SOC 2 et des regles sectorielles qui exigent des controles de traitement des donnees. Les relations avec les fournisseurs ne sont pas suivies : pas d'accords de traitement des donnees, pas d'evaluations de securite, pas de protections contractuelles.

Et lorsqu'un regulateur demande quels outils d'IA l'organisation utilise, qui les utilise et quelles donnees ils traitent, la plupart des organisations ne peuvent pas repondre.

Pourquoi les outils de securite traditionnels sont insuffisants

Les pare-feu peuvent bloquer des domaines mais ne peuvent pas categoriser le trafic comme lie a l'IA ni evaluer le profil de risque d'un fournisseur d'IA. Les systemes DLP detectent des motifs dans les donnees sortantes mais ne maintiennent pas de registre d'outils d'IA. Les plateformes SIEM collectent les journaux bruts qui contiennent des preuves d'utilisation de l'IA mais n'ont pas la logique de detection pour les trouver et les classifier.

Ce qu'il faut, c'est un systeme qui ingere les donnees de journaux existantes, identifie l'utilisation d'outils d'IA, evalue le risque et fournit un chemin de la detection a la gouvernance.

Comment fonctionne la detection du shadow AI par VerifyWise

La detection du shadow AI dans VerifyWise est passive. Pas d'agents sur les terminaux, pas d'extensions de navigateur. Elle ingere les donnees de journaux que les organisations collectent deja aupres de leur infrastructure de securite.

Ingestion des journaux

Deux methodes d'ingestion sont disponibles. Une API REST accepte les evenements au format JSON et fonctionne avec les systemes SIEM, les pipelines de journaux personnalises et les outils d'orchestration. Un recepteur syslog sur le port TCP 5514 accepte les messages syslog standard provenant des proxys web, des pare-feu et des appliances reseau.

Analyse et normalisation

Les journaux bruts arrivent dans differents formats selon la source. Quatre analyseurs integres gerent les sources d'entreprise les plus courantes : Zscaler Internet Access, Netskope Cloud Security, le proxy Squid et un analyseur generique cle-valeur pour les systemes qui produisent des paires structurees cle=valeur. Chaque analyseur extrait l'horodatage, l'adresse IP source, le nom d'utilisateur, le domaine de destination, le chemin URL, la methode HTTP, les octets transferes et l'action effectuee, puis les normalise dans un schema d'evenement commun.

Identification des outils d'IA

Les evenements normalises sont mis en correspondance avec un registre organise de plus de 50 outils et services d'IA classes par categorie : chatbots LLM (ChatGPT, Claude, Gemini, Perplexity), assistants de codage (GitHub Copilot, Cursor, Tabnine), generateurs d'images (Midjourney, DALL-E, Stable Diffusion), outils d'ecriture (Notion AI, Jasper, Grammarly) et plateformes d'IA low-code (v0.dev, Bolt, Replit). Chaque entree du registre comprend le nom de l'outil, le fournisseur, les domaines associes, la classification de risque par defaut et les metadonnees de categorie.

La detection va au-dela de la simple correspondance de domaine. Des motifs regex appliques aux chemins URI extraient des identifiants de modeles specifiques a partir du trafic API. Lorsqu'une requete atteint le point de terminaison AWS Bedrock avec un chemin contenant anthropic.claude-3-opus, ou lorsque le trafic vers Azure OpenAI reference gpt-4-turbo dans le chemin de deploiement, le systeme capture le modele specifique invoque. Cette extraction au niveau du modele couvre AWS Bedrock, Azure OpenAI, Google Vertex AI et les points de terminaison API directs des principaux fournisseurs.

Enrichissement des evenements

Chaque evenement detecte est enrichi avec le contexte organisationnel. Le nom d'utilisateur est correle avec le departement, le titre du poste et le responsable hierarchique a partir des donnees SIEM. Cela compte pour la notation des risques : un analyste financier accedant a un outil d'IA non approuve presente un risque different d'un developpeur utilisant le meme outil.

Notation des risques : quatre facteurs ponderes

Chaque outil d'IA detecte recoit un score de risque composite de 0 a 100, calcule a partir de quatre facteurs ponderes.

Le statut d'approbation (40 %) est le facteur le plus important. Un outil non approuve sans dossier de gouvernance recoit la penalite maximale. Un outil formellement examine et approuve recoit la penalite minimale. Les outils en cours d'examen se situent entre les deux.

La conformite de la politique de donnees (25 %) evalue la posture de securite du fournisseur d'IA. Le fournisseur detient-il un SOC 2 Type II ? Le service est-il conforme au RGPD avec un accord de traitement des donnees publie ? Le fournisseur chiffre-t-il les donnees au repos et en transit ? Utilise-t-il les donnees des clients pour l'entrainement des modeles ? Les fournisseurs avec des politiques d'entrainement opt-out ou sans politique de conservation publiee obtiennent un risque plus eleve.

La sensibilite du departement (20 %) pondere plus fortement l'utilisation provenant des departements Finance, Juridique, RH et Direction que du Marketing, des Ventes ou de l'Ingenierie. Ces departements traitent des donnees reglementees (dossiers financiers, secret professionnel juridique, donnees personnelles des employes, plans strategiques) ou l'exposition a un outil d'IA non verifie a des consequences disproportionnees.

Le volume d'utilisation (15 %) normalise les comptages d'evenements bruts par rapport aux moyennes organisationnelles pour trouver les valeurs aberrantes. Un outil generant 10 fois le volume de trafic moyen est a risque eleve quel que soit son statut d'approbation, car un volume eleve implique une integration plus profonde dans les flux de travail et une plus grande exposition des donnees.

Les scores de risque ne sont pas statiques. Ils se recalculent a mesure que de nouveaux evenements arrivent, que les schemas d'utilisation evoluent et que le statut des outils progresse dans la gouvernance.

Alertes via un moteur de regles configurable

Le systeme d'alerte dispose de six types de declencheurs configurables :

1. Nouvel outil d'IA detecte - se declenche lorsque le systeme voit un outil qu'il n'a jamais rencontre dans le trafic de l'organisation
2. Seuil d'utilisation depasse - se declenche lorsque le nombre d'evenements d'un outil depasse une limite configurable dans une periode donnee
3. Acces par un departement sensible - se declenche lorsque des utilisateurs de departements a haute sensibilite accedent a un outil ou une categorie d'outils
4. Tentatives d'acces bloquees - se declenche lorsque les journaux montrent qu'un proxy ou pare-feu a bloque l'acces a un outil d'IA, indiquant une intention meme lorsque l'acces a ete refuse
5. Score de risque depasse - se declenche lorsque le score de risque composite d'un outil franchit un seuil configurable
6. Nouvel utilisateur detecte - se declenche lorsqu'un utilisateur jamais vu auparavant commence a acceder a un outil d'IA connu

Chaque regle peut declencher une ou plusieurs actions : envoyer des notifications d'alerte, creer des taches de gouvernance avec des responsables et des echeances, lancer une revue de gouvernance ou creer des entrees de risque. Des periodes de refroidissement empechent la fatigue des alertes en supprimant les notifications repetees pendant un intervalle configurable. Les listes de destinataires sont definies par regle, de sorte qu'une alerte de nouvel outil atteint l'equipe de securite tandis qu'une alerte de departement sensible va au responsable de la conformite.

De la detection a la gouvernance en quatre etapes

La plupart des organisations qui s'attaquent au shadow AI s'arretent a la detection. Elles identifient quels outils sont utilises, produisent un rapport et laissent les processus manuels decider de la suite. VerifyWise comble cette lacune avec un assistant de gouvernance qui convertit un outil detecte en un actif gere et tracable.

• Etape 1 : Ajouter a l'inventaire des modeles. L'outil detecte est ajoute a l'inventaire des modeles de l'organisation. Les champs sont pre-remplis avec les donnees de detection : nom de l'outil, fournisseur, domaine principal, categorie, score de risque initial. Le responsable de la gouvernance examine et complete ces informations.

• Etape 2 : Attribuer la responsabilite de gouvernance. Un proprietaire, un relecteur et une date d'echeance sont attribues. Le proprietaire pilote l'evaluation ; le relecteur assure la supervision secondaire ; la date d'echeance cree la responsabilite.

• Etape 3 : Evaluation des risques. Une evaluation structuree capture la classification de sensibilite des donnees (quels types de donnees sont exposes), le nombre d'utilisateurs (combien de personnes l'utilisent) et l'exposition par departement (quelles fonctions sont concernees). Cela alimente le registre des risques de VerifyWise.

• Etape 4 : Initier le cycle de vie du modele (optionnel). L'outil peut etre inscrit dans un processus de cycle de vie complet, declenchant une revue de securite du fournisseur, un examen juridique des conditions d'utilisation et la negociation d'un accord de traitement des donnees.

A mesure qu'un outil progresse dans la gouvernance, son statut evolue : Detecte (aucune action prise), En cours d'examen (gouvernance demarree), puis l'un des quatre etats terminaux : Approuve (sanctionne), Restreint (autorise sous conditions), Bloque (interdit) ou Rejete (non pertinent ou faux positif).

Cela produit une chaine auditable allant de « outil inconnu dans le trafic reseau » a « revue de gouvernance avec responsable attribue » puis « actif d'IA formellement gouverne avec decision d'approbation documentee ». C'est cette chaine que les regulateurs et les auditeurs recherchent.

Analyses et rapports

Le tableau de bord des insights s'ouvre avec quatre cartes KPI : applications d'IA uniques decouvertes, nombre total d'utilisateurs d'IA tous outils confondus, l'outil a risque le plus eleve actuellement detecte et le departement le plus actif en volume d'evenements. Celles-ci fournissent un apercu au niveau executif avant tout approfondissement.

Quatre types de graphiques offrent des vues plus detaillees. Un graphique a barres des outils par volume d'evenements classe les outils detectes par trafic total, montrant quels outils ont la plus grande surface d'exposition des donnees. Un graphique a barres des outils par utilisateurs uniques classe par nombre d'utilisateurs distincts, revelant quels outils ont l'adoption la plus large. Un graphique circulaire des utilisateurs par departement montre ou l'utilisation de l'IA se concentre. Un graphique en courbes d'analyse de tendance suit le total des evenements, les utilisateurs uniques et les decouvertes de nouveaux outils sur des plages configurables de 30 jours a un an.

Les donnees d'activite des utilisateurs sont disponibles a deux niveaux. Au niveau individuel : les comptages d'evenements de chaque utilisateur, les outils accedes, les scores de risque et le departement. Au niveau du departement : utilisation agregee, principaux outils et exposition maximale au risque, adapte aux rapports destines aux responsables de departement et aux comites de conformite.

Conservation des donnees

Un modele de conservation a trois niveaux equilibre la profondeur avec le stockage :

• Les evenements bruts sont conserves pendant 30 jours avec tous les details pour les investigations forensiques et l'analyse detaillee
• Les syntheses quotidiennes sont conservees pendant un an, fournissant des resumes agreges pour l'analyse des tendances et les rapports trimestriels
• Les syntheses mensuelles sont conservees indefiniment pour les comparaisons d'une annee sur l'autre et les demandes reglementaires couvrant plusieurs annees

Toutes les donnees sont consultables, triables et filtrables. Des exports sont disponibles pour les flux de conformite necessitant l'extraction de donnees pour les auditeurs ou les soumissions reglementaires.

Ce que la detection du shadow AI peut et ne peut pas faire

Il est important d'etre clair sur le perimetre. La detection du shadow AI opere sur les metadonnees reseau. Voici ce qu'elle couvre et ou elle a ses limites.

Ce qu'elle fait :

• Decouvre l'utilisation d'outils d'IA cloud et SaaS a partir des journaux reseau sans agents sur les terminaux ni extensions de navigateur
• Identifie plus de 50 outils d'IA dans cinq categories et extrait les noms de modeles specifiques du trafic API sur AWS Bedrock, Azure OpenAI, Google Vertex AI et les points de terminaison directs des fournisseurs
• Evalue le risque sur une echelle de 0 a 100 selon quatre facteurs ponderes : statut d'approbation, posture de conformite du fournisseur, volume d'utilisation et sensibilite du departement
• Alerte les equipes via 6 types de declencheurs avec 4 types d'actions (notifications, taches, revues de gouvernance, entrees de risque)
• Convertit les outils detectes en actifs gouvernes via un assistant en quatre etapes qui cree des entrees d'inventaire de modeles, attribue des responsables et lance des evaluations de risques
• Analyse 4 formats de journaux prets a l'emploi (Zscaler, Netskope, Squid, cle-valeur generique)

Ce qu'elle ne fait pas :

• Inspecter le contenu HTTPS chiffre. Elle opere sur les metadonnees : domaines, chemins URL, horodatages, identifiants d'utilisateurs. L'extraction de ces elements a partir du trafic chiffre necessite un proxy d'interception TLS ou une passerelle API en amont
• Detecter les modeles d'IA heberges localement (Ollama, instances locales de Llama, serveurs d'inference prives). Ceux-ci ne generent pas de trafic reseau externe
• Capturer les prompts, reponses ou conversations reels. Elle fonctionne uniquement sur les metadonnees d'acces : qui a accede a quoi, quand, depuis quel departement, a quelle frequence
• Bloquer le trafic. Elle est uniquement consultative. Le blocage de l'acces necessite une configuration au niveau du proxy, du pare-feu ou de la couche DNS
• Executer une detection d'anomalies comportementales. Les alertes sont basees sur des regles avec des seuils explicites, et non sur une analyse de motifs par apprentissage automatique

Pour commencer

La detection du shadow AI est un module de la plateforme de gouvernance de l'IA VerifyWise, aux cotes de l'inventaire des modeles, de la gestion des risques, du suivi des cadres de conformite et des evaluations de LLM. Si votre organisation collecte deja des journaux de proxy web ou de pare-feu, vous disposez des donnees necessaires. La question est de savoir si vous les utilisez pour trouver les outils d'IA avant qu'ils ne deviennent des incidents de conformite.

Explorez notre fonctionnalite de detection du shadow AI pour voir comment la decouverte passive basee sur les journaux, la notation des risques et les flux de gouvernance se combinent dans une seule plateforme.

Reservez une demonstration pour voir comment la detection du shadow AI fonctionne avec votre infrastructure de journaux existante, ou explorez la plateforme VerifyWise complete pour voir comment la detection se connecte a la gouvernance.