Figure 1 : L’exemple d’une fuite de données personnelles dans ChatGPT (décembre 2023)

Des scandales de ce type révèlent une réalité plus profonde : l’architecture même des grands modèles de langage (LLMs ) comme ChatGPT-4  ou Gemini de Google est, par nature, sujette aux fuites de données. Ces fuites peuvent concerner des informations personnelles identifiables (PII) ou des données confidentielles d’entreprise.

Si les techniques employées par les attaquants continueront d’évoluer en réponse aux défenses renforcées des géants technologiques, les vecteurs sous-jacents, eux, restent inchangés.

Aujourd’hui, trois vecteurs principaux permettent aux PII (informations personnelles identifiables) ou aux données sensibles d’être exposées à ce type d’attaques :

• L’utilisation de contenus web accessibles au public dans les jeux de données d’entraînement
• Le réentraînement continu des modèles à partir des requêtes et conversations des utilisateurs
• L’introduction de fonctionnalités de mémoire persistante dans les chatbots

Fuites de données de pré-entraînement des LLM 

La plupart des modèles disponibles aujourd’hui sont fondés sur des architecturesfuite transformers, en particulier les GPT (Generative Pre-Trained Transformers). Le terme pré-entraîné dans GPT fait référence à la phase initiale d’entraînement, durant laquelle le modèle est exposé à un corpus massif et diversifié de données, sans lien direct avec son application finale. Cette étape permet au modèle d’apprendre des bases essentielles comme la grammaire, le vocabulaire et des faits généraux.

Lorsque les premiers GPT ont été lancés, les entreprises communiquaient de manière transparente sur la provenance des données d’entraînement. Mais aujourd’hui, les plus grands modèles disponibles sur le web s’appuient sur des jeux de données devenus trop vastes et trop variés, souvent gardés confidentiels.

Une source majeure des données utilisées pour le pré-entraînement des GPT provient des forums en ligne tels que Reddit (pour les modèles de Google), Stack Overflow, et d’autres plateformes sociales. Cela représente un risque important, car ces forums contiennent souvent des informations personnelles identifiables (PII). Bien que les entreprises affirment filtrer ces données sensibles durant l’entraînement, de nombreux exemples ont montré que les LLM peuvent malgré tout divulguer des données personnelles issues de leur corpus d’entraînement, notamment lorsqu’ils sont soumis à des techniques de prompt engineering* ou de jailbreaking* .  Ce risque ne fera que croître, à mesure que les entreprises accélèreront la collecte de données par web scraping pour entrainer des modèles toujours plus grands et plus sophistiqués.

Les fuites connues de ce type sont pour la plupart découvertes par des chercheurs, qui conçoivent des méthodes toujours plus créatives pour contourner les défenses des chatbots. L’exemple mentionné plus tôt en est une illustration: en demandant au chatbot de répéter indéfiniment un mot, celui-ci « oublie » sa tâche initiale et adopte un comportement connu sous le nom de mémorisation. Dans cet état, le chatbot régurgite des données issues de son ensemble d’entraînement. Bien que cette attaque ait été corrigée, de nouvelles techniques de prompt continuent d’émerger pour modifier le comportement des chatbots.

Réexploitation des saisies utilisateur pour le réentraînement

Le réentraînement à partir des saisies utilisateur est le processus qui consiste à améliorer en continu le LLM en l’entraînant sur les entrées fournies par les utilisateurs. Cela peut se faire de plusieurs manières. La plus répandue étant le RLHF (Reinforcement Learning from Human Feedback), ou apprentissage par renforcement à partir de retours humains.

Figure 2:  Le bouton de retour utilisé pour le RHLF 

Cette méthode repose sur la collecte de retours utilisateurs concernant les réponses générées par le LLM. De nombreux utilisateurs de LLM ont probablement vu les boutons « Pouce en haut » ou « Pouce en bas » dans ChatGPT ou d’autres plateformes de LLM. Ces boutons permettent de collecter les avis des utilisateurs qui seront utilisés pour réentraîner le modèle.  Si l’utilisateur indique que la réponse est positive, la plateforme prend le couple entrée utilisateur / sortie du modèle et encourage le modèle à reproduire ce comportement. De même, si l’utilisateur indique que la performance du modèle est insatisfaisante, ce couple entrée utilisateur / sortie du modèle sera utilisé pour décourager le modèle de reproduire ce comportement.

