AI Security Monitoring comment sécuriser l’IA ?

L’AI Security Monitoring sert à voir ce que les outils sécurité classiques ratent souvent dans les systèmes d’IA. Je parle ici de données empoisonnées, prompt injection, attaques adversariales, dépendances douteuses, puis de télémétrie, détection d’anomalies et réponse automatisée avant l’impact en prod.

Pourquoi le SIEM classique rate le signal ?

Le SIEM classique rate le signal parce qu’il surveille très bien l’infrastructure, mais pas assez ce que l’IA comprend, produit et déforme.

Un SIEM, Security Information and Event Management, reste utile. Je ne le remets pas en cause. Il centralise les logs, corrèle des événements, détecte des accès suspects, des scans réseau, des comportements endpoint bizarres. C’est indispensable dans un SOC sérieux.

Mais pour surveiller une IA, ça ne suffit pas. Le risque se cache souvent ailleurs. Dans les modèles, les datasets, les prompts, les sorties, les scores de confiance et les comportements statistiques. J’ai souvent vu des équipes sécurité très bien équipées, avec un SIEM propre, bien maintenu, mais presque aveugles sur ce que fait réellement le modèle en production. Pas par négligence. Juste parce que les bons signaux ne remontaient pas.

Une API métier classique est plutôt déterministe. Vous envoyez une requête, elle applique une règle, elle retourne une réponse attendue. Un modèle d’IA, lui, fonctionne avec des probabilités. Deux entrées très proches peuvent produire deux sorties différentes. Une attaque peut ne générer aucun malware, aucun scan réseau, aucune élévation de privilège visible. Elle peut juste dégrader la décision du modèle, faire baisser la confiance moyenne, pousser un LLM, Large Language Model, à ignorer une instruction système, ou faire approuver des cas qui devraient être bloqués.

C’est là que les sujets deviennent plus subtils. Empoisonnement des données, attaques adversariales, prompt injection, vulnérabilités de supply chain sur les modèles ou les dépendances ML. L’OWASP Top 10 for Large Language Model Applications est une bonne référence sur ces risques, surtout pour la prompt injection et la manipulation des sorties.

Surveillance classique	AI Security Monitoring
Règles fixes, signatures, événements connus	Baselines comportementales, anomalies, dérives
Logs réseau, endpoints, IAM, serveurs	Entrées et sorties d’inférence, scores, prompts, datasets, artefacts ML
Détection d’un incident technique	Détection d’un comportement modèle anormal ou manipulé

La sécurité traditionnelle cherche surtout un événement technique connu. L’AI Security Monitoring cherche aussi une variation anormale dans la façon dont le modèle décide. Et si on veut surveiller sérieusement l’IA, il faut d’abord savoir ce qu’on cherche vraiment.

Quels risques IA surveiller en priorité ?

Les risques IA à surveiller en priorité, ce sont ceux qui touchent les données, les entrées utilisateur, les dépendances et le comportement réel du modèle en production. C’est là que les problèmes deviennent visibles, ou pire, restent invisibles trop longtemps.

Le data poisoning, c’est l’empoisonnement des données. Une modification malveillante, ou juste non maîtrisée, des jeux d’entraînement. Le vrai sujet, c’est la persistance. Une fois le modèle entraîné avec des données polluées, le mauvais comportement peut rester “absorbé” dans le modèle. J’ai déjà vu un client chercher un bug applicatif pendant des jours alors que le problème venait d’un lot de données source modifié sans validation.

À l’ingestion, je surveille les hash, donc les empreintes numériques des fichiers, les contrôles d’intégrité, la dérive de distribution, les écritures non autorisées et les changements suspects dans les sources. En production, je compare le modèle à une baseline comportementale ou à un modèle de référence. Si les décisions dérivent sans raison métier claire, je creuse.

Les attaques adversariales sont plus discrètes. Ce sont des entrées subtilement modifiées, parfois invisibles pour un humain, comme quelques pixels, des tokens ou une formulation légèrement différente, mais capables de provoquer une mauvaise sortie. Exemple simple : un modèle de fraude commence à approuver des cas très proches de ceux qu’il refusait avant. Là, je regarde les clusters d’anomalies dans les logs d’inférence, les requêtes similaires avec des scores très différents, les chutes de confiance et l’apparition de nouveaux groupes d’entrées.

