3 Un dossier clinique fourni à un modèle de diagnostic reste une information de santé protégée. Une feuille de calcul tarifaire fournie à un modèle de prévision reste un secret commercial. Un rapport de défense fourni à un index de récupération reste classifié. Le stockage d’IA pour les données sensibles est la discipline qui consiste à faire respecter ces classifications de l’ingestion à l’inférence — à travers chaque embedding, chaque checkpoint, chaque journal de prompts, chaque copie de sauvegarde. Les données ne deviennent pas moins sensibles parce qu’elles ont été utiles à un modèle. Ce guide s’adresse aux RSSI, aux architectes sécurité et aux responsables d’infrastructure qui gèrent des charges de travail d’IA portant sur des informations de santé protégées (PHI), des données personnelles identifiables (PII), de la propriété intellectuelle ou des informations classifiées. Il aborde les contrôles qui comptent, la posture de chiffrement et de gestion des clés qui tient, les règles de conservation qui résistent aux audits, et le rôle que joue Scality ADI (Autonomous Data Infrastructure) au niveau du stockage. Pourquoi l’IA change le problème des données sensibles Les données sensibles étaient déjà difficiles à gérer avant l’IA. Les régulateurs, les conseils d’administration, les assureurs et les équipes de sécurité attendaient des preuves de résidence, de contrôle d’accès, de conservation et de restauration. Les cadres de conformité — HIPAA, RGPD, CCPA, PIPL, CJIS, SEC 17a-4, DORA — ont été rédigés pour des systèmes dans lesquels un enregistrement avait un propriétaire clair, un périmètre d’accès défini et un cycle de vie prévisible. Les charges de travail d’IA remettent en cause cette hypothèse. Un modèle entraîné sur des enregistrements de sensibilité mixte hérite de la sensibilité la plus élevée de tous les enregistrements qu’il a vus. Un index de récupération construit sur plusieurs locataires hérite de l’union de leurs politiques d’accès. Un journal de prompts capture tout ce que l’utilisateur y a collé, y compris ce qu’il n’aurait pas dû. Le pipeline présente bien plus de surfaces qu’un système transactionnel, et chacune est une source potentielle de fuite. Telle est la réalité opérationnelle. La classification doit être portée par la couche de stockage, évaluée à chaque lecture, préservée à chaque transition du cycle de vie et protégée contre les acteurs les plus susceptibles de vouloir effacer les preuves. Les contrôles au niveau applicatif ne suffisent pas. Le socle doit tenir. Ce que recouvrent ici les données sensibles Quatre catégories couvrent la plupart des charges de travail d’IA des entreprises et des administrations. Les informations de santé protégées (PHI). Identifiants des patients, diagnostics, imagerie, génomique et dossiers de traitement, soumis à HIPAA aux États-Unis, au cadre de l’Espace européen des données de santé dans l’UE et à des règles équivalentes ailleurs. L’IA met à rude épreuve les contrôles sur les PHI en agrégeant des dossiers issus de différentes consultations, modalités et institutions. Les données personnelles identifiables (PII). Identifiants directs et indirects soumis au RGPD, au CCPA, à la PIPL et à un patchwork mondial en expansion. Des PII pseudonymisées peuvent être réidentifiées lorsqu’elles sont combinées à des embeddings, à un contexte de récupération ou à la mémorisation d’un modèle : les contrôles doivent donc accompagner les artefacts dérivés autant que les enregistrements bruts. La propriété intellectuelle et les secrets commerciaux. Code source, spécifications techniques, contrats, travaux de recherche et modèles tarifaires dont la valeur dépend d’une diffusion restreinte. Les contrôles sur la propriété intellectuelle sont généralement plus faibles que ceux sur les données personnelles — une lacune que les modèles d’assistance au code et à la recherche ont rendue douloureusement visible. Les informations classifiées et contrôlées. Classifications formelles de sécurité nationale, informations non classifiées contrôlées (CUI) et catégories sectorielles comme CJIS pour les forces de l’ordre. Les charges de travail classifiées imposent les exigences les plus strictes : personnel habilité, séparation physique de tout ce qui relève d’un niveau de classification inférieur et isolement démontrable de l’enclave. Une architecture défendable de stockage d’IA pour les données sensibles étiquette chaque objet — jeux de données, artefacts de modèles, embeddings, jeux d’évaluation, journaux d’inférence — avec sa classification au moment de l’écriture, et traite cette étiquette comme une donnée d’entrée de premier plan pour chaque décision d’accès. L’isolation du stockage multi-locataire (en anglais) en est le modèle fondateur ; les étiquettes de classification l’étendent des frontières entre locataires aux frontières de sensibilité des données. Les quatre contrôles qui résistent aux audits Lorsque les régulateurs, les conseils d’administration ou les assureurs demandent des preuves, ils demandent les quatre mêmes choses. La couche de stockage doit produire des éléments probants pour chacune. Un contrôle d’accès par classification, évalué au niveau du stockage Chaque identité — humaine, de service ou de modèle — porte une étiquette d’habilitation. Chaque objet porte une étiquette de classification. La couche de stockage les compare à chaque lecture, à chaque écriture et à chaque action d’administration. Un utilisateur habilité pour les PII mais pas pour les PHI ne peut pas lire un bucket de PHI, même s’il le demande. Un pipeline approuvé pour le traitement de propriété intellectuelle ne peut pas ingérer de données issues d’un corpus classifié, sauf si un flux de déclassification explicite et audité l’y autorise. Le principe est simple ; la difficulté réside dans son application cohérente à travers les politiques IAM S3, les conditions basées sur les attributs et les périmètres d’accès au niveau des buckets. L’architecture zero trust (en anglais) en est le modèle plus général. Un chiffrement avec une gestion des clés tenant compte de leur garde Le chiffrement au repos est un prérequis. Le chiffrement en transit aussi. Ce qui fait la différence pour les charges de travail d’IA réglementées, c’est la garde des clés. Les clés protégeant les PHI doivent résider dans une juridiction qui respecte l’obligation de résidence des données. Les clés protégeant des informations classifiées doivent être détenues par du personnel habilité, sur une infrastructure habilitée. Les clés protégeant la propriété intellectuelle doivent pouvoir être révoquées par l’entreprise sans passer par un ticket de support auprès d’un tiers. La gestion des clés de chiffrement (en anglais) couvre les pratiques fondamentales ; la spécificité de l’IA est que la rotation des clés doit s’étendre aux artefacts dérivés — checkpoints, embeddings, index vectoriels — et pas seulement aux corpus principaux. Une conservation appliquée par la couche de stockage, et non par l’application Les règles de conservation de HIPAA, du RGPD, de la SEC 17a-4, de DORA et des cadres relatifs aux informations classifiées sont précises : telle catégorie d’enregistrements doit être conservée pendant tant d’années, supprimée à tel déclencheur et produite en réponse à tel type de demande légale. Le niveau de stockage doit encoder ces règles là où elles ne peuvent pas être contournées en silence. Les politiques de conservation Object Lock, les transitions de cycle de vie encadrées et la préservation WORM (write once, read many) font passer l’application des règles de la logique applicative au socle. La promesse de conservation résiste à une application compromise, à un opérateur négligent ou à un initié malveillant — car la couche de stockage est le point d’application des politiques. Des preuves d’audit qui survivent à l’incident qu’elles documentent Les journaux d’audit sont le livrable. Chaque lecture, écriture, modification de politique, ajustement de conservation, modification de classification et action d’administration est journalisé de manière immuable, dans un locataire distinct, avec son propre horizon de conservation. Object Lock sur le bucket d’audit signifie que le journal ne peut être modifié par aucun acteur — pas même un administrateur privilégié sous la contrainte. Les procédures de restauration couvrent explicitement le corpus d’audit et vérifient la chaîne des journaux sur toute la fenêtre de restauration. La piste d’audit du stockage (en anglais) couvre le modèle fondateur ; pour les charges de travail d’IA, le lignage doit s’étendre à chaque artefact dérivé, afin que la preuve que « ce modèle a vu cette classification » survive au modèle lui-même. ContrôleCe qu’il fait respecterPreuves d’audit requisesAccès par classificationComparaison de l’habilitation de l’identité et de la classification de l’objet à chaque lectureJournaux d’accès par enregistrement, journaux des refus d’accès, approbations de déclassificationChiffrement avec garde des clésAu repos et en transit, avec des clés adaptées à la juridictionInventaire des clés, journaux de rotation, attestation de résidenceConservation au niveau du stockageWORM, Object Lock, préservation du cycle de vieDifférences entre politiques de conservation, preuves de suppression, historique immuable du cycle de vieAudit immuableJournalisation infalsifiable de chaque action privilégiéeIntégrité de la chaîne de journaux, corpus de journaux testé en restauration, preuves de séparation des tâches Ce schéma se retrouve dans HIPAA, le RGPD, le CCPA, la PIPL, la SEC 17a-4, DORA et les cadres relatifs aux informations classifiées. Les noms diffèrent ; le fond reste le même. Là où les charges de travail d’IA sollicitent davantage ces contrôles Quelques points précis où les charges de travail d’IA mettent ces contrôles à plus rude épreuve qu’un système traditionnel. Les corpus d’entraînement agrègent la sensibilité. Un jeu d’entraînement constitué à partir de nombreux enregistrements porte la sensibilité maximale de ses contributeurs, et non leur moyenne. Le corpus doit bénéficier des contrôles de son élément le plus sensible, et le lignage doit indiquer quels éléments y ont été intégrés. Les embeddings et les index vectoriels sont des artefacts sensibles dérivés. Un vecteur construit à partir de PHI est un artefact de PHI. Un index de récupération construit à partir de textes classifiés est un artefact classifié. Stockez-les dans des locataires dont les contrôles correspondent à la classification de la source. Les checkpoints et les poids des modèles mémorisent. Un modèle qui a ingéré des textes classifiés en conserve des fragments, que l’extraction par prompts, l’inférence d’appartenance ou la régurgitation des résultats peuvent faire ressortir. Le checkpoint hérite de la classification de la source et relève des mêmes politiques de conservation, d’accès et d’immuabilité que les données qui l’ont entraîné. Les journaux capturent ce que les utilisateurs collent. Les journaux de prompts, les traces d’évaluation et la télémétrie d’inférence contiennent régulièrement tout ce que l’utilisateur a envoyé. Traitez ces journaux comme des artefacts sensibles : classez-les, chiffrez-les, conservez-les selon un calendrier défini et protégez-les contre toute altération avec Object Lock. Les sauvegardes restent dans le périmètre. Une copie de sauvegarde d’un bucket de PHI reste une PHI. Les mêmes contrôles de classification, de conservation et d’audit doivent s’appliquer à chaque copie de sauvegarde et à chaque site secondaire. La place de Scality ADI dans le stockage d’IA pour les données sensibles La couche de stockage est l’endroit où l’architecture tient ou se délite. Les étiquettes, les politiques, les journaux d’audit, les règles de conservation et les preuves de restauration y résident tous, et l’intégrité de cette couche détermine si les autres contrôles ont encore quelque chose à défendre. Scality ADI 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 plusieurs pétaoctets à l’échelle de l’exaoctet. Pour les charges de travail d’IA réglementées, quatre propriétés de la plateforme comptent directement. Un contrôle souverain sur l’emplacement, la garde et l’inspection. Scality ADI existe pour les données que le cloud ne peut pas gérer selon les conditions de l’entreprise — exigences strictes de résidence, charges de travail d’IA pour lesquelles l’egress à l’échelle du pétaoctet rend le cloud public inexploitable, et environnements dans lesquels les conseils d’administration ou les régulateurs exigent un contrôle démontrable. Les PHI restent dans leur juridiction. Les informations classifiées restent dans l’enclave. La propriété intellectuelle reste sous la garde de l’entreprise. Résidence, inspectabilité et souveraineté opérationnelle sont des propriétés de l’architecture, et non des garanties du fournisseur. La souveraineté des données dans le cloud (en anglais) en est le cadre plus large. Un S3 multi-locataire avec un accès par classification régi par des politiques. Scality ADI offre un comportement S3 cloud natif avec des environnements de données multi-locataires. Buckets, préfixes, étiquettes d’objets, politiques IAM, conditions basées sur les attributs et conservation Object Lock sont des contrôles de premier plan. Les étiquettes de classification appliquées à l’écriture accompagnent l’objet et sont comparées à l’habilitation du demandeur à chaque lecture. La limitation des finalités, l’évaluation des habilitations et l’isolation des locataires sont appliquées au niveau du stockage plutôt que dans du code applicatif qui peut être réécrit ou contourné. La cyber-résilience CORE5 comme infrastructure d’audit. Dans Scality ADI, la cyber-résilience est architecturale. La protection, la capacité de restauration et l’auditabilité sont intégrées à la plateforme, et non ajoutées après coup. La cyber-résilience CORE5 (en anglais) couvre l’immuabilité, la durabilité grâce au codage à effacement, la protection des métadonnées, la protection multisite et le cycle de vie appliqué par des politiques. L’immuabilité Object Lock protège les étiquettes de classification, les journaux d’accès, les preuves de consentement et les preuves de suppression contre toute modification après écriture. La protection des métadonnées préserve les étiquettes de classification et de finalité dont dépendent les politiques. La durabilité multisite garantit la cohérence des preuves dans les zones géographiques où les régulateurs s’attendent à les trouver. Un cycle de vie multi-températures qui préserve la classification. Scality ADI couvre quatre niveaux selon un modèle opérationnel unique — flash GPU-Direct, QLC et NL-SSD chauds, NL-HDD et HDD tièdes, et archivage froid sur bande ou à proximité du cloud. Les enregistrements sensibles traversent ces niveaux à mesure que les schémas d’accès évoluent, mais les étiquettes de classification, la posture de chiffrement, les règles de conservation et le lignage d’audit les accompagnent. Un dossier de PHI sur bande est soumis à la même politique d’accès qu’un dossier de PHI sur flash. Un embedding classifié archivé pour le long terme conserve les contrôles qui l’encadraient à sa création. Scality ADI sert aussi de cible objet S3 immuable et à grande échelle pour les écosystèmes de sauvegarde — Veeam, Commvault, Rubrik, Atempo — qui protègent l’infrastructure d’IA environnante. Les copies de sauvegarde héritent des mêmes étiquettes de classification et des mêmes propriétés de chiffrement, de conservation et d’immuabilité que les données principales. La lacune fréquente des sauvegardes situées hors du périmètre de classification est comblée par conception. Découvrez comment Scality ADI assure un contrôle souverain pour les charges de travail d’IA sensibles (en anglais) Bonnes pratiques de mise en œuvre Étiquetez dès l’écriture. La classification, la juridiction, la finalité, le niveau d’habilitation et la conservation doivent être appliqués par le pipeline qui écrit les données, encadrés par des politiques et considérés comme immuables par la suite. Une classification rétroactive sous la pression d’un audit est la façon dont les erreurs deviennent des incidents. Faites de la couche de stockage le point d’application. Les vérifications au niveau applicatif sont pratiques et faciles à contourner. Appliquez les règles au niveau du stockage objet avec IAM, des conditions basées sur les attributs et Object Lock, afin que la même décision s’applique à chaque charge de travail, pipeline et identité. Étendez les contrôles aux artefacts dérivés. Les corpus d’entraînement, les checkpoints de modèles, les embeddings, les jeux d’évaluation, les journaux d’inférence et les traces de prompts héritent de la classification de leurs entrées. Stockez-les là où les contrôles correspondent. Traitez les journaux d’audit comme les données les plus sensibles que vous possédez. Locataire distinct, conservation la plus stricte, durabilité la plus élevée, tests de restauration les plus fréquents. Lorsqu’un régulateur demande des preuves, les preuves doivent être là. Restaurez l’état des politiques en même temps que les données. Les attaques par ransomware, les erreurs de configuration et les erreurs d’opérateurs peuvent effacer les politiques IAM, les étiquettes de classification, les règles de conservation et les journaux d’audit aussi facilement que les données. Les procédures de restauration doivent rétablir l’état complet des politiques et vérifier leur continuité sur toute la fenêtre de restauration. Questions fréquentes Qu’est-ce que le stockage d’IA pour les données sensibles ? Le stockage d’IA pour les données sensibles est l’ensemble des contrôles de stockage — étiquetage de classification, application des accès, chiffrement avec garde des clés, conservation et audit immuable — qui permettent de garder défendables les PHI, les PII, la propriété intellectuelle et les informations classifiées tout au long du cycle de vie de l’IA, de l’ingestion à l’entraînement, à la récupération, à l’inférence et à la conservation à long terme. Quelles réglementations comptent le plus ? HIPAA et le cadre de l’Espace européen des données de santé pour les PHI ; le RGPD, le CCPA et la PIPL pour les PII ; la SEC 17a-4 et DORA pour les services financiers ; CJIS pour les forces de l’ordre ; et les cadres nationaux applicables aux informations classifiées et contrôlées. Les contrôles techniques — accès par classification, chiffrement avec des clés tenant compte de leur garde, conservation appliquée, audit immuable — sont communs à tous. Pourquoi l’immuabilité est-elle importante pour l’IA appliquée aux données sensibles ? L’immuabilité protège les preuves d’audit qui démontrent que les contrôles ont fonctionné. Les journaux d’accès, les modifications de classification, les ajustements de conservation, les preuves de consentement et les preuves de suppression doivent tous survivre aux ransomwares, aux altérations internes et à la compromission de comptes privilégiés. Sans Object Lock ou une immuabilité équivalente, la première chose que fait un attaquant compétent est de modifier les journaux. Comment Scality ADI prend-il en charge le stockage d’IA pour les données sensibles ? Scality ADI offre un contrôle souverain sur l’emplacement des données sensibles, un S3 multi-locataire avec un accès par classification régi par des politiques, la cyber-résilience CORE5 pour des preuves d’audit et de suppression infalsifiables, ainsi qu’un cycle de vie multi-températures qui préserve les étiquettes de classification et les contrôles d’accès, du traitement actif à l’archivage à long terme. Pour aller plus loin L’isolation du stockage multi-locataire (en anglais) — la multi-location comme socle d’un stockage délimité par classification L’architecture zero trust (en anglais) — des modèles d’accès liés à l’identité qui s’étendent à la classification La souveraineté des données dans le cloud (en anglais) — garder les charges de travail d’IA sensibles sous la juridiction de l’entreprise La piste d’audit du stockage (en anglais) — des preuves d’audit défendables au niveau du stockage La solution de cyber-résilience CORE5 (en anglais) — l’architecture de cyber-résilience en cinq piliers de Scality Le stockage conforme HIPAA (en anglais) — les contrôles sur les PHI au niveau du stockage La gestion des clés de chiffrement (en anglais) — des pratiques de gestion des clés tenant compte de leur garde pour les charges de travail réglementées