Renforcer la confiance : les bases de la sécurité, de la sûreté et de la transparence dans l'IA

Cet article de blog est une adaptation d'un article de recherche Red Hat du même nom (Bestavros, Chen, Fox, Mollett & Sidhurwalla, 2024). Vous pouvez accéder au document complet ici.

Les modèles d'intelligence artificielle (IA) accessibles au public évoluent rapidement, ce qui entraîne également une croissance des menaces de sécurité et de sûreté liées à ces modèles. Il est donc nécessaire de mieux comprendre les risques et les vulnérabilités associés. Pour harmoniser la sécurité, la sûreté et la transparence dans le développement et l'exploitation des modèles d'IA, ainsi que leurs écosystèmes et communautés ouverts, nous devons changer notre façon d'aborder les défis actuels, notamment la cohérence des informations sur les modèles, le manque de distinction entre problèmes de sécurité et de sûreté et les évaluations de sécurité défectueuses et non standardisées utilisées par les créateurs de modèles.

Risques et vulnérabilités

Bien que similaires, la sécurité et la sureté de l'IA sont des aspects distincts de la gestion des risques dans les systèmes d'IA. La sécurité de l'IA protège les systèmes des menaces externes et internes, tandis que la sûreté de l'IA garantit que le système et les données ne menacent ni ne nuisent aux utilisateurs, à la société ou à l'environnement en raison du fonctionnement, de l'entraînement ou de l'utilisation du modèle. Cependant, la différence entre la sécurité et la sûreté de l'IA est souvent floue.

Une attaque qui serait généralement considérée comme un problème de sécurité peut engendrer des problèmes de sûreté (ou vice versa), comme lorsqu'un modèle produit du contenu volumineux ou dangereux ou expose des informations personnelles. La conjonction de la sécurité et de la sûreté de l'IA met en évidence la nécessité d'adopter une approche complète de la gestion des risques de l'IA qui prend en compte à la fois les préoccupations en matière de sécurité et de sûreté.

Défis et tendances actuels

Bien que le secteur de l'IA ait pris des mesures pour résoudre les problèmes de sécurité et de sûreté, plusieurs défis majeurs persistent, notamment la priorité accordée à la rapidité plutôt qu'à la sécurité, une gouvernance inadaptée et des pratiques de création de rapports défectueuses. De nouvelles tendances suggèrent que ces domaines de croissance sont essentiels pour développer des pratiques efficaces de sécurité, de sûreté et de transparence dans le domaine de l'IA.

La rapidité au détriment de la sureté

Dans l'optique de développer et de déployer rapidement des technologies d'IA pour « s'approprier » la part du marché, de nombreuses entreprises donnent la priorité à l'accélération de leur mise sur le marché plutôt qu'aux tests de sûreté et aux considérations éthiques. Comme le montrent les incidents de sécurité passés, la sécurité a souvent des années de retard sur les technologies naissantes, ce qui conduit généralement à un incident majeur avant que le secteur ne commence à se corriger lui-même. Il est raisonnable de prévoir que l'absence d'individus qui préconisent la gestion des risques dans le domaine de l'IA pourrait nous amener à subir des incidents de sécurité majeurs. Alors que les nouveaux modèles sont introduits en tenant compte de la sécurité et de la sûreté, l'absence de consensus sur la manière de transmettre les informations nécessaires en matière de sûreté et de transparence rend leur évaluation difficile. Pourtant, la multiplication des modèles axés sur la sûreté constitue un pas en avant positif pour le secteur de l'IA.

Gouvernance et autorégulation

Malgré la rareté des lois gouvernementales, le secteur de l'IA s'est appuyé sur l'autoréglementation libre et les directives éthiques non contraignantes, qui se sont révélées insuffisantes pour répondre aux préoccupations en matière de sécurité. En outre, les lois proposées ne sont souvent pas alignées sur les réalités du secteur des technologies ou les préoccupations exprimées par les leaders du secteur et les communautés. De leur côté, les initiatives d'entreprise en matière d'IA ne permettent pas de résoudre les problèmes structurels ou de garantir une véritable responsabilité, car elles sont développées spécialement pour leur propre usage.

L’autonomie a rencontré un succès limité et a tendance à impliquer un ensemble défini de meilleures pratiques mises en œuvre indépendamment du développement des fonctionnalités principales. Comme nous l'avons vu historiquement dans tous les secteurs, faire le choix de la sécurité au détriment de la fonctionnalité est souvent un compromis que les parties prenantes ne souhaitent pas faire. L'IA simplifie encore davantage les situations avec des conséquences directes sur la sûreté.

Pratiques en matière de signalement défectueuses

Dans le secteur actuel, les méthodes et pratiques communes pour traiter les défauts de modèle signalés par les utilisateurs sont insuffisantes. Cela s'explique en partie par le fait que le système d'information et de création de rapports pour les vulnérabilités logicielles, qui offre des défauts mais qui fonctionne bien, n'est pas une solution universelle pour la création de rapports dans le domaine de l'IA. L'IA est une évolution technique de la science des données et de l'apprentissage automatique (AA), différente de l'ingénierie logicielle et du développement technologique traditionnels en raison de l'importance qu'elle accorde aux données et aux mathématiques, et qui s'affranchit de la construction de systèmes pour les utilisateurs qui disposent de méthodes établies pour la modélisation des menaces, l'interaction entre les utilisateurs et la gestion des systèmes. sécurité. Si l'entreprise ne dispose pas d'un système d'information et de signalement bien compris, il peut être fastidieux et irréaliste de signaler un problème en contactant directement le fabricant de modèles.En l'absence d'un processus de signalement standardisé et bien compris, les répercussions d'un incident de sûreté lié à l'IA pourraient être bien plus graves qu'elles ne le devraient, en raison du retard de coordination et de résolution.

