KANBrief 3/22
Comment contrôler la sécurité fonctionnelle et opérationnelle de systèmes d’intelligence artificielle (IA) quand il est impossible de recourir pour cela aux méthodes classiques d’évaluation, les systèmes en question étant en effet très complexes, voire capables de s’auto-perfectionner ? Les « cas d’assurance » sont l’option à retenir lorsqu’on a recours à de nouvelles technologies potentiellement critiques pour la sécurité et pour lesquelles on ne dispose pas encore d’expérience pratique suffisante.
Malgré des années de discussion dans le contexte de la normalisation et de la réglementation, il n’existe pas encore de consensus sur la définition à donner à un « système d’IA ». Au niveau des instances de réglementation européenne, on semble s’être pratiquement accordé sur le fait qu’un système d’IA est un certain type de logiciel. Ce qui est moins clair, en revanche, c’est la question de savoir dans quelle mesure il se distingue d’un logiciel classique.
Dans le cas des systèmes autonomes et semi-autonomes, les procédures normalisées d’évaluation de la sécurité se heurtent de plus en plus souvent à leurs limites. Aussi simplement conçu soit-il, un concept de sécurité peut prendre d’énormes proportions quand il s’agit de l’automatisation de tâches complexes exécutées dans des environnements eux-mêmes complexes. Différentes mesures, comme la gestion des incertitudes lors de la détection de l’environnement1 s’imbriquent les unes dans les autres, formant alors plusieurs niveaux de sécurisation ( « Layers of Protection Architecture » ). Les environnements d’intervention et les tâches à automatiser de ces systèmes autonomes ou semi-autonomes peuvent être très complexes. Il est alors indispensable que leurs niveaux de sécurisation se basent sur un logiciel qui, aux termes de la proposition de règlement européenne, est un système d’IA.
Pour des concepts de sécurité d’une telle complexité, il faut teniren matière de sécurité une argumentation qui garantisse que l’ensemble du concept soit vraiment porteur, et ce durablement. Les cas d’assurance définis dans la norme ISO/IEC 15026 (Assurance des systèmes et du logiciel) semblent être pour cela une approche adéquate. Ils sont généralement considérés comme étant bien adaptés lorsqu’on ne dispose pas encore pour une technologie donnée d’une expérience suffisante dans un contexte critique en termes de sécurité2.
Un cas d’assurance se compose par principe d’une assertion à prouver concernant le niveau de sécurité visé, ainsi que d’une argumentation correspondante, qui repose sur une quantité de justificatifs et d’éléments de preuve.
Comme le montre le tableau, l’argumentation peut être structurée hiérarchiquement en explicitant chacun des raisonnements. Chaque raisonnement associe une assertion à démontrer (p.ex. le produit est sûr) et des prémisses (p.ex. le risque électrique est maîtrisé). Au niveau suivant, celles-ci sont considérées comme étant de nouvelles assertions, qui sont alors elles-mêmes étayées par des prémisses dans le raisonnement suivant (p.ex. le câble d’alimentation est intact l’isolation est suffisante).
La conclusion logique qui, partant de certaines prémisses, conduit à une assertion n’est souvent valable que sous certaines hypothèses, comme par exemple un environnement d’utilisation donné (p.ex. l’utilisateur est expérimenté / les courants électriques sont inférieurs à...). Ces hypothèses sont définies lors du développement, et consignées explicitement dans le cas d’assurance. Chaque assertion qui n’a pas été affinée doit être étayée par des preuves, telles que des documentations ou des résultats de vérifications.
Un cas d’assurance élaboré offre une série d’avantages. Il regroupe de manière modulaire tous les éléments (artefacts) nécessaires à l’argumentation concernant la sécurité, et peut être intégré dans le logiciel du système global par le biais de modules de programmes spéciaux ( Digital Dependability Identities3 ). La réalisation d’hypothèses et d’assertions importantes peut ainsi être surveillée pendant le fonctionnement, le but étant de détecter à un stade précoce les failles du cas d’assurance, d’améliorer celui-ci en continu et de l’adapter aux changements de l’environnement d’utilisation4. Mais les cas d’assurance offrent surtout un niveau élevé de flexibilité dans la manière de structurer l’argumentation, ce qui permet de tenir compte des spécificités de l’application concrète et des technologies utilisées.
Pour gérer cette flexibilité de manière productive, il existe des aides pratiques. La méthode AMLAS5, par exemple, décrit des manières génériques de procéder pour structurer un argument concernant la sécurité. AMLAS ne précise toutefois pas ce que signifie « suffisamment sûr » lorsqu’il s’agit d’un système d’IA.
Dans le cadre du projet ExamAI, il a été élaboré une suggestion sur la manière dont pourraient se présenter des procédures de test pour les systèmes d’IA. Cette proposition repose sur deux lignes argumentaires indépendantes l’une de l’autre6 : la première vise à montrer que le risque de sécurité a été réduit autant que faire se peut dans la pratique, en optant pour une combinaison aussi efficace que possible de mesures de sécurisation, et en la mettant en œuvre le mieux possible après analyse du rapport coûts-avantages. La deuxième vise à démontrer quantitativement que la réduction du risque obtenue est suffisante.
Le projet de recherche actuel LOPAAS7 combine ces approches, ainsi que d’autres provenant d’études scientifiques. Les partenaires du projet font en outre l’apport du consensus scientifique dans les activités de standardisation et de normalisation, telles que la règle d’application pour les systèmes autonomes/cognitifs VDE-AR-E 2842-61, le rapport technique TR 5469 de l’ISO et de la CEI sur l’IA et la sécurité fonctionnelle, ou encore le BSI PAS 8800 pour l’IA critique en termes de sécurité dans le domaine automobile.
Il faudrait premièrement que les instances de réglementation et de normalisation élaborent des définitions cohérentes pour les termes « système d’IA » et « système autonome ». C’est le seul moyen de comprendre et de combler les lacunes dans la réglementation et la normalisation concernant la sécurité et les autres biens juridiques. Il faudrait deuxièmement promouvoir la recherche sur les cas d’assurance, incluant la participation des chercheurs dans la normalisation et la standardisation, et diffuser le savoir sur les cas d’assurance auprès des personnes concernées. Il faudrait troisièmement formuler les exigences réglementaires de manière à ce qu’elles constituent une bonne base de départ pour l’élaboration et l’application de normes relatives aux cas d’assurance. Concernant les exigences réglementaires, il faudrait que l’accent soit mis sur les assertions indispensables à la sécurité, qui se situent généralement dans la partie supérieure d’un cas d’assurance. Ce qui pourrait en revanche poser problème, ce sont les exigences qui se situent en aval et qui, en fonction de la conduite de l’argumentation ou du cas d’application, ne font pas obligatoirement partie d’une argumentation valide en matière de sécurité. Les exigences réglementaires concernant ce type de détails pourraient diminuer inutilement les marges de manœuvre ou entraîner un travail ou des coûts inutiles.
1 La gestion des incertitudes lors de la détection de l’environnement (en anglais)
2 Understanding what it means for assurance cases to work (en anglais, pdf, n'est pas accessible)
3 Digital Dependability Identities (en anglais)
4 Assurance Cases as Foundation Stone for Auditing AI-enabled and Autonomous Systems (en anglais)
5 La méthode AMLAS (en anglais)
6 Les lignes argumentaires (en anglais)
7 Le projet de recherche actuel LOPAAS (en anglais)
Rasmus Adler, Fraunhofer Institute for Experimental Software Engineering IESE
rasmus.adler@iese.fraunhofer.de
Michael Kläs, Fraunhofer Institute for Experimental Software Engineering IESE
michael.klaes@iese.fraunhofer.de
