Checklist conformité IA 2026 : les 60 points de contrôle RGPD, NIS2 et AI Act

1. Inventaire & Gouvernance — 10 points de contrôle

Référence : AI Act art. 49 (registre), AI Act art. 4 (compétences), ISO 42001

✓/✗	Point de contrôle	Exigence	Action recommandée
☐	G1 — Registre des systèmes IA	Inventaire exhaustif de tous les systèmes IA déployés ou en cours de déploiement dans l'organisation.	Créer et maintenir un registre IA incluant : nom du système, fournisseur, usage, classification de risque AI Act, données traitées, responsable.
☐	G2 — Classification des risques AI Act	Chaque système IA est classifié selon la taxonomie AI Act (risque inacceptable / haut risque / risque limité / risque minimal).	Réaliser une analyse de classification pour chaque système IA en consultant les Annexes I, II et III de l'AI Act.
☐	G3 — Comité IA constitué	Instance de gouvernance pluridisciplinaire chargée de valider les projets IA et de superviser la conformité.	Constituer un comité IA incluant DSI, DPO, RSSI, représentants métiers et direction, avec des réunions régulières (au minimum trimestrielles).
☐	G4 — Politique IA documentée	Document formel définissant les outils autorisés, les données pouvant être traitées par l'IA, les processus de validation.	Rédiger et approuver une politique IA comprenant classification des données, liste des outils homologués, processus de demande de nouveaux outils et sanctions.
☐	G5 — Charte IA communiquée	Tous les collaborateurs ont été informés de la politique d'usage de l'IA et ont confirmé leur prise de connaissance.	Diffuser la charte IA, organiser des sessions d'information et recueillir les accusés de réception (signature électronique ou quiz de validation).
☐	G6 — Processus de validation des nouveaux outils	Un processus formel permet d'évaluer et d'homologuer les nouveaux outils IA avant leur déploiement.	Définir un formulaire de demande d'homologation, des critères d'évaluation (sécurité, conformité, pertinence) et un délai de traitement maximal (ex : 10 jours ouvrés).
☐	G7 — Responsable IA désigné	Un responsable IA (ou Chief AI Officer) est identifié, avec des responsabilités claires sur la gouvernance des systèmes IA.	Désigner formellement un responsable IA (peut être le DSI ou un rôle dédié) et documenter ses responsabilités dans la gouvernance IA.
☐	G8 — Audit IA annuel planifié	Un audit formel des systèmes IA est planifié au minimum annuellement, couvrant la conformité, la performance et la sécurité.	Inscrire l'audit IA au plan d'audit interne ou prévoir un audit externe indépendant. Définir le périmètre et les critères d'évaluation à l'avance.
☐	G9 — Inventaire du Shadow AI	Une démarche proactive identifie les outils IA utilisés sans validation dans l'organisation.	Réaliser une enquête anonyme auprès des collaborateurs, analyser les logs réseau pour détecter les usages d'outils IA non autorisés, et mettre en place des blocages techniques si nécessaire.
☐	G10 — Procédure de gestion des incidents IA	Une procédure documentée existe pour détecter, qualifier, traiter et notifier les incidents liés aux systèmes IA.	Intégrer les incidents IA dans le processus de gestion des incidents cyber, avec des seuils de criticité spécifiques et des procédures de notification RGPD (72h CNIL) et NIS2 (24h ANSSI).

2. RGPD & Données personnelles — 12 points de contrôle

Référence : RGPD art. 5, 6, 13, 22, 25, 28, 32, 35, 37 — Recommandations CNIL sur l'IA (2023-2024)

