Dans cet article, nous faisons le point sur les dernières actualités réglementaires cybersécurité et les challenges qu’elles engendrent, et nous vous proposons deux approches pour gérer au mieux l’empilement des réglementations.

Etat des lieux : Des réglementations cybersécurité toujours plus nombreuses

En Europe, un renforcement des réglementations cybersécurité associé à un élargissement du périmètre d’applicabilité

Ces dernières années, l’Union Européenne a poursuivi sa dynamique de réglementation en matière de cybersécurité et de résilience, avec l’entrée en vigueur de réglementations structurantes telles que DORA, NIS2, le CRA ou encore l’IA Act. Ces réglementations concernent également un plus grand nombre d’acteurs, avec une extension des secteurs régulés.

La première est le règlement DORA. Entré en vigueur en janvier 2025, il impose aux entités financières des obligations visant à renforcer leur résilience numérique, en se concentrant sur quatre grands axes : la gestion des risques liés aux TIC, la gestion des incidents, les tests de résilience opérationnelle et la gestion des risques liés aux prestataires de services TIC.

La directive NIS2, entrée en vigueur en octobre 2024, vient quant à elle élargir les objectifs et le périmètre d’application de NIS1. Elle s’applique désormais à deux types d’entités :  

• Les Entités Essentielles (EE), déjà présentes sous le nom d’Opérateur de Services Essentiels (OES) dans NIS1. La liste des secteurs d’activités concernés a cependant été élargie.
• Les Entités Importantes (EI). La construction de cette dernière catégorie vise à accompagner le développement des usages numériques dans la société. Elle concerne par exemple le secteur de la fabrication d’équipements informatiques. Les EI sont considérés comme moins critiques que les EE, les obligations qui leur sont imposées par les transpositions nationales seront donc moins contraignantes.

Dans le même temps, l’UE s’est également dotée de la directive sur la Résilience des Entités Critiques (REC), entrée en vigueur en octobre 2024 comme NIS2. Cette directive impose aux infrastructures critiques de mettre en place des mesures de prévention, de protection et de gestion des risques afin de garantir la continuité des services vitaux pour la stabilité économique et sociale de l’Union.  

Les directives NIS 2 et REC devaient être transposées dans les législations nationales au plus tard le 17 octobre 2024. À ce jour, seuls quelques États membres ont achevé ce processus. En France, après un premier vote au Sénat le 12 mars 2025 les débats ont désormais rejoint l’Assemblée nationale. Prochaine étape : une lecture en séance publique est prévue pour la mi-septembre.  

En complément, pour répondre à la montée des cybermenaces liées aux produits numériques, l’Union européenne a adopté le Cyber Resilience Act, en vigueur depuis le 10 décembre 2024. Ce texte s’applique aux produits avec éléments numériques (produits de consommation, smart cities, logiciels non essentiels) et aux produits critiques avec éléments numériques (pare-feux, systèmes de contrôle industriels, logiciels essentiels). Il impose notamment qu’ils soient conçus sans vulnérabilités connues, accompagnés d’une documentation claire et soumis à une gestion rigoureuse des failles.

Au-delà des frontières de l’UE, le Royaume-Uni a également renforcé son cadre réglementaire, conscient que le rythme législatif n’avait pas suivi l’évolution rapide des technologies et faisant face à une recrudescence des cyberattaques visant des infrastructures critiques, telles que le NHS ou le ministère de la Défense. Le gouvernement britannique a ainsi présenté en avril 2025 le Cyber Security and Resilience Bill, un projet de loi inspiré de la directive NIS2 et visant à renforcer la résilience du pays face à l’intensification des menaces numériques.

Une dynamique similaire constatée en Asie

Les réglementations cybersécurité se sont également renforcées en Asie ces dernières années, en particulier en Chine et à Hong-Kong.

En Chine, le Network Data Security Management Regulations est entré en vigueur le 1^er janvier 2025. Il vient compléter, préciser et étendre les obligations issues des précédentes réglementations (CSL, DSL, PIPL). Il couvre toutes les données électroniques traitées via des réseaux, y compris les données non personnelles et s’articule autour de trois axes majeurs : 

