¿Podrías demostrar qué condiciones aceptó un cliente hace dos años?

Cuando un usuario marca una casilla de «Acepto los términos y condiciones», normalmente queda algún registro interno: una fecha, un usuario y, en el mejor de los casos, una versión de las condiciones.

Eso sirve para saber que hubo una aceptación.

Pero demostrar, tiempo después, qué texto exacto aceptó esa persona, cuándo lo hizo y que ese registro no fue modificado posteriormente es otra cosa.

En Sellat nos hicimos esa misma pregunta con nuestras propias condiciones.

Y decidimos resolverla utilizando nuestra propia tecnología.

¿Cómo se demuestra que un cliente aceptó unos términos y condiciones?

Para poder reconstruir una aceptación de forma sólida no basta con guardar un simple «sí».

Es importante conservar, como mínimo:

• cuándo se produjo la aceptación;
• qué usuario realizó la acción;
• qué versión concreta de las condiciones estaba vigente;
• en qué idioma se mostraron;
• y cuál era exactamente el contenido de esas condiciones.

El problema aparece cuando toda esa información está almacenada únicamente dentro de los sistemas de la propia empresa.

Si años después existe una disputa, surge una pregunta razonable:

¿cómo puede comprobarse que ese registro no fue modificado después?

¿Es suficiente guardar la aceptación en una base de datos?

Una base de datos es necesaria para gestionar una aplicación, pero tiene una limitación evidente como mecanismo de prueba: la controla la misma empresa que necesita demostrar lo ocurrido.

Un registro puede indicar:

Usuario X aceptó las condiciones v2.3 el 28 de septiembre de 2026.

Pero esa información, por sí sola, no permite a un tercero comprobar si el registro existía realmente en ese momento o si fue alterado posteriormente.

Por eso en Sellat separamos dos cosas:

el registro interno de la aplicación y la prueba externa de ese registro.

¿Cómo saber qué versión exacta de las condiciones aceptó un usuario?

Guardar simplemente «aceptó la versión 2.3» tampoco es suficiente si dentro de unos años ya no podemos saber qué decía exactamente esa versión.

Por eso cada versión de las condiciones de Sellat se conserva como un documento independiente. Cuando publicamos una nueva versión, la anterior no desaparece: sigue pudiendo descargarse tal como estaba.

Ese archivo contiene el contenido exacto que estaba vigente en ese momento.

Así podemos relacionar una aceptación con un documento concreto, y no solo con un número de versión almacenado en una base de datos.

¿Cómo demostrar que las condiciones no se modificaron después?

Aquí entra en juego la huella digital del documento.

A cada registro y a cada versión de las condiciones se le calcula un hash SHA-256.

Un hash funciona como una huella digital: si se cambia incluso un pequeño fragmento del contenido, el resultado será diferente.

Esa huella se registra mediante Sellat y queda vinculada a pruebas externas.

Actualmente Sellat utiliza Polygon y Bitcoin mediante OpenTimestamps.

Eso permite comprobar posteriormente que una determinada huella ya existía y contrastarla con el documento que se conserva hoy.

Si el documento cambia, su hash cambia.

¿Qué información guarda Sellat cuando alguien acepta sus condiciones?

Cada vez que una persona acepta nuestras condiciones registramos la información necesaria para identificar esa aceptación, incluyendo:

• la versión de las condiciones;
• el idioma;
• el momento de la aceptación;
• y la referencia correspondiente al usuario.

A partir de esos datos generamos un registro que se sella utilizando la propia API de Sellat.

La huella queda anclada en Polygon y Bitcoin.

Es decir, utilizamos para nuestras propias condiciones el mismo sistema de prueba de existencia que ofrecemos a nuestros clientes.

¿Puede el usuario verificar su propia aceptación?

Sí.

No queríamos que la evidencia quedara únicamente en nuestros servidores.

Desde su cuenta, cada usuario puede descargar un paquete con la información relacionada con su propia aceptación.

El ZIP contiene:

• el registro de aceptación sellado;
• el documento exacto de las condiciones que aceptó;
• la información necesaria para verificar la prueba;
• y las instrucciones para comprobarla utilizando herramientas abiertas.

El objetivo es que la prueba pueda verificarse de manera independiente.

No hace falta confiar únicamente en lo que diga nuestra base de datos.

¿Qué permite comprobar este sistema?

Si dentro de unos años necesitamos revisar una aceptación, podemos reconstruir y contrastar varios elementos:

• cuándo se produjo, a partir del registro de aceptación;
• qué versión se aceptó, porque el registro identifica la versión concreta;
• qué decía exactamente esa versión, porque el documento correspondiente se conserva;
• si el documento sigue siendo el mismo, calculando de nuevo su SHA-256 y comparándolo con la huella registrada;
• y si existía una prueba externa asociada, mediante los sistemas de timestamp utilizados por Sellat.

Así, la base de datos interna deja de ser la única fuente de información.

Cómo comprobar una aceptación en tres pasos

El ZIP que descarga el usuario contiene record.json (el registro sellado), terms.json (el documento exacto de las condiciones) y, una vez anclada, la prueba pública de cada uno. Cualquiera puede comprobarlo con herramientas que no son nuestras:

1. El registro es el que dice ser. Calcula la huella de record.json (sha256sum record.json, o certutil -hashfile record.json SHA256 en Windows). Es la huella que certifica la prueba pública.
2. Las condiciones son las que el registro nombra. Dentro de record.json, el campo terms.sha256 es la huella de las condiciones. Calcula la de terms.json: debe ser la misma.
3. El registro existía en esa fecha y no ha cambiado. npx sellat-verify record.json record-proof.json comprueba la prueba contra Polygon y Bitcoin con el verificador de código abierto (github.com/skanthemore/sellat-verify), sin cuenta y sin depender de Sellat.

Lo que demuestra es que ese registro exacto, que nombra esas condiciones exactas, existía en esa fecha y no se ha alterado. Lo que eso vale como prueba lo decide un juez o un árbitro, no nosotros.

¿Puede utilizarse este sistema en otras empresas?

Sí.

Una empresa puede aplicar el mismo principio cuando necesite conservar una prueba verificable de lo que ocurrió en un momento concreto.

Por ejemplo, para registrar:

• términos y condiciones;
• condiciones de una compra;
• presupuestos aceptados;
• consentimientos;
• contratos;
• entregas;
• versiones de documentos;
• políticas internas;
• o cualquier otro contenido cuya versión y fecha sea importante poder comprobar posteriormente.

En estos casos, el sistema de la empresa genera el registro correspondiente y Sellat permite crear una prueba verificable asociada a ese contenido.

Actualmente la integración mediante API se realiza de forma acompañada.

Sellat es el primer cliente de su propia API

Podríamos limitarnos a explicar que nuestra API sirve para registrar evidencias.

Preferimos utilizarla nosotros mismos.

Cada vez que alguien acepta nuestras condiciones, generamos una prueba utilizando el mismo sistema que ofrecemos a nuestros clientes.

Porque una buena forma de demostrar que una herramienta resuelve un problema real es utilizarla para resolver ese problema en tu propia empresa.

Si tu negocio necesita poder demostrar qué aceptó un cliente, qué versión estaba vigente y cuándo ocurrió, escríbenos: lo integramos contigo sobre la API de Sellat.

Y si tu tienda funciona con WooCommerce, estamos preparando un plugin que hace esto sin escribir código: escríbenos también y te avisamos cuando esté disponible.