Comment prouver vos données d'entraînement sans les divulguer

Oui, vous pouvez prouver qu'un jeu de données privé a existé sans publier ce jeu de données.

Le schéma est simple : vous construisez un manifeste de jeu de données, vous hachez ses entrées, vous repliez ces empreintes dans une seule racine de Merkle, puis vous publiez un record de preuve d'existence Label 309 sur Cardano. Le jeu de données lui-même ne quitte jamais votre contrôle. Plus tard, vous pouvez révéler exactement un fichier, une ligne, une entrée de manifeste ou une preuve d'inclusion pour montrer qu'il faisait partie de l'instantané engagé — et rien de plus.

Cela prouve la possession antérieure à un instant donné. Cela ne prouve pas, à lui seul, la propriété, le statut au regard du droit d'auteur, le consentement ni l'usage licite. Ce sont des questions distinctes qui appellent des records distincts.

Pourquoi une équipe IA aurait-elle besoin de cela ?

Les données d'entraînement sont devenues une question de niveau conseil d'administration. Un fournisseur de modèle peut avoir à montrer quelles données il détenait, à quel moment, d'où elles provenaient, comment elles ont été traitées et quels jeux de données ont alimenté une version donnée d'un modèle — pour ses investisseurs, ses partenaires, ses clients, les régulateurs, les auditeurs, les concédants de licence ou un contentieux.

Dans le même temps, l'entreprise ne peut souvent pas publier le jeu de données. Il peut contenir du contenu sous licence, des données clients, des données personnelles, des sources propriétaires, des annotations internes, des secrets d'affaires, des évaluations de sécurité, des corpus de récupération, des données synthétiques ou des règles de filtrage sensibles.

La preuve d'existence résout cette tension. Elle vous permet de vous engager sur l'état et la chronologie du jeu de données sans le divulguer publiquement. Vous publiez une empreinte ; les octets restent chez vous.

Sur quoi devez-vous vous engager : les données brutes ou un manifeste ?

Engagez-vous sur un manifeste, pas sur les octets bruts seuls.

Un manifeste de jeu de données décrit l'instantané de manière structurée et lisible par machine. Il peut consigner :

le nom du jeu de données et l'identifiant de l'instantané ;
la fenêtre de collecte ;
les catégories de sources et les métadonnées de droits ;
les empreintes par fichier et par ligne ;
les versions de déduplication et de filtrage ;
les versions des pipelines d'annotation et de prétraitement ;
le modèle ou l'exécution d'entraînement qui l'a utilisé ;
la politique de rétention et la propriété interne.

Le manifeste n'a pas à exposer publiquement le moindre détail sensible. Il peut rester entièrement à l'intérieur de l'entreprise. La preuve publique ne s'engage que sur son empreinte, ou sur une racine de Merkle couvrant de nombreuses entrées de manifeste. L'objectif est précis et durable : figer la preuve de l'état du jeu de données à un moment connu.

Pourquoi utiliser une racine de Merkle plutôt qu'un record par fichier ?

Les jeux de données sont volumineux, et publier un record par fichier ou par ligne ne passe pas à l'échelle. Une racine de Merkle résout ce problème : elle s'engage sur une liste ordonnée de nombreuses empreintes sous une seule valeur de 32 octets, ancrée dans une unique transaction.

Plus tard, pour prouver qu'un élément donné y figurait, vous ne révélez que :

l'élément ou son empreinte ;
l'entrée de manifeste correspondante ;
une preuve d'inclusion Merkle ;
la référence de transaction Label 309.

Un vérificateur recalcule le chemin depuis cette feuille jusqu'à la racine et confirme que la racine a été publiée à un instant de bloc Cardano précis. La preuve ne croît qu'avec le logarithme de la taille du lot, si bien qu'elle reste compacte même pour des millions de feuilles. Surtout, construire l'arbre et vérifier les preuves relève d'un calcul purement hors ligne — aucun serveur, aucun compte, aucune coopération de votre part n'est requise au moment de la vérification.

C'est ce qui rend possible la divulgation sélective. Vous n'avez jamais à révéler l'ensemble du jeu de données pour prouver qu'un élément appartenait à l'instantané engagé.

Que voit réellement le public ?

Uniquement le record de preuve sur la chaîne. Selon la manière dont vous publiez, il peut inclure une empreinte de manifeste, une racine de Merkle, un nombre de feuilles, l'instant de la transaction, une signature optionnelle de votre entreprise ou de votre système, et des URI optionnelles adressées par le contenu (ar://, ipfs://) pour des éléments justificatifs publics ou chiffrés.

Le public ne voit ni les fichiers du jeu de données, ni la liste complète des feuilles, ni les métadonnées de source, ni les données clients, ni les détails de licence, ni les annotations, ni les notes internes. Ceux-ci restent à l'intérieur de votre système de preuve jusqu'à ce qu'une question précise impose la divulgation.