• La protection des données à caractère personnel, avec un accent sur le consentement explicite, la portabilité et la transparence ; 
• La gestion des données importantes, imposant leur identification, documentation et sécurisation ;
• La responsabilisation des grandes plateformes numériques, soumises à des obligations renforcées en matière de gouvernance, de transparence et d’éthique algorithmique.

À Hong Kong, un nouveau dispositif visant à renforcer la sécurité des infrastructures critiques a été adopté le 19 mars 2025 et devrait entrer en vigueur le 1er janvier 2026. Les principales exigences du Computer Systems Bill s’articulent autour de quatre thématiques : une structure organisationnelle renforcée (présence locale, unité cybersécurité, déclaration des changements), la prévention des menaces (plan de sécurité, évaluation annuelle, audit), la gestion des incidents (notification rapide, plan de réponse, rapport écrit), ainsi que des obligations de reporting auprès des autorités.

Des approches divergentes entre l’Union Européenne et les Etats-Unis, qui viennent complexifier la gestion de la conformité

A. Affaiblissement du PCLOB : quel avenir pour les transferts de données entre UE et Etats-Unis ?

Les accords pour les transferts de données à caractère personnel entre l’UE et les États-Unis ont connu plusieurs ruptures, marquées par les arrêts Schrems I et Schrems II, qui ont successivement invalidé les accords transatlantiques en raison du non-respect des exigences de la CJUE. Puis, en 2023, la Commission européenne adopte le Data Privacy Framework (DPF), censé rétablir un cadre juridique conforme en s’appuyant notamment sur le PCLOB, organe indépendant chargé de contrôler les pratiques de renseignement américaines.

Cependant, le 27 janvier 2025, l’administration Trump révoque plusieurs membres du PCLOB, rendant l’organe inopérant. Cette décision fragilise la validité du DPF, poussant les entreprises à revenir aux Transfert Impact Assessments (TIA), complexes, coûteux et incertains sur le plan juridique.

Historique sur les relations UE-USA en matière de transferts de données à caractère personnel

Une invalidité du DPF soulèverait à nouveau des questions quant à l’encadrement juridique des transferts de données à caractère personnel entre UE et Etats-Unis. Dans ce contexte d’instabilité juridique, une solution durable pourrait émerger de la technologie plutôt que du droit. Cela pourrait par exemple être le chiffrement homomorphique qui, bien que peu mature, constitue une piste prometteuse pour garantir la sécurité des données, à condition de développer des solutions européennes souveraines.

B. Des approches divergentes pour l’encadrement de l’intelligence artificielle

L’intelligence artificielle a connu ces dernières années un essor fulgurant, avec lequel apparaissent aussi de nouveaux risques et menaces cybersécurité. Pour répondre à ces enjeux, l’Union européenne et les États-Unis adoptent des approches réglementaires opposées.

L’Union Européenne a choisi la mise en œuvre d’une réglementation pour encadrer le développement de l’intelligence artificielle. L’AI Act a ainsi été adopté en mai 2024, et vient imposer des mesures de sécurité à mettre en œuvre suivant les niveaux de risques des systèmes.

Les États-Unis, à l’inverse, misent sur une stratégie axée sur la compétitivité technologique et la souveraineté industrielle, avec une réglementation minimaliste. Cette orientation s’est concrétisée avec le décret Executive Order 14179 du 23 janvier 2025, intitulé « Removing Barriers to American Leadership in Artificial Intelligence ». Ce décret impose l’élaboration d’un plan d’action pour consolider la position dominante des États-Unis sur l’intelligence artificielle. Il abroge également les mesures jugées contraignantes pour l’innovation, et entend écarter tout parti pris idéologique ou agenda social dans le développement des systèmes d’intelligence artificielle.

Dans ce contexte de renforcement des réglementations, quelle approche adopter pour gérer l’empilement ?

La dynamique de renforcement des réglementations à l’international contribue à un empilement de multiples réglementations qui rendent complexe la gestion de la conformité, en particulier pour les entreprises ayant une forte empreinte internationale. Face à cette complexité, deux grandes approches peuvent être privilégiées, suivant le contexte, l’organisation et l’empreinte internationale des entreprises.