La prompt injection est un classique des LLM, et l’OWASP la classe clairement parmi les risques majeurs. Un LLM ne distingue pas naturellement une instruction d’une donnée. Une injection directe, c’est l’utilisateur qui écrit une consigne malveillante dans un champ. Une injection indirecte, c’est plus vicieux : le modèle lit une page, un document ou un email qui contient une instruction cachée. Je traite donc toute entrée externe comme suspecte, je l’encadre avec des balises explicites, et je filtre ou classe les injections avant le modèle principal.

La supply chain, c’est tout ce qu’on embarque sans toujours le regarder : modèles préentraînés, bibliothèques open-source, datasets tiers, registres, dépendances. Je veux connaître la provenance, vérifier les signatures, figer les hash de dépendances et tenir un SBOM adapté au ML. Un SBOM, c’est l’inventaire des composants logiciels. Les pratiques SBOM sont déjà poussées en cybersécurité moderne, notamment côté NIST, mais l’IA oblige à les étendre aux datasets et aux modèles.

Menace	Signal faible	Contrôle utile
Data poisoning	Dérive source, fichiers modifiés, écritures inattendues	Hash, intégrité, baseline, modèle de référence
Attaque adversariale	Scores instables, chute de confiance, clusters suspects	Analyse des logs d’inférence, détection d’anomalies
Prompt injection	Instructions cachées, sorties hors consigne	Filtrage, balisage des données externes, classification préalable
Supply chain IA	Dépendance non signée, dataset inconnu, modèle non vérifié	Provenance, signatures, hash, SBOM ML

Quelles données faut-il collecter ?

Il faut collecter la télémétrie qui raconte vraiment la vie du modèle. Ce qu’il reçoit, ce qu’il renvoie, comment il tourne, et qui l’utilise. Pas seulement trois logs techniques perdus dans un serveur.

Le premier bloc, c’est la télémétrie d’inférence. L’inférence, c’est le moment où le modèle répond à une requête. Je veux voir les entrées reçues, les sorties produites, les scores de confiance, les raisons de blocage par les filtres, les catégories de prompts, la longueur des requêtes, le taux de refus, le taux d’erreur, et la latence par type d’entrée. C’est souvent là qu’on repère les comportements bizarres. Un prompt trop long, une série de refus, une sortie inhabituelle, ça peut être du bruit. Ou le début d’un vrai problème.

Mais attention aux données sensibles. Je ne collecte pas tout en clair “au cas où”. Je prévois du masquage, de la minimisation, et une vraie gouvernance. Les prompts peuvent contenir des données clients, du code interne, des secrets, parfois même des informations RH. J’ai déjà vu des logs IA plus sensibles que la base métier elle-même.

Le deuxième bloc, ce sont les métriques runtime. Le runtime, c’est l’environnement où le modèle tourne. CPU, GPU, mémoire, latence, timeouts, erreurs, saturation, changements de version, incidents de pipeline. Ces métriques ne prouvent pas une attaque à elles seules. Mais elles donnent le contexte. Si le modèle commence à répondre lentement au même moment où les prompts changent de forme, là ça devient intéressant.

Le troisième bloc, ce sont les schémas d’accès. Qui appelle le modèle, depuis quelle application, à quelle fréquence, avec quel rôle, depuis quel environnement, avec quel volume. Je surveille surtout les accès inattendus, les pics de requêtes, les appels depuis un nouveau service, les changements brutaux de pattern. Un modèle appelé soudainement par une application qui n’a rien à faire là, c’est rarement anodin.

La pile d’observabilité doit rester simple et propre :

• Instrumentation des applications IA et pipelines ML
• Logs structurés pour prompts, réponses, scores et filtres
• Service de détection d’anomalies et de dérive
• Enrichissement avec contexte asset, version modèle, propriétaire, criticité
• Transmission au SIEM avec alertes exploitables

