Chapitre 2 — Le cadre réglementaire complet : RGPD, NIS2, AI Act, Cloud Act, DORA

Matrice réglementaire : quel règlement s'applique à quelle situation

Avant d'entrer dans le détail de chaque texte, voici une grille de lecture rapide pour identifier vos obligations selon votre situation :

RGPD et IA : les obligations en détail

Le Règlement Général sur la Protection des Données (RGPD, Règlement 2016/679) s'applique à tous les traitements de données à caractère personnel, y compris lorsque ces traitements sont réalisés par ou via une intelligence artificielle. Il n'y a pas d'exemption pour les projets IA, et l'excuse «nous ne savions pas que le LLM traitait des données personnelles» n'est pas recevable en droit.

Les bases légales pour les traitements IA

Tout traitement de données personnelles par une IA doit reposer sur une base légale parmi les six prévues à l'article 6 du RGPD. En pratique, pour les entreprises, les bases les plus utilisées pour les traitements IA sont :

Le consentement (art. 6.1.a) : Approprié pour les traitements dont la personne concernée est directement l'utilisateur final (chatbot grand public, personnalisation). Difficile à maintenir en contexte B2B car le consentement doit être libre, éclairé, spécifique et révocable. Le retrait du consentement doit entraîner l'effacement des données — ce qui est techniquement complexe avec des LLM fine-tunés sur des données personnelles.

L'exécution du contrat (art. 6.1.b) : Applicable si le traitement IA est nécessaire à l'exécution d'un contrat avec la personne concernée. Par exemple, utiliser un LLM pour analyser un sinistre déclaré par un assuré est justifiable sur cette base. Attention : «nécessaire» est interprété strictement — la commodité ne suffit pas.

L'intérêt légitime (art. 6.1.f) : La base la plus flexible, mais aussi la plus contestable. L'intérêt légitime de l'entreprise doit être mis en balance avec les droits et intérêts des personnes concernées. Pour les traitements IA internes (analyse de la performance des équipes, détection de fraude interne), c'est souvent la base appropriée, à condition d'avoir documenté le raisonnable test.

L'obligation légale (art. 6.1.c) : Applicable aux traitements imposés par la loi (LCB-FT, conformité AML, obligations fiscales). Si votre IA de détection de fraude est imposée par une réglementation sectorielle, cette base est la plus solide.

L'Analyse d'Impact relative à la Protection des Données (AIPD)

L'article 35 du RGPD impose la réalisation d'une AIPD (Data Protection Impact Assessment, DPIA) avant tout traitement «susceptible d'engendrer un risque élevé» pour les droits et libertés des personnes. La CNIL a publié une liste indicative des types de traitements nécessitant une AIPD : les systèmes d'IA en font systématiquement partie dans les catégories suivantes :

• Évaluation ou notation de personnes (scoring client, évaluation de performance)
• Décision automatique avec effet juridique ou significatif (octroi de crédit, admission, embauche)
• Surveillance systématique (monitoring des communications, suivi comportemental)
• Traitement de données sensibles à grande échelle (santé, biométrie, opinions politiques)
• Traitement de données de personnes vulnérables (mineurs, patients)
• Usage innovant de technologies nouvelles (tout LLM en 2026 entre dans cette catégorie)

Une AIPD comprend : la description du traitement et de ses finalités, l'évaluation de la nécessité et de la proportionnalité, l'identification et l'évaluation des risques, les mesures envisagées pour traiter ces risques. Si l'AIPD conclut à un risque résiduel élevé, le responsable de traitement doit consulter la CNIL avant de mettre le traitement en œuvre.

Les droits des personnes concernées et l'IA

Le RGPD accorde aux personnes concernées plusieurs droits qui créent des obligations techniques spécifiques pour vos systèmes IA :

Droit d'accès (art. 15) : Toute personne peut demander à savoir si des données la concernant sont traitées par vos IA, et obtenir une copie. Si votre LLM a ingéré des e-mails clients, des rapports les mentionnant, ou des transcriptions de réunions, vous devez être en mesure d'extraire toutes ces données à la demande. Les systèmes IA doivent donc intégrer dès la conception une fonctionnalité de recherche par sujet de données.

