Choisir un modèle IA pour le SOC : évaluer les erreurs avant le tarif
Comparez les modèles IA sur des dossiers SOC représentatifs : preuves, omissions, abstention et travail de reprise, avant d’arbitrer leur coût.
Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.
Le prix d’un modèle renseigne sur une composante du budget. Il ne permet pas, à lui seul, de prévoir sa fiabilité pour qualifier une alerte ou expliquer une chronologie.
Un choix de modèle pour le SOC devrait donc commencer par les erreurs que l’équipe cherche à éviter.
Le NIST recommande de tester les systèmes d’IA avant leur déploiement puis régulièrement en exploitation. Sa fonction « Measure » associe des méthodes quantitatives et qualitatives pour apprécier les risques.
Nous proposons d’appliquer ce principe à un corpus représentatif du travail des analystes. Source : NIST, AI RMF Core.
Constituez un jeu de dossiers comprenant des situations simples, ambiguës et incomplètes. Les scénarios peuvent provenir d’incidents clôturés, après préparation et autorisation appropriées. Retirez les éléments inutiles et séparez les données d’évaluation de celles utilisées pour ajuster les instructions.
Sinon, une bonne performance risque surtout de refléter la familiarité avec les exemples.
Définissez plusieurs critères observables. Le modèle retrouve-t-il les événements importants ? Distingue-t-il les faits établis des hypothèses ? Cite-t-il une preuve accessible ? Signale-t-il qu’une information manque ? Évite-t-il de conclure à partir d’un événement isolé ?
Ces critères produisent un diagnostic plus utile qu’une note globale unique.
Il faut aussi classer les conséquences des erreurs. Une formulation maladroite et l’omission d’un compte compromis n’ont pas le même poids. Avant le test, l’équipe doit préciser les défauts éliminatoires et les limites acceptables pour l’usage envisagé.
Un modèle adapté à une synthèse préparatoire peut rester inadapté à une recommandation de confinement.
Comparez les candidats dans des conditions identiques : mêmes données disponibles, mêmes outils, même consigne et même format attendu. Répétez les scénarios sensibles pour observer les variations.
Faites relire les résultats sans afficher systématiquement le nom du fournisseur, afin de limiter l’influence de sa réputation.
Le coût opérationnel inclut ensuite le temps de vérification et de correction. Une réponse moins chère mais nécessitant une reprise fréquente peut réduire l’intérêt du dispositif.
À l’inverse, un modèle plus coûteux doit démontrer un bénéfice réel sur les usages retenus.
Conservez enfin la version évaluée et les conditions du test. Un changement de modèle, de connecteur ou de consigne justifie une nouvelle vérification ciblée.
Vous préparez un pilote ? Un échange avec Seculogik peut commencer par la définition d’un petit corpus et d’une grille d’acceptation liés à vos risques, avant toute décision de généralisation.