Cependant, le réentraînement continu peut également avoir lieu sans aucune interaction utilisateur. Les modèles peuvent parfois utiliser les entrées des utilisateurs et les sorties des modèles pour se réentraîner de manière aléatoire. Le manque de transparence de la part des fournisseurs et développeurs de modèles rend difficile la détermination exacte du processus. Toutefois, de nombreux utilisateurs sur internet ont rapporté que les modèles acquéraient de nouvelles connaissances à travers le réentraînement à partir des discussions d’autres utilisateurs, remontant jusqu’en 2022. Par exemple, le GPT 3.5 d’OpenAI ne devrait pas être capable de connaître des informations après septembre 2021 (date du contenu le plus récent utilisé pour son entrainement). Pourtant, en lui demandant des informations récentes, telles que la nouvelle position d’Elon Musk en tant que PDG de Twitter (maintenant X), vous obtiendrez une réponse différente.

Essentiellement, cela signifie pour les utilisateurs finaux que leurs discussions ne sont absolument pas confidentielles, et toute information donnée au LLM via des documents internes, des comptes rendus de réunions ou des lignes de code de développement  pourrait apparaître dans les discussions d’autres utilisateurs, entraînant ainsi des fuites. Cela pose des risques importants pour la confidentialité, non seulement pour les individus, mais aussi pour les entreprises. Un exemple notable s’est produit en avril 2023, lorsque Samsung a interdit l’utilisation de ChatGPT et d’autres chatbots similaires après qu’un groupe d’employés avait  utilisé l’outil pour ecrire des lignes de code et pour résumer des notes de réunion. Bien que Samsung ne dispose d’aucune preuve concrète que les données aient été utilisées par OpenAI, le risque a été jugé trop élevé pour permettre aux employés de continuer à utiliser l’outil. Il s’agit d’un exemple classique de Shadow AI*,  où l’utilisation non autorisée des outils d’IA pourrait entrainer une fuite d’informations confidentielles ou propriétaires. 

De nombreuses entreprises à l’échelle mondiale attendent des régulations plus strictes sur l’IA et les données avant d’utiliser les LLM à des fins commerciales. Certaines industries, comme le conseil, commencent à s’ouvrir, mais de manière encore très progressive.  D’autres entreprises, en revanche, renforcent  leur contrôle sur l’utilisation interne des LLM pour éviter les fuites de données confidentielles et d’informations sur leurs clients.

Mémoire persistante

Bien que les deux risques précédents soient connus  depuis quelques années, une nouvelle menace est apparue avec l’introduction d’une fonctionnalité par ChatGPT en septembre 2024. Cette fonctionnalité permet au modèle de conserver une mémoire à long terme des conversations utilisateurs. L’idée est de réduire la redondance en permettant au chatbot de se souvenir des préférences de l’utilisateur, du contexte et des interactions précédentes, améliorant ainsi la pertinence et la personnalisation des réponses.

Cependant, cette commodité comporte un risque de sécurité important. Contrairement aux failles précédentes, où les informations divulguées étaient plus ou moins aléatoires, la mémoire persistante introduit un ciblage du compte . Désormais, les attaquants pourraient potentiellement exploiter cette mémoire pour extraire des détails spécifiques de l’historique d’un utilisateur particulier, augmentant ainsi considérablement les risques.

Le chercheur en sécurité Johannes Rehberger a démontré comment cette vulnérabilité pourrait être exploitée via une technique appelée empoisonnement de contexte (context poisoning). Dans sa démonstration, il a créé un site avec une image malveillante contenant des instructions. Une fois que le chatbot ciblé consulte l’URL, sa mémoire persistante est « empoisonnée ». Le chatbot peut ainsi être manipulé et des informations sensibles de l’historique de conversation de la victime peuvent être extraites et transmises à une URL externe.

