Cómo demostrar tus datos de entrenamiento sin revelarlos

Sí, puedes demostrar que un conjunto de datos privado existió sin necesidad de publicarlo.

El patrón es breve: construyes un manifiesto del conjunto de datos, calculas el hash de sus entradas, pliegas esos hashes en una única raíz de Merkle y publicas un registro de prueba de existencia Label 309 en Cardano. El conjunto de datos en sí nunca sale de tu control. Más adelante puedes revelar exactamente un archivo, una fila, una entrada del manifiesto o una prueba de inclusión para demostrar que formaba parte de la instantánea comprometida, y nada más.

Eso demuestra la posesión previa en un momento concreto. Por sí solo, no demuestra la propiedad, el estado de los derechos de autor, el consentimiento ni el uso legal. Esas son preguntas distintas que requieren registros distintos.

¿Por qué necesitaría esto un equipo de IA?

Los datos de entrenamiento se han convertido en una cuestión de consejo de administración. Un proveedor de modelos puede tener que mostrar qué datos tenía, cuándo los tenía, de dónde provenían, cómo se procesaron y qué conjuntos de datos alimentaron una versión concreta del modelo, ya sea ante inversores, socios, clientes, reguladores, auditores, licenciantes o un litigio.

Al mismo tiempo, la empresa a menudo no puede publicar el conjunto de datos. Puede contener contenido con licencia, datos de clientes, datos personales, fuentes propietarias, anotaciones internas, secretos comerciales, evaluaciones de seguridad, corpus de recuperación, datos sintéticos o reglas de filtrado sensibles.

La prueba de existencia resuelve esa tensión. Te permite comprometerte con el estado y la cronología del conjunto de datos sin divulgarlo públicamente. Publicas una huella; los bytes se quedan en casa.

¿Con qué debes comprometerte: los datos en bruto o un manifiesto?

Comprométete con un manifiesto, no solo con los bytes en bruto.

El manifiesto de un conjunto de datos describe la instantánea de forma estructurada y legible por máquina. Puede registrar:

el nombre del conjunto de datos y el identificador de la instantánea;
la ventana de recopilación;
las categorías de fuentes y los metadatos de derechos;
los hashes por archivo y por fila;
las versiones de deduplicación y filtrado;
las versiones del flujo de anotación y preprocesamiento;
el modelo o la ejecución de entrenamiento que lo utilizó;
la política de retención y la titularidad interna.

El manifiesto no tiene por qué exponer ningún detalle sensible públicamente. Puede vivir por completo dentro de la empresa. La prueba pública se compromete únicamente con su hash, o con una raíz de Merkle sobre muchas entradas del manifiesto. El objetivo es preciso y duradero: congelar la prueba del estado del conjunto de datos en un momento conocido.

¿Por qué usar una raíz de Merkle en lugar de un registro por archivo?

Los conjuntos de datos son grandes, y publicar un registro por cada archivo o fila no escala. Una raíz de Merkle resuelve esto: se compromete con una lista ordenada de muchos hashes bajo un único valor de 32 bytes, anclado en una sola transacción.

Más adelante, para demostrar que un único elemento estaba incluido, revelas solo:

el elemento o su hash;
la entrada correspondiente del manifiesto;
una prueba de inclusión de Merkle;
la referencia de transacción Label 309.

El verificador recalcula el camino desde esa hoja hasta la raíz y confirma que la raíz se publicó en un instante concreto de bloque de Cardano. La prueba crece con el logaritmo del tamaño del lote, así que se mantiene pequeña incluso con millones de hojas. Y lo más importante: construir el árbol y comprobar las pruebas es puro cálculo offline, sin servidor, sin cuenta y sin que se requiera tu cooperación en el momento de la verificación.

Esto es lo que hace posible la divulgación selectiva. Nunca tienes que revelar el conjunto de datos completo para demostrar que un elemento pertenecía a la instantánea comprometida.

¿Qué ve realmente el público?

