Prueba legal y e-discovery: sellar en el tiempo documentos y exportaciones de e-discovery

Una prueba de existencia permite a un equipo legal demostrar dos cosas sobre un archivo: que existía en un momento público concreto y que una copia presentada después es la misma secuencia de bytes. Calculas el hash de un documento, de un paquete de pruebas o de una exportación de e-discovery (la exhibición electrónica de pruebas), publicas ese hash en la blockchain de Cardano bajo Label 309 y conservas el archivo original junto con la referencia de la transacción. Cualquiera —incluido el abogado de la parte contraria o un perito designado por el tribunal— puede más adelante recalcular el hash y confirmar que coincide con lo que hay en la cadena pública, sin confiar en tus servidores.

Lo que no hace es convertir una prueba en admisible, auténtica, privilegiada, completa o jurídicamente suficiente. Un sello de tiempo es un único hecho de apoyo dentro de un proceso mucho más amplio. Puede reforzar un relato de autenticidad e integridad; no puede resolver el caso. Trátalo como una capa de integridad y temporalidad, y consulta con tu asesor legal antes de apoyarte en cualquier sistema de prueba en un litigio.

¿Qué problema resuelve realmente un sello de tiempo?

Las disputas legales giran en torno a la cronología, y las cronologías se cuestionan.

A menudo, un equipo necesita responder a preguntas como estas:

¿Existía este documento antes de que surgiera la disputa?
¿Es este el mismo archivo que se revisó o se presentó?
¿Se creó esta exportación antes del plazo de producción?
¿Formaban parte estos archivos concretos del paquete de pruebas?
¿Se alteró el informe después de cerrarlo?
¿Existía el conjunto de pruebas antes de que llegara una orden de conservación?

Los sistemas internos pueden almacenar documentos y registros, pero esos registros viven dentro de una infraestructura que una de las partes controla, así que la otra parte puede cuestionar cuándo se hizo realmente una anotación. Un compromiso público con sello de tiempo desplaza el anclaje temporal fuera del alcance de cualquiera. La afirmación «esta secuencia exacta de bytes existía en el momento del bloque T o antes» la puede comprobar cualquiera contra la cadena de Cardano, sin necesidad de confiar en quien publica, en un dominio ni en ningún servidor.

¿Qué se puede sellar en el tiempo?

Casi cualquier secuencia de bytes. Al hash le da igual lo que signifiquen los bytes.

Un equipo legal podría comprometerse con:

contratos y anexos;
PDF e informes firmados;
correos exportados a un formato estable;
producciones de e-discovery;
imágenes forenses o manifiestos de imágenes;
registros de cadena de custodia;
registros de revisión de privilegio;
materiales y transcripciones de declaraciones;
inventarios de pruebas;
informes periciales;
borradores de acuerdo;
presentaciones regulatorias;
paquetes completos de un caso.

El contenido en sí nunca tiene que ser público. El registro en cadena puede llevar solo el hash o, para toda una colección, una única raíz de Merkle. Nada legible sobre las pruebas toca la cadena.

¿Cómo funciona esto para un solo documento?

Para un único archivo, el flujo es corto:

Crea o reúne el documento.
Calcula su hash.
Publica el hash en un registro Label 309.
Conserva juntos el archivo original y la referencia de la transacción.
Más adelante, recalcula el hash a partir del archivo.
Compáralo con el registro en cadena.

Si los hashes coinciden, el archivo que tienes en la mano es la misma secuencia de bytes que se comprometió en el momento de la transacción. Ese es exactamente el par integridad-temporalidad que una disputa suele necesitar: los bytes no han cambiado y existían en un momento público conocido.

¿Cómo funciona esto para un gran conjunto de pruebas?

Usa un manifiesto y una raíz de Merkle, no el hash de un único archivo gigante.

El e-discovery rara vez llega como un solo archivo. Es una carpeta, una exportación, un conjunto de producción, una recopilación forense. Puedes calcular el hash de un único ZIP enorme, pero entonces cada verificación implica volver a calcular el hash de todo, y un solo byte cambiado invalida el compromiso entero sin manera de señalar qué se movió. Un manifiesto y un árbol de Merkle resuelven eso.

El manifiesto enumera cada archivo y su digest. La raíz de Merkle compromete toda la lista ordenada en un único valor de 32 bytes, y publicas solo esa raíz en una sola transacción. Más adelante, una parte puede demostrar que un archivo concreto estaba en el conjunto con una prueba de inclusión compacta —que solo crece con el logaritmo del tamaño del lote— sin revelar ni reprocesar el resto del paquete. Construir el árbol y comprobar una prueba de inclusión son puro cálculo fuera de línea; solo publicar la raíz toca un gateway. El mismo patrón escala una única prueba a miles de archivos, algo que cubrimos en un registro para miles de archivos.