Cette attaque est particulièrement dangereuse car elle combine persistance et discrétion. Une fois implantée  dans le chatbot, elle reste active indéfiniment, exfiltrant continuellement les données de l’utilisateur jusqu’à ce que la mémoire soit nettoyée. En même temps, elle est suffisamment subtile pour passer inaperçue, nécessitant une analyse minutieuse  de la mémoire pour être détectée.

Confidentialité des données des LLM et stratégies de mitigation

Les développeurs de LLM rendent souvent difficile la désactivation du réentraînement, car cela profite au développement de leurs modèles. Si vos informations personnelles sont déjà publiques, elles ont probablement été récupérées par des processus de scraping et utilisées pour le pré-entraînement d’un LLM. De plus, si vous avez donné un document confidentiel à ChatGPT ou à un autre LLM dans votre prompt (sans avoir désactivé manuellement le réentraînement), il a potentiellement déjà été utilisé pour le réentraînement.

Actuellement, il n’existe pas de technique fiable permettant à un individu de demander la suppression de ses données une fois qu’elles ont été utilisées pour l’entraînement d’un modèle. Il existe un domaine de recherche émergent appelé Machine Unlearning qui tente de répondre à ce défi.  Ce domaine se concentre sur le développement de méthodes permettant de supprimer sélectivement l’influence de données spécifiques d’un modèle entraîné, effaçant ainsi ces données de la mémoire du modèle. Ce domaine évolue rapidement, notamment en réponse aux réglementations RGPD qui imposent le droit à l’effacement. Pour cette raison, il est important de minimiser ces risques à l’avenir en contrôlant les données que les individus et les organisations diffusent sur internet et les informations que les employés ajoutent dans leurs prompts.

Il est essentiel pour de nombreuses opérations commerciales que la confidentialité des données soit maintenue. Cependant, l’augmentation de la productivité que les LLM apportent au   travail des employés ne peut être ignorée. Pour cette raison, nous avons élaboré un cadre en trois étapes pour garantir que les organisations puissent exploiter la puissance des LLM sans perdre le contrôle de leurs données.

Choisir le modèle, l’environnement et la configuration les plus optimaux

Assurez-vous que l’environnement et le modèle que vous utilisez sont bien sécurisés. Vérifiez la période de rétention des données du modèle et la politique du fournisseur concernant le réentraînement sur les conversations des utilisateurs. Assurez-vous que l’option « Suppression automatique » est activée et que « Historique des discussions » est désactivé.

Chez Wavestone, nous avons développé un outil qui compare les 3 modèles propriétaires et open-source principaux en termes de tarification, période de rétention des données, garde-fous et confidentialité pour aider les organisations dans leur parcours en IA.

Sensibiliser les employés aux bonnes pratiques lors de l’utilisation des LLM

Assurez-vous que vos employés comprennent le danger de fournir des informations confidentielles  aux LLM et ce qu’ils peuvent faire pour minimiser l’ajout  d’informations confidentielles ou personnelles dans le corpus de données de pré-entraînement et de réentraînement du LLM.

Mettre en place une politique interne solide sur l’IA

Pour anticiper les challenges à venir, les entreprises devraient mettre en place une politique interne robuste sur l’IA qui spécifie :

• Quelles informations peuvent et ne peuvent pas être partagées avec les LLM en interne
• La surveillance du comportement de l’IA
• La limitation de leur présence en ligne
• L’anonymisation des données  
• Limiter l’utilisation aux outils d’IA sécurisés

En suivant ces étapes, les organisations peuvent minimiser les risques numériques auxquels elles sont confrontées en utilisant les derniers outils GenAI tout en bénéficiant des augmentations de productivité qu’ils apportent.

Perspectives… 

Les vulnérabilités en matière de confidentialité des données mentionnées dans cet article affectent des individus comme vous et moi. Leurs origines résident dans l’appétit insatiable des développeurs de LLM pour les données.  Cet appétit pour les données assure des produits finis de meilleure qualité, mais au prix de la confidentialité des données et de l’autonomie.
De nouvelles réglementations et technologies ont été mises en place pour lutter contre ce problème, comme le règlement européen sur l’IA (EU AI Act) et la liste des 10 meilleures pratiques LLM d’OWASP. Cependant, se fier uniquement à une gouvernance responsable ne suffit pas. Les individus et les organisations doivent activement reconnaître le rôle critique que jouent les informations personnellement identifiables dans le paysage numérique actuel et prendre des mesures proactives pour les protéger. Cela est d’autant plus important à mesure que nous avançons vers des systèmes d’IA plus agentiques, qui interagissent de manière autonome avec plusieurs services tiers. Ces systèmes traiteront non seulement une quantité croissante de données personnelles et sensibles, mais ces données seront également transmises et manipulées par de nombreux services différents, compliquant ainsi la surveillance et le contrôle. 