Droit à l'effacement (art. 17) : Si une personne demande l'effacement de ses données, vous devez les supprimer de tous les systèmes, y compris des modèles IA qui auraient été entraînés sur ces données. Techniquement, l'effacement de données d'un modèle de machine learning est un sujet de recherche actif (on parle de «machine unlearning»). En pratique, pour un LLM fine-tuné sur des données incluant des données personnelles, l'effacement complet implique souvent de réentraîner le modèle sans les données en question — ce qui est coûteux. C'est un argument supplémentaire pour ne pas fine-tuner des LLM sur des données personnelles non indispensables.

Droit à la portabilité (art. 20) : Les données fournies par la personne et traitées par vos IA doivent pouvoir être transmises dans un format structuré et lisible par machine. Cela impose des standards d'interopérabilité à vos systèmes IA.

Droit d'opposition aux décisions automatisées (art. 22) : Toute décision prise exclusivement par une IA et produisant des effets juridiques ou «significatifs similaires» doit pouvoir être contestée et faire l'objet d'un réexamen humain. Cet article interdit de fait les systèmes IA de décision totalement autonomes pour des décisions importantes (embauche, crédit, assurance, justice). Un humain doit toujours pouvoir intervenir dans la boucle.

La sous-traitance IA et l'article 28

Dès lors que vous confiez à un tiers (fournisseur SaaS IA, hébergeur, intégrateur) le traitement de données personnelles, ce tiers devient sous-traitant au sens de l'article 28. Le contrat entre vous et ce sous-traitant doit obligatoirement contenir :

• L'objet, la durée, la nature et la finalité du traitement
• Le type de données et les catégories de personnes concernées
• Les obligations et droits du responsable de traitement
• L'obligation de n'agir que sur instruction documentée
• Les mesures de sécurité techniques et organisationnelles
• L'interdiction de sous-traiter sans autorisation préalable (et les obligations imposées aux sous-sous-traitants)
• L'assistance dans l'exercice des droits des personnes concernées
• L'assistance dans les obligations de sécurité, notification de violations, AIPD
• La suppression ou la restitution des données à la fin du contrat
• La mise à disposition des informations nécessaires à la démonstration du respect des obligations

Si votre contrat avec votre fournisseur IA ne contient pas ces éléments, vous êtes en infraction caractérisée, indépendamment de toute violation de données. La CNIL a sanctionné plusieurs entreprises uniquement sur l'absence ou l'insuffisance des clauses de sous-traitance, sans qu'aucune violation de données ne se soit produite.

NIS2 : résilience des SI et IA

La Directive NIS2 (Directive 2022/2555, transposée en droit français par la loi du 26 janvier 2025) élargit considérablement le périmètre des entités soumises à des obligations de cybersécurité renforcées. Elle distingue deux catégories :

Entités essentielles : Secteurs de haute criticité (énergie, transports, banques, infrastructures des marchés financiers, santé, eau potable, eaux usées, infrastructure numérique, fournisseurs de services TIC, administration publique, espace). Soumises aux obligations les plus strictes et à des contrôles ex ante.

Entités importantes : Secteurs critiques supplémentaires (services postaux, gestion des déchets, chimie, alimentation, fabrication, fournisseurs numériques, recherche). Soumises à des obligations similaires mais avec des contrôles ex post.

Pour une entreprise concernée par NIS2, tout système IA déployé dans le SI est dans le périmètre des obligations NIS2. Cela implique :

Mesures techniques minimales requises par NIS2 pour les systèmes IA

• Politiques de sécurité IA : Documentation formelle des risques liés aux systèmes IA, des mesures de mitigation, et des procédures de revue périodique
• Gestion des risques de la chaîne d'approvisionnement : Audit de vos fournisseurs IA (voir notre article sur l'audit fournisseur IA), clauses contractuelles de sécurité, surveillance continue
• Continuité d'activité : Plans de reprise d'activité incluant les systèmes IA, tests de DR réguliers
• Contrôle d'accès : Authentification forte pour l'accès aux LLM et aux données d'entraînement, principe du moindre privilège
• Chiffrement : Chiffrement des données en transit et au repos, y compris les prompts, les contextes et les outputs des LLM
• Audit logs : Journalisation complète des interactions avec les systèmes IA pour permettre la détection d'anomalies et la reconstruction des incidents