Approche centralisée

La première approche repose sur l’élaboration d’un référentiel global de mesures. Ce référentiel peut être basé sur des standards internationaux reconnus tels que l’ISO/IEC 27001 ou le NIST CSF 2.0, ou sur une réglementation jugée clé et particulièrement complète. L’ensemble des réglementations applicables est ensuite mappé sur ce référentiel, permettant d’assurer une couverture transverse des obligations par un standard unique.

La responsabilité de la mise en œuvre des mesures de mise en conformité est portée par les équipes centrales ou locales, suivant la nature des mesures, avec toujours un fort contrôle au niveau central.

Cette approche est particulièrement adaptée pour les entreprises disposant d’une organisation et d’un système d’information centralisés, et avec une empreinte internationale limitée.

Approche décentralisée

La deuxième approche privilégie une organisation décentralisée de la conformité, s’appuyant sur les équipes locales. Dans ce cadre, un référentiel réglementaire global est défini au niveau central, qui constitue un socle minimal de conformité pour l’ensemble des régions. Il couvre généralement 85 à 90 % des exigences de l’ensemble des réglementations qu’on pourra retrouver au niveau local.

En revanche, on ne cherche pas, dans cette approche, à compléter le référentiel global sur la base de l’analyse de l’ensemble des réglementations locales. La responsabilité de l’ajustement aux exigences locales ou régionales est portée par les RSSI locaux, qui assurent la conformité aux mesures locales, en particulier les 10 à 15 % de mesures non couvertes dans le référentiel global. Cette organisation permet une mise en œuvre différenciée selon les régions, tout en conservant un cadre normatif central.

Ce modèle est particulièrement adapté aux structures décentralisées, caractérisées par une forte autonomie locale et une empreinte internationale étendue. Il offre une plus grande agilité face aux évolutions réglementaires, en s’appuyant sur la connaissance fine des contextes nationaux, tout en allégeant la charge de pilotage central.

Cas concret de l’accompagnement d’un client fortement implanté à l’international

Un programme de cybersécurité récemment mis en œuvre au sein d’un groupe international illustre une approche décentralisée mais avec un fort contrôle du groupe.

Le cadre de conformité, défini par le siège, repose sur des objectifs de sécurité fondé sur des scénarios de menaces, et s’appuie sur un socle commun intégrant les principales réglementations applicables. Ce socle est articulé à partir d’une matrice multi-référentiels (DORA, NIS2, ISO 27001). Les entités locales assurent le déploiement opérationnel des mesures définies au niveau groupe, ainsi que leur contrôle interne, sous la coordination d’un responsable RSSI local chargé de consolider les informations et d’en assurer la remontée d’information. Le dispositif prévoit également une capacité d’ajustement local, permettant de formuler des remarques sur la stratégie centrale, notamment pour éviter les potentielles contradictions avec les réglementations locales.

Le RSSI groupe joue un rôle de supervision transverse. Il vérifie que les exigences définies au niveau central sont bien prises en compte par les RSSI locaux, même si ces derniers ont la responsabilité de leur mise en œuvre. Il s’assure également que les dispositifs déployés sont alignés à la fois avec les exigences du groupe et avec les réglementations locales. Son rôle n’est pas de remettre en cause les choix locaux, mais d’en vérifier la cohérence avec le cadre global.

En matière de gouvernance des contrôles, chaque exigence réglementaire, qu’elle soit d’origine locale ou groupe, est associée à un contrôle spécifique. Une gouvernance claire entre les niveaux groupe et local est donc indispensable pour gérer un catalogue de contrôles cohérent, éviter les redondances et garantir une bonne articulation dans le dispositif de conformité.

Ce modèle permet de garantir un socle de sécurité homogène, tout en préservant la flexibilité nécessaire à l’adaptation aux réglementations locales. Cependant, il présente également certaines limites. En particulier sa structuration centralisée, bien que garante d’une cohérence globale, induit une certaine lourdeur dans la gestion quotidienne, notamment lorsqu’il s’agit de faire évoluer le dispositif ou d’intégrer rapidement de nouvelles exigences réglementaires.