Références 

[1] D. Goodin, “OpenAI says mysterious chat histories resulted from account takeover,” Ars Technica, https://arstechnica.com/security/2024/01/ars-reader-reports-chatgpt-is-sending-him-conversations-from-unrelated-ai-users/ (accessed Jul. 13, 2024).  

[2] M. Nasr et al., “Extracting Training Data from ChatGPT,” not-just-memorization , Nov. 28, 2023. Available: https://not-just-memorization.github.io/extracting-training-data-from-chatgpt.html  

[3] “What Is Confidential Computing? Defined and Explained,” Fortinet. Available: https://www.fortinet.com/resources/cyberglossary/confidential-computing#:~:text=Confidential%20computing%20refers%20to%20cloud  

[4] S. Wilson, “OWASP Top 10 for Large Language Model Applications | OWASP Foundation,” owasp.org, Oct. 18, 2023. Available: https://owasp.org/www-project-top-10-for-large-language-model-applications/  

[5] “Explaining the Einstein Trust Layer,” Salesforce. Available: https://www.salesforce.com/news/stories/video/explaining-the-einstein-gpt-trust-layer/  

[6] “Hacker plants false memories in ChatGPT to steal user data in perpetuity” Ars Technica , 24 sept. 2024 Available: https://arstechnica.com/security/2024/09/false-memories-planted-in-chatgpt-give-hacker-persistent-exfiltration-channel/ 

[7] “Why we’re teaching LLMs to forget things” IBM, 07 Oct 2024 Available: https://research.ibm.com/blog/llm-unlearning 

Cet article Fuite de données : comment les chatbots d’IA peuvent faire fuiter vos informations est apparu en premier sur RiskInsight.

Pour arriver à ce vote favorable, le Parlement Européen a dû faire face à de lourdes oppositions des lobbyistes, notamment certaines entreprises d’IA qui pouvaient jusqu’à présent bénéficier d’un très large panel de données d’entraînement, sans se soucier des droits d’auteurs. Certains gouvernements ont aussi tenté de faire barrage. C’est le cas de l’Etat Français, qui craignait que la réglementation puisse freiner le développement de la French Tech.

Le 9 décembre 2023, le Parlement et le Conseil tombent d’accord sur un texte, après trois jours de « pourparlers-marathon » et des mois de négociations. Un nombre quasi record de 771 amendements ont été intégrés au texte de loi, c’est plus que pour le RGPD, et c’est dire les difficultés rencontrées pour l’adoption de ce texte.

Le règlement sur l’intelligence artificielle (AI Act) est approuvé le 13 mars 2024 par le Parlement Européen, puis le 21 mai 2024 par le Conseil Européen. Il s’agit de la dernière étape du processus décisionnel européen, ouvrant la voie à la mise en application du texte. S’agissant d’un règlement, il est directement applicable à l’ensemble des pays membres de l’UE. Les prochaines échéances sont données dans la figure 6, à la fin de cet article.

Figure 1 : Chronologie de l’adoption de l’AI Act

Quels sont les acteurs concernés et les autorités de surveillance ?

L’AI Act concerne essentiellement cinq grands types d’acteurs : les fournisseurs, les intégrateurs, les importateurs, les distributeurs et les organisations utilisatrices d’IA Naturellement, les fournisseurs, les distributeurs et les organisations utilisatrices sont les plus visés par la réglementation.

Chaque état de l’UE est responsable de « l’application et de la mise en œuvre du règlement » en son sein et doit désigner une autorité de contrôle nationale. En France, la CNIL pourrait être un bon candidat¹ et a créé, en janvier 2023, un « Service de l’intelligence artificielle ».