Solutions et stratégies

Nous nous sommes appuyés sur les travaux précédents de Cattel, Ghosh & Kaffee (2024), et nous sommes convaincus que l'extension des cartes de modèles/systèmes et le suivi des risques sont essentiels à l'amélioration de la sûreté dans le secteur de l'IA.

Déploiement des cartes de modèle/sûreté

Les cartes de modèle servent à documenter l'utilisation possible d'un modèle d'IA, ainsi que son architecture et, parfois, les données d'entraînement utilisées pour le modèle. Actuellement, les cartes de modèles sont utilisées pour fournir un premier ensemble de données générées par l'homme sur le modèle, qui est ensuite utilisé pour évaluer sa viabilité. Cependant, les cartes de modèles peuvent avoir plus de potentiel et être applicables au-delà de leur utilisation actuelle, indépendamment de la destination ou de l'endroit où elles se trouvent. déployées.

Pour comparer efficacement les modèles, les adopteurs et les ingénieurs ont besoin d'un ensemble cohérent de champs et de contenus présents sur la carte, ce qui peut être accompli par le biais d'une spécification. Outre les champs recommandés par Barnes, Gebru, Hutchinson, Mitchell, Raji, Spitzer, Vasserman, Wu et Zaldivar, 2019, nous proposons les modifications et ajouts suivants :

• Étendre l'intention et l'utilisation pour décrire les utilisateurs (qui) et les cas d'utilisation (pourquoi) du modèle, ainsi que la manière dont le modèle doit être utilisé ;
• Ajouter une portée pour exclure les problèmes connus que le producteur du modèle n’a pas l’intention de résoudre ou n’est pas en mesure de résoudre. Ainsi, les signaleurs qui signalent les dangers comprennent l'objectif du modèle avant de signaler un problème jugé insoluble par rapport à son utilisation définie.
• Ajuster les données d'évaluation pour fournir une structure imbriquée à transmettre si un cadre a également été utilisé, et les résultats de l'évaluation qui ont été exécutés sur le modèle. Des évaluations de sécurité standardisées permettraient à un utilisateur qualifié de construire un modèle durablement équivalent.
• Ajoutez des informations de gouvernance concernant le modèle afin de comprendre comment un adopteur ou un consommateur peut interagir avec les créateurs de modèles ou comprendre comment celui-ci a été produit.
• Fournissez des références facultatives, telles que des artefacts et d’autres contenus, pour aider les utilisateurs potentiels à comprendre le fonctionnement du modèle et à démontrer la maturité et le niveau professionnel d’un modèle donné.

L'obligation de fournir ces champs pour les cartes de modèles permet au secteur de commencer à établir le contenu essentiel au raisonnement, à la prise de décision et à la production de modèles. En développant une norme de fiches de modèles, nous pourrons promouvoir l'interopérabilité des modèles et leurs métadonnées dans l'ensemble des écosystèmes.

Suivi des dangers

Si le processus courant de divulgation des vulnérabilités utilisé pour surveiller les failles de sécurité est efficace dans le domaine de la sécurité logicielle traditionnelle, son application dans les systèmes d'IA se heurte à plusieurs difficultés. D'une part, les problèmes de modèle d'AA doivent respecter les seuils de validité statistique. Cela signifie que tous les problèmes identifiés dans un modèle d'IA, tels que les biais, doivent être mesurés et évalués par rapport à des normes statistiques établies pour s'assurer qu'ils sont significatifs. Ensuite, les inquiétudes liées à la fiabilité et au biais dépassent souvent les vulnérabilités de la sécurité et ne sont pas toujours conformes à la définition acceptée. Au vu de ces limites, nous pensons que l'expansion de l'écosystème à l'aide d'un comité centralisé et neutre sur la divulgation des risques et l'exposition aux risques et d'un numéro CFS (Common Faults and Exposures) pourrait répondre à ces inquiétudes. Cela ressemble à la façon dont CVE a été lancée en 1999 par MITRE pour identifier et catégoriser les vulnérabilités dans les logiciels et micrologiciels.

Les utilisateurs qui découvrent des problèmes de sécurité doivent se coordonner avec les fournisseurs de modèles pour trier et analyser le problème en détail. Dès que le problème est considéré comme un problème de sécurité, le comité attribue un numéro CFE. Les fabricants de modèles et les distributeurs peuvent également demander des numéros CFE pour suivre les risques de sécurité qu'ils trouvent dans leurs propres modèles. Le comité coordonné d'information sur les risques et d'exposition aux risques est le dépositaire des numéros CFE. Il est chargé de les attribuer aux risques de sécurité, de les suivre et de les publier. En outre, la formation d'un groupe annexe sera chargée de faciliter la résolution des risques de sécurité signalés.

Et ensuite ?

Les modèles développés selon les principes de l'Open Source peuvent jouer un rôle considérable dans l'avenir de l'IA. Les cadres et les outils nécessaires au développement et à la gestion des modèles en fonction des attentes du secteur et des consommateurs doivent faire preuve d'ouverture et de cohérence pour permettre aux entreprises d'évaluer raisonnablement les risques. La transparence et l'accès aux fonctionnalités essentielles nous permettent de détecter, de suivre et d'écarter les risques de sécurité avant qu'ils n'entraînent des conséquences généralisées. Nos propositions visent à apporter de la flexibilité et de la cohérence grâce à la structure, aux workflows et à la gouvernance existants. Leur mise en œuvre permettrait de répondre plus efficacement à la nécessité de gérer efficacement la sécurité de l'IA.