Je préfère garder le SIEM comme tour de contrôle. Le SIEM, c’est l’outil central qui consolide les alertes sécurité. Mais je ne lui demande pas de deviner seul le comportement d’un modèle. Je l’alimente avec des signaux déjà propres, enrichis avec la threat intelligence et la CMDB, c’est-à-dire l’inventaire des assets, propriétaires et dépendances.

La qualité de détection dépend d’abord de la qualité de télémétrie. Sans traces propres, on fait du ressenti, pas de la sécurité.

Comment détecter sans règles fixes ?

Je détecte sans règles fixes en construisant des baselines comportementales, puis en cherchant ce qui s’écarte du comportement normal. Une baseline, c’est simplement une référence vivante. Elle apprend ce qui est habituel pour un modèle, une application, une population d’utilisateurs, une version donnée, parfois même un segment métier précis.

Une règle cherche quelque chose qu’on connaît déjà. Un prompt interdit, une adresse IP suspecte, un seuil dépassé. C’est utile, mais ça rate tout ce qui est nouveau. L’apprentissage non supervisé fait autre chose. Il observe les données sans qu’on lui donne une liste d’attaques à reconnaître, puis il regroupe les comportements proches et remonte les écarts. C’est très pratique quand l’attaque ne ressemble pas encore à un scénario documenté.

Les signaux intéressants sont rarement spectaculaires au début. C’est souvent une petite variation qui devient bizarre quand on la regarde avec le bon contexte.

• Une hausse des outputs bloqués par les filtres.
• Une baisse de confiance moyenne sur les prédictions.
• De nouveaux clusters d’entrées qui ne ressemblaient pas au trafic habituel.
• Une explosion du taux de refus.
• Une hausse des réponses hors politique.
• Une divergence entre le modèle en production et un modèle de référence.
• Une variation anormale sur un segment précis, par exemple un pays, un client ou une application appelante.

Ce qui compte, c’est de relier ces signaux aux menaces. Une dérive lente après réentraînement peut faire penser à du data poisoning, donc à des données d’entraînement polluées. Des clusters d’entrées très proches avec des décisions incohérentes peuvent indiquer une attaque adversariale. Une hausse de prompts bloqués ou de consignes contradictoires peut signaler une prompt injection. Un changement de comportement juste après la mise à jour d’une dépendance peut pointer vers un problème supply chain.

Je fais quand même attention à un point. Le but n’est pas de déclencher une panique à chaque anomalie. Une alerte sans contexte, ça fatigue les équipes. Il faut l’enrichir avec la version du modèle, le dataset utilisé, le dernier pipeline lancé, la dépendance changée, l’application appelante et la criticité business. C’est là que la CMDB, la base qui décrit les composants du SI, le SIEM, l’outil qui centralise les événements de sécurité, et la gestion de configuration deviennent vraiment utiles.

Signal	Hypothèse	Action
Baisse forte de confiance moyenne	Dérive ou attaque adversariale	Comparer au modèle de référence et analyser les clusters
Hausse des prompts bloqués	Prompt injection ou abus	Isoler les sources et renforcer le classifieur d’entrée
Changement après réentraînement	Data poisoning ou dataset instable	Vérifier intégrité, provenance et distribution

Comment automatiser la réponse ?

Pour automatiser la réponse, je sépare toujours quatre blocs : détection, enrichissement, décision et confinement. Le but n’est pas de tout bloquer comme un bourrin. Le vrai sujet, c’est de réduire le temps d’exposition, sans casser la prod pour une alerte mal qualifiée.

Chaque type de menace mérite une réponse différente. C’est là que beaucoup d’équipes se plantent : elles veulent un bouton rouge unique. En IA, c’est rarement propre.

Data poisoning	Je bloque le réentraînement, j’isole le dataset suspect, je vérifie les hash, je reviens à une version saine et je compare le comportement avec un modèle de référence.
Attaque adversariale	Je limite temporairement certaines classes d’entrées, j’augmente les contrôles, je route vers une revue humaine et je déclenche une analyse de clusters pour repérer les motifs anormaux.
Prompt injection	J’applique un classifieur d’injection avant le LLM, j’encapsule les contenus externes, je retire des permissions outil si besoin et je bloque les prompts à risque.
Supply chain	Je bloque le déploiement, je vérifie les signatures et les registres, je compare le SBOM, c’est l’inventaire des composants logiciels, puis je reviens à une dépendance validée.