Une nouvelle hiérarchie des risques qui amène des exigences de cybersécurité

L’AI Act définit un SIA comme un système automatisé qui est conçu pour fonctionner à différents niveaux d’autonomie et qui, à partir de données d’entrée, déduit des recommandations ou des décisions qui peuvent influencer les environnements physiques ou virtuels.

Les SIA sont classés sur quatre niveaux en fonction du risque qu’ils représentent : les risques inacceptables, les risques hauts, les risques limités et les risques faibles.

Figure 2 : Classification des risques, exigences et sanctions

1. Les SIA à risque inacceptable sont ceux engendrant des risques qui contreviennent aux valeurs de l’UE et qui portent atteinte aux droits fondamentaux. Ces SIA sont tout simplement interdits, ils ne peuvent ni être commercialisés au sein de l’UE, ni être exportés. Les différents risques jugés inacceptables et par conséquent induisant qu’un SIA soit interdit sont cités dans la figure ci-après. La commercialisation de ce type de SIA est passible d’une amende de 7% du chiffre d’affaires annuel de l’entreprise ou de 35 millions €.

Figure 3 : Les cas d’usage de risques inacceptables

2. Les SIA à haut risque présentent un risque d’impact négatif sur la sécurité ou les droits fondamentaux. On y retrouve par exemple les systèmes d’identification biométrique ou de gestion de la main-d’œuvre. Ils sont la cible de la quasi-totalité des exigences mentionnées dans le texte. Il est demandé, pour ces SIA, une déclaration de conformité et leur enregistrement dans la base de données de l’UE. De plus, ils sont soumis à des exigences en cybersécurité qui sont présentées dans la figure 4. Le non-respect des critères donnés est sanctionné à hauteur maximum de 3% du chiffre d’affaires annuel de l’entreprise ou 15 millions € d’amende.
3. Les SIA à risque limité sont les systèmes d’IA interagissant avec les personnes physiques et n’étant ni à risque inacceptable, ni à haut risque. On y retrouve par exemple des deepfakes à vocation artistique ou pédagogique. Dans ce cas, les utilisateurs doivent être informés sur le fait que le contenu a été généré par l’IA. Un manque de transparence peut être sanctionné à 7,5M€ ou 1% du chiffre d’affaires.
4. Les SIA à risque faible sont ceux qui n’entrent pas dans les catégories citées ci-dessus. Il s’agit par exemple des IA de jeux vidéo ou des filtres anti-spams. Aucune sanction n’est prévue pour ces systèmes, ils sont soumis à l’application volontaire de codes de conduite et représentent la plus grande partie des SAI actuellement utilisés en UE.

Des exigences en cybersécurité adressées aux SIA à haut risque

Bien que le règlement sur l’AI Act ne soit pas uniquement axé sur la cybersécurité, ce dernier fixe un certain nombre d’exigences dans ce domaine :

Figure 4 : Les exigences de l’AI Act en termes de cybersécurité

Nous avons identifié sept grandes catégories d’exigences cybersécurité :

Gestion des risques : Le texte impose, pour les SIA à haut risque, un système de gestion des risques qui se déroule tout au long du cycle de vie du SIA. Il doit prévoir, entre autres, l’identification et l’analyse des risques actuels, à venir et la maîtrise des risques résiduels.

Security by design : L’AI Act demande aux SIA à haut risque de tenir compte du niveau de risque. Les risques doivent être réduits « autant que possible grâce à une conception et un développement approprié ». Le règlement évoque aussi la maîtrise des boucles de rétroaction dans le cas d’un SIA qui continuerait son apprentissage après la mise sur le marché.

Documentation : Chaque SIA doit être accompagné d’une documentation technique qui prouve que les exigences indiquées dans l’annexe 4 du texte de loi sont bien respectées. En plus de cette documentation technique à l’adresse des autorités nationales, l’AI Act exige la rédaction d’un mode d’emploi compréhensible par les utilisateurs. Il contient par exemple, les mesures mises en place pour la maintenance du système et la collecte des logs.

