Demostrar la procedencia del contenido de IA a escala con agrupación de Merkle

Si tu equipo genera contenido de IA a escala, puedes demostrar qué creaste y cuándo lo creaste sin poner cada activo en la cadena. Calcula el hash de cada salida o manifiesto de procedencia, agrupa esos hashes en raíces de Merkle y publica compromisos Label 309 con sello de tiempo a un ritmo regular. Más adelante podrás demostrar que una imagen, un vídeo, un archivo de texto, un manifiesto de prompt y salida o un manifiesto de Content Credentials concretos formaron parte de un lote comprometido, usando solo la referencia de la transacción y un explorador público de Cardano.

Lo que esto te da es una prueba de existencia: la prueba de que esos bytes exactos existían en un momento público. No demuestra que el contenido sea veraz, lícito ni hecho por humanos. Demuestra un compromiso con sello de tiempo sobre unos bytes concretos, anclado fuera de tus propios sistemas editables.

¿Por qué necesita el contenido de IA una capa de prueba aparte?

El contenido de IA es fácil de crear, editar, remezclar y regenerar, y ese es justamente el problema.

Si una empresa produce miles de activos generados por IA, ¿cómo demuestra después qué salidas creó, cuándo las creó, qué prompt o contexto de modelo quedó registrado y qué versión se mostró a un cliente o se publicó en línea?

Un registro en una base de datos interna a menudo no basta por sí solo. Los registros se pueden reescribir. El almacenamiento se migra. Los activos se pueden regenerar byte por byte. Los metadatos se eliminan en tránsito. Un cliente, un auditor, un regulador, un socio o un tribunal pueden pedir pruebas que existieran fuera de los sistemas editables de la empresa, y en un momento verificable.

La prueba de existencia da a esos registros un sello de tiempo externo que no depende de confiar en la empresa, en sus servidores ni en su dominio.

¿De qué debería calcular el hash un equipo de IA?

Calcula el hash de las pruebas que quizá tengas que presentar más adelante.

En el caso del contenido generado por IA, eso suele incluir:

el archivo de salida generado;
el prompt y el prompt de sistema o perfil de política;
el nombre y la versión del modelo;
la semilla o los parámetros de generación, cuando sean relevantes;
el historial de ediciones;
el resultado de moderación;
el identificador de usuario o de la petición;
el manifiesto de salida;
el manifiesto de Content Credentials (C2PA);
las referencias al conjunto de datos o al contexto de recuperación;
el evento de aprobación o publicación;
el paquete de entrega al cliente.

No todo esto debe ser público. Los detalles sensibles pueden quedarse en un manifiesto privado del que calculas el hash y al que te comprometes mediante una raíz de Merkle. Más adelante revelas solo el subconjunto necesario para una disputa, una auditoría o una verificación de cliente concretas; el resto sigue siendo privado y, aun así, queda comprometido de forma demostrable.

¿Por qué agrupar con una raíz de Merkle en vez de un registro por salida?

Una plataforma puede producir miles o millones de salidas. Publicar un registro en cadena aparte para cada una sería lento y derrochador. Una raíz de Merkle te permite comprometer muchos hashes en un solo registro.

El flujo de trabajo es así:

Genera o recibe las salidas.
Construye un manifiesto canónico para cada salida.
Calcula el hash del activo y de su manifiesto en una hoja.
Añade la hoja a una lista ordenada.
Publica una raíz de Merkle cada hora, día, lanzamiento o lote.
Conserva la lista de hojas y las pruebas de inclusión.

Más adelante podrás demostrar que una salida o un manifiesto se incluyó en un lote concreto sin publicar el lote entero en la cadena. Construir el árbol y verificar una prueba de inclusión son operaciones totalmente fuera de línea; solo la publicación de la raíz pasa por un gateway. Con las herramientas de código abierto, una prueba de inclusión crece con el logaritmo del tamaño del lote, así que una prueba para un elemento entre un millón de hojas se mantiene pequeña. Encontrarás la mecánica detallada en un registro para miles de archivos.

¿Cómo funciona esto junto a C2PA y Content Credentials?

C2PA y Label 309 resuelven problemas distintos, y encajan bien.