Possibilité d’un découplage des SI

Au-delà de ces approches, certaines entreprises font le choix d’aller vers un découplage de leurs systèmes d’information. Ce choix est réalisé dans un contexte où les tensions géopolitiques influencent de plus en plus les stratégies cybersécurité. Dans ce contexte, la place croissante de la souveraineté et du protectionnisme dans les réglementations cybersécurité engendre des contradictions entre réglementations et rend difficile, voire impossible, la mise en conformité d’un SI unique à des réglementations de différentes plaques géographiques.

Le découplage vient répondre à ces problématiques en prévoyant des infrastructures, des applications ou encore des équipes dédiées sur les différentes plaques géographiques, généralement US, UE et Asie, avec un filtrage strict entre les zones.

Vers une phase de consolidation et de rationalisation ?

Dans ce contexte, on semble se diriger vers phase de consolidation des réglementations, avec la mise en œuvre des textes récemment adoptés et un ralentissement de la publication de nouvelles réglementations. Des évolutions pourraient tout de même arriver afin de prendre en compte l’émergence de nouvelles technologies, en particulier l’informatique quantique.

Par ailleurs, face à une complexité réglementaire croissante dans l’UE, la Commission européenne semble amorcer une nouvelle phase de rationalisation, visant à alléger certaines obligations jugées inadaptées. Cette volonté de rationalisation se traduit notamment par un projet d’allègement ciblé du RGPD pour les PME-TPE.  

Une autre piste de simplification passe par la mise en place de mécanismes de reconnaissance mutuelle entre réglementations dans différents pays. La conformité réglementaire des entreprises pourrait alors être simplifiée à condition que les Etats intègrent explicitement cette logique dans leur réglementation nationale. La France, par exemple, envisage d’intégrer ce mécanisme dans le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité. Cependant, une reconnaissance mutuelle pourrait engendrer un risque de dumping réglementaire : certaines entreprises pourraient choisir les référentiels les moins exigeants afin de réduire le coût et la complexité de la mise en conformité, au détriment de la sécurité.

Ce principe n’est pourtant pas complètement nouveau : le RGPD reconnaît déjà des pays tiers comme disposant d’un niveau de protection « adéquat » (ex. : Japon, Canada, Argentine), facilitant ainsi les transferts de données avec ces pays.

[1] Global Cybersecurity Outlook 2025 | World Economic Forum

Cet article Réglementations cybersécurité : Comment gérer la complexité d’un empilement réglementaire croissant ? est apparu en premier sur RiskInsight.

Dans un contexte où la transformation numérique du secteur de la santé s’accélère, la protection des données de santé est un enjeu toujours plus critique. En 2021, notre article « Certification Hébergeur de Données de Santé : deux ans déjà ! », par Laurent Guille et Alexandra Cuillerdier, dressait un premier bilan prometteur du référentiel HDS. Face à la croissance des enjeux liés à la souveraineté des données et à la cybersécurité, une refonte s’imposait. Cette évolution vers HDS v2, entrée en vigueur en 2024, marque un tournant dans l’approche de l’hébergement des données de santé en France, en renforçant la protection et la souveraineté des données de santé dans un contexte numérique en constante évolution. 

HDS v1 : un premier cadre structurant mais perfectible 

Depuis son introduction en 2018, le référentiel HDS a contribué à structurer et professionnaliser le secteur de l’hébergement des données de santé. Cependant, cette première version du référentiel présentait certaines limitations. En particulier, le cadre initial présentait des zones d’ombre concernant la souveraineté des données, notamment sur la localisation et le contrôle des données de santé. En outre, l’évolution rapide des menaces cyber et des technologies imposait une mise à jour substantielle des exigences de sécurité pour maintenir un niveau de protection adapté aux risques actuels. 

Refonte du cadre technique et sécuritaire 

Sur le plan technique, les nouvelles exigences de la norme ISO 27001:2023 sont adoptées au sein de la nouvelle version de HDS. Cette mise à jour intègre une gestion des risques de sécurité adaptée aux nouveaux contextes numériques, ainsi que de nouveaux contrôles liés à la cybersécurité. 