Gouvernance des données : L’AI Act réglemente d’une part le choix des données d’entraînement² et d’autre part, la sécurité des données de l’utilisateur. Les données d’entrainement doivent être examinées de manière à ce qu’elles ne contiennent aucun biais³ ou insuffisance susceptible d’entraîner des discriminations ou d’affecter la santé et la sécurité des personnes. Ces données doivent être représentatives de l’environnement dans lequel le SIA sera utilisé. Pour la protection des données à caractère personnel, la résolution des problèmes liés à des biais (présentés plus tôt), dans la mesure où il ne peut être traité autrement, fait office de seule dérogation pour l’accès aux données sensibles (origines, convictions politiques, données biométriques ou de santé…). Cet accès est soumis à plusieurs obligations de confidentialité et à la suppression de ces données une fois le biais corrigé.

Tenue de registres : L’enregistrement automatique de journaux (logs) fait partie des exigences cyber de l’AI Act. Ces derniers doivent, tout au long de leur cycle de vie, relever les éléments pertinents pour l’identification de situations à risque et pour permettre la facilitation de la surveillance postérieure à la mise sur le marché.

Résilience : L’AI Act impose aux SIA à haut risque d’être résistants aux tentatives de personnes extérieures visant à modifier leur utilisation ou leurs performances. Le texte appuie notamment sur le risque « d’empoisonnement » des données⁴. De plus, des solutions techniques redondantes, telles que des plans de sauvegarde ou des mesures de sécurité après défaillance, doivent être intégrées au programme afin de garantir la robustesse des systèmes d’IA à haut risque.

Surveillance humaine : L’AI Act introduit une obligation de surveillance des SIA par l’être humain. Cela passe d’abord par une conception adaptée à la surveillance et au contrôle humain. Ensuite, il est imposé que la conception du modèle assure qu’aucune action ou décision ne soit prise par le responsable du déploiement sans l’approbation de deux personnes physiques compétentes, à quelques exceptions près.

Le nouveau cas des IA à usage général : des exigences particulières

Depuis la proposition de loi d’avril 2021, les négociations ont mené à l’apparition d’un nouveau terme dans le règlement : celui de GenIA ou « modèle d’IA à usage général ». Ce dernier est défini dans le texte comme un modèle d’IA qui présente une généralité significative et qui est capable d’exécuter de manière compétente un large éventail de tâches distinctes. Ces modèles forment une catégorie de SIA bien distincte et doivent répondre à des exigences particulières. Le nouveau chapitre V du règlement leur est dédié. On y retrouve principalement des obligations de transparence vis-à-vis de l’UE, des fournisseurs et des utilisateurs ainsi que le respect des droits d’auteurs. Enfin, les fournisseurs doivent désigner un mandataire responsable du respect de ces exigences.  Mais la nouvelle version de l’AI Act a également introduit une nouvelle notion : celle de GenIA à « risque systémique », qui sont les plus réglementés.

Qu’est-ce qu’un GenIA à risque systémique ?

L’AI Act définit un « risque systémique » comme « un risque à fort impact des modèles d’IA à usage général, ayant une incidence significative sur le marché de l’Union Européenne en raison de leur portée ou d’effets négatifs sur la santé publique, la sûreté, la sécurité publique, les droits fondamentaux ou la société dans son ensemble, pouvant être propagé à grande échelle. » Concrètement, un GenIA est considéré comme présentant un risque systémique s’il dispose d’une capacité de fort impact selon les critères suivants :

1. Une quantité de calcul utilisé pour son entraînement supérieur à 10^25 FLOPS⁵
2. Une décision de la Commission sur la base de divers critères définis en Annexe XIII tels que la complexité des paramètres du modèle ou sa portée parmi les entreprises et les consommateurs.

Quelles sont les mesures à mettre en œuvre ?

Si le SIA rentre dans ces catégories, il devra se soumettre à de nombreuses exigences, notamment en matière de cybersécurité.  Par exemple, l’article 55 1a) demande aux fournisseurs de ces SIA de mettre en place des essais contradictoires des modèles en vue d’identifier et d’atténuer le risque systémique. De plus, les GenIA à risque systémique doivent présenter, au même titre que les SIA à haut risque, un niveau approprié de protection en cybersécurité et une protection de l’infrastructure physique du modèle. Enfin, à l’image du RGPD avec les violations de données personnelles, l’AI Act exige, en cas d’incident grave, de contacter le Bureau de l’IA⁶ ainsi que l’autorité nationale compétente. Les mesures correctives pour remédier à l’incident doivent aussi être communiquées.