Esto encaja con:

producciones de e-discovery;
exportaciones de revisión documental;
inventarios de sala de pruebas;
recopilaciones forenses;
paquetes de respuesta regulatoria;
paquetes de investigación interna.

La raíz ancla el conjunto. El manifiesto lo explica.

¿Conviene sellar las pruebas legales?

A menudo, sí, porque la mayoría de las pruebas están protegidas por privilegio, son confidenciales, personales o comercialmente sensibles, y publicar el texto plano sería un error.

Hay tres enfoques, en orden creciente de confidencialidad:

Prueba solo con hash: publicas únicamente el compromiso y mantienes las pruebas totalmente privadas. Nada del contenido llega a la cadena más allá de su hash.
Prueba de Merkle: publicas una raíz sobre muchos archivos privados y luego revelas pruebas de inclusión individuales solo a las partes que tienen derecho a ellas.
Prueba sellada: ciframos las pruebas o el manifiesto y guardamos el texto cifrado donde los destinatarios autorizados pueden recuperarlo. La cadena sigue llevando solo el hash del texto plano, la hora del bloque y las claves envueltas; nunca el texto plano ni quiénes son los destinatarios.

Un registro sellado es la herramienta adecuada cuando los bytes originales deben seguir siendo recuperables más adelante pero no pueden ser públicos ahora: el destinatario descifra del lado del cliente y recalcula el hash del texto plano contra el compromiso en cadena. Eso sí, ten claro el límite: sellar mantiene el texto plano legible solo para quienes tienen las claves; no garantiza el anonimato, y un destinatario siempre puede filtrar el texto plano después de descifrarlo. El patrón de demostrar que algo existía manteniendo el archivo confidencial se explora en divulgación confidencial sin archivos públicos.

¿Puede esto reemplazar la cadena de custodia?

No. La prueba de existencia apoya la cadena de custodia; no la sustituye.

La cadena de custodia tiene que ver con las personas y el proceso: quién recopiló las pruebas, cómo se almacenaron, quién tuvo acceso, cómo se transfirieron, qué herramientas se usaron, si se siguieron los procedimientos y si el material se protegió frente a manipulaciones. Una prueba Label 309 puede demostrar que un archivo o un manifiesto existía en un momento público y que una copia posterior coincide con el hash comprometido. No dice nada sobre quién manipuló los bytes ni cómo.

Úsala como una capa de integridad y sello de tiempo dentro de un proceso probatorio más amplio y documentado, no como el proceso en sí.

¿Puede un sello de tiempo hacer admisible una prueba?

Por sí solo, no. La admisibilidad depende de la jurisdicción, de las normas del tribunal, del contexto del caso, de la autenticidad, la relevancia, la prueba de referencia, el privilegio, las reglas de exhibición de pruebas (discovery), el testimonio pericial y mucho más.

Una ilustración concreta de la práctica federal estadounidense, que depende de la jurisdicción y no constituye asesoramiento legal: según la Federal Rule of Evidence 901(a), quien aporta la prueba debe «presentar material probatorio suficiente para sustentar la conclusión de que el elemento es lo que quien lo aporta afirma que es». Un sello de tiempo criptográfico puede contribuir a esa conclusión —en particular en cuanto a integridad y temporalidad—, pero no es toda la base. La Rule 901(b)(9) reconoce la autenticación mediante la «descripción de un proceso o sistema y la demostración de que produce un resultado preciso», que es justo el terreno en el que se mueve un compromiso de hash verificable. La Rule 902(14) va más allá y contempla específicamente autenticar «datos copiados de un dispositivo electrónico, un medio de almacenamiento o un archivo» mediante una identificación digital como un valor de hash. Nada de esto es automático: las partes contrarias pueden seguir impugnando la autenticidad o plantear otras objeciones, y otras jurisdicciones tratan la prueba electrónica de forma distinta.

Así que una prueba «puede sustentar» y «puede ayudar»; no garantiza la admisibilidad, ni demuestra la titularidad, ni resuelve la autoría. El asesor legal decide cómo encaja en el asunto.

¿Qué debe incluir un manifiesto de pruebas?

Mantenlo claro, estable y reproducible.

Un manifiesto de pruebas legales podría registrar:

