Shadow AI : un inventaire ne suffit pas s'il n'explique pas le risque

Le Shadow AI, terme de l'industrie sans définition réglementaire, recouvre les actifs IA que les équipes responsables ne connaissent pas ou ne gouvernent pas. Une liste de ces actifs est un point de départ. Elle ne devient utile qu'au moment où elle permet de décider quoi corriger en premier.

Ce qu'il faut chercher

L'IA d'une organisation ne se limite pas aux abonnements à des assistants conversationnels. Les types d'actifs à inclure :

• modèles : hébergés en interne, appelés via une API externe, affinés sur des données propres ;
• agents : développés en interne ou créés par des équipes métier sur une plateforme ;
• datasets : d'entraînement, d'évaluation, d'indexation RAG ;
• pipelines : entraînement, affinage, ingestion ;
• notebooks : souvent le premier endroit où des données de production rencontrent un modèle ;
• serveurs MCP : installés sur des postes ou déployés comme services ;
• endpoints d'inférence ;
• services IA SaaS ;
• workloads : conteneurs et fonctions qui exécutent l'ensemble.

Trois niveaux de maturité

Niveau 1 : trouvé

On sait que l'actif existe. C'est déjà un progrès, mais une ligne « endpoint-inference-07 » dans un tableur ne dit ni qui en répond, ni ce qu'il traite.

Niveau 2 : compris

On connaît son owner, sa finalité, son environnement, les données qu'il utilise, ses interfaces et ses dépendances. On peut contacter quelqu'un et situer l'actif dans le système d'information.

Niveau 3 : actionnable

On connaît son exposition, ses permissions, sa criticité et le risque qui en découle, ce qui permet de fixer une priorité de remédiation. À ce stade, deux actifs d'apparence identique peuvent recevoir des priorités opposées.

Les champs d'un inventaire utile

• actif et type ;
• owner (une équipe ou une personne joignable) ;
• finalité ;
• environnement (production, test, poste) ;
• modèle utilisé ;
• données traitées et leur classification ;
• outils accessibles ;
• credentials utilisés et leur portée ;
• exposition externe ;
• dépendances ;
• criticité ;
• date de dernière revue.

Tous ces champs n'existeront pas pour chaque actif. Un dataset n'a pas d'outils ; un service SaaS n'expose pas toujours le modèle qu'il utilise. L'important est que les champs vides soient visibles comme tels : une inconnue sur les credentials d'un agent en production est en soi une information de risque.

Exemple de priorisation : un agent de test sans accès réseau et un agent de production connecté par un serveur MCP à votre CRM avec un token en écriture apparaissent tous deux au niveau 1 comme « agent ». Le niveau 3 les sépare immédiatement.

Découvrir n'est pas contrôler

Un agent découvert conserve les permissions qu'il avait la veille. L'inventaire révèle qu'un compte de service donne à un agent l'accès en écriture à toute une base ; il ne réduit pas ce droit. La réduction passe par le moindre privilège, l'autorisation contextuelle des actions et les contrôles runtime, traités dans Le rôle d'un agent n'est pas son autorisation.

Le rôle de l'AI-SPM

AI-SPM est une catégorie de produits qui peut automatiser une partie de ce travail : découverte des actifs IA, analyse de leur configuration, corrélation avec leur exposition. Ce n'est pas un standard ; les périmètres varient d'un produit à l'autre. Avant d'en retenir un, vérifier quels types d'actifs de la liste ci-dessus il découvre réellement, par quels moyens (API cloud, analyse de code, observation runtime), et s'il alimente les champs des niveaux 2 et 3 ou seulement le niveau 1.