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

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.

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.

Décompose les exigences et regarde quelle technologie répond à chacune. Créer un ticket, collecter les logs pertinents et proposer un playbook sont des actions qui touchent plusieurs systèmes, autrement dit de l’orchestration. Exécuter ces étapes automatiquement dès qu’une alerte de gravité élevée se déclenche relève de l’automatisation déclenchée par des événements. C’est en proposant le playbook le plus pertinent à partir du contexte de l’alerte que l’assistance de l’IA apporte de la valeur. Laisser la décision finale à un analyste correspond à la validation human-in-the-loop. Les analystes confirment les actions à fort impact, mais ils n’ont pas besoin d’approuver chaque étape de routine. Une plateforme SOAR (security orchestration, automation and response) appartient à la catégorie conçue pour cette combinaison. Ses playbooks sont des ensembles préconfigurés d’actions de remédiation qui s’exécutent automatiquement lorsqu’une alerte ou un incident correspond à une règle, ou qu’un analyste déclenche manuellement pendant une investigation.

Chaque alternative laisse de côté au moins une exigence. À elles seules, des règles de corrélation statiques détectent et alertent, mais rien dans cette option n’ouvre de ticket ni ne collecte de logs. Un chatbot sans intégrations peut discuter d’un incident, mais il ne peut atteindre ni le système de tickets ni le stockage des logs, et il ne peut donc exécuter lui-même aucune de ces étapes. Un runbook piloté par des tâches planifiées n’est ni événementiel ni adaptatif. Les tâches s’exécutent selon un minuteur, quoi qu’il se soit passé, et les étapes manuelles attendent toujours une personne.

Conseil pour l’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 humaine explicite t’indique que la bonne réponse garde l’analyste dans la boucle au lieu de l’en retirer.

L’objectif 1.2 énumère des concepts de traitement des données essentiels à la sécurité des données d’IA : nettoyage, vérification, lignage, intégrité, provenance, augmentation et équilibrage. La provenance des données consigne l’origine et la propriété des données, tandis que le lignage des données suit leurs déplacements et leurs transformations dans le pipeline ; ensemble, ils fournissent les preuves documentées nécessaires pour évaluer la fiabilité et appuyer les audits et les investigations d’incidents. C’est important pour la sécurité, car des données empoisonnées ou altérées sont bien plus faciles à détecter lorsque l’origine et l’historique sont documentés et vérifiables. Ne confonds pas provenance/lignage avec l’augmentation (création de données synthétiques), l’équilibrage (correction du déséquilibre entre classes) ou le tatouage numérique (intégration de marques de propriété ou détection de contenu généré par l’IA). Conseil pour l’examen : « d’où viennent les données et comment ont-elles été transformées ? » correspond à la provenance et au lignage.