Que révéleriez-vous plus tard, et quand ?

Ne révélez que ce que la question exige.

Un fichier figurait-il dans le jeu de données ? Révélez le fichier ou son empreinte, l'entrée de manifeste et une preuve d'inclusion.
Une catégorie de sources était-elle incluse ? Révélez la section de manifeste correspondante et la preuve qu'elle appartient à l'instantané engagé.
Une version de modèle a-t-elle utilisé un instantané particulier ? Révélez le manifeste d'exécution d'entraînement qui relie la version du modèle à la racine du jeu de données.
S'agit-il d'un audit complet ? Révélez l'intégralité du manifeste et de la liste de feuilles dans le cadre de la procédure de confidentialité appropriée.

La racine sur la chaîne prouve la chronologie. Votre archive interne détermine la quantité de détails que vous pouvez montrer, et à qui. Lorsque les éléments justificatifs eux-mêmes doivent passer à un tiers tout en restant privés, vous pouvez les partager de manière confidentielle plutôt que de les rendre publics.

Quel rapport avec la réglementation de l'IA ?

La réglementation de l'IA évolue vers des obligations renforcées de documentation et de transparence. Le règlement européen sur l'IA, par exemple, énonce des règles de transparence et de droit d'auteur pour les modèles d'IA à usage général, et la Commission européenne a publié un modèle de résumé public des contenus d'entraînement — décrit, selon les termes mêmes de la Commission, comme un socle minimal des informations à mettre à la disposition du public.

Une preuve de jeu de données privé n'a rien à voir avec ce résumé public. Elle ne remplace ni le reporting réglementaire, ni l'examen juridique, ni la gestion du consentement, ni les registres de licences, et la question de savoir si tout cela est utile dans un cas donné dépend de votre juridiction et de votre conseil juridique.

Ce qu'elle peut étayer, c'est la couche de preuve qui sous-tend ces processus. Si une entreprise doit plus tard montrer ce qu'elle détenait, ce qu'elle savait, ou sur quel instantané reposait un résumé publié, un engagement de manifeste horodaté constitue une preuve concrète, ancrée par un tiers, de la chronologie et de l'intégrité.

Que prouve réellement une preuve de jeu de données ?

Elle prouve qu'un engagement précis sur un jeu de données existait à un instant de bloc public. Selon les éléments que vous conservez, cela peut aider à montrer :

qu'un fichier figurait dans un instantané de jeu de données ;
qu'un manifeste existait avant un litige ;
qu'une version de jeu de données existait avant la sortie d'un modèle ;
qu'une exécution d'entraînement référençait un instantané particulier ;
qu'une catégorie de sources était documentée à l'époque ;
qu'un pipeline de prétraitement ou de filtrage avait été consigné.

Si le record est signé — Label 309 prend en charge les signatures optionnelles au niveau du record — il peut aussi montrer qu'une clé d'entreprise ou de système s'est portée garante de l'engagement. La signature n'est jamais requise : un engagement non signé est tout aussi valable ; la signature ne fait qu'ajouter une paternité attribuable.

Que ne prouve-t-elle pas ?

C'est la partie sur laquelle il faut être honnête, car les angles morts comptent.

Une preuve de jeu de données ne prouve pas que l'usage des données était licite. Elle ne prouve pas que vous étiez propriétaire des données, qu'elles ont été collectées avec consentement, ni quel est leur statut au regard du droit d'auteur. Elle ne prouve pas non plus que les données ont effectivement servi à l'entraînement — à moins que votre pipeline d'entraînement et les records de votre modèle ne soient eux-mêmes liés à l'instantané du jeu de données. Et elle ne prouve pas que le manifeste est complet ; seuls vos processus et vos contrôles peuvent rendre cette exhaustivité crédible.

La preuve d'existence est une preuve de chronologie et d'intégrité. Elle établit que des octets exacts existaient à un instant public. Elle ne dit rien de la véracité, de la propriété, des droits ou de la conformité — ces éléments exigent des records supplémentaires et une analyse juridique. Pour une vision complète de l'endroit où se situe la limite, voyez ce qu'une preuve prouve et ne prouve pas.

Comment concevoir le flux de travail ?

Concevez-le en fonction de la question à laquelle vous prévoyez de répondre plus tard, pas seulement du calcul d'empreinte d'aujourd'hui.

Une structure praticable :

Définissez un format canonique de manifeste de jeu de données.
Hachez chaque élément du jeu de données ou chaque entrée de manifeste.
Construisez une racine de Merkle pour l'instantané.
Publiez un record Label 309, signé si vous souhaitez une paternité attribuable.
Conservez le manifeste, la liste de feuilles et les éléments des preuves d'inclusion.
Reliez les exécutions d'entraînement des modèles aux racines des jeux de données.
Scellez les paquets de preuves sensibles à destination des équipes juridiques ou de conformité.
Consignez les instantanés de remplacement lorsque le jeu de données change.