C2PA —la Coalition for Content Provenance and Authenticity, cuya forma de cara al usuario es Content Credentials— es una capa de procedencia estructurada. Un manifiesto C2PA puede llevar aserciones, afirmaciones, firmas y vinculaciones que describen el origen y el historial de ediciones de un activo multimedia.

Label 309 ancla un hash —de ese manifiesto, o del activo más el manifiesto— a un sello de tiempo independiente de Cardano. Entonces:

C2PA describe la procedencia dentro del activo multimedia o junto a él.
Label 309 demuestra que un manifiesto o un compromiso sobre un activo concreto existía en un momento público, sin servidor de emisor en el que confiar ni al que sobrevivir.

C2PA le da al contenido un vocabulario de procedencia; Label 309 le da a la prueba un anclaje temporal público. Para una comparación más detallada de ambos, consulta prueba de existencia frente a C2PA y por qué C2PA se beneficia de un anclaje temporal.

¿Por qué no fiarse solo de los metadatos incrustados?

Los metadatos incrustados se pueden eliminar, perder o transformar en tránsito. La mayoría de las recodificaciones de las redes sociales descartan por completo un manifiesto C2PA.

Eso no hace inútil la procedencia incrustada. Las Content Credentials son valiosas precisamente porque viajan con el contenido y permiten a los consumidores inspeccionar su origen. Pero un compromiso externo y con sello de tiempo ayuda cuando los metadatos se eliminan, se disputan o se separan del activo.

En la práctica, un equipo conserva:

el activo generado original;
el manifiesto C2PA;
el manifiesto de salida;
la referencia de transacción Label 309;
la prueba de inclusión de Merkle.

Si después circula una copia sin sus metadatos, todavía puedes conectar el activo o el manifiesto originales con el compromiso público recalculando el hash.

¿Y las normas de transparencia de la IA?

La presión regulatoria sobre la procedencia de la IA va en aumento. La síntesis de la Ley de IA de la Comisión Europea establece que los proveedores de IA generativa deben asegurarse de que el contenido generado por IA sea identificable, y que las normas de transparencia de la Ley de IA entran en vigor en agosto de 2026.

Esto no es asesoramiento legal, y los requisitos varían según la jurisdicción y el caso de uso. Pero la dirección es clara: las empresas que producen contenido de IA necesitan prácticas de prueba más sólidas.

La prueba de existencia no es un programa de cumplimiento por sí misma. Es una capa de pruebas que puede respaldar el trabajo de cumplimiento al hacer que los registros sean más difíciles de reescribir en silencio a posteriori. Que ayude en algún contexto regulatorio concreto depende de la norma y de tu jurisdicción, y no sustituye a un asesor legal.

¿Qué puede demostrar realmente aquí una prueba Label 309?

Puede demostrar que unos datos exactos existían en un momento público. En el contenido de IA, esos datos podrían ser un archivo de salida, un manifiesto de prompt y salida, un manifiesto C2PA, una raíz de lote sobre muchos activos generados, un informe de moderación, un registro de aprobación o un manifiesto de publicación.

Tres funciones opcionales amplían lo que puede llevar un solo registro:

Registros firmados. Si el registro lleva una firma opcional, también muestra que una clave concreta avaló el registro. La autoría siempre es opcional en Label 309: nunca es obligatoria para publicar.
Registros sellados. Los archivos sensibles se pueden cifrar y conservar sin hacerse públicos, con la clave de cifrado del contenido envuelta para una o varias claves de destinatario.
Agrupación de Merkle. Una sola raíz puede cubrir volúmenes muy grandes de salida.

¿Qué es lo que no demuestra?

Un compromiso con sello de tiempo es deliberadamente acotado. No demuestra que el contenido sea veraz. No demuestra que la salida provenga de un modelo concreto, salvo que el contexto del modelo quede registrado y sea de confianza como parte de tu flujo de trabajo. No demuestra que el contenido se haya generado, entrenado ni publicado de forma lícita. No demuestra que un manifiesto C2PA sea de fiar, salvo que la validación C2PA y el modelo de confianza del firmante también cuadren. Y no demuestra que tu canalización interna fuera honesta, salvo que esa canalización esté a su vez controlada, registrada y sea auditable.

La prueba es un compromiso con sello de tiempo sobre unos bytes concretos. El sistema de procedencia que la rodea es lo que da sentido al compromiso. Para profundizar en este límite, consulta qué no demuestra una prueba.