Les autres références normatives sont quant à elles rationnalisées. Les références aux normes ISO 20000-1, ISO27017 et ISO27018 disparaissent dans le cadre d’HDS v2 tandis que 31 exigences spécifiques sont directement intégrées dans le référentiel, qui s’appuie également sur la norme ISO/IEC-17021-1:2015 pour encadrer l’évaluation de la conformité. Cette nouvelle version vient également préciser l’articulation avec les exigences du référentiel SecNumCloud afin de faciliter l’obtention de la certification HDS pour les hébergeurs déjà qualifiés SecNumCloud. 

Un renforcement majeur de la souveraineté numérique 

L’une des évolutions les plus marquantes d’HDS v2 concerne le renforcement de la souveraineté numérique. Le nouveau référentiel impose désormais que l’hébergement physique des données de santé soit réalisé exclusivement sur le territoire de l’Espace Économique Européen (EEE). Cette exigence vient renforcer les garanties en termes de protection des données et contribue à l’émergence d’un écosystème d’acteurs européens dans le domaine de la santé numérique. 

Elle est complétée par le renforcement de la transparence, qui devient également un enjeu central du dispositif, avec deux obligations majeures : 

• Les hébergeurs doivent désormais publier sur leur site internet une cartographie des éventuels transferts de données vers des pays hors EEE, permettant ainsi aux personnes concernées et aux acteurs de santé d’avoir une visibilité claire sur le parcours de leurs données ;
• En cas d’accès distant aux données depuis un pays tiers ou de soumission à une législation extra-européenne n’assurant pas un niveau de protection adéquat au sens de l’article 45 du RGPD, l’hébergeur doit en informer ses clients dans le contrat. Il doit notamment préciser les risques associés et détailler les mesures technique et juridiques mises en œuvre pour les limiter.

Renforcement des exigences contractuelles 

L’encadrement de la sous-traitance fait l’objet d’une attention particulière dans HDS v2. Les mesures associées sont renforcées et les hébergeurs doivent désormais notamment : 

• Détailler précisément les activités d’hébergement certifiées dans leurs contrats ;
• Maintenir une transparence totale sur leur chaîne de sous-traitance ;
• S’assurer que leurs sous-traitants respectent les mêmes exigences de sécurité et de localisation des données ;
• Mettre en place des mécanismes de contrôle et d’audit de leurs sous-traitants.

Ces nouvelles obligations contractuelles visent à garantir une meilleure maîtrise de la chaîne de valeur et une plus grande transparence pour les responsables de traitement. 

Conséquences pratiques pour l’écosystème 

Pour les hébergeurs de données de santé, ces évolutions du référentiel impliquent une adaptation de leurs infrastructures pour garantir la localisation des données dans l’EEE. Elles nécessitent également une mise à niveau de leurs mesures de sécurité pour répondre aux exigences de la version 2023 de la norme ISO 27001 et la revue des contrats, tant avec leurs clients qu’avec leurs sous-traitants. 

Perspectives et mise en œuvre 

Cette nouvelle version modernisée du référentiel HDS permet de répondre aux enjeux croissants de sécurité, de souveraineté et de transparence. Sa mise en œuvre s’échelonne sur environ deux ans, avec une application immédiate pour les nouvelles certifications à partir du 16 novembre 2024, et une période de transition jusqu’au 16 mai 2026 pour les hébergeurs déjà certifiés HDS v1. 

À plus long terme, plusieurs questions se posent sur l’évolution du dispositif. À l’heure où la directive NIS 2 intègre déjà les prestataires de soins de santé et l’industrie pharmaceutique parmi ses secteurs d’activité essentiels, tout en classant la fabrication de dispositifs médicaux et de diagnostic in vitro dans ses secteurs importants, l’émergence d’HDS 2 soulève une question : la coopération européenne pourrait-elle aboutir à un cadre encore plus intégré pour la protection des données de santé et harmoniser les pratiques à l’échelle du continent ? 