Le plus difficile, ce n'est presque jamais la cryptographie. Le plus difficile, c'est de décider quelles preuves seront pertinentes lorsque quelqu'un les réclamera dans des mois ou des années.

À quelle fréquence engager un instantané ?

Engagez un instantané chaque fois que le jeu de données change de façon significative — typiquement après une nouvelle ingestion, avant une exécution d'entraînement, après une déduplication ou un filtrage, après l'étiquetage, avant la sortie d'un modèle, à un point de contrôle de gouvernance, ou avant de partager le jeu de données avec un partenaire.

La cadence doit correspondre aux questions que vous prévoyez d'avoir à traiter. Engagez un instantané une fois par an et vous risquez de ne pas pouvoir prouver quel instantané intermédiaire a existé. Engagez-en un à chaque modification anodine et vous générez du bruit opérationnel. Comme le regroupement Merkle permet à une seule racine de représenter un instantané entier — une transaction, quel que soit le nombre de fichiers couverts — le coût reste à peu près constant par engagement ; vous pouvez donc choisir une cadence adaptée aux preuves dont vous avez besoin plutôt qu'une cadence dictée par le prix.

Comment le stockage scellé s'intègre-t-il ?

Parfois, le calcul d'empreinte ne suffit pas — vous voulez préserver la preuve elle-même, pas seulement son empreinte.

Une PoE scellée vous le permet. Le record public s'engage toujours sur l'empreinte du texte en clair, exactement comme une preuve ordinaire. Le contenu sensible est chiffré et stocké à une URI adressée par le contenu, la clé de chiffrement du contenu étant enveloppée vers une ou plusieurs clés de destinataires. Les destinataires autorisés peuvent le déchiffrer plus tard et confirmer que le texte en clair récupéré correspond à l'engagement sur la chaîne en recalculant l'empreinte.

La chaîne ne transporte jamais le texte en clair et ne révèle jamais l'identité des destinataires ; elle montre seulement qu'un engagement scellé a été pris à l'instant T. Cela compte lorsque la perte du manifeste original affaiblirait votre preuve. Un record avec empreinte seule prouve l'existence tant que vous détenez encore le fichier. Un record scellé peut préserver le fichier chiffré lui-même, de sorte que la preuve et l'engagement voyagent ensemble.

Une limite mérite d'être énoncée clairement : le scellement maintient le contenu privé vis-à-vis de tous sauf des détenteurs de clés choisis, mais il ne rend personne anonyme, et un destinataire peut toujours divulguer le texte en clair après l'avoir déchiffré. Le scellement contrôle qui peut lire, pas ce que cette personne en fait ensuite.

Qui doit être responsable du processus ?

Un processus de preuve de jeu de données ne devrait pas être un script d'ingénierie sans responsable. Il touche au juridique, à la sécurité, à la gouvernance des données, à la conformité et au développement de modèles, et un bon processus rend les frontières explicites : qui peut créer des instantanés, qui peut signer les engagements, où sont stockés les manifestes, qui peut déchiffrer les paquets scellés, comment sont générées les preuves d'inclusion, comment les exécutions de modèles se relient aux racines, comment sont traités les instantanés remplacés, et comment les preuves sont produites lors d'un audit ou d'un litige.

La preuve est cryptographique. La gouvernance est organisationnelle. Il vous faut les deux.

En résumé

Pour prouver vos données d'entraînement sans les divulguer, engagez-vous sur l'instantané, pas sur le jeu de données. Construisez un manifeste, hachez ses entrées, publiez une racine de Merkle dans un record Label 309, et conservez la liste de feuilles ainsi que les preuves d'inclusion. Scellez les fichiers justificatifs sensibles lorsque leur perte affaiblirait la preuve. Puis ne révélez que les preuves que chaque question exige réellement.

Vous obtenez ainsi une preuve durable, ancrée par un tiers, de possession antérieure et de chronologie. Cela ne prouve pas en soi la propriété, l'usage licite ni la conformité — et c'est le plus utile lorsque vous êtes clair sur ce qu'elle fait, et ne fait pas, exactement.

Pour aller plus loin

Le standard ouvert derrière ces preuves : label309.org. Il est en cours de soumission au processus CIP de Cardano et est examiné par les éditeurs CIP ; vous pouvez suivre la proposition dans la pull request ouverte.
Les SDK open source et le CLI cardanowall qui construisent manifestes, arbres de Merkle et preuves d'inclusion hors ligne : github.com/cardanowall.
Un seul record pour des milliers de fichiers — le fonctionnement du regroupement Merkle en détail.
Les manifestes de jeux de données IA — comment structurer le manifeste sur lequel vous vous engagez.
Divulgation confidentielle sans fichiers publics — remettre des preuves à une contrepartie sans les publier.