Le plus efficace, c’est de brancher ça sur les outils déjà en place. Le SIEM centralise et corrèle les logs. La gestion de configuration dit quel modèle tourne où. La CMDB, la base qui décrit les assets de l’entreprise, donne la criticité métier. Un outil low code ou un SOAR, Security Orchestration Automation and Response, déclenche les playbooks. Dans mes projets, les gains viennent souvent de playbooks simples et propres, pas d’une grosse usine à gaz que personne n’ose toucher.

Un bon playbook ressemble à ça :

• Qualifier l’alerte avec version modèle, source, criticité, volume et historique.
• Vérifier si un changement récent existe côté dataset, modèle, prompt système ou dépendance.
• Appliquer un confinement proportionné comme throttling, blocage d’entrée, rollback ou revue humaine.
• Créer un ticket enrichi avec preuves, logs, métriques et propriétaire.
• Mettre à jour la baseline ou le contrôle si l’incident est confirmé.

Le meilleur scénario reste quand même d’attraper le problème avant la production. Je mets donc des moniteurs dans les pipelines, une vérification de provenance, un SBOM ML pour les modèles et dépendances, des contrôles d’intégrité des données et une classification des injections de prompt avant le modèle principal. C’est moins spectaculaire qu’une réponse automatique en prod, mais c’est souvent là que la sécurité IA devient vraiment rentable.

Et si on surveillait enfin l’IA comme un vrai système critique ?

L’AI Security Monitoring, ce n’est pas un SIEM avec deux règles en plus. C’est une façon de surveiller les modèles, les données, les prompts, les dépendances et les comportements en production. Les vrais signaux sont souvent statistiques, discrets, parfois invisibles dans les logs classiques. Il faut collecter la bonne télémétrie, créer des baselines, détecter les dérives, enrichir les alertes et automatiser des réponses proportionnées. C’est comme ça qu’on repère data poisoning, prompt injection, attaques adversariales ou supply chain avant que ça coûte cher. Le bénéfice pour vous est simple, vous gardez le contrôle sur vos systèmes IA sans freiner le business.

FAQ

• Qu’est-ce que l’AI Security Monitoring ?
  L’AI Security Monitoring consiste à surveiller les systèmes d’IA au-delà des logs techniques classiques. On regarde les entrées, les sorties, les scores, les prompts, les datasets, les dépendances, les dérives et les comportements anormaux du modèle en production.
• Pourquoi un SIEM classique ne suffit pas pour l’IA ?
  Un SIEM classique cherche surtout des événements connus avec des règles. Les attaques IA peuvent être plus subtiles. Une donnée empoisonnée, une prompt injection ou une attaque adversariale peut changer le comportement du modèle sans déclencher de signal réseau évident.
• Comment détecter un empoisonnement des données ?
  Je surveille d’abord l’intégrité à l’ingestion avec hash, dérive de distribution et écritures non autorisées. Ensuite je compare le comportement du modèle en production avec une baseline ou un modèle de référence. Une dérive étrange après réentraînement mérite une analyse immédiate.
• La prompt injection concerne seulement les chatbots ?
  Non. Elle concerne surtout les LLM connectés à des outils, documents, emails, pages web ou bases internes. L’injection peut être directe dans un champ utilisateur, ou indirecte via un contenu externe récupéré pendant la tâche.
• Quels contrôles mettre en place en premier ?
  Je commencerais par la télémétrie d’inférence, les baselines comportementales, les contrôles d’intégrité des données, la classification des prompts à risque, le suivi de provenance des modèles et un SBOM pour les artefacts ML. C’est une base solide avant d’automatiser les réponses.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’accompagne des équipes chez Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football, Texdecor et d’autres sur des sujets data, IA, mesure et automatisation. Si vous voulez sécuriser, monitorer ou industrialiser vos usages IA sans créer une usine à gaz, contactez-moi.