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.