11 Les régulateurs posent aux équipes IA une question à laquelle la plupart des organisations ne savent pas répondre clairement : « Montrez-moi les preuves. » Les demandes d’audit des équipes de conformité internes, des évaluateurs externes et des régulateurs arrivent désormais plus vite que les équipes stockage et sécurité ne peuvent y répondre — non pas parce que les contrôles sont absents, mais parce que les preuves ne sont pas capturées, conservées ou protégées de manière cohérente. Bâtir des cadres d’audit de l’IA solides comble cet écart avant qu’un audit ne se transforme en constat. Ce guide s’adresse aux RSSI et aux architectes sécurité qui portent la préparation aux audits. Il présente ce que sont les cadres d’audit de l’IA, pourquoi le contexte réglementaire est aujourd’hui pressant, les composants qui les font fonctionner et la manière dont les choix d’infrastructure déterminent si les preuves d’audit résistent à l’examen. Que sont les cadres d’audit de l’IA ? Les cadres d’audit de l’IA sont des ensembles structurés de contrôles, d’exigences documentaires et de processus de revue qui permettent aux organisations de démontrer leur responsabilité vis-à-vis de leurs systèmes d’IA. Ils répondent aux questions suivantes : qui a autorisé un modèle, sur quelles données il a été entraîné, comment les décisions sont journalisées, si les résultats peuvent être contestés et comment le système se rétablit en cas de compromission. Le terme couvre tout un éventail. À une extrémité se trouvent de simples checklists de gouvernance interne. À l’autre, des programmes de conformité formels alignés sur les exigences réglementaires — l’AI Act européen, l’ISO/IEC 42001 (la norme de système de management de l’IA), SOC 2 Type II étendu aux charges d’IA et le cadre de gestion des risques IA du NIST (AI RMF). La plupart des équipes de sécurité d’entreprise finissent par construire une solution intermédiaire : un cadre qui se rattache à plusieurs normes externes tout en s’intégrant aux mécanismes d’audit existants de l’organisation. Un cadre d’audit de l’IA opérationnel couvre six préoccupations centrales : La gouvernance des modèles. Qui a approuvé la mise en production du modèle ? Existe-t-il une trace de cette décision, avec la version, la traçabilité des données d’entraînement et l’évaluation des risques ? La provenance des données. D’où viennent les données d’entraînement et d’inférence ? Leur intégrité est-elle vérifiable ? Sont-elles soumises à des exigences de conservation ou de suppression ? La journalisation des décisions. Les entrées et sorties du modèle sont-elles enregistrées de manière infalsifiable pour chaque décision importante ? Le contrôle d’accès. Qui peut lire les poids du modèle, les données d’entraînement et les journaux d’inférence ? Les accès sont-ils journalisés et revus périodiquement ? La détection des incidents et de la dérive. Comment l’organisation détecte-t-elle un changement significatif du comportement d’un modèle ? Existe-t-il une procédure de réponse documentée ? La capacité de reprise. Si un modèle ou ses données sont corrompus — par un ransomware, un acteur interne ou une compromission de la chaîne d’approvisionnement — l’organisation peut-elle revenir à un état sain connu et le prouver ? Pourquoi la préparation aux audits IA est urgente Trois évolutions réglementaires ont raccourci les délais pour les organisations qui prévoyaient de traiter la gouvernance de l’IA « plus tard ». L’AI Act européen. Les systèmes d’IA à haut risque — utilisés pour le recrutement, l’évaluation du crédit, le diagnostic médical, l’application de la loi et les infrastructures critiques — doivent conserver une documentation technique, tenir des journaux de fonctionnement et se soumettre à des évaluations de conformité. Les organisations exposées à l’UE qui déploient une IA à haut risque ont des obligations déjà en vigueur ou en cours d’entrée en vigueur, et non dans un futur cycle d’application. L’ISO/IEC 42001. Première norme internationale de système de management de l’IA, elle fournit un cadre certifiable très proche de l’ISO 27001. Pour les organisations déjà certifiées ISO 27001, l’extension à l’ISO/IEC 42001 est une suite logique — et les auditeurs des certifications existantes commencent à poser des questions couvertes par cette norme. Les réglementations de cyber-résilience. Le Cyber Resilience Act européen et le règlement sur la résilience opérationnelle numérique (DORA) traitent tous deux les systèmes dépendant de l’IA comme des produits numériques et des infrastructures de services financiers soumis à des exigences de sécurité et d’auditabilité. DORA, en particulier, impose aux entités financières de maintenir des systèmes TIC restaurables — et les pipelines d’inférence IA entrent pleinement dans ce périmètre. Ces réglementations partagent une exigence d’audit commune : l’organisation doit pouvoir produire des preuves, et pas seulement des affirmations. Des fichiers journaux pouvant être supprimés, modifiés ou écrasés a posteriori ne constituent pas des preuves. L’architecture de stockage compte. Composants d’un cadre d’audit de l’IA efficace Structure de gouvernance Tout cadre d’audit de l’IA a besoin d’un responsable désigné — généralement le RSSI ou un adjoint — disposant de l’autorité nécessaire pour suspendre un système en attendant sa remédiation. Une responsabilité sans autorité produit une documentation que les auditeurs écartent. La structure de gouvernance doit classer les systèmes d’IA par niveau de risque, définir une cadence de revue pour chaque niveau et préciser les voies d’escalade lorsqu’un système sort de ses paramètres approuvés. Traçabilité des données et des modèles La documentation de traçabilité doit répondre, pour tout modèle en production, aux questions suivantes : quelles données d’entraînement ont été utilisées, de quelle source, dans quelle version, et ont-elles été modifiées depuis le dernier audit. C’est plus difficile qu’il n’y paraît en pratique. Les équipes qui utilisent des modèles de fondation hébergés dans le cloud manquent souvent de visibilité complète sur la traçabilité. Le cadre doit définir des exigences minimales de traçabilité et signaler explicitement les lacunes plutôt que de les laisser non documentées. Pour les organisations qui opèrent à grande échelle, la traçabilité des données est directement liée aux capacités de piste d’audit du stockage — en particulier, au fait que le stockage objet journalise ou non qui a consulté ou modifié les données d’entraînement, et que ces journaux soient conservés et protégés. Journaux d’audit immuables Les journaux d’audit ne sont crédibles que dans la mesure de leurs garanties d’intégrité. Des journaux stockés sur des systèmes de fichiers modifiables, supprimables par des administrateurs privilégiés ou hébergés avec les systèmes qu’ils surveillent ne sont pas des preuves d’audit — ce sont un risque. Le stockage immuable avec sémantique object lock ou WORM (write once, read many) est l’exigence de base pour des journaux d’audit capables de résister à l’examen. Les exigences d’immuabilité vont au-delà des journaux. Les artefacts de modèles, les jeux de données d’entraînement et les instantanés de configuration utilisés dans les dossiers de preuves doivent tous être conservés sur un stockage qui empêche toute modification silencieuse. Contrôle d’accès et gestion des identités Les politiques de gestion des identités et des accès (IAM) déterminent qui peut lire, écrire ou supprimer les artefacts de modèles et les données d’audit. Le cadre doit exiger un accès au moindre privilège avec des politiques basées sur les rôles, une MFA obligatoire pour les opérations privilégiées et des revues d’accès régulières. Chaque opération privilégiée sur des données pertinentes pour l’audit doit générer une entrée de journal d’accès, elle-même immuable. Les principes de l’architecture zero trust — ne jamais faire confiance, toujours vérifier — s’appliquent directement ici. Traiter les magasins de données d’audit comme des ressources hautement sensibles exigeant une vérification continue, plutôt que comme des ressources librement accessibles aux utilisateurs internes une fois le périmètre franchi, est cohérent à la fois avec une bonne posture de sécurité et avec les orientations réglementaires émergentes. Réponse aux incidents et capacité de reprise Un cadre d’audit de l’IA est incomplet sans plan de reprise testé. Les auditeurs, au titre de DORA et du NIST Cybersecurity Framework, veulent voir non seulement que les contrôles existent, mais aussi que l’organisation peut rétablir ses opérations et démontrer l’intégrité des données restaurées. Les tests de reprise des charges d’IA doivent inclure la restauration des artefacts de modèles depuis une sauvegarde, la vérification des sommes de contrôle par rapport aux valeurs stockées et la confirmation que la continuité des journaux d’audit est maintenue tout au long de la reprise. Politique de conservation des données La politique de conservation des données régit la durée de conservation des preuves d’audit et le moment où elles peuvent être supprimées. Les calendriers de rétention des journaux d’audit IA vont généralement de trois à sept ans selon le contexte réglementaire. Le cadre doit automatiser l’application du cycle de vie afin que les journaux soient conservés pendant la période requise, ne puissent pas être supprimés manuellement pendant cette fenêtre et soient purgés de manière documentée et auditable à l’expiration de la rétention. Bonnes pratiques de mise en œuvre Classez vos systèmes d’IA par niveau de risque. Tous les modèles n’ont pas besoin du même dispositif d’audit. Un moteur de recommandation de contenus internes ne présente pas le même risque qu’un modèle utilisé pour approuver des demandes de prêt. Ce classement concentre l’effort d’audit là où il compte le plus et maintient des coûts de conformité proportionnés. Rattachez-vous aux cadres existants plutôt que de repartir de zéro. L’ISO 27001, SOC 2 et le NIST CSF fournissent déjà des structures d’audit que votre organisation a peut-être mis des années à construire. Les exigences d’audit de l’IA peuvent souvent y être intégrées sous forme d’extensions de contrôles plutôt que de programmes parallèles. Cela réduit la lassitude des examinateurs et centralise les preuves d’audit. Automatisez la collecte des preuves au niveau de l’infrastructure. La collecte manuelle est lente, sujette aux erreurs et coûteuse. Chaque entrée de journal d’audit, chaque enregistrement d’accès et chaque contrôle d’intégrité capturés automatiquement — avec horodatage cryptographique si possible — réduit le coût de production d’un dossier de preuves lorsqu’un audit survient. Testez la capacité de reprise avant un incident, pas pendant. Les bonnes pratiques de sécurité zero trust incluent des exercices de reprise réguliers pour les magasins de données sensibles. L’infrastructure IA doit figurer dans ce calendrier d’exercices. Une reprise jamais testée n’est pas un plan de reprise — c’est un espoir. Traitez le nommage et le versioning comme des exigences d’audit. Les conventions de nommage informelles pour les modèles et les jeux de données (« final », « final_v2 », « final_v2_vraiment ») sont un constat récurrent des audits IA. Imposez dès le départ un versioning sémantique pour les artefacts de modèles et les instantanés de jeux de données. Comment Scality ADI soutient la préparation aux audits IA Les choix d’infrastructure faits des années avant un audit déterminent si la collecte des preuves sera simple ou relèvera de l’enquête forensique. Scality ADI (Autonomous Data Infrastructure) est une infrastructure de données pour l’IA d’entreprise, la cyber-résilience et le contrôle souverain, qui aligne de manière autonome et durable les bons supports de stockage, de l’échelle multi-pétaoctet à l’exaoctet. Dans Scality ADI, la cyber-résilience est architecturale : la protection, la capacité de reprise et l’auditabilité sont intégrées à la plateforme plutôt qu’ajoutées après coup. Pour les équipes de sécurité qui construisent des cadres d’audit de l’IA, le modèle de cyber-résilience CORE5 de Scality ADI répond directement à cinq des exigences de preuves d’audit les plus courantes : Immuabilité. L’object lock avec sémantique WORM garantit que journaux d’audit, artefacts de modèles et instantanés de données d’entraînement ne peuvent être ni écrasés ni supprimés pendant la période de rétention — ni par un ransomware, ni par un administrateur, ni par quiconque. Erasure coding. La durabilité des données à l’échelle multisite garantit que les preuves restent récupérables même en cas de perte d’un site. Les auditeurs qui demandent une restauration à un instant donné peuvent l’obtenir. Protection des métadonnées. Scality ADI protège les métadonnées des objets en même temps que leur contenu, de sorte que les enregistrements d’accès et les journaux système conservent leur intégrité lors des événements de stockage. Durabilité multisite. Les charges d’IA réparties sur plusieurs zones géographiques ont besoin de preuves d’audit soumises aux mêmes contrôles géographiques que les données. La réplication multisite maintient la cohérence des preuves entre juridictions. Cycle de vie piloté par des politiques. Les politiques de rétention et de suppression sont appliquées au niveau du stockage, et non par une logique applicative contournable. C’est le mécanisme que recherchent les auditeurs lorsqu’ils vérifient que les calendriers de rétention sont réellement respectés. Scality ADI sert également de cible objet S3 immuable et à grande échelle pour les écosystèmes de sauvegarde — Veeam, Commvault, Rubrik (en anglais), Atempo — que les organisations utilisent pour protéger leur infrastructure IA. Les tâches de sauvegarde écrivent sur Scality ADI avec object lock activé ; les copies obtenues sont infalsifiables et auditables par conception. Découvrez comment la cyber-résilience CORE5 de Scality ADI résiste à l’audit → Questions fréquentes Que sont les cadres d’audit de l’IA ? Les cadres d’audit de l’IA sont des structures de gouvernance qui permettent aux organisations de démontrer leur responsabilité vis-à-vis de leurs systèmes d’IA — traçabilité des modèles, journalisation des décisions, contrôle d’accès, réponse aux incidents et capacité de reprise. Ils traduisent les contrôles internes en preuves qui satisfont les auditeurs externes et les régulateurs. Quelles réglementations exigent des capacités d’audit de l’IA ? L’AI Act européen impose une documentation technique et des journaux de fonctionnement pour les systèmes d’IA à haut risque. L’ISO/IEC 42001 fournit une norme certifiable de système de management de l’IA. SOC 2 Type II peut être étendu aux charges d’IA. DORA exige des systèmes TIC restaurables, ce qui inclut l’infrastructure d’inférence IA. L’AI RMF du NIST propose une approche de gestion des risques qui éclaire à la fois la gouvernance interne et les échanges sur la conformité réglementaire. Comment le stockage immuable soutient-il la préparation aux audits IA ? Le stockage immuable empêche la modification ou la suppression a posteriori des journaux d’audit, des artefacts de modèles et des données d’entraînement. C’est le fondement technique de preuves infalsifiables — sans lui, les journaux d’audit ne sont que des affirmations. La sémantique object lock au niveau du stockage applique automatiquement les calendriers de rétention et résiste aussi bien aux attaques externes qu’aux menaces internes. Quelle est la différence entre les cadres d’audit de l’IA et les cadres d’audit informatique traditionnels ? Les cadres d’audit informatique traditionnels (SOC 2, ISO 27001, NIST CSF) portent sur les systèmes, les contrôles d’accès et la continuité opérationnelle. Les cadres d’audit de l’IA étendent ces préoccupations aux risques propres aux modèles : provenance des données d’entraînement, responsabilité des décisions algorithmiques, dérive des modèles et intégrité des journaux d’inférence dans le temps. La plupart des organisations construisent leurs programmes d’audit IA comme des extensions de leurs structures d’audit informatique existantes plutôt que comme des programmes autonomes. À quelle fréquence faut-il auditer les systèmes d’IA ? Les systèmes d’IA à haut risque — ceux qui affectent les droits, la sécurité ou la situation financière des personnes — doivent être revus au minimum une fois par an, avec une surveillance automatisée continue entre deux revues. Les systèmes à plus faible risque peuvent suivre un cycle de deux ans. Le niveau réglementaire du système et le rythme de mise à jour des modèles sont les deux facteurs qui déterminent le plus souvent la fréquence des audits. Pour aller plus loin Piste d’audit du stockage — comment les systèmes de stockage d’entreprise génèrent et protègent les preuves d’audit Qu’est-ce que le stockage immuable : définition, avantages et fonctionnement — les fondamentaux de la sémantique WORM et de l’object lock Solution de cyber-résilience CORE5 — l’architecture de cyber-résilience en cinq piliers de Scality Les cinq niveaux d’une cyber-résilience inébranlable — un modèle de maturité progressif pour la résilience au niveau du stockage Cyber Resilience Act européen — ce qu’exige le CRA et qui est concerné Le règlement DORA expliqué — périmètre de DORA, exigences en matière de risques TIC et obligations de test Politique de conservation des données : définition, exemples et bonnes pratiques — structurer des calendriers de rétention qui satisfont les régulateurs