Solo el registro de la prueba en la cadena. Según cómo publiques, eso puede incluir el hash de un manifiesto, una raíz de Merkle, un número de hojas, el instante de la transacción, una firma opcional de tu empresa o sistema, y URIs opcionales direccionadas por contenido (ar://, ipfs://) para material de respaldo público o cifrado.

El público no ve los archivos del conjunto de datos, la lista completa de hojas, los metadatos de las fuentes, los datos de clientes, los detalles de licencia, las anotaciones ni las notas internas. Eso permanece dentro de tu sistema de pruebas hasta que una pregunta concreta fuerce la divulgación.

¿Qué revelarías más adelante, y cuándo?

Revela solo lo que la pregunta exija.

¿Estaba un archivo en el conjunto de datos? Revela el archivo o su hash, la entrada del manifiesto y una prueba de inclusión.
¿Se incluyó una categoría de fuente? Revela la sección correspondiente del manifiesto y la prueba de que pertenece a la instantánea comprometida.
¿Una versión del modelo usó una instantánea concreta? Revela el manifiesto de la ejecución de entrenamiento que vincula la versión del modelo con la raíz del conjunto de datos.
¿Es esto una auditoría completa? Revela el manifiesto y la lista de hojas íntegros bajo el proceso de confidencialidad adecuado.

La raíz en la cadena demuestra la cronología. Tu archivo interno determina cuánto detalle puedes mostrar y a quién. Para los casos en que el propio material de respaldo deba pasar a un tercero pero seguir siendo privado, puedes compartirlo de forma confidencial en lugar de hacerlo público.

¿Cómo se relaciona esto con la regulación de la IA?

La regulación de la IA avanza hacia deberes más estrictos de documentación y transparencia. El Reglamento de IA de la UE, por ejemplo, establece normas de transparencia y relacionadas con los derechos de autor para los modelos de IA de propósito general, y la Comisión Europea ha publicado una plantilla para el resumen público del contenido de entrenamiento, descrita, en palabras de la propia Comisión, como una base mínima de la información que debe ponerse a disposición del público.

La prueba de un conjunto de datos privado no es lo mismo que ese resumen público. No sustituye los informes regulatorios, la revisión legal, la gestión del consentimiento ni los registros de licencias, y si algo de esto ayuda en un caso concreto depende de tu jurisdicción y de tu asesor.

Lo que sí puede respaldar es la capa probatoria que hay detrás de esos procesos. Si una empresa necesita más adelante mostrar qué tenía, qué sabía o en qué instantánea se basó un resumen publicado, un compromiso de manifiesto con sello de tiempo es una prueba concreta de cronología e integridad, anclada por un tercero.

¿Qué demuestra realmente la prueba de un conjunto de datos?

Demuestra que un compromiso concreto con un conjunto de datos existía a una hora pública de bloque. Según las pruebas que conserves, eso puede ayudar a mostrar:

que un archivo estaba en la instantánea de un conjunto de datos;
que un manifiesto existía antes de una disputa;
que una versión de un conjunto de datos existía antes del lanzamiento de un modelo;
que una ejecución de entrenamiento hacía referencia a una instantánea concreta;
que una categoría de fuente estaba documentada en su momento;
que un flujo de preprocesamiento o filtrado quedó registrado.

Si el registro está firmado —Label 309 admite firmas opcionales a nivel de registro—, también puede mostrar que una clave de la empresa o del sistema avaló el compromiso. Firmar nunca es obligatorio, así que un compromiso sin firmar es igual de válido; la firma solo añade una autoría atribuible.

¿Qué no demuestra?

Esta es la parte sobre la que conviene ser honesto, porque las lagunas importan.

La prueba de un conjunto de datos no demuestra que el uso de los datos fuera legal. No demuestra que fueras propietario de los datos, que se recopilaran con consentimiento, ni cuál es su estado de derechos de autor. No demuestra que los datos se usaran realmente para entrenar, a menos que tu flujo de entrenamiento y los registros del modelo estén a su vez vinculados a la instantánea del conjunto de datos. Y no demuestra que el manifiesto esté completo; solo tu proceso y tus controles pueden hacer creíble esa exhaustividad.

La prueba de existencia es material probatorio de cronología e integridad. Establece que unos bytes exactos existían a una hora pública. No dice nada sobre la verdad, la propiedad, los derechos o el cumplimiento: eso requiere registros adicionales y un análisis legal. Si quieres ver con claridad dónde está el límite, consulta qué demuestra y qué no demuestra una prueba.

¿Cómo deberías diseñar el flujo de trabajo?

Diseña para la pregunta que esperas responder más adelante, no solo para calcular hashes hoy.

Una forma viable:

Define un formato canónico de manifiesto del conjunto de datos.
Calcula el hash de cada elemento del conjunto de datos o entrada del manifiesto.
Construye una raíz de Merkle para la instantánea.
Publica un registro Label 309, firmado si quieres una autoría atribuible.
Guarda el manifiesto, la lista de hojas y el material de las pruebas de inclusión.
Vincula las ejecuciones de entrenamiento del modelo con las raíces del conjunto de datos.
Sella los paquetes de pruebas sensibles para destinatarios legales o de cumplimiento.
Registra las instantáneas que sustituyen a otras cuando el conjunto de datos cambia.

La parte difícil rara vez es la criptografía. La parte difícil es decidir qué pruebas resultarán significativas cuando alguien las pida dentro de meses o años.

¿Con qué frecuencia deberías comprometer una instantánea?

Comprométete siempre que el conjunto de datos cambie de forma significativa: normalmente tras una nueva ingesta, antes de una ejecución de entrenamiento, después de deduplicar o filtrar, tras el etiquetado, antes del lanzamiento de un modelo, en un punto de control de gobernanza o antes de compartir el conjunto de datos con un socio.

La cadencia debe ajustarse a las preguntas que esperas responder. Comprométete una vez al año y puede que no puedas demostrar qué instantánea intermedia existió. Comprométete con cada cambio trivial y generas ruido operativo. Como la agrupación de Merkle permite que una sola raíz represente una instantánea entera —una transacción, sin importar cuántos archivos abarque—, el coste se mantiene prácticamente constante por compromiso, así que puedes elegir una cadencia que se ajuste a las pruebas que necesitas en lugar de una dictada por el precio.

¿Cómo encaja el almacenamiento sellado?

A veces calcular el hash no basta: quieres preservar las pruebas en sí, no solo una huella de ellas.

Una PoE sellada te permite hacerlo. El registro público sigue comprometiéndose con el hash del texto plano, exactamente como lo haría una prueba normal. La carga sensible se cifra y se almacena en una URI direccionada por contenido, con la clave de cifrado de contenido envuelta para una o más claves de destinatario. Los destinatarios autorizados pueden descifrarla más adelante y confirmar que el texto plano recuperado coincide con el compromiso en la cadena recalculando el hash.

La cadena nunca transporta el texto plano y nunca revela quiénes son los destinatarios; solo muestra que se hizo un compromiso sellado en el instante T. Esto importa cuando perder el manifiesto original debilitaría tu prueba. Un registro con solo el hash demuestra la existencia mientras sigas teniendo el archivo. Un registro sellado puede preservar el propio archivo cifrado, de modo que la prueba y el compromiso viajan juntos.

Conviene dejar clara una limitación: el sellado mantiene el contenido privado frente a todos salvo los titulares de las claves elegidos, pero no hace anónimo a nadie, y un destinatario siempre puede filtrar el texto plano después de descifrarlo. El sellado controla quién puede leer, no qué hace a continuación.

¿Quién debería ser responsable del proceso?

Un proceso de prueba de conjuntos de datos no debería ser un script de ingeniería sin dueño. Toca al área legal, de seguridad, de gobernanza de datos, de cumplimiento y de desarrollo de modelos, y un buen proceso hace explícitos los límites: quién puede crear instantáneas, quién puede firmar compromisos, dónde se guardan los manifiestos, quién puede descifrar los paquetes sellados, cómo se generan las pruebas de inclusión, cómo se vinculan las ejecuciones del modelo con las raíces, cómo se gestionan las instantáneas sustituidas y cómo se aportan las pruebas durante una auditoría o una disputa.

La prueba es criptográfica. La gobernanza es organizativa. Necesitas las dos.

La versión corta

Para demostrar tus datos de entrenamiento sin revelarlos, comprométete con la instantánea, no con el conjunto de datos. Construye un manifiesto, calcula el hash de sus entradas, publica una raíz de Merkle en un registro Label 309 y conserva la lista de hojas y las pruebas de inclusión. Sella los archivos de respaldo sensibles cuando perderlos debilitaría la prueba. Después revela solo las pruebas que cada pregunta exija realmente.

Eso te da una prueba duradera, anclada por un tercero, de posesión previa y cronología. Por sí sola, no demuestra la propiedad, el uso legal ni el cumplimiento, y es más útil cuando tienes claro exactamente cuál de esas cosas está haciendo y cuál no.

Lecturas adicionales

El estándar abierto detrás de estas pruebas: label309.org. Se está presentando al proceso CIP de Cardano y está bajo revisión de los editores de CIP; puedes seguir la propuesta en el pull request abierto.
Los SDK de código abierto y la CLI cardanowall que construyen manifiestos, árboles de Merkle y pruebas de inclusión offline: github.com/cardanowall.
Un registro para miles de archivos: cómo funciona en profundidad la agrupación de Merkle.
Manifiestos de conjuntos de datos de IA: cómo estructurar el manifiesto con el que te comprometes.
Divulgación confidencial sin archivos públicos: cómo entregar pruebas a una contraparte sin publicarlas.