Notification des incidents NIS2 impliquant des IA

NIS2 impose des délais de notification très courts pour les incidents de sécurité significatifs. Pour un incident impliquant un système IA :

• Dans les 24 heures : notification précoce à l'ANSSI (dans le cas français) si l'incident est susceptible d'avoir un impact transfrontalier ou d'être d'origine malveillante
• Dans les 72 heures : notification complète incluant l'évaluation initiale, la sévérité, les indicateurs de compromission
• Dans le mois : rapport final avec analyse de cause racine, impact, mesures prises et recommandations

Un incident IA peut déclencher la notification NIS2 même sans violation de données personnelles : une attaque par prompt injection qui compromet un système IA critique, une dégradation des performances d'un LLM de sécurité, ou un accès non autorisé aux données d'entraînement sont des exemples d'incidents à notifier.

AI Act : classification des risques et calendrier d'obligations

Le Règlement européen sur l'intelligence artificielle (Règlement 2024/1689) est le premier cadre réglementaire mondial dédié à l'IA. Il s'applique à tous les systèmes IA mis sur le marché ou mis en service dans l'UE, quelle que soit l'origine géographique du fournisseur.

La pyramide des risques AI Act

Niveau 1 — Risque inacceptable (interdit) : Applicable depuis le 2 février 2025. Sont interdits : les systèmes de notation sociale par les pouvoirs publics, les systèmes d'identification biométrique en temps réel dans les espaces publics (sauf exceptions), les systèmes de manipulation comportementale subliminale, les systèmes d'exploitation des vulnérabilités individuelles. Aucune entreprise ne devrait déployer de tels systèmes.

Niveau 2 — Haut risque (réglementé) : Applicable depuis le 2 août 2026. Ce sont les systèmes les plus importants pour les entreprises. Les systèmes IA à haut risque incluent :