Le schéma suivant résume les différentes exigences en fonction du modèle d’IA d’usage général :

Figure 5 : Les exigences des différents modèles GenIA

Est-il possible d’alléger certaines exigences ?

Dans le cas d’un modèle d’IA à usage général ne présentant pas de risque systémique, il est possible de réduire considérablement les obligations du règlement en le rendant libre de consultation, de modification et de distribution (Open Source⁷). Dans ce cas, le fournisseur est tenu de respecter les droits d’auteurs et de mettre à disposition du public un résumé suffisamment détaillé du contenu utilisé pour entraîner le modèle d’IA.

En revanche, un GenIA à risque systémique devra forcément respecter les exigences énoncées plus haut. Cependant il est possible de demander à réévaluer son modèle d’IA en prouvant que ce dernier ne présente plus de risque systémique afin de se défaire des exigences supplémentaires. Cette réévaluation est possible deux fois par an et est validée par la Commission européenne sur des critères objectifs (Annexe XIII).

Comment se préparer à la conformité à l’AI Act ?

Pour bien se préparer, il convient de respecter l’approche par les risques qui est imposée par le texte. La première étape consiste à faire l’inventaire de ses cas d’usage, autrement dit, identifier tous les SIA que l’organisation développe ou emploie. Dans un second temps, il s’agit de classer ses SIA par niveau de risque (par exemple à travers une heat map). Les mesures applicables seront alors identifiées en fonction du niveau de risque des SIA. L’AI Act impose également la mise en œuvre d’un processus d’intégration de la sécurité dans les projets d’IA qui permet, comme pour tout projet, d’évaluer les risques du projet par rapport à l’organisation et d’élaborer un plan de remédiation de ces risques qui soit pertinent.

Pour initier la mise en conformité aux mesures applicables, il convient de démarrer par la mise à jour de la documentation et des outils existants, en particulier :

• Politiques de sécurité pour définir des exigences propres à la sécurité de l’IA ;
• Questionnaire d’évaluation de la sensibilité des projets ciblant les questions pertinentes pour les projets d’IA ;
• Librairie de scénarios de risque avec les attaques spécifiques à l’IA ;
• Librairie de mesures de sécurité à insérer dans les projets d’IA.

Quelles sont les prochaines étapes ?

Figure 6 : Chronologie de la mise en application de l’AI Act

—

¹ La CNIL et ses équivalents européens pourraient mettre à profit leur expérience afin contribuer à une gouvernance plus harmonisée (entre les États membres et entre les textes eux-mêmes).

² Données d’entrainements : Large ensemble de données d’exemples utilisées pour apprendre à l’IA à faire des prédictions ou prendre des décisions.

³ Biais : Un biais algorithmique est le fait que le résultat d’un algorithme ne soit pas neutre, loyal ou équitable que ce soit de manière inconsciente ou délibérée.

⁴ Empoisonnement des données : Les attaques par empoisonnement visent à modifier le comportement du système d’IA en introduisant des données corrompues en phase d’entraînement (ou d’apprentissage).

⁵ FLOPS : Unité de mesure de la puissance d’un ordinateur correspondant au nombre d’opérations en virgule flottante qu’il effectue par seconde, par exemple, GPT-4 a été entrainé avec une puissance de calcul de l’ordre de 10^28 FLOPs contre 10^22 pour GPT-1.

⁶ Bureau de L’IA : Organisme européen en charge de la mise en œuvre du règlement. A ce titre, il se voit confier de nombreuses tâches comme le développement d’outils ou de méthodologies ou encore la coopération avec les différents acteurs impliqués par ce règlement.

⁷ Open Source : Sont considérés en licence libre et ouverte (Open Source), les modèles d’IA qui permettent leur libre consultation, modification et distribution. Leurs paramètres et informations sur l’utilisation du modèle doivent être rendus publics.

