Cybersécurité des systèmes d’IA : appliquer l’article 15 de l’AI Act.
La cybersécurité d’un système d’IA couvre l’infrastructure classique et les vulnérabilités propres aux modèles, aux données et aux interfaces. L’article 15 demande un niveau approprié pendant tout le cycle de vie. La preuve associe analyse de menace, mesures techniques, tests, limites connues et surveillance.
Un système d’IA à haut risque doit atteindre un niveau approprié d’exactitude, de robustesse et de cybersécurité. Les mesures couvrent les erreurs, défaillances, boucles de rétroaction et attaques spécifiques à l’IA, notamment l’empoisonnement, les exemples adversariaux, l’évasion et les atteintes à la confidentialité.
Cluster éditorial : Conformité opérationnelle AI Act · Intention : Sécuriser un système d’IA selon les exigences de l’article 15
En bref
L’essentiel à retenir
01
Menaces classiques et spécifiques réunies
02
Performance suivie sur le cycle de vie
03
Attaques adversariales testées
04
Incidents reliés aux versions et mesures
01
Définir le système à protéger
Cartographiez le modèle, les données, les API, l’interface, l’infrastructure, les bibliothèques, les outils de préparation et les dépendances tierces. Identifiez les environnements d’entraînement, de test et de production. Les actifs comprennent aussi les poids, prompts système, journaux, configurations et résultats d’évaluation.
Reliez cette architecture aux rôles et à la finalité. Un service externe, un modèle embarqué et un système qui continue d’apprendre présentent des surfaces différentes. Attribuez chaque composant à un propriétaire et conservez les versions. Une vulnérabilité ne peut pas être traitée si personne ne sait quelle version du modèle ou du jeu de données est en production.
Ajoutez aux menaces classiques l’empoisonnement des données, l’empoisonnement de modèles, les exemples adversariaux, l’évasion, l’extraction d’information, l’inversion, les défauts du modèle et les manipulations par les entrées. Pour l’IA générative, examinez les instructions malveillantes, les connecteurs et les sorties susceptibles de déclencher une action.
Décrivez l’adversaire, l’accès nécessaire, le chemin d’attaque, la conséquence et la capacité de détection. Priorisez selon la finalité et les personnes affectées. Une attaque modifiant silencieusement un classement peut être plus grave qu’une indisponibilité visible. Intégrez aussi les erreurs non malveillantes, car la robustesse couvre fautes, incohérences et situations inattendues.
Protégez la provenance et l’intégrité des données, les accès aux modèles, les secrets, les environnements et la chaîne logicielle. Validez les entrées et sorties, limitez les permissions, segmentez les services et préparez un mode dégradé. Les mesures doivent correspondre au risque, pas à une liste générique.
Pour les composants tiers, demandez le processus de vulnérabilité, les notifications, les versions, les évaluations et les conditions d’assistance. Prévoyez la réversibilité. Un fournisseur peut corriger une vulnérabilité en modifiant le comportement du modèle, ce qui impose un nouveau test fonctionnel et réglementaire. Sécurité et gestion des changements doivent partager la même chronologie.
Définissez des scénarios avant l’évaluation : données manquantes, bruit, dérive, entrée hors distribution, charge, panne d’un composant, manipulation adversariale et tentative d’exfiltration. Mesurez la performance globale et sur les groupes pertinents. Vérifiez le passage à un état sûr lorsque les limites sont dépassées.
Conservez l’environnement, les jeux de test, les outils, les versions, les résultats et la décision. Faites corriger les écarts puis rejouez les tests de régression. Un test d’intrusion classique ne couvre pas nécessairement les comportements du modèle. Associez compétences sécurité, data science, métier et qualité pour interpréter les conséquences.
Les instructions destinées au déployeur présentent les niveaux d’exactitude et les métriques pertinentes, ainsi que les circonstances connues qui peuvent les affecter. Elles décrivent les exigences matérielles, la maintenance, les mises à jour et les mesures de supervision. Une limite importante doit être compréhensible pour les personnes qui exploitent le système.
Évitez les pourcentages sans contexte. Indiquez la population, le jeu de test, la période, le seuil et les conséquences d’une erreur. Expliquez les signaux qui imposent une vérification ou une interruption. Le déployeur doit pouvoir intégrer ces informations dans ses propres procédures et surveiller le comportement réel.
Collectez les événements utiles, les anomalies, les changements de distribution, les échecs de contrôle, les tentatives d’attaque et les incidents signalés par les déployeurs. Définissez des seuils et une astreinte adaptée au risque. Préservez les éléments sans recopier inutilement des données personnelles ou confidentielles.
Le plan de réponse associe sécurité, produit, data, juridique, conformité et communication. Il prévoit la limitation, le correctif, la notification et la décision de reprise. Alimentez le système de gestion des risques et la documentation technique. Les enseignements deviennent de nouveaux tests et des exigences fournisseurs.