el ID del caso o del asunto;
la fecha de recopilación;
el custodio o la fuente;
el nombre del archivo o un identificador neutral;
el tamaño del archivo;
el algoritmo de hash;
el digest;
el estado de privilegio;
el estado de confidencialidad;
la versión de la herramienta de recopilación;
el revisor o aprobador;
la ubicación de almacenamiento;
el índice de la hoja de Merkle;
la referencia de la prueba de inclusión;
la referencia de la transacción de Label 309.

No pongas hechos privilegiados o sensibles en un manifiesto que vaya a ser público a menos que tu asesor legal lo haya aprobado. El manifiesto en sí puede permanecer privado o sellarse; solo su raíz tiene que ir a la cadena.

¿En qué ayuda firmar un registro?

Una firma demuestra que una clave concreta respaldó el cuerpo del registro. Es opcional en Label 309 —el estándar es agnóstico respecto al emisor, y una prueba es plenamente válida sin firma alguna—, pero a veces la rendición de cuentas importa.

Un registro firmado podría producirlo:

la identidad de un bufete;
un departamento jurídico corporativo;
un proveedor de e-discovery;
un equipo forense;
un responsable de cumplimiento;
un custodio de pruebas designado.

La firma no demuestra ningún hecho jurídico. Demuestra únicamente que la clave de firma firmó el cuerpo del registro. Quien se apoye en ella todavía tiene que explicar quién controla esa clave y qué significa su proceso de firma: la criptografía da fe de la clave, no de la organización que hay detrás.

¿En qué ayuda la sustitución cuando los registros cambian?

Los registros legales se corrigen, se complementan y se revisan. Un manifiesto se vuelve a generar, un conjunto de producción se complementa, un informe se modifica, un registro de privilegio se actualiza.

Label 309 lleva un puntero de sustitución opcional: un hash de transacción de 32 bytes en un registro nuevo que apunta a uno anterior. El puntero no elimina, revoca ni invalida el registro previo —la cadena solo añade (append-only), y los verificadores deben seguir tratando el registro anterior como existente y verificable de forma independiente—. Simplemente crea un enlace visible e independiente de cualquier servicio desde la corrección hacia lo que corrige.

Esa visibilidad es el objetivo. El historial legal no debería desaparecer en silencio; las correcciones deberían leerse como correcciones, con ambas versiones demostrables.

¿Qué puede salir mal?

Muchas cosas, y la mayoría son de proceso, no de criptografía.

Un equipo puede calcular el hash del archivo equivocado. Puede perder los bytes originales. Puede no conservar el manifiesto o la lista de hojas, y quedarse con una raíz válida contra la que nadie puede construir una prueba. Puede revelar datos sensibles por accidente. Puede firmar con una clave que nadie gestiona. Puede esgrimir una prueba sin ningún procedimiento documentado detrás.

Una prueba puede ser criptográficamente sólida y aun así débil en lo jurídico si el proceso que la rodea es descuidado. El límite más amplio también se aplica aquí: una prueba de existencia demuestra que unos bytes exactos existían en un momento público; no demuestra la verdad, la titularidad, la autoría, la legalidad ni derechos exclusivos. Vale la pena interiorizar ese límite, y se desarrolla en lo que una prueba no demuestra.

Un buen uso legal exige procedimientos, no solo hashes.

La versión corta

Label 309 ayuda a los equipos legales a sellar pruebas en el tiempo: calcular el hash de los documentos, usar raíces de Merkle para los conjuntos de pruebas, sellar el material sensible y firmar los registros cuando importa la rendición de cuentas. Conserva juntos los manifiestos, las listas de hojas, las referencias de transacción y los archivos originales: una prueba cuyas entradas no puedes reconstruir vale poco.

La prueba puede demostrar la integridad y la temporalidad. No reemplaza la cadena de custodia, el criterio jurídico ni las normas del tribunal, y nunca decide la verdad ni la titularidad. Usada dentro de un proceso sólido, le da a la cronología un anclaje que ninguna parte controla por sí sola.

Para seguir leyendo

El estándar abierto Label 309 y su especificación: label309.org.
Las implementaciones de referencia —los SDK y la herramienta de línea de comandos cardanowall— son de código abierto en github.com/cardanowall.
La propuesta se ha presentado al proceso CIP de Cardano y está bajo revisión de los editores de CIP como un CIP de categoría Metadata: pull request #1205.
Federal Rule of Evidence 901 — Authenticating or Identifying Evidence: law.cornell.edu/rules/fre/rule_901.
Federal Rule of Evidence 902 — Evidence That Is Self-Authenticating (ver 902(13) y 902(14)): law.cornell.edu/rules/fre/rule_902.