¿Cómo deberían estructurar los equipos el manifiesto?

Mantenlo aburrido, canónico y estable. Un manifiesto de salida de IA podría incluir:

el hash del activo y el tipo de activo;
el sello de tiempo de creación del sistema;
el identificador y la versión del modelo;
los parámetros de generación;
un hash del prompt o una referencia a un prompt cifrado;
el identificador de usuario o de flujo de trabajo;
la decisión de moderación;
el hash del manifiesto C2PA;
el estado de publicación;
el identificador de lote;
una referencia de aprobación interna.

Los valores sensibles no tienen que ser públicos. El manifiesto puede ser privado, sellado o divulgarse de forma selectiva más adelante; la prueba pública se compromete con el hash del manifiesto, o con una raíz de Merkle sobre muchos hashes de manifiesto. La clave es la coherencia: si cada equipo inventa una forma nueva de manifiesto cada semana, la verificación futura se vuelve penosa.

¿Deberían ser públicos los prompts?

Normalmente no. Los prompts pueden contener datos de clientes, secretos comerciales, datos personales, material de pruebas de seguridad o detalles de política interna. Puedes calcular el hash de los prompts o de los manifiestos de prompt sin publicar nunca el texto del prompt.

Para flujos de trabajo sensibles, un registro sellado puede conservar un paquete cifrado de prompt y salida. Un verificador posterior que tenga la clave correcta puede descifrar el paquete, recalcular el hash y confirmar que coincide con el compromiso público. Esto te da pruebas sin hacerlas públicas desde el primer día. Ten en cuenta la limitación: una vez que un destinatario descifra un paquete sellado, tiene el texto plano y puede compartirlo; el sellado controla quién puede abrir el registro, no qué hace después con él. El patrón se trata en divulgación confidencial sin archivos públicos.

¿Cuál es una buena primera implementación?

Empieza con compromisos por lotes. Para cada día o lanzamiento:

Reúne las salidas generadas que importan.
Construye un manifiesto por salida.
Incluye los hashes de los manifiestos C2PA cuando estén disponibles.
Calcula el hash de cada manifiesto en una hoja.
Construye una raíz de Merkle.
Publica un registro Label 309 firmado.
Guarda la lista de hojas, las pruebas de inclusión y la referencia de la transacción.

Después añade la conservación sellada para los paquetes sensibles y la verificación de cara al cliente para los activos públicos. El objetivo no es construir el universo de procedencia perfecto desde el primer día; es dejar de perder la línea temporal. El mismo patrón de agrupación aparece en pruebas de compilación de CI/CD y manifiestos de conjuntos de datos de IA.

¿Quién necesita esto?

Este patrón encaja con cualquier equipo que produzca contenido a escala y que quizá tenga que demostrar después qué generó y cuándo:

empresas de medios de IA y herramientas de diseño generativo;
plataformas de vídeo e imagen con IA;
plataformas de automatización de marketing;
equipos de IA empresarial;
empresas de datos sintéticos y equipos de evaluación de modelos;
editoriales que usan flujos de trabajo asistidos por IA;
empresas que se preparan para auditorías de procedencia de IA.

La versión corta

La procedencia de la IA a escala necesita agrupación. Calcula el hash de tus salidas y manifiestos, pliega los hashes en raíces de Merkle y publica registros Label 309 a un ritmo constante. Conserva las listas de hojas y las pruebas de inclusión. Usa C2PA y Content Credentials para la procedencia multimedia donde encajen, y usa Label 309 como el anclaje temporal público que va debajo.

La prueba no establece la verdad ni la legalidad. Establece la línea temporal de unos bytes exactos, y esa suele ser la pieza que ya no puedes reconstruir a posteriori.

Para seguir leyendo

Anclar miles de archivos bajo una sola raíz
Prueba de existencia frente a C2PA y por qué C2PA necesita un anclaje temporal
Manifiestos de conjuntos de datos de IA y demostrar los datos de entrenamiento sin revelarlos
Qué no demuestra una prueba
C2PA / Content Credentials: c2pa.org, la especificación técnica de C2PA y contentcredentials.org
Comisión Europea, Marco regulatorio de la IA
El estándar abierto en label309.org y los SDK y la CLI de código abierto en github.com/cardanowall