✓/✗	Point de contrôle	Exigence	Action recommandée
☐	R1 — Base légale documentée	Chaque traitement de données personnelles par un système IA a une base légale identifiée et documentée (art. 6 RGPD).	Mettre à jour le registre des traitements pour inclure tous les traitements IA. Documenter la base légale retenue pour chacun (intérêt légitime, contrat, obligation légale, consentement).
☐	R2 — Registre des traitements IA mis à jour	Le registre des activités de traitement (art. 30 RGPD) inclut tous les traitements impliquant des systèmes IA.	Compléter le registre pour chaque système IA : finalité, catégories de données, destinataires, durées de conservation, mesures de sécurité, transferts hors UE.
☐	R3 — DPA signé avec chaque fournisseur IA	Un accord de traitement des données (art. 28 RGPD) est signé avec chaque fournisseur IA traitant des données personnelles pour votre compte.	Lister tous les fournisseurs IA, vérifier l'existence d'un DPA conforme (incluant les sous-traitants et les garanties de sécurité) et régulariser les relations sans DPA.
☐	R4 — AIPD réalisée pour les traitements à risque élevé	Une Analyse d'Impact relative à la Protection des Données est réalisée avant le déploiement des systèmes IA à risque élevé (art. 35 RGPD).	Vérifier pour chaque système IA si une AIPD est obligatoire (profilage à grande échelle, données sensibles, décisions automatisées). Si oui, réaliser l'AIPD avant le déploiement.
☐	R5 — Privacy by design implémenté	Les principes de protection des données dès la conception et par défaut (art. 25 RGPD) sont intégrés dans les projets IA.	Inclure le DPO dans les phases de conception des projets IA. Valider la minimisation des données, la pseudonymisation, et les accès restreints dès l'architecture.
☐	R6 — Droits des personnes garantis	Les droits d'accès, de rectification, d'effacement et d'opposition peuvent être exercés même pour les données traitées par les systèmes IA.	Documenter comment honorer chaque type de demande de droits pour chaque système IA. Vérifier la capacité technique à effacer les données d'un individu dans les bases RAG et les modèles.
☐	R7 — Information des personnes concernées	Les personnes dont les données sont traitées par des systèmes IA sont informées de manière transparente (art. 13-14 RGPD).	Mettre à jour les politiques de confidentialité et les mentions légales pour mentionner explicitement l'usage de systèmes IA dans le traitement des données.
☐	R8 — Décisions automatisées encadrées	Les décisions prises automatiquement par des systèmes IA ayant un effet juridique ou similaire sur des personnes respectent l'art. 22 RGPD.	Identifier tous les systèmes IA prenant des décisions automatisées. Vérifier la base légale, l'information des personnes et l'existence d'un droit à intervention humaine.
☐	R9 — Transferts hors UE analysés	Les transferts de données personnelles vers des pays tiers via les systèmes IA sont identifiés et encadrés (CCT, décision d'adéquation).	Cartographier les flux de données de chaque fournisseur IA vers des pays tiers. Réaliser un Transfer Impact Assessment (TIA) pour chaque transfert et s'assurer des mécanismes de protection adéquats.
☐	R10 — Durées de conservation définies	Des durées de conservation sont définies et appliquées pour toutes les données traitées par les systèmes IA (historiques de conversations, logs, données RAG).	Définir des politiques de rétention pour chaque catégorie de données IA. Implémenter des mécanismes de suppression automatique à l'échéance.
☐	R11 — Données spéciales protégées	Les données de catégories spéciales (santé, opinion politique, biométrie, etc.) ne transitent pas par des systèmes IA non autorisés et non sécurisés.	Identifier tous les flux potentiels de données sensibles vers des systèmes IA. Mettre en place des contrôles techniques (filtrages, alertes) et organisationnels (formation, contrôle d'accès) pour prévenir les fuites accidentelles.
☐	R12 — DPO impliqué dans les projets IA	Le DPO est systématiquement consulté lors de la conception et du déploiement des systèmes IA traitant des données personnelles.	Intégrer le DPO dans la liste des parties prenantes obligatoires pour tout projet IA dès la phase de POC. Documenter ses avis et les actions prises en conséquence.

3. AI Act & Classification des risques — 10 points de contrôle

Référence : Règlement (UE) 2024/1689 — AI Act, art. 4, 9, 13, 14, 26, 49 — Applicable progressivement jusqu'en août 2027

✓/✗	Point de contrôle	Exigence	Action recommandée
☐	A1 — Classification AI Act complétée	Chaque système IA est classifié selon la taxonomie AI Act et la classification est documentée.	Réaliser la classification en consultant les Annexes I, II, III de l'AI Act. Intégrer la classification dans le registre IA. Revoir la classification à chaque évolution significative du système.
☐	A2 — Documentation technique des systèmes à haut risque	Les systèmes IA à haut risque disposent d'une documentation technique complète (art. 11 AI Act).	Pour chaque système à haut risque : rédiger la documentation technique conforme à l'Annexe IV de l'AI Act (description du système, données d'entraînement, métriques de performance, limitations).
☐	A3 — Supervision humaine garantie	Les systèmes IA à haut risque permettent une supervision humaine effective et les décisions critiques peuvent être invalidées par un opérateur humain (art. 14 AI Act).	Définir les processus de supervision humaine pour chaque système à haut risque. S'assurer que les interfaces permettent à l'opérateur d'intervenir, de corriger ou d'arrêter le système facilement.
☐	A4 — Journalisation automatique	Les systèmes IA à haut risque conservent automatiquement des journaux d'événements pour traçabilité (art. 12 AI Act).	Implémenter des logs d'audit automatiques pour les systèmes à haut risque : qui a utilisé le système, quand, avec quels inputs, quels outputs, et quelles décisions ont été prises ou recommandées.
☐	A5 — Transparence envers les utilisateurs	Les personnes interagissant avec des systèmes IA sont informées qu'elles interagissent avec une IA (art. 50 AI Act pour les systèmes d'interaction directe).	Ajouter des mentions claires « Powered by AI » ou équivalent dans les interfaces de chatbots, assistants et tout système IA interagissant directement avec des personnes physiques.
☐	A6 — Évaluation des biais réalisée	Une analyse des biais potentiels a été réalisée pour les systèmes à haut risque, notamment ceux impliquant des décisions sur des personnes.	Utiliser des outils d'audit de biais (Fairlearn, AI Fairness 360) pour analyser les outputs des systèmes IA sur des groupes protégés. Documenter les résultats et les mesures correctives.
☐	A7 — Compétences IA des collaborateurs	L'organisation s'assure que les personnes responsables de systèmes IA disposent des compétences nécessaires (art. 4 AI Act).	Réaliser une cartographie des compétences IA dans l'organisation. Identifier les gaps et mettre en place un programme de formation ciblé, documenté et mesuré.
☐	A8 — Évaluation de conformité réalisée (haut risque)	Les systèmes à haut risque ont fait l'objet d'une évaluation de conformité avant leur mise sur le marché ou en service (art. 43 AI Act).	Pour les systèmes à haut risque, réaliser l'évaluation de conformité selon les procédures définies à l'art. 43. Certains systèmes nécessitent l'intervention d'un organisme notifié tiers.
☐	A9 — Watermarking des contenus IA	Les contenus générés par des IA (textes, images, vidéos) produits par votre organisation sont marqués comme tels (art. 50 AI Act).	Mettre en place des processus de marquage des contenus IA : mention explicite « Généré par IA » dans les métadonnées et/ou dans le contenu visible selon le contexte d'usage.
☐	A10 — Veille réglementaire AI Act active	Un processus de veille est en place pour suivre les évolutions de l'AI Act et les actes délégués qui précisent son application.	Désigner un responsable de la veille réglementaire IA. S'abonner aux publications de la Commission européenne, de l'ENISA et de l'ANSSI sur l'IA. Prévoir une revue trimestrielle des évolutions réglementaires.

