CompTIA SecAI+ — Questions d'entraînement et examen blanc

Décompose les exigences et regarde quelle technologie satisfait chacune d'elles. Créer un ticket, rassembler les logs pertinents et proposer un playbook, ce sont trois actions réparties sur trois systèmes différents, c'est-à-dire de l'orchestration. Les exécuter automatiquement dès qu'une alerte de sévérité élevée se déclenche, c'est de l'automatisation pilotée par l'IA. Laisser la décision finale à un analyste, c'est de la validation human-in-the-loop. Une plateforme SOAR — security orchestration, automation and response — est précisément la catégorie conçue pour cette combinaison : des ensembles préconfigurés d'actions de remédiation qui s'exécutent automatiquement quand une alerte ou un incident correspond à une règle, ou qu'un analyste déclenche manuellement pendant une investigation.

Chaque alternative laisse tomber une exigence. Les règles de corrélation statiques détectent et alertent mais n'agissent pas, donc aucun ticket n'est ouvert et aucun log n'est collecté. Un chatbot sans intégrations peut discuter d'un incident mais n'atteint ni le système de ticketing ni le stockage des logs, donc rien de ce qu'il propose ne peut être exécuté. Un runbook manuel piloté par des tâches planifiées n'est ni événementiel ni adaptatif, puisqu'il s'exécute selon une minuterie quoi qu'il se soit passé et qu'un humain effectue toujours chaque étape.

Astuce d'examen : lis les verbes de l'énoncé. Détecter renvoie à la supervision, orchestrer et remédier renvoient aux outils de réponse, et un point de décision humain explicite t'indique que la réponse attendue garde l'analyste dans la boucle plutôt que de l'en retirer.

L’EU AI Act est une législation majeure qui établit un cadre réglementaire fondé sur le risque pour l’intelligence artificielle. Il classe les systèmes d’IA en quatre niveaux de risque : risque inacceptable (interdit purement et simplement, comme les systèmes de social scoring), risque élevé (soumis à des exigences strictes, y compris des évaluations de conformité, comme l’IA dans le recrutement ou les forces de l’ordre), risque limité (obligations de transparence, comme les chatbots qui doivent indiquer qu’ils sont une IA) et risque minimal (aucune exigence spécifique, comme les filtres antispam). Les organisations qui déploient de l’IA dans l’UE ou traitent les données de citoyens de l’UE doivent respecter les exigences du niveau applicable. L’Act inclut aussi des dispositions pour les modèles d’IA à usage général, comme les grands modèles de langage. Comprendre la classification des risques de l’EU AI Act est essentiel pour l’examen SecAI+, car elle représente l’approche réglementaire la plus complète au monde en matière de gouvernance de l’IA. Astuce d’examen : l’EU AI Act comporte quatre niveaux de risque — retiens la hiérarchie, de l’inacceptable au minimal.

L'objectif 1.2 énumère les concepts de traitement des données essentiels à la sécurité des données en IA : nettoyage des données, vérification, lineage, intégrité, provenance, augmentation et balancing. La data provenance consigne l'origine et la propriété des données, tandis que le data lineage suit leurs déplacements et leurs transformations tout au long de la pipeline ; ensemble, ils établissent la fiabilité et facilitent les audits et les investigations d'incident. C'est important pour la sécurité, car des données empoisonnées ou altérées sont bien plus faciles à repérer quand l'origine et l'historique sont documentés et vérifiables. Ne confonds pas provenance/lineage avec l'augmentation (créer des données synthétiques), le balancing (corriger un déséquilibre de classes) ou le watermarking (intégrer des marques de propriété ou détecter des contenus générés par IA). Astuce d'examen : 'd'où viennent les données et comment ont-elles été transformées' équivaut à provenance et lineage.

Deux exigences doivent être satisfaites par un seul contrôle, et cela réduit vite le champ. L'attribution des coûts exige une comptabilisation par consommateur ; l'isolation en partage équitable exige un plafond par consommateur. Une politique de limite de tokens sur la gateway apporte les deux, car elle applique des limites par consommateur de l'API en fonction de la consommation de tokens et te laisse définir un débit de tokens par minute en plus d'un quota sur une période plus longue, rattaché à quelque chose qui identifie l'appelant, comme une clé d'abonnement.

Les tokens sont la bonne unité. Le coût comme la capacité du backend d'un modèle de langage évoluent avec les tokens plutôt qu'avec le nombre de requêtes, donc une simple limite de requêtes par minute est une mauvaise approximation : un seul prompt très long peut consommer plus de capacité que mille prompts courts et passer malgré tout un contrôle de débit de requêtes. Compter par consommateur est ce qui transforme une soupape de sécurité globale en isolation, car une équipe qui atteint son plafond est limitée sans toucher à la marge des autres.

Les distracteurs résolvent d'autres problèmes. Un filtre de sujets interdits est un contrôle de sûreté du contenu et ne mesure rien. Le cache sémantique réduit les appels au backend pour les prompts répétés, ce qui aide le coût moyen mais ne garantit rien en matière d'équité ou d'attribution. Une fenêtre de contexte plus grande augmente ce qu'une seule requête peut consommer, ce qui aggrave le risque de famine au lieu de le réduire.

Astuce d'examen : quand une question sur les gateways associe coût et capacité, cherche le contrôle dont l'unité est le token et dont la portée est la clé de consommateur.