Cet article Evolution du référentiel HDS – Vers une sécurité et une souveraineté renforcées  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.

Une densification et une complexification du paysage réglementaire cybersécurité

Les premières tentatives de réglementations en matière de protection des données à caractère personnel et de cybersécurité restent partielles jusqu’au début des années 2000. Elles sont alors initiées essentiellement par les Etats-Unis et l’Union Européenne. Elles sont d’abord axées sur la protection des données à caractère personnel, en France avec la Loi Informatique et Libertés (1978) et aux Etats-Unis avec des réglementations sectorielles :  le Privacy Act (1974) pour le secteur public, le Health Insurance Portability and Accountability Act pour le secteur de la santé (1996) et le Gramm–Leach–Bliley Act (1999) pour le secteur financier.

Les premières réglementations cybersécurité ont ensuite vu le jour au début des années 2000 dans le secteur financier et visaient à améliorer la sécurité des services fournis. Parmi les réglementations notables, on peut citer le Sarbanes-Oxley Act (2002), aux Etats-Unis, renforçant la transparence des entreprises en matière de contrôle interne ainsi que la Directive sur les Services de Paiement (2007), au sein de l’Union Européenne, qui règlemente la sécurité des paiements et des opérations en ligne.

Depuis le début des années 2010, des réglementations plus structurantes ont émergé pour constituer un premier socle réglementaire cyber, toujours dans les mêmes régions. Ces réglementations sont principalement centrées sur la protection des infrastructures critiques, avec en France la Loi de Programmation Militaire de 2013-2018 (2013), aux Etats-Unis le National Cyber Security and Critical Infrastructure Protection Act (2014), mais aussi la directive Network and Information Security 1 (2016) promulguée par l’Union Européenne.

Ce n’est qu’à la fin des années 2010 que la volonté de réglementer l’espace cyber devient plus globale. Alors que de nombreux pays ont emboîté le pas des Etats-Unis et de l’Union Européenne, des réglementations cyber plus contraignantes émergent également, engendrant des impacts en profondeur sur les systèmes d’information. Cela se manifeste à travers l’arrivée de réglementations majeures sur la protection des données à caractère personnel à travers le monde : le Règlement Général sur la Protection des Données (RGPD, 2018) en Europe, le California Consumer Privacy Act (CCPA, 2020) en Californie, la Loi pour la Protection des Données personnelles (LGPD, 2020) au Brésil, la Personal Information Protection Law (PIPL, 2021) en Chine, ou encore le Personal Data Law (2022) en Russie.

D’autres réglementations visant à protéger les systèmes d’informations se multiplient, avec la Cybersecurity Law en Chine (2017), la Réglementation Cybersécurité NYCRR 500 pour l’Etat de New-York (2017), ou encore la nouvelle mouture de la Directive NIS (2023) et DORA en Europe.

Evolution du paysage réglementaire cybersécurité[2]

À ce paysage réglementaire cybersécurité complexe vient par ailleurs s’ajouter un vaste écosystème d’exigences et standards cybersécurité, avec différents niveaux de contraintes : des exigences réglementaires issues de réglementations cyber ou non, à valeur obligatoire, des recommandations ou encore des exigences ayant valeur de contrat. Dans ce contexte, il est nécessaire de bien identifier l’ensemble des exigences applicables et le niveau de contrainte qu’elles imposent.

Typologies d’exigences et standards cybersécurité, au-delà des réglementations cyber

Une stratégie de conformité réglementaire cybersécurité à adapter au nouveau paradigme

Face à la complexification du paysage réglementaire cybersécurité de par le monde, la conformité ne peut être pensée uniquement comme une conformité totale à l’ensemble des exigences réglementaires applicables. Face à des exigences pointues et coûteuses à appliquer, voire parfois contradictoires, il devient nécessaire de mettre en place des stratégies de conformité cyber basées sur les risques. Leur définition sera basée sur l’étude du niveau de conformité réglementaire de l’existant, sur l’évaluation de l’effort et de la complexité des mesures devant être déployées pour la mise en conformité à chaque réglementation, mise au regard des risques associés à de potentielles non-conformités, tant en termes de sanctions qu’en termes de protection du SI. Cette analyse, loin de vouloir échapper à la loi, vise à bien identifier le bénéfice/risque des activités et peut conduire à réorienter des activités, limiter leurs périmètres, ou encore agir de concert avec l’écosystème pour faire évoluer les exigences.