4. NIS2 & Résilience — 8 points de contrôle

Référence : Directive (UE) 2022/2555 (NIS2) — Loi SREN 2024 (transposition française) — S'applique aux entités essentielles et importantes

✓/✗	Point de contrôle	Exigence	Action recommandée
☐	N1 — Gestion des risques IA intégrée	Les systèmes IA sont intégrés dans la gestion des risques de cybersécurité de l'organisation (art. 21 NIS2).	Ajouter les risques spécifiques aux systèmes IA (prompt injection, hallucination, dépendance fournisseur, fuite de données) dans votre cartographie des risques cyber.
☐	N2 — Risques fournisseurs IA évalués	Les risques liés aux fournisseurs et sous-traitants IA sont évalués dans le cadre de la gestion des risques de la chaîne d'approvisionnement (art. 21 NIS2).	Réaliser une due diligence de sécurité sur chaque fournisseur IA critique. Exiger des certifications (ISO 27001, SOC 2) et inclure des clauses de sécurité dans les contrats.
☐	N3 — Plan de continuité incluant l'IA	Le Plan de Continuité d'Activité (PCA) et le Plan de Reprise d'Activité (PRA) intègrent les scénarios de défaillance des systèmes IA critiques.	Mettre à jour le PCA/PRA pour inclure les scénarios : indisponibilité du LLM, compromission du fournisseur IA, défaillance de l'infrastructure GPU. Tester ces scénarios annuellement.
☐	N4 — Procédure de notification d'incident NIS2	Une procédure permet de notifier l'ANSSI sous 24h en cas d'incident significatif affectant les systèmes IA dans le scope NIS2 (art. 23 NIS2).	Documenter la procédure de notification NIS2 : critères de déclenchement, responsable de la notification, contacts ANSSI, délais (notification initiale 24h, rapport complet 72h).
☐	N5 — Tests de résilience réalisés	Des tests de résilience des systèmes IA critiques sont réalisés régulièrement (tests de pénétration, exercices de crise).	Planifier des tests de pénétration annuels incluant les systèmes IA. Réaliser des exercices de crise simulant la compromission ou l'indisponibilité d'un LLM critique.
☐	N6 — Gouvernance NIS2 au niveau Direction	La Direction générale est impliquée et responsable de la conformité NIS2, y compris pour les risques liés aux systèmes IA (art. 20 NIS2).	Organiser une séance de formation des dirigeants sur les obligations NIS2 et les risques IA. Inclure les indicateurs de conformité NIS2 dans les reportings de Direction.
☐	N7 — Enregistrement auprès de l'ANSSI	L'organisation s'est enregistrée auprès de l'ANSSI dans les délais prévus par la loi SREN si elle est dans le scope NIS2.	Vérifier votre obligation d'enregistrement sur le portail ANSSI. Compléter l'enregistrement avec les informations requises (coordonnées, secteur, taille, systèmes critiques).
☐	N8 — Chiffrement et contrôle d'accès aux systèmes IA critiques	Les mesures de chiffrement et de contrôle d'accès appropriées sont appliquées aux systèmes IA critiques (art. 21 NIS2).	Auditer le chiffrement en transit et au repos des systèmes IA. Mettre en place une authentification forte (MFA) pour l'accès aux LLM critiques et aux bases de données RAG sensibles.