• Infrastructures critiques (énergie, eau, transport)
• Éducation et formation professionnelle (systèmes d'évaluation)
• Emploi et gestion des travailleurs (recrutement, évaluation de la performance, promotion, licenciement)
• Accès aux services essentiels (crédit, assurance, prestations sociales)
• Application de la loi (identification de personnes, évaluation de la fiabilité de preuves)
• Gestion des migrations et de l'asile
• Administration de la justice et processus démocratiques

Niveau 3 — Risque limité (transparence requise) : Applicable depuis le 2 août 2025. Les systèmes d'IA qui interagissent avec des humains (chatbots) doivent informer les utilisateurs qu'ils interagissent avec une IA. Les systèmes de génération de contenu synthétique (deepfakes, texte généré par IA) doivent marquer ce contenu.

Niveau 4 — Risque minimal (non réglementé) : Les jeux vidéo avec IA, les filtres anti-spam, les systèmes de recommandation de contenu non sensible. Pas d'obligations spécifiques.

Les modèles d'IA à usage général (GPAI)

L'AI Act introduit une catégorie spécifique pour les grands modèles d'IA à usage général (GPAI — General Purpose AI), applicable depuis le 2 août 2025. Les LLM commerciaux comme GPT-4, Gemini Ultra, ou ELODIE 32B entrent dans cette catégorie.

Les obligations des fournisseurs de GPAI (obligations qui vous concernent si vous utilisez un modèle de fondation pour développer votre propre application) :

• Documentation technique et instructions d'utilisation
• Respect des droits d'auteur dans les données d'entraînement
• Résumé du contenu utilisé pour l'entraînement (transparence)

Pour les modèles GPAI à haut impact systémique (>10^25 FLOP d'entraînement), des obligations supplémentaires s'appliquent : évaluation adversarielle («red teaming»), rapport aux autorités, mesures de cybersécurité renforcées. OpenAI GPT-4, Google Gemini Ultra et Anthropic Claude 3 entrent dans cette catégorie. ELODIE 32B, Mistral Medium, et les modèles de taille comparable n'y entrent pas, ce qui simplifie la conformité pour leurs utilisateurs.

Obligations concrètes pour les systèmes IA à haut risque

Si votre entreprise déploie un système IA classé haut risque (notamment dans les RH, le crédit, ou la santé), voici vos obligations principales :

• Système de gestion des risques : Documentation continue des risques identifiés, tests de robustesse et de précision, mesures de mitigation
• Gouvernance des données : Pratiques de gestion des données pour les jeux d'entraînement, de validation et de test
• Documentation technique : Documentation avant mise sur le marché permettant aux autorités d'évaluer la conformité
• Conservation des logs : Journalisation automatique des événements significatifs tout au long du cycle de vie
• Transparence et information : Information des utilisateurs humains sur les capacités et limites du système
• Contrôle humain : Conception permettant à des personnes physiques de surveiller, comprendre, et intervenir
• Précision, robustesse, cybersécurité : Niveaux appropriés selon l'état de l'art
• Enregistrement dans la base de données EU : Avant mise sur le marché pour certaines catégories

DORA pour le secteur financier

Le Règlement DORA (Digital Operational Resilience Act, Règlement 2022/2554) est entré en vigueur le 17 janvier 2025. Il s'applique à un périmètre très large d'entités financières : banques, assurances, entreprises d'investissement, gestionnaires de fonds, établissements de paiement, prestataires de services de cryptoactifs, et — point crucial — leurs prestataires TIC critiques.

Ce que DORA change pour l'IA dans le secteur financier

DORA ne réglemente pas l'IA spécifiquement, mais ses exigences de résilience opérationnelle numérique s'appliquent de facto à tous les systèmes IA utilisés par les entités financières :

Gestion du risque TIC : Tout système IA doit être intégré dans le dispositif de gestion des risques TIC. Cela inclut l'identification des risques spécifiques aux LLM (hallucinations, biais, prompt injection), leur quantification, et les mesures de mitigation.

Tests de résilience opérationnelle : DORA impose des tests périodiques de résilience, incluant pour les entités les plus critiques des tests de pénétration fondés sur la menace (TLPT — Threat-Led Penetration Testing). Les systèmes IA en production doivent être inclus dans le périmètre de ces tests.

Gestion du risque tiers : DORA introduit une obligation de due diligence renforcée pour les prestataires TIC critiques. Si un LLM externe est utilisé dans un processus financier critique, le fournisseur de ce LLM est un «prestataire TIC critique» soumis aux exigences contractuelles DORA. Ces exigences sont substantielles : droit d'audit, clauses de sous-traitance, garanties de continuité, localisation des données.

Registre des prestataires TIC : Les entités financières doivent maintenir un registre de tous leurs prestataires TIC, mis à jour et disponible sur demande des autorités de supervision. Chaque LLM externe utilisé doit y figurer.

Pour les établissements financiers, DORA crée de facto une forte incitation à l'IA souveraine : il est bien plus simple de satisfaire les exigences DORA avec un LLM hébergé on-premise ou chez un opérateur souverain européen qu'avec un LLM cloud américain pour lequel les droits d'audit et les garanties de résilience sont difficiles à obtenir contractuellement.

Pour aller plus loin : DORA : guide pratique pour le SI financier.

Cloud Act et Schrems II : la réalité des transferts de données

Le Cloud Act en pratique

Le Cloud Act (Clarifying Lawful Overseas Use of Data Act, 2018) autorise les autorités américaines à exiger d'une entreprise de droit américain la communication de données stockées ou contrôlées par elle, quelle que soit la localisation géographique de ces données. Concrètement :

• Microsoft Azure Europe, Google Cloud Frankfurt, AWS Paris : tous soumis au Cloud Act
• OpenAI, Anthropic, Cohere, même opérant depuis des serveurs européens : soumis au Cloud Act
• Une filiale européenne d'une entreprise américaine détenant plus de 25 % du capital : soumise au Cloud Act (depuis 2025)

Les modalités d'application : une injonction judiciaire américaine (National Security Letter, grand jury subpoena) est émise. Le délai de réponse est de 72 heures dans les cas prioritaires. L'entreprise reçevant l'injonction n'est souvent pas autorisée à en informer ses clients. Vous ne saurez peut-être jamais que vos données ont été transmises.

Schrems II et les transferts vers les États-Unis

L'arrêt Data Protection Commissioner v Facebook Ireland Limited, Maximillian Schrems (C-311/18, juillet 2020) a invalidé le Privacy Shield (cadre de transfert EU-US précédent) au motif que la surveillance américaine (FISA 702, EO 12333) ne respecte pas les standards européens de protection des données. L'arrêt Schrems II reste pleinement applicable en 2026.

Le Data Privacy Framework (DPF, successeur du Privacy Shield, adopté en juillet 2023) a fourni un cadre temporaire, mais des recours juridiques sont en cours et la durabilité du DPF est incertaine. Le CEPD a explicitement recommandé aux entreprises de ne pas se reposer uniquement sur le DPF pour les transferts de données sensibles.

La position actuelle du CEPD (recommandations de mars 2025) : les transferts de données vers des pays tiers sans niveau de protection adéquat (dont les États-Unis pour certains types de données) doivent être encadrés par des Clauses Contractuelles Types (CCT) et des mesures techniques supplémentaires garantissant que les données ne peuvent être accédées par les autorités du pays tiers. Pour les données très sensibles, la seule mesure technique efficace est le chiffrement de bout en bout avec des clés gérées exclusivement en Europe — ce qui rend le traitement par le LLM impossible si le fournisseur doit accéder aux données en clair.

Intersections et contradictions entre règlements

La complexité réglementaire ne vient pas seulement du nombre de règlements, mais de leurs interactions parfois contradictoires :

RGPD vs AI Act : la tension sur la transparence

L'AI Act exige que les utilisateurs de systèmes IA à haut risque soient informés des caractéristiques du système et de ses limites. Le RGPD exige que les personnes concernées soient informées des traitements les concernant. Ces deux obligations convergent, mais créent une tension avec l'obligation de confidentialité commerciale du fournisseur IA, qui peut ne pas vouloir divulguer les détails de son modèle. La solution réglementaire passe par l'IA souveraine : vous maîtrisez le modèle, vous pouvez satisfaire les deux obligations sans dépendre de la coopération d'un tiers.

NIS2 vs DORA : double régulation pour les établissements financiers

Les banques et assurances sont soumises à la fois à NIS2 (comme entités essentielles) et à DORA. Les deux textes imposent des exigences de cybersécurité qui se chevauchent largement. La BCE et l'ACPR ont publié en 2025 un guide de concordance pour aider les établissements à éviter la double conformité inutile : en pratique, DORA est plus prescriptif et, lorsque ses exigences sont satisfaites, elles couvrent généralement les exigences NIS2 correspondantes pour les systèmes IA.

Cloud Act vs RGPD : le conflit fondamental

Le Cloud Act crée une obligation légale américaine de divulgation qui entre en contradiction directe avec les obligations de confidentialité et de protection des données imposées par le RGPD. Il n'existe pas de solution contractuelle à ce conflit : aucune clause de votre contrat avec un fournisseur américain ne peut supprimer son obligation légale de répondre à une injonction américaine. La seule solution est de ne pas utiliser de fournisseurs américains pour les données sensibles.

Rôles DPO, RSSI, DSI dans la conformité IA

La conformité réglementaire IA est un effort collectif qui implique au minimum trois fonctions : le DPO, le RSSI, et le DSI. Voici une répartition des responsabilités :

Le DPO (Délégué à la Protection des Données)

• Identifier les traitements IA nécessitant une AIPD et piloter leur réalisation
• Valider les contrats de sous-traitance avec les fournisseurs IA (art. 28)
• Répondre aux demandes d'exercice de droits des personnes concernées impliquant des données traitées par IA
• Notifier la CNIL en cas de violation de données impliquant un système IA
• Maintenir le registre des activités de traitement incluant les traitements IA
• Donner son avis sur les nouveaux projets IA avant déploiement

Le RSSI (Responsable de la Sécurité des SI)

• Évaluer les risques de sécurité des systèmes IA (prompt injection, exfiltration de données, empoisonnement de modèle)
• Définir les exigences de sécurité pour les LLM (chiffrement, contrôle d'accès, audit logs)
• Conduire ou superviser les tests de sécurité des systèmes IA (red teaming)
• Piloter la réponse aux incidents de sécurité impliquant des IA
• Maintenir la cartographie des risques IA dans le SMSI
• Assurer la conformité NIS2 et DORA pour les composants IA

Le DSI (Directeur des Systèmes d'Information)

• Définir la politique d'adoption IA de l'organisation (quels outils, qui peut utiliser, dans quel cadre)
• Piloter la sélection et l'intégration des solutions IA souveraines
• Assurer la cohérence entre les choix IA et l'architecture SI globale
• Gérer le budget et les ressources pour la conformité IA
• Arbitrer les choix build vs buy vs hybrid (voir notre analyse dédiée)
• Rendre compte au COMEX et au Conseil d'Administration de la maturité IA et des risques résiduels

Tableau récapitulatif des obligations

Questions fréquentes

L'AI Act s'applique-t-il si nous utilisons un LLM américain depuis la France ?

Oui. L'AI Act s'applique à tous les systèmes IA «mis sur le marché» ou «mis en service» dans l'UE, quelle que soit la localisation du fournisseur. Si vous utilisez GPT-4 via l'API OpenAI pour faire fonctionner un système de recrutement automatisé, ce système est soumis aux obligations AI Act applicables aux systèmes à haut risque. La responsabilité du déploiement de la conformité incombe au «déployeur» (vous), même si vous n'êtes pas le «fournisseur» du modèle sous-jacent.

Devons-nous nommer un «responsable IA» distinct du DPO et du RSSI ?

L'AI Act ne crée pas d'obligation de nommer un «AI Officer» pour les déployeurs de systèmes IA à haut risque. Cependant, la complexité de la gouvernance IA conduit de nombreuses grandes entreprises françaises à créer cette fonction. Si votre organisation déploie plusieurs systèmes IA à haut risque, un coordinateur IA dédié qui fait le lien entre le DPO, le RSSI, les équipes métier et la DSI peut être justifié. Pour les ETI, cette fonction peut être assurée à temps partiel par le DSI ou le RSSI.

Le RGPD s'applique-t-il si le LLM traite des données de personnes morales (entreprises) uniquement ?

Non. Le RGPD s'applique aux données de personnes physiques uniquement. Si votre LLM traite exclusivement des données sur des entreprises (nom de société, SIREN, CA, etc.) sans aucune information permettant d'identifier une personne physique, le RGPD ne s'applique pas à ces traitements spécifiques. En pratique, cette situation est rare : les données d'entreprise contiennent presque toujours des données de contact (nom du dirigeant, e-mail professionnel) qui sont des données personnelles au sens du RGPD.

Nos obligations NIS2 couvrent-elles automatiquement nos obligations au titre de l'AI Act ?

Non. NIS2 et AI Act ont des objets différents : NIS2 vise la résilience et la sécurité des réseaux et systèmes d'information, l'AI Act vise la sécurité et la fiabilité des systèmes IA spécifiquement. Certaines exigences se recoupent (gestion des risques, audit logs, tests de sécurité), mais l'AI Act impose des obligations supplémentaires spécifiques à l'IA (documentation technique, contrôle humain, gestion des biais, gouvernance des données d'entraînement) que NIS2 ne couvre pas.

Conclusion

Le paysage réglementaire de l'IA en 2026 est sans précédent par sa complexité et sa densité. Mais cette complexité n'est pas une fatalité : avec une cartographie claire de vos obligations par usage, par secteur et par type de donnée, vous pouvez construire un programme de conformité cohérent qui répond à l'ensemble des textes applicables.

La bonne nouvelle est que la souveraineté IA simplifie considérablement cet exercice : en gardant vos données et vos modèles sous contrôle direct, vous éliminez la majorité des problèmes liés au Cloud Act et à la chaîne de responsabilité sous-traitant. Le Chapitre 3 de ce Livre Blanc détaille les options technologiques concrètes pour déployer une IA souveraine conforme à ce cadre réglementaire.