Afin de mettre en œuvre une telle stratégie, il est d’abord essentiel d’identifier l’ensemble des réglementations applicables et de mettre en place une veille réglementaire permettant de suivre l’évolution des réglementations et les actualités associées. Une organisation à deux niveaux doit ensuite être mise en place afin d’assurer le pilotage de la conformité réglementaire cyber.

Un premier niveau de pilotage global visant à disposer d’une vue d’ensemble haut-niveau : une analyse globale du niveau de conformité cyber doit être réalisée. Elle pourra s’appuyer sur un référentiel cybersécurité reconnu tel que NIST ou ISO 27001 pour les exigences sécurité. Pour les exigences relatives à la protection des données à caractère personnel, le RGPD est un bon socle puisque l’essentiel des réglementations sur cette thématique à l’international en sont dérivées. Le NIST privacy et les normes ISO privacy constituent également des référentiels solides en la matière. Ces référentiels pourront être mappés avec les principales réglementations applicables et on pourra tirer parti des synergies existantes entre les réglementations, comme l’illustrent les deux exemples ci-dessous.

Pour compléter cette analyse, un plan d’audit devra être déroulé afin d’évaluer plus précisément la conformité aux réglementations locales clés.

Un deuxième niveau de pilotage « local », à l’échelle géographique ou métier, visant à assurer la conformité réglementaire locale dans chacune des régions où le groupe est présent. Cela nécessite tout d’abord la mise en place d’une veille locale afin d’identifier et de connaître précisément les réglementations et les actualités associés. Cela passe ensuite par l’analyse détaillée du niveau de conformité aux réglementations locales, l’identification des spécificités et des besoins pour assurer le bon niveau de conformité, et la remontée de ces éléments au groupe pour assurer le pilotage global des actions de conformité.

Des réglementations protectionnistes questionnant le besoin de découplage des systèmes d’information

Être conforme à une multitude de règlementations cybersécurité devient un véritable défi pour les entreprises présentes à l’international et disposant d’un système d’information centralisé. Cela s’explique par l’empilement de ces réglementations avec parfois des dispositions incompatibles ou contradictoires entre certaines réglementations, mais aussi en raison de l’émergence d’exigences engendrant des impacts en profondeur sur les systèmes d’information.

C’est entre autres le cas de la réglementation PIPL en Chine, et en particulier son article 40 qui prévoit que le transfert de données hors de Chine sera autorisé seulement si leur traitement est conforme à l’évaluation de sécurité établie par l’administration chinoise. Cette réglementation sera applicable au-delà d’un certain volume de données à caractère personnel (pas encore spécifié par les autorités chinoises).

Des incompatibilités entre les réglementations ont également vu le jour entre les Etats-Unis et l’Union Européenne. Cette situation est illustrée par l’invalidation du Privacy Shield [3] américain par la Cour de Justice de l’Union Européenne, ses arrêts Schrems remettant en question la capacité des hébergeurs Cloud américains à traiter les données personnelles de leurs clients européens conformément aux exigences européennes.

Dans ce contexte de renforcement des exigences de cybersécurité et de protection des données à caractère personnel, exacerbé par les volontés protectionnistes de certains Etats, il peut devenir nécessaire d’étudier les besoins de découplage des systèmes d’information globalisés et centralisés en considérant la séparation en plusieurs zones géographiques, qui pourraient être :

• Une zone comprenant les Etats-Unis et le Royaume-Uni ;
• Une deuxième zone centrée sur la Chine ;
• Une troisième zone composée de l’Union Européenne et les pays adéquats[4] au sens du GDPR.

Selon leur réalité réglementaire et les évolutions potentielles, les autres pays ou régions pourraient être rattachés à l’une ou l’autre de ces trois zones.

À l’avenir, les systèmes d’information de ces différentes zones pourraient s’appuyer plus largement sur les clouds souverains qui sont en cours de développement.