5. Sécurité & RSSI — 10 points de contrôle

Référence : OWASP LLM Top 10 (2025), ISO 27001, recommandations ANSSI sur la sécurité des IA

✓/✗	Point de contrôle	Exigence	Action recommandée
☐	S1 — Authentification forte sur les LLM	L'accès aux systèmes IA internes requiert une authentification forte (MFA, SSO d'entreprise).	Intégrer les LLM au SSO d'entreprise. Activer le MFA pour tous les accès. Mettre en place des politiques de session (timeout, invalidation).
☐	S2 — Contrôle d'accès basé sur les rôles (RBAC)	Les droits d'accès aux bases documentaires RAG sont granulaires et reflètent les permissions de l'utilisateur dans l'organisation.	Implémenter un RBAC sur les bases vectorielles RAG : un collaborateur ne voit via l'IA que les documents auxquels il aurait accès directement. Tester régulièrement l'isolation des permissions.
☐	S3 — Protection contre la prompt injection	Des mesures techniques sont en place pour détecter et bloquer les tentatives de prompt injection (OWASP LLM01).	Implémenter une API Gateway avec validation des inputs. Isoler les instructions système des inputs utilisateurs. Monitorer les patterns d'interaction anormaux. Tester régulièrement la résistance aux injections.
☐	S4 — Journalisation complète des interactions	Toutes les interactions avec les systèmes IA sont journalisées pour permettre l'audit et la détection d'incidents.	Mettre en place des logs centralisés (SIEM) pour toutes les interactions IA : identifiant utilisateur, timestamp, requête (hash ou contenu selon sensibilité), réponse, durée. Conserver les logs selon la politique de rétention.
☐	S5 — Chiffrement des données IA	Les données en transit vers et depuis les LLM (TLS 1.3 minimum) et au repos (bases vectorielles, historiques) sont chiffrées.	Auditer la configuration TLS des API LLM. Chiffrer les bases vectorielles RAG avec AES-256. Gérer les clés de chiffrement en dehors des systèmes IA (HSM ou KMS souverain).
☐	S6 — Segmentation réseau des LLM	Les serveurs LLM sont isolés dans des segments réseau dédiés avec des règles de pare-feu strictes.	Mettre les serveurs LLM dans un VLAN dédié. Restreindre les flux entrants (uniquement depuis l'API Gateway) et sortants (uniquement vers les ressources nécessaires). Interdire les accès directs depuis les postes utilisateurs.
☐	S7 — Gestion sécurisée des clés API	Les clés API utilisées pour accéder aux LLM externes (si applicable) sont gérées de manière sécurisée et ne sont pas exposées dans le code ou les configurations.	Stocker les clés API dans un gestionnaire de secrets (Vault, AWS Secrets Manager, Azure Key Vault). Mettre en place une rotation régulière. Monitorer les usages anormaux de clés API.
☐	S8 — Red teaming réalisé	Des tests offensifs (red teaming) ont été réalisés sur les systèmes LLM en production pour identifier les vulnérabilités.	Planifier un red teaming IA annuel (jailbreak, prompt injection, extraction de données, test de résilience). Utiliser des frameworks comme Garak ou PyRIT. Documenter les vulnérabilités trouvées et les mesures correctives.
☐	S9 — Monitoring des outputs anormaux	Un système de monitoring détecte les comportements anormaux des LLM en production (outputs inhabituels, exfiltration de données).	Implémenter un système d'alertes sur les patterns d'outputs anormaux : réponses très longues contenant des données structurées, requêtes répétées sur des données sensibles, outputs en langues inattendues.
☐	S10 — Plan de sauvegarde et récupération	Des sauvegardes régulières des modèles, configurations, bases RAG et données d'entraînement permettent une récupération rapide après incident.	Mettre en place des sauvegardes quotidiennes des bases RAG et des configurations LLM. Tester la procédure de récupération semestriellement. Définir un RTO (Recovery Time Objective) et un RPO (Recovery Point Objective) pour chaque système IA critique.

6. Contrats fournisseurs — 6 points de contrôle

Référence : RGPD art. 28, NIS2 art. 21, AI Act art. 25-26

✓/✗	Point de contrôle	Exigence	Action recommandée
☐	C1 — DPA RGPD avec tous les fournisseurs IA	Un accord de traitement des données conforme RGPD est en vigueur avec chaque fournisseur IA traitant des données personnelles.	Lister tous les fournisseurs IA actifs. Vérifier l'existence et la validité des DPA. Régulariser les situations sans DPA ou avec des DPA non conformes.
☐	C2 — Droit d'audit contractualisé	Les contrats fournisseurs IA incluent un droit d'audit permettant à votre organisation (ou un tiers mandaté) d'auditer la conformité du fournisseur.	Lors du renouvellement ou de la renégociation des contrats, exiger l'inclusion d'une clause de droit d'audit. À défaut, exiger la fourniture de rapports d'audit tiers (SOC 2 Type II, ISO 27001).
☐	C3 — Clauses de réversibilité et portabilité	Les contrats définissent les modalités de récupération des données et de migration en cas de changement de fournisseur (réversibilité).	Vérifier que chaque contrat IA inclut : format d'export des données, délai de mise à disposition, assistance à la migration, suppression certifiée des données après résiliation.
☐	C4 — Localisation des données contractualisée	La localisation des données (pays, datacenters) est explicitement précisée dans les contrats et correspond à vos exigences de souveraineté.	Exiger une clause contractuelle spécifiant que toutes les données seront traitées et stockées exclusivement en France/UE (préciser les pays autorisés). Toute modification doit nécessiter votre accord préalable écrit.
☐	C5 — SLA de sécurité contractualisé	Des SLA de sécurité sont définis contractuellement : délais de notification d'incident, disponibilité, RPO/RTO.	Exiger un SLA incluant : délai de notification en cas d'incident de sécurité (24h maximum), disponibilité garantie (99,5% minimum pour les systèmes critiques), pénalités contractuelles en cas de non-respect.
☐	C6 — Liste des sous-traitants connue et approuvée	La liste complète des sous-traitants de chaque fournisseur IA est connue, documentée et approuvée par votre organisation.	Exiger de chaque fournisseur IA la liste exhaustive de ses sous-traitants (hébergement, modèles tiers, services annexes) et leur localisation. Exiger une notification préalable avant tout changement de sous-traitant.

7. Formation & Culture — 4 points de contrôle

Référence : AI Act art. 4 (compétences IA), recommandations CNIL sur la gouvernance IA

✓/✗	Point de contrôle	Exigence	Action recommandée
☐	F1 — Formation obligatoire IA pour tous	Tous les collaborateurs ont suivi une formation de sensibilisation aux risques et bonnes pratiques de l'IA (obligation art. 4 AI Act).	Déployer un parcours de formation IA obligatoire (e-learning de 1 à 2 heures minimum) couvrant : les outils autorisés, les données qu'on peut y saisir, les risques du Shadow AI, les incidents à signaler.
☐	F2 — Formation avancée pour les équipes IA	Les équipes en charge des systèmes IA (développeurs, data scientists, chefs de projet) disposent des compétences techniques et réglementaires nécessaires.	Prévoir des formations spécifiques pour les équipes IA : sécurité LLM (OWASP LLM Top 10), conformité AI Act/RGPD, MLOps, évaluation et monitoring des modèles.
☐	F3 — Canal de signalement des incidents IA	Un canal dédié permet aux collaborateurs de signaler les comportements anormaux, les incidents ou les utilisations inappropriées des systèmes IA.	Créer un canal de signalement IA simple et accessible (email dédié, formulaire interne, intégration dans le système de tickets). Communiquer ce canal dans la charte IA et les formations.
☐	F4 — Taux de couverture formation mesuré	Le taux de couverture de la formation IA est mesuré régulièrement et un plan de rattrapage est prévu pour les collaborateurs non formés.	Mettre en place un tableau de bord de suivi de la formation IA : taux de complétion par département, date de dernière formation, résultats des quiz. Objectif cible : 95% de couverture en 6 mois.

Score de maturité et interprétation

Comptabilisez vos résultats : chaque ✓ = 1 point, chaque ~ = 0,5 point, chaque ✗ = 0 point.

Score	Niveau	Interprétation	Priorité
0 — 20 points	Niveau initial	Exposition élevée aux risques réglementaires et sécuritaires. Actions urgentes requises.	Lancer immédiatement un programme de mise en conformité avec l'aide d'un expert externe.
21 — 40 points	Niveau basique	Socle de conformité partiel. Des lacunes significatives subsistent dans plusieurs domaines.	Identifier les domaines les plus déficients et les traiter en priorité (généralement : DPA fournisseurs, AIPD, formation).
41 — 50 points	Niveau intermédiaire	Bonne base de conformité. Des améliorations ciblées permettront d'atteindre un niveau avancé.	Travailler sur les points manquants, renforcer la documentation et automatiser les contrôles.
51 — 60 points	Niveau avancé	Conformité solide et mature. Maintenir le niveau par des révisions régulières et une veille active.	Maintenir et améliorer en continu. Envisager une certification formelle (ISO 27001, ISO 42001).