2 Les responsables conformité et les dirigeants IT du secteur public se retrouvent de plus en plus en terrain inconnu : le développement de l’IA et du machine learning. Votre organisation construit des modèles de machine learning. Les équipes itèrent rapidement. Les data scientists réclament de l’agilité. Et vous êtes responsable de la gouvernance, des pistes d’audit et de la conformité réglementaire. Ces priorités semblent parfois en tension. La tension est réelle, mais elle peut être résolue. La clé est de comprendre comment le stockage des données MLOps recoupe les exigences de conformité. Lorsque votre organisation stocke des données d’entraînement, suit le développement des modèles et audite les décisions de l’IA, ces activités relèvent des mêmes cadres réglementaires que l’infrastructure IT traditionnelle : le RGPD pour les données personnelles, HIPAA pour les informations de santé, SOX pour les services financiers et, de plus en plus, des réglementations propres à l’IA comme l’AI Act européen. Cet article s’adresse aux responsables conformité qui doivent collaborer avec les équipes MLOps sans connaissances techniques approfondies en ML. Il explique ce que recouvre le stockage des données MLOps, pourquoi la conformité compte davantage que la plupart des data scientists ne le pensent au départ, et comment bâtir une gouvernance qui permet un développement rapide de l’IA tout en respectant les obligations réglementaires. Ce que les responsables conformité doivent savoir sur les données d’entraînement Les modèles de machine learning sont entraînés sur des données : dossiers clients, antécédents médicaux, transactions financières ou relevés de capteurs. Quelle que soit leur source, si ces données contiennent des informations personnelles ou sont soumises à des exigences réglementaires, les contrôles de conformité doivent s’appliquer. C’est là que beaucoup d’organisations trébuchent : elles traitent les données d’entraînement différemment des données opérationnelles. Une société financière peut appliquer des contrôles stricts aux données de transactions clients dans son système de production, mais des contrôles bien plus lâches aux mêmes données une fois copiées dans un environnement d’entraînement ML. C’est une faille de conformité. Du point de vue réglementaire, des données d’entraînement restent des données. Si le RGPD s’applique aux données clients de votre système opérationnel, il s’applique aussi à ces mêmes données dans votre environnement d’entraînement. Si la norme PCI-DSS s’applique aux données de cartes de paiement, elle s’applique aussi à ces données dans les jeux d’entraînement. Le cadre réglementaire ne change pas selon que les données se trouvent dans une base de données ou dans un jeu d’entraînement. L’entraînement ML pose toutefois des défis de conformité inédits pour l’IT traditionnelle : les données sont dupliquées entre plusieurs entraînements, les jeux de données sont versionnés et archivés, les modèles sont entraînés sur des données de plus en plus difficiles à retracer au fil du temps, et les décisions prises par des modèles entraînés sur des données biaisées peuvent avoir des conséquences réglementaires. Lignage des données et pistes d’audit pour l’entraînement ML Une exigence de conformité essentielle consiste à savoir d’où viennent les données et ce qu’il en est advenu. Pour les bases de données traditionnelles, c’est relativement simple : les journaux de transactions montrent quel utilisateur a modifié quel enregistrement et quand. Pour le ML, la chaîne est plus complexe. Un modèle est entraîné sur un jeu de données. Ce jeu peut être un sous-ensemble des données de production, combiné à des données historiques, avec certains enregistrements supprimés ou transformés. Il est versionné : la v1.0 utilisait peut-être des enregistrements de 2023, la v2.0 a ajouté ceux de 2024 et supprimé les valeurs aberrantes, la v3.0 a appliqué une transformation pour corriger des problèmes de qualité. Quelle version a servi à entraîner le modèle de production ? Une solution de stockage évolutif pour les pipelines d’IA (en anglais) dotée de fonctions de versionnage facilite le suivi de ce lignage. Du point de vue de la conformité, vous devez pouvoir répondre aux questions suivantes : quelles données ont servi à entraîner ce modèle ? D’où viennent-elles ? Le consentement a-t-il été correctement recueilli (au sens du RGPD) ? Cet usage était-il autorisé ? Les données ont-elles été modifiées depuis l’entraînement (par exemple à la suite d’une demande de suppression d’un client) ? Si oui, faut-il réentraîner le modèle ? Cela exige un suivi systématique du lignage des données. Votre infrastructure MLOps doit capturer automatiquement : Les métadonnées des jeux de données : chaque jeu de données doit indiquer sa date de création, sa version, son système source, son propriétaire et sa politique de rétention. Lorsqu’un data scientist crée un jeu d’entraînement, ces champs doivent être renseignés (via des modèles ou de l’automatisation, et non en texte libre). La provenance des données : le système doit savoir quels enregistrements de production ont été inclus dans le jeu d’entraînement. Si vous devez supprimer les données personnelles d’un client (à la suite d’une demande de suppression au titre du RGPD), vous devez pouvoir identifier les jeux d’entraînement qui les contenaient et déterminer si les modèles entraînés sur ces jeux doivent être réentraînés. Les enregistrements d’entraînement des modèles : chaque entraînement doit être journalisé : quel jeu de données, quand, à l’initiative de qui, avec quels paramètres et quelles performances pour le modèle obtenu. Ces enregistrements constituent votre piste d’audit. Les enregistrements de déploiement des modèles : lorsqu’un modèle passe en production, journalisez cette décision. Qui l’a approuvée ? Quels tests ont été réalisés ? Ce journal est essentiel si des enquêteurs demandent un jour pourquoi un modèle ayant pris des décisions biaisées a été déployé. Traiter les biais et l’équité dans un contexte de conformité La réglementation de l’IA s’intéresse de plus en plus aux biais algorithmiques. L’AI Act européen vise spécifiquement les systèmes d’IA à haut risque, notamment ceux utilisés pour les décisions d’emploi, l’évaluation du crédit et la justice pénale. Les régulateurs veulent la preuve que votre organisation a testé ses modèles pour détecter les biais avant de les déployer. Pour un responsable conformité, cela signifie : Les tests de biais doivent être documentés : votre équipe data science doit tester les modèles pour détecter les biais envers les catégories protégées (origine, genre, âge, etc.) avant leur mise en production. Ces tests doivent être journalisés, avec leurs résultats et les mesures correctives appliquées. Si un modèle présente un biais, documentez pourquoi il a été jugé acceptable ou ce que vous faites pour y remédier. La composition des données d’entraînement compte : si vos données d’entraînement sont biaisées (par exemple si seulement 5 % des demandeurs de prêt de votre jeu d’entraînement appartiennent à des minorités), le modèle obtenu sera probablement biaisé. La conformité doit comprendre la composition des données d’entraînement : sont-elles représentatives de la population que le modèle servira ? Les analyses d’impact sont obligatoires : pour les systèmes d’IA à haut risque, réalisez une analyse d’impact avant le déploiement. À l’image des analyses d’impact relatives à la protection des données (AIPD), elle documente les préjudices potentiels, les stratégies d’atténuation et la surveillance continue. Les enquêteurs demanderont à la consulter. La surveillance et les pistes d’audit : une fois un modèle déployé, une surveillance continue est nécessaire pour détecter tout changement de comportement ou toute décision biaisée. Cela suppose de journaliser les prédictions et les résultats, avec des pistes d’audit indiquant quels modèles prennent quelles décisions. Résidence et souveraineté des données en MLOps Les cadres de conformité exigent de plus en plus que les données restent dans des juridictions précises. Le RGPD restreint le transfert des données personnelles européennes hors de l’UE (sauf exceptions limitées), et le RGPD britannique impose des restrictions similaires. Les nouvelles réglementations au Canada, en Australie et dans d’autres pays ajoutent des exigences de résidence des données. Pour entraîner des modèles de ML, les données doivent souvent être déplacées là où se trouve le calcul. Si votre infrastructure d’entraînement est aux États-Unis mais que vous détenez des données européennes, il vous faut une méthode conforme pour transférer et traiter ces données. Plusieurs options existent : L’entraînement sur site : l’infrastructure d’entraînement est dans l’UE, et les données y restent. La conformité est garantie, mais l’investissement en infrastructure est important et l’échelle limitée. Les régions cloud approuvées : de nombreux fournisseurs cloud proposent des options de résidence des données. Vous pouvez entraîner vos modèles avec du calcul cloud dans des régions de l’UE et des données stockées dans l’UE. Vérifiez que les accords de traitement des données du fournisseur sont conformes au RGPD. La minimisation des données : n’utilisez que les données strictement nécessaires à l’entraînement. Si vous pouvez entraîner un modèle efficace sur des données anonymisées ou synthétiques plutôt que sur des données personnelles, le périmètre des exigences de résidence se réduit. Les garanties contractuelles : si vous faites appel à un sous-traitant pour l’entraînement (fournisseur cloud ou équipe ML externe), un accord de traitement des données (DPA) doit préciser le traitement, la conservation et la résidence des données. Ce DPA constitue votre documentation de conformité. Pour les organisations du secteur public, la souveraineté des données (le lieu physique de stockage et de traitement) est souvent aussi importante que la résidence. Vous devrez peut-être garantir que les données ne quittent jamais le pays, même chiffrées. Conservation et suppression des données d’entraînement Les données d’entraînement doivent tôt ou tard être supprimées. Les cadres réglementaires ne fixent généralement pas explicitement de durée de conservation pour ces données, mais le principe est clair : ne conservez les données que tant que vous en avez besoin. Pour les équipes ML, la notion de « besoin » est ambiguë. Les données ayant servi à entraîner un modèle de production peuvent être conservées indéfiniment, car le modèle ne pourrait plus être réentraîné si elles étaient supprimées. Une fois le modèle remplacé, ses données d’entraînement peuvent ne plus être nécessaires. Définissez des politiques de conservation explicites pour les données d’entraînement : La conservation selon l’usage : un jeu de données utilisé pour entraîner un modèle actif doit être conservé tant que le modèle est en production, plus une certaine durée (au cas où vous devriez reproduire le modèle). Une fois le modèle retiré, les données d’entraînement peuvent être supprimées selon votre calendrier de conservation. Définir des politiques de conservation des données (en anglais) claires garantit une application cohérente à tous les modèles. La conservation réglementaire : certaines données sont soumises à des durées de conservation légales. Les dossiers RH, médicaux et financiers peuvent devoir être conservés pendant des périodes définies. Même si le modèle est retiré, les données peuvent devoir être gardées pour des raisons réglementaires. Les processus de suppression : définissez une procédure de demande de suppression des données. Un propriétaire de données ou un responsable conformité doit pouvoir demander la suppression d’un jeu de données. Cette demande doit déclencher une journalisation d’audit et la vérification qu’aucun modèle actif n’en dépend, puis la suppression définitive (journalisée elle aussi). La suppression doit rester réversible pendant un certain temps (au cas où la demande serait erronée), avant de devenir définitive. Le droit à l’effacement (RGPD) : le RGPD donne aux personnes le droit de demander la suppression de leurs données personnelles. En cas de demande, vous devez supprimer leurs données des systèmes de production, mais aussi de tous les jeux d’entraînement qui les contiennent. Si un modèle a été entraîné sur ces données, il faudra peut-être le réentraîner pour éliminer réellement leur influence. Bâtir un cadre de gouvernance des données MLOps Bien faire exige une collaboration entre data science, MLOps, conformité et IT. Voici une approche pratique : Commencez par un inventaire des données : documentez les données utilisées pour le ML. Classez-les par sensibilité et par périmètre réglementaire. Identifiez les propriétaires de données (les personnes responsables de leur qualité et de leur conformité). Définissez des politiques de données : créez des modèles de création de jeux de données. Lorsqu’un data scientist crée un jeu d’entraînement, il renseigne le nom du jeu, le système source, la période couverte, la présence ou non de données personnelles, la durée de conservation et l’approbation (du propriétaire des données, et de la conformité si les données sont sensibles). Mettez en place une journalisation d’audit : votre plateforme MLOps doit journaliser automatiquement la création des jeux de données, l’entraînement et le déploiement des modèles. Ces journaux alimentent votre système d’audit et vos rapports de conformité. Établissez des contrôles d’accès : tout le monde ne doit pas accéder aux données d’entraînement sensibles. Utilisez un contrôle d’accès basé sur les rôles : les data scientists qui travaillent sur des modèles approuvés accèdent à leurs données, personne d’autre. Journalisez tous les accès. Créez une procédure de suppression des données : définissez comment les jeux de données sont supprimés. Exigez une approbation, vérifiez qu’aucun modèle n’en dépend, exécutez la suppression et journalisez-la. Consignez-la dans votre dossier de conformité. Menez des audits réguliers : chaque trimestre ou chaque année, auditez vos données MLOps. Des jeux de données sont-ils conservés plus longtemps que nécessaire ? Les demandes de suppression ont-elles été traitées ? Les journaux d’audit sont-ils complets ? Documentez vos constats et les mesures correctives. Le rôle de la conformité dans les décisions MLOps Les équipes MLOps voient souvent la conformité comme un obstacle, et les équipes conformité connaissent souvent mal les processus de ML. Mais lorsque les deux travaillent ensemble de manière systématique, la conformité accélère le développement au lieu de le freiner. La conformité apporte de la clarté sur les données utilisables (plutôt que des suppositions), des pistes d’audit qui protègent l’organisation en cas de problème et une détection précoce des problèmes de biais ou d’équité avant le déploiement. Autant de facteurs de réduction du risque. Le MLOps apporte des solutions techniques qui rendent la conformité efficace (journalisation automatisée, versionnage des données, suivi des déploiements) plutôt que manuelle et fastidieuse. Une bonne infrastructure MLOps facilite la gouvernance. La collaboration fonctionne mieux lorsque la conformité est associée tôt aux décisions d’architecture, lorsque les équipes MLOps comprennent que pistes d’audit et contrôles d’accès sont des leviers et non des freins, et lorsque les deux parties raisonnent en risques métier plutôt qu’en règles abstraites. La marche à suivre Si votre organisation développe des modèles de ML et que vous êtes responsable de la conformité, commencez par comprendre vos pratiques actuelles. Où sont stockées les données d’entraînement ? Qui y a accès ? Combien de temps sont-elles conservées ? Que se passe-t-il lorsqu’une personne demande la suppression de ses données ? Vous découvrirez peut-être des lacunes. Travaillez ensuite avec votre équipe MLOps pour bâtir une gouvernance systématique. Elle n’a pas besoin d’être complexe : capturer les métadonnées, journaliser les accès, définir des politiques de conservation et tenir des pistes d’audit. La plateforme peut automatiser l’essentiel. Le stockage hiérarchisé pour l’IA (en anglais) peut simplifier à la fois la gouvernance et la maîtrise des coûts. La réglementation de l’IA arrive, et elle portera précisément sur ces pratiques. Les organisations qui ont délibérément bâti une gouvernance des données MLOps trouveront la conformité réglementaire simple ; les autres devront se démener. Votre rôle de responsable conformité est de permettre à vos équipes ML de construire en toute confiance, en sachant que la gouvernance des données est intégrée dès le départ et non ajoutée après coup. C’est à la fois un avantage concurrentiel et un gage de résilience réglementaire. Pour aller plus loin Pipelines de données d’IA : architecture, étapes et bonnes pratiques (en anglais) Les exigences du RGPD en matière de stockage des données (en anglais) Bonnes pratiques de gestion des identités et des accès (IAM) (en anglais) Qu’est-ce que le NIST Cybersecurity Framework ? (en anglais) Stratégie de données en cloud hybride pour les charges de travail d’IA (en anglais) Le chiffrement des données : guide pour les responsables conformité et IT (en anglais)