Des contraintes qui peuvent même exhorter à l’arrêt de l’activité dans une région

Nous observons même l’arrêt ou le décalage de lancement d’activités de plusieurs entreprises dans certains pays où les contraintes réglementaires et risques de sanctions associés sont trop importants au regard des enjeux métiers et de la stratégie de l’entreprise. C’est notamment le cas dans certains Etats des Etats-Unis, et en Europe, où certains grands acteurs freinent leur développement à cause du RGPD (exemple de l’open AI/ Bard de Google, encore le lancement de Thread par Meta).

Perspectives : quelles évolutions en 2023 et après ?

Le paysage réglementaire, complexe comme évoqué précédemment, va continuer à s’étoffer dans les mois et les années à venir. A la fois sur des sujets nouveaux (IA, sécurité des produits) comme sur des pans existants, comme les infrastructures critiques.

Sur le volet « infrastructure critique », après de premières phases de réglementations centrées sur la protection des données à caractère personnel, les autorités ont veillé à la protection des infrastructures critiques, qui se poursuit avec notamment la directive NIS 2. Adoptée le 10 novembre 2022 et bientôt transposée en droit français, elle vise à réduire les disparités entre les Etats membres, renforcer la cybersécurité dans un contexte de digitalisation croissant et établir des mesures de sécurité pour améliorer le niveau de sécurité des infrastructures critiques au sein des Etats membres de l’UE.

Une nouvelle phase se profile désormais, durant laquelle les réglementations se concentreront sur la sécurité des produits numériques, avec en particulier :

• L’AI Act, réglementation européenne visant à définir un référentiel commun pour le développement et l’utilisation de l’Intelligence Artificielle (IA). Dans un contexte d’accélération fulgurante des usages de l’IA, de nouvelles réglementations devraient également émerger de par le monde, et notamment en Chine où des mesures ont d’ores-et-déjà été prises et ont entraîné la fermeture de 55 applications et 4200 sites entre janvier et mars 2023[5].
• Le Cyber Résilience Act (R.A), réglementation européenne elle aussi, qui vise à renforcer le niveau de sécurité des produits numériques en imposant des mesures à respecter par les constructeurs dès la conception des produits. Sans compter l’annonce récente par la Maison Blanche de l’initative « Cyber trust mark » ciblant le même objectif mais avec une approche différente[6].

L’enjeu réglementaire n’est donc pas près de réduire et les équipes cyber doivent s’y préparer. Il sera, a minima, nécessaire de renforcer les liens avec les métiers concernés et également avec les équipes juridiques. Les entreprises les plus matures dans le domaine ont créé des pôles juridiques au sein même des équipes cyber, pour échanger avec les différents services juridiques. Ceci n’est pas forcément nécessaire en fonction de l’organisation de chaque structure, mais peut aussi être un gage de mobilisation important.

Dans tous les cas, l’enjeu sera pour les entreprises d’arriver à transformer ces exigences réglementaires, souvent obligatoires, en un avantage concurrentiel dans leurs activités, en ne faisant pas de la conformité punitive, a minima, mais bien en s’emparant du sujet et en faisant un acte de transformation de ces pratiques qu’elle pourra valoriser extérieurement.

[1] https://blog.checkpoint.com/2023/01/05/38-increase-in-2022-global-cyberattacks/

[2] Liste non exhaustive des réglementations cyber

[3] https://www.cnil.fr/fr/invalidation-du-privacy-shield-les-suites-de-larret-de-la-cjue

[4] Pays en adéquation avec le niveau de protection requis par l’UE https://www.cnil.fr/fr/la-protection-des-donnees-dans-le-monde

[5] https://www.01net.com/actualites/comment-les-lois-chinoises-tres-strictes-risquent-de-nuire-a-lia-made-in-china.html

[6] https://arstechnica.com/information-technology/2023/07/the-cyber-trust-mark-is-a-voluntary-iot-label-coming-in-2024-what-does-it-mean/

Cet article Paysage réglementaire cyber : enjeux et perspectives est apparu en premier sur RiskInsight.