Cet article La cybersécurité au cœur de l’AI Act : éléments clés pour la mise en conformité est apparu en premier sur RiskInsight.

L’AI Act vise à garantir que les systèmes et modèles d’intelligence artificielle commercialisés au sein de l’Union européenne soient utilisés de manière éthique, sûre et respectueuse des droits fondamentaux de l’UE. Cette loi a également été rédigée pour renforcer la compétitivité et l’innovation des entreprises en matière d’IA. L’AI Act réduira les risques de dérives, renforçant la confiance des utilisateurs dans son utilisation et adoption.

France Digitale, la plus grande association de startups en Europe, Gide, un cabinet d’avocats d’affaires français à dimension internationale, et Wavestone, ont réuni leurs forces pour co-écrire un livre blanc pour vous permettre de comprendre et appliquer la loi européenne sur l’IA : L’AI Act : les clés pour comprendre et appliquer la loi européenne sur l’intelligence artificielle.

Dans cette publication, France Digitale, Gide et Wavestone vous partagent leur vision de l’AI Act, des types de systèmes concernés aux grandes étapes de la mise en conformité.

Quelques définitions pour commencer

L’AI Act effectue une distinction entre les systèmes et les modèles d’intelligence artificielle qu’il définit comme suit :

• Un système d’intelligence artificielle (SIA) est un système automatisé conçu pour fonctionner à différents niveaux d’autonomie et qui peut générer des prédictions, des recommandations ou des décisions qui influencent les environnements physiques ou virtuels.
• Un modèle d’intelligence artificielle à usage général (“General Purpose AI systems” ou “GPAI”) est un système d’IA polyvalent, capable d’exécuter un large éventail de tâches distinctes. Il peut être intégré dans une variété de systèmes ou d’applications, démontrant ainsi une grande flexibilité et adaptabilité.

Acteurs concernés

L’AI Act concerne tous les fournisseurs, distributeurs ou déployeurs de systèmes et de modèles d’IA, personnes morales (entreprises, fondations, associations, laboratoires de recherche, etc.), dont le siège social se situe dans l’Union européenne, ou lorsque le siège social est situé en dehors de l’Union européenne, qui commercialisent leur système ou modèle d’IA dans l’Union européenne.

Le niveau de réglementation et les obligations associées dépendent du niveau de risque que présente le système ou le modèle d’IA.

La classification des SIA selon le niveau de risque

L’AI Act introduit une classification des systèmes d’intelligence artificielle. Les SIA doivent être analysés et hiérarchisés en fonction du risque qu’ils présentent pour les utilisateurs : minime, faible, haut et inacceptable. Les différents niveaux de risque impliquent plus ou moins d’obligations.

Les SIA à risque inacceptable sont interdits par l’AI Act et les SIA à risque minime n’ont pas d’obligations vis-à-vis du texte. Ce sont donc les SIA à risque haut et à risque faible qui concentrent l’essentiel des mesures prévues par le Règlement.

Des obligations particulières s’appliquent aux IA génératives et au développement de modèles d’IA à usage général (e.g. Large Language Models ou “LLMs”) selon différents facteurs : puissance de calcul, nombre d’utilisateur, utilisation d’un modèle open-source etc.

Afin de répondre aux nouveaux enjeux liés à l’émergence de l’intelligence artificielle générative, l’AI Act prévoit notamment des mesures spécifiques de cybersécurité, qui visent à réduire les risques engendrés par l’émergence de l’intelligence artificielle générative.

Dans une prochaine publication, nous reviendrons en détails sur les volets cybersécurité de l’AI Act. D’ici là, vous pouvez retrouver nos dernières publications sur l’IA et la cybersécurité : « Sécuriser l’IA : Les Nouveaux Enjeux de Cybersécurité », « L’industrialisation de l’IA par les cybercriminels, faut-il vraiment s’inquiéter ? », ou encore « Quand les mots deviennent des armes : prompt Injection et Intelligence artificielle ».

[1] Intelligence artificielle : la France accepte de valider l’AI Act après sept mois d’opposition (lemonde.fr)

Cet article L’AI Act : les clés pour comprendre la première législation mondiale sur l’intelligence artificielle est apparu en premier sur RiskInsight.