Atténuer les risques liés à l'IA/ML dans les logiciels critiques

Temps de lecture : 8 minutes

L’intelligence artificielle (IA) et l’apprentissage automatique (Machine Learning (ML)) sont les nouvelles frontières pour les développeurs de logiciels embarqués critiques pour la sécurité. Ces technologies peuvent intégrer et analyser des données à grande échelle et prendre en charge des capacités avec une intelligence de type humain. En tant que praticiens de la sécurité fonctionnelle habitués à des processus et techniques d’atténuation des risques  élaborés depuis des décennies, les développeurs travaillant dans ce domaine doivent s’adapter à l’énorme promesse de l’IA/ML sans compromettre la sécurité à aucun niveau des systèmes qu’ils construisent.

ChatGPT, GitHub Copilot, Amazon Q Developer et d’autres outils d’IA générative similaires ont suscité beaucoup de buzz et de confusion autour de ce qu’est réellement l’IA/ML. Pour le développement critique de la sécurité, l’IA/ML englobe un large éventail de capacités avec des applications apparemment illimitées, des assistants de codage aux principales fonctionnalités embarquées.

L’Oxford English Dictionary (OED) définit l’IA comme la « capacité des ordinateurs ou d’autres machines à présenter ou à simuler un comportement intelligent ; le domaine d’étude concerné par cette question ». L’OED définit l’apprentissage automatique comme la « capacité des ordinateurs à apprendre et à s’adapter sans suivre d’instructions explicites, en utilisant des algorithmes et des modèles statistiques pour analyser et déduire des modèles dans les données ».

Les algorithmes d’IA sont classés en « étroits » ou « généraux ». L’IA étroite (ou faible) exécute des tâches spécifiques et n’a pas l’intelligence générale humaine. Deep Blue d’IBM est peut-être l’exemple le plus célèbre d’IA faible, tout comme les chatbots modernes, les systèmes de reconnaissance d’images, les modèles de maintenance prédictive et les voitures autonomes. La génération automatisée de vecteurs de tests unitaires est une forme d’IA faible car elle « simule un comportement intelligent » en dérivant des stubs de test et des contrôles à partir du code existant. La figure 1 montre un ensemble de vecteurs de test créés automatiquement par logiciel, éliminant ainsi le besoin pour les humains de passer du temps à les créer.

En revanche, l'IA générale (ou forte) accomplit une variété de tâches et peut apprendre à résoudre de nouveaux problèmes comme si elle s'appuyait sur l'intelligence humaine. De tels systèmes n'ont pas encore été développés et il y a beaucoup de débats sur leur possibilité de notre vivant (en dépit de l'ordinateur principal de Star Trek).

Le Machine Learning (ML) peut être classé selon les types de données facilitant ses algorithmes, soit « étiquetées » soit « non étiquetées ». Les données étiquetées font référence aux données qui ont été annotées d'une manière ou d'une autre avec des résultats corrects ou des valeurs cibles. Ce type de données est généralement plus difficile à acquérir et à stocker que les données non étiquetées.

Les quatre principaux types d’apprentissage automatique sont :

• Apprentissage supervisé : l'algorithme est formé sur des données étiquetées de manière à ce que la sortie correcte soit fournie pour chaque entrée. L'expérience acquise en mappant les entrées aux sorties fournit une base pour les prédictions sur de nouvelles données.
• Apprentissage non supervisé : l'algorithme reçoit des données non étiquetées et identifie des modèles ou des structures à utiliser par les applications.
• Apprentissage semi-supervisé : l’algorithme est formé sur une combinaison de données étiquetées et non étiquetées.
• Apprentissage par renforcement : l’algorithme apprend à prendre des séquences de décisions basées sur un système de récompense, en recevant un retour sur la qualité de ses décisions et en ajustant son approche en conséquence.

Bien que les différents types d’apprentissage automatique nécessitent différents niveaux d’intervention humaine, ils s’alignent sur des normes de sécurité fonctionnelle qui ont fait leurs preuves pour produire des logiciels suffisamment fiables dans le contexte de leur déploiement. Par exemple, la norme de sécurité fonctionnelle IEC 62304 « Logiciels de dispositifs médicaux – processus du cycle de vie du logiciel » est typique d’une approche « axée sur les exigences avant tout » incarnée par l’apprentissage supervisé et semi-supervisé.

Cette norme n’insiste pas sur un modèle de processus spécifique, mais elle est souvent représentée comme un modèle en V comme le montre la figure 2.

L'International Medical Device Regulators Forum (IMDRF) publie un document définissant une approche systématique de classification des risques pour les logiciels destinés à des fins médicales. Intitulé « Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations », le document classe les risques d'un dispositif donné en fonction d'un spectre d'impact sur les patients, comme le montre la figure 3.

Cela inclut des facteurs tels que l’utilisation prévue du logiciel, l’importance des informations fournies par le logiciel pour la prise de décisions médicales et les conséquences potentielles d’une défaillance du logiciel.

Comme cette classification est indépendante de la méthodologie utilisée pour créer le logiciel, les développeurs de dispositifs médicaux peuvent appliquer ces lignes directrices pour déterminer le niveau d’exigences et de contrôle réglementaire nécessaire pour les logiciels basés sur des techniques basées sur l’IA/ML.

De son côté, l’industrie automobile adopte une approche plus proactive, en élaborant de nouvelles normes pour s’adapter à la croissance des applications d’IA/ML :

• ISO/CD PAS 8800, Véhicules routiers — Sécurité et intelligence artificielle : Cette norme définira les propriétés liées à la sécurité et les facteurs de risque ayant un impact sur les performances insuffisantes et le dysfonctionnement de l'IA.
• ISO/CD TS 5083, Véhicules routiers — Sécurité des systèmes de conduite automatisée — Conception, vérification et validation : Ce document fournira un aperçu et des conseils sur les étapes de développement et de validation d'un véhicule automatisé équipé d'un système de conduite automatisée sûr.

La figure 4 illustre la manière dont ces normes s’inscrivent dans le contexte des lignes directrices existantes de l’industrie.

Dans les systèmes modernes, les sorties des composants basés sur l'IA/ML seront envoyées à des logiciels créés avec des techniques non basées sur l'IA, y compris des systèmes impliquant des humains. Cela permet de séparer les domaines familiers aux développeurs critiques pour la sécurité dans lesquels les composants IA/ML sont contenus, et les composants non IA sont conçus pour atténuer les risques liés aux interactions entre domaines.

La norme IEC 62304:2006 +AMD1:2015 autorise cette approche, en indiquant que « l'ARCHITECTURE logicielle doit favoriser la séparation des éléments logiciels nécessaires à un fonctionnement sûr et doit décrire les méthodes utilisées pour assurer une séparation efficace de ces ÉLÉMENTS LOGICIELS ». Elle indique en outre que la séparation ne se limite pas à la séparation physique, mais plutôt à « tout mécanisme qui empêche un ÉLÉMENT LOGICIEL d'affecter négativement un autre ». Cela suggère que la séparation logicielle entre les composants IA/ML et les composants traditionnels est valide.

Les outils de test actuels peuvent prendre en charge l’évaluation des risques et l’atténuation de ces interactions inter-domaines. Comme l’illustre la figure 5, l’analyse des souillures peut valider les flux de données provenant des composants IA/ML dans les logiciels développés de manière traditionnelle.

Le document de l’Agence européenne de la sécurité aérienne (AESA), « Feuille de route de l’intelligence artificielle : une approche centrée sur l’humain de l’IA dans l’aviation », contient des suggestions supplémentaires pour garantir la sécurité de l’IA :

• Inclure un humain aux commandes ou dans la boucle.
• Surveillez les résultats de l'IA/ML via un système de sauvegarde traditionnel.
• Encapsuler le ML dans des approches basées sur des règles.
• Surveillez l’IA via un agent d’IA indépendant.

Les développeurs de systèmes critiques pour la sécurité sont prudents à l’égard des algorithmes d’IA/ML et cherchent des moyens d’atténuer les risques de manière proactive. Pour les équipes qui hésitent à adopter l’IA/ML, les principes de sécurité fonctionnelle existants, tels que la séparation des domaines, peuvent être efficaces pour atténuer les risques. Les outils existants peuvent également être utilisés pour déterminer l’influence de l’IA/ML sur les éléments logiciels développés de manière traditionnelle.