Referencia

Qué guardamos sobre un dominio

Escrito para abogados y delegados de protección de datos. Cada término técnico se explica donde aparece por primera vez.

Esta página responde por completo a una pregunta: si MachineWitness observa un dominio, ¿qué acaba exactamente en el archivo? No un resumen, sino los campos reales. Recorremos un ejemplo resuelto, beispielfirma.example, desde el momento en que nuestro observador se conecta hasta el punto en que un tribunal podría verificar el registro años después.

Antes de recuperar cualquiera de los archivos que siguen, leemos el robots.txt del dominio y lo obedecemos. Cuando nos indica que no recuperemos un archivo, no lo recuperamos, y el registro lo hace constar: la observación de ese día se registra como disallowed_by_robots, con la procedencia policy: robots_respected, en lugar de una respuesta. Esa es una afirmación distinta de la de un servidor que no contestó, y el archivo mantiene ambas separadas. El 10 de agosto de 2026 esto afectó a unos 14.000 de los 128.347 dominios del anillo, para los tres archivos distintos del propio robots.txt. Podríamos recuperarlos igualmente (los archivos son públicos), y no lo hacemos. Cómo se lee un robots.txt está a su vez fechado: hasta el 8 de septiembre de 2026 ambos testigos lo interpretaban con urllib.robotparser de Python, anterior a RFC 9309; el testigo 2 lo lee conforme a RFC 9309 (protego) desde el 9 de septiembre de 2026, y el testigo 1 desde el 11 de septiembre de 2026. Los dos analizadores difieren solo en casos límite (comodines, prioridad de la coincidencia más larga); el archivo registrado es el mismo en ambos casos, únicamente puede diferir en esos días la decisión de recuperar o no los demás archivos.

Dos precisiones antes del detalle. Primera: solo recuperamos lo que cualquier navegador puede recuperar sin iniciar sesión, un puñado de pequeños archivos de política que un sitio publica para que las máquinas los lean. No rastreamos el contenido de las páginas, no seguimos enlaces hacia aplicaciones y no registramos nada sobre las personas que visitan un sitio. Segunda: nada de esto es secreto. El valor de este archivo no está en qué contiene (cualquiera podría recuperarlo hoy por sí mismo), sino en que lo tuvimos en una fecha pasada concreta y podemos acreditar que el registro no ha sido alterado desde entonces.

1. Qué recuperamos por dominio

Cinco peticiones. Nada más, nunca, para un dominio de nuestro anillo amplio.

Recurso	Qué es y por qué importa jurídicamente
/robots.txt	El archivo de instrucciones legible por máquinas más antiguo de la web. Indica a rastreadores nombrados qué partes de un sitio pueden recuperar. Dado que las empresas de IA publican los nombres de sus rastreadores (GPTBot, ClaudeBot, Google-Extended y otros), este archivo es donde la mayoría de los sitios expresa, o deja de expresar, una negativa al entrenamiento de IA.
/ai.txt	Una convención más reciente, específica para IA, con el mismo fin. Todavía no está normalizada, y precisamente por eso su presencia o ausencia en una fecha dada puede discutirse más adelante.
/.well-known/tdmrep.json	La reserva formal y legible por máquinas de los derechos frente a la minería de textos y datos (TDM Reservation Protocol, W3C). Conforme al art. 4.3 de la Directiva de la UE sobre derechos de autor en el mercado único digital, la reserva del titular solo es eficaz si es legible por máquinas; el Tribunal Superior Regional de Hamburgo confirmó en diciembre de 2025 que unas condiciones en lenguaje natural no bastan por sí solas. Este archivo es la vía más limpia para formular esa reserva.
/llms.txt	Una convención emergente dirigida directamente a los grandes modelos de lenguaje.
/ (página de inicio)	Se recupera solo por sus cabeceras de respuesta y los primeros kilobytes, nunca la página completa. Algunos sitios expresan su reserva TDM en una cabecera HTTP o en una etiqueta meta en lugar de en un archivo.

Cada respuesta está limitada por un tope estricto de bytes. Estos archivos ocupan normalmente unos pocos kilobytes; el tope existe para que un servidor mal configurado no pueda hacernos descargar algo grande.

Cambio de método, en vigor desde el 3 de agosto de 2026

Desde ese día el archivo aplica las reglas siguientes. Se enuncian aquí en lugar de darse por supuestas, porque un cambio de método cambia aquello para lo que sirve un registro de una fecha determinada. Nada anterior al 3 de agosto de 2026 se modificó; los días anteriores conservan el método vigente cuando se sellaron.

Dos anillos. Las reglas difieren entre un anillo central pequeño y un anillo amplio grande. El anillo amplio se define por un criterio declarado, no por selección: todos los dominios de la UE incluidos en la lista Tranco top-1M, tal como se obtuvo el 2 de agosto de 2026. El anillo central es un conjunto mucho menor de dominios observados más de cerca. Se compone a mano y todavía no publicamos criterios para él, de modo que debe leerse como una selección de trabajo y no como un registro curado.

Los cuatro archivos de reserva se siguen recuperando a diario para cada dominio. Esa es la parte con peso jurídico, y no ha cambiado.
La página de inicio se recupera semanalmente, no a diario, para los dominios del anillo amplio. La consecuencia honesta: cuando un sitio expresa su reserva únicamente en una etiqueta meta o una cabecera HTTP de la página de inicio, nuestro registro en el anillo amplio de esa reserva es preciso a la semana, no al día. Para el anillo central nada cambia: allí la página de inicio se sigue recuperando a diario.
Los topes de bytes difieren según el anillo. Anillo central: sin tope. Anillo amplio: 256 KB, y lo que exceda se marca como truncated. Lo que se conserva es siempre el comienzo de la respuesta, que es donde viven estas señales.
Las respuestas de error se registran sin su cuerpo. Se conservan el código de estado, todas las cabeceras, el tamaño y el hash del contenido, de modo que el hecho y la forma del error siguen siendo acreditables; la página de error en sí no se guarda. Una excepción: los cuerpos de 403 Forbidden se conservan hasta 32 KB, porque a veces la negativa dirigida a los rastreadores se formula en esa página.

Cambio de método, en vigor desde el 17 de septiembre de 2026

Desde ese día el registro crece en tres puntos. Como antes, nada anterior se modificó: los días previos al 17 de septiembre de 2026 conservan el método vigente cuando se sellaron. El primer rastreo con el nuevo alcance comenzó el 17 de septiembre de 2026 a las 03:00 UTC.

El anillo central tiene ahora un criterio declarado. Hasta el 16 de septiembre de 2026 era una selección de trabajo de 115 dominios, compuesta a mano. Desde el 17 de septiembre contiene 1.133 dominios, formados así: 1.057 dominios de organizaciones de la UE que publican, registradas en Wikidata con un sitio web activo, ya sean periódicos y sitios de noticias, radiodifusores, editoriales de libros, agencias de noticias y agencias fotográficas o entidades de gestión colectiva, y cuyo sitio llevaba al mismo tiempo una señal dirigida a los rastreadores de IA que ya habíamos observado: una regla para un bot de IA nombrado en robots.txt o una cabecera Content-Signal. Se reparten en 26 Estados miembros. A ellos se suman 43 editores más registrados en Wikidata que ya estaban en el anillo y no llevan tal señal; 14 dominios conservados de la selección anterior por un motivo declarado; 4 dominios que llevan tal señal pero no tienen entrada en Wikidata; y los 15 dominios de la propia empresa del operador, mantenidos como serie de control y no ocultos. Para cada dominio central el registro nombra ahora la organización, su país y su identificador de Wikidata. Cuando Wikidata atribuye un dominio a más de una organización, se tomó la etiqueta más corta y la entrada queda marcada como no resuelta (61 dominios), para corregirla conforme avance la curación; el dominio mismo no se ve afectado. Las reglas del anillo central del 3 de agosto de 2026, página de inicio a diario y sin tope de bytes, se aplican a todos ellos desde el 17 de septiembre. El anillo amplio no cambia. Un dominio de la propia empresa del operador que ya no resuelve en el DNS se retiró del anillo ese mismo día, y se añadieron otros tres; el manifiesto del anillo de esa fecha enumera cada dominio con su anillo.

Declaraciones de los operadores. Para cada uno de 13 operadores de rastreadores (AI2, Amazon, Anthropic, Apple, Cohere, Common Crawl, Diffbot, DuckDuckGo, Google, Microsoft, Mistral, OpenAI, Perplexity) se recuperan a diario, sin tope de bytes, las declaraciones que el propio operador publica sobre sus rastreadores, la página de documentación y los rangos de IP publicados (JSON), y se les aplica hash, sellado y anclaje como a cualquier otro artefacto: 26 direcciones. No se comprueba si algún acceso procedió realmente de esos rangos; se atestigua únicamente lo que el operador declaró el día T. Donde existía una redirección se registra el destino, para que la procedencia acompañe al documento y no a la redirección. Se dejan fuera, con el motivo declarado, las páginas que no entregan nada a un cliente sin navegador (la documentación de rastreadores de Meta), porque un envoltorio vacío no prueba nada.

Declaraciones de los proveedores. Por el mismo mecanismo, las políticas de uso, las condiciones y las políticas de rastreo publicadas por 12 de esos operadores (AI2, Amazon, Anthropic, Apple, Cohere, Common Crawl, Diffbot, DuckDuckGo, Google, Meta, Microsoft, Mistral): 32 direcciones, a diario, sin tope de bytes. Dos operadores, OpenAI y Perplexity, no entregan estas páginas a un cliente que no sea un navegador; sus condiciones no están, por tanto, en el registro, y lo decimos aquí en lugar de llenar el hueco por otros medios. En conjunto son la contraparte de los archivos de reserva: qué había reservado un sitio el día T, y qué había declarado el operador ese mismo día sobre su propia conducta. Nada se valora: el registro conserva el texto, no un juicio sobre él.

2. Qué contiene una observación

Una observación es un registro de un recurso en un momento. Esta es una completa para nuestro dominio de ejemplo, en la forma en que el archivo la guarda.

El contenido en sí

GET https://beispielfirma.example/robots.txt
→ HTTP 200, 412 bytes

User-agent: *
Allow: /

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

Exactamente los bytes que entregó el servidor, guardados sin alterar y comprimidos. No nuestro resumen de ellos, ni una representación: los bytes. En un conflicto la pregunta nunca es «qué dice el archivo», sino «qué decía el 14 de agosto de 2027».

La huella

payload_sha256 = 9f2a41d7c8e05b3a…7d1e6084bb93c2f5
payload_size   = 412 bytes

Un hash SHA-256 es un código corto de longitud fija calculado a partir de los bytes exactos de un archivo. Si cambia un solo carácter el código cambia por completo, y es computacionalmente inviable construir un archivo distinto con el mismo código. Funciona como la huella de una versión concreta de un documento. Es además el número de expediente: el contenido se guarda bajo su propia huella, de modo que nada puede sustituirse sin que la etiqueta deje de coincidir.

Las circunstancias de la entrega

observed_at   = 2027-08-14 03:00:11 UTC
observer_id   = witness-1
status_code   = 200
final_url     = https://www.beispielfirma.example/robots.txt   (tras redirección)
http_version  = HTTP/1.1
headers       = content-type: text/plain; charset=UTF-8
                cache-control: max-age=600
                x-served-by: cache-fra-…
                (cabeceras completas de la respuesta, literales)
tls_version   = TLSv1.3
peer_cert     = subject:  *.beispielfirma.example
                issuer:   GlobalSign Atlas R3 DV TLS CA
                valid:    2027-06-01 → 2028-06-01
                sha256:   3b8c07f2ad91…e5240ac71f6b88
                (huella del certificado del servidor,
                 más los cinco campos extraídos arriba)
peer_cert_chain = 3b8c07f2ad91…e5240ac71f6b88   (certificado del servidor)
                6f1d0ba47c33…9a7e1c40db2f51   (intermedio)
                c04e83fa1d67…2b95e7708aa361   (intermedio)
                (la cadena tal como la entregó el servidor, en ese
                 orden; cada certificado guardado íntegro)
observer_addr = la dirección IP desde la que conectó nuestro observador
peer_addr     = la dirección IP que respondió

Esto es lo que los juristas llaman cadena de custodia: no solo «este archivo existió», sino «este servidor, presentando este certificado TLS, entregó estos bytes a este observador en este momento». El certificado TLS importa porque vincula la entrega con alguien que pudo obtener un certificado para ese dominio. Todo ello se sella junto con el contenido, de modo que ninguna parte pueda sustituirse después.

Qué se registra aquí exactamente y qué no. Desde el 15 de septiembre de 2026 guardamos la cadena de certificados completa tal como la entrega el servidor: el certificado del servidor y los intermedios que lo acompañan, cada uno íntegro, con las huellas registradas en el orden en que llegaron. No es una cadena reconstruida contra nuestro propio almacén de confianza: un testigo registra lo que se le entregó, y si esa cadena valida o no es la pregunta del examinador, no la nuestra. Junto a ella seguimos registrando la huella SHA-256 del certificado del servidor y los cinco campos extraídos que se muestran arriba.

El cambio no obra hacia atrás. Para las observaciones anteriores al 15 de septiembre de 2026 existe solo la huella, no el certificado; cuando se necesita ese certificado, por lo general puede obtenerse de forma independiente en los registros públicos de Certificate Transparency (RFC 6962), la misma infraestructura de auditoría en la que se apoyan los navegadores. Los datos antiguos conservan el estado que tenían entonces y no se rellenan después. Con ello queda cumplida la promesa que esta página venía haciendo desde el 1 de agosto de 2026.

La marca de cambio

changed = true   (la huella difiere de la observación anterior)

Se activa cuando la huella de hoy difiere de la de ayer para el mismo recurso. Es la razón de ser de este archivo: estos archivos cambian en silencio, sin historial público, y el cambio en sí es a menudo el hecho controvertido.

3. Cómo se ve un archivo ausente

El registro de que «allí no había nada» también es prueba, y se anota con el mismo cuidado que un contenido. Si nuestro dominio de ejemplo no sirve ningún ai.txt:

GET https://beispielfirma.example/ai.txt
→ HTTP 404, no se guarda contenido
   estado, cabeceras completas, huella del contenido y
   datos TLS registrados como arriba

Esta distinción tiene peso real. «El sitio no había publicado ninguna reserva de IA legible por máquinas en esa fecha» es con frecuencia el hecho decisivo en un conflicto TDM, y solo puede acreditarlo alguien que miró y dejó escrito que no encontró nada. Otros dos casos se registran con la misma claridad: un servidor que rechaza a nuestro observador (HTTP 403) produce un registro del rechazo, no de un contenido; y un recurso que el propio robots.txt de un sitio nos indica no recuperar se registra como deliberadamente no recuperado. Cumplimos esa indicación y dejamos constancia de haberlo hecho.

4. Cómo se sella el registro

Un archivo llevado por una parte interesada acredita poco por sí solo: en principio podríamos reescribir nuestra propia base de datos. Cuatro pasos responden a esa objeción, cada uno independiente de los demás.

Paso 1 · el mismo día

Todas las observaciones del día se atan a una sola cifra

Todas las huellas registradas ese día se combinan por pares, nivel a nivel, hasta que queda una única raíz diaria que depende de cada registro que hay debajo. Si después se altera una sola observación, la raíz deja de cuadrar. Es la construcción que emplean los registros públicos en los que se apoyan los navegadores para auditar certificados TLS (RFC 6962).

Paso 2 · presentada el mismo día

Esa cifra se deposita fuera de nuestro control

La raíz diaria se presenta el mismo día a OpenTimestamps, que la agrega hacia la cadena de bloques de Bitcoin, y por separado a una autoridad independiente de sellado de tiempo conforme a RFC 3161, que devuelve de inmediato un token firmado. Desde el 31 de julio de 2026 se obtiene además un sello de tiempo cualificado conforme a eIDAS. No podemos reescribir ninguno de ellos. Eso eleva el sello de una afirmación interna a una prueba externa: acredita que el registro existía a más tardar ese día.

Estado del anclaje en Bitcoin: completado el 7 de agosto de 2026. Las dos autoridades de sellado devuelven su prueba de inmediato, y esos tokens están aquí. OpenTimestamps trabaja en dos fases: la raíz se presenta enseguida, pero el recibo resultante solo se sostiene por sí mismo cuando la confirmación de Bitcoin se incorpora de vuelta a él. Hasta el 7 de agosto de 2026 no habíamos realizado ese segundo paso, y una versión anterior de este pasaje así lo decía. Ya se ha realizado para todos los días sellados en ambos testigos, y un proceso diario lo ejecuta desde entonces, de modo que los recibos aquí guardados remiten a cabeceras de bloque de Bitcoin y no a servidores de calendario. El paso modificó los recibos, pero no lo que atestiguan: el hash que cada recibo acredita se registró antes y después y es idéntico para todos los días. La vía de Bitcoin ya no depende de que esos servidores de calendario sigan accesibles. Los anclajes RFC 3161 y eIDAS cualificado no se vieron afectados en ningún momento y se sostienen por sí solos.

Paso 3 · el mismo día

La raíz se publica

Cada raíz diaria aparece en nuestro registro público de raíces, con URL estables y en forma legible por máquinas. Cualquiera puede guardar su propia copia el día en que aparece; varios sistemas ajenos la capturan de forma automática.

Paso 4 · en funcionamiento desde el 04-08-2026

Un segundo testigo independiente observa los mismos objetivos

Un sistema separado, sobre infraestructura distinta en otro país y con una clave de operador distinta, registra de forma independiente y publica su propia raíz diaria. Ninguna de las dos máquinas guarda credenciales de la otra y ninguna puede escribir en la base de datos de la otra. Dos relatos llevados de forma independiente son más difíciles de descartar que un testigo repitiéndose.

Dos límites, dichos con claridad. Primero, esto comenzó el 4 de agosto de 2026: todos los días sellados entre el 22 de julio y el 3 de agosto de 2026 se apoyan solo en el primer testigo, y el registro público muestra esa laguna en lugar de ocultarla. Segundo, las dos raíces diarias nunca son idénticas, por construcción: cada testigo rastrea según su propio calendario, de modo que el conjunto de observaciones tras cada raíz difiere. La comparación se hace por tanto observación a observación, y no comprobando si dos raíces coinciden; unas raíces idénticas indicarían, de hecho, que los dos sistemas no son independientes.

5. Qué contiene un extracto probatorio

El archivo no es navegable, por diseño. Lo que elaboramos a petición, para un dominio y un intervalo de fechas concretos, es un extracto probatorio: un paquete que contiene

el contenido guardado de cada observación del intervalo, byte por byte;
las circunstancias selladas completas de la entrega, tal como se exponen en el apartado 2;
la huella de cada observación;
una prueba de inclusión: un recibo matemático breve que demuestra que esa observación concreta está contenida en la raíz de ese día, comprobable sin confiar en nosotros y sin acceso al resto del archivo;
la raíz diaria y los recibos de los sellos de tiempo externos;
instrucciones de verificación paso a paso que cualquier perito competente puede seguir con herramientas estándar.

Conviene decir sin rodeos el sentido del último punto: el extracto está diseñado para que el perito de la parte contraria pueda verificarlo. Un registro que solo una parte puede comprobar no es prueba.

Cómo se solicita, en qué condiciones se expide y cuánto cuesta figura en la página de extracto probatorio. Si este archivo observa o no un dominio determinado puede comprobarse antes, sin coste, con la comprobación de cobertura.

6. Si alguien nos pide suprimir

La mayor parte de lo que guardamos no contiene datos personales: son archivos técnicos de política publicados por organizaciones. Cuando una solicitud de supresión fundada conforme al art. 17 del RGPD sí afecta a contenido archivado, ejecutamos lo que llamamos una lápida: el contenido guardado se borra y se sustituye por un marcador. Borrado significa borrado, y ninguna copia de seguridad lo restituye.

Lo que permanece es la huella, el sello y las pruebas. Conviene entender la consecuencia con precisión: después, nadie puede saber qué decía el archivo, pero sigue siendo acreditable que un archivo con exactamente esta huella estuvo en esta dirección en esta fecha, y que los registros circundantes de ese día están intactos. Conservar la huella se ampara en el art. 17.3.e del RGPD, porque borrarla rompería la cadena probatoria de todas las demás observaciones selladas ese día, incluidas las de terceros ajenos.

A petición también excluimos un dominio de toda observación futura, con o sin supresión. Ambas cosas son gratuitas y ninguna necesita motivo. Para una exclusión sí le pedimos que acredite que controla el dominio: un registro DNS TXT, o un archivo en una ruta que le indicaremos, lo que le resulte más cómodo. No porque la solicitud deba justificarse, sino porque una exclusión pedida por otra persona sacaría un dominio del registro sin que su titular llegara a saberlo. Una supresión conforme al art. 17 del RGPD no lleva ese paso: ahí solo pedimos identificación cuando existe una duda real. Véanse Privacidad y Rastreador y contacto.

7. Qué no acredita este registro

Enunciar los límites con precisión forma parte de ser un testigo creíble.

Muestra lo que un servidor entregó a nuestro observador, en los momentos registrados. No dice nada sobre los intervalos entre observaciones, ni sobre lo que vieron otros visitantes.
Muestra el contenido y las circunstancias de la entrega, no la autoría, la intención ni la licitud. Si una reserva era eficaz, si un rastreador la respetó y qué se sigue de ello en Derecho son cuestiones para los letrados y el tribunal.
El anclaje externo acredita que un registro existía a más tardar en la fecha de su anclaje. No acredita nada sobre fechas anteriores.
Un archivo ausente acredita que el recurso no estaba en esa dirección en ese momento, no que el titular nunca reservara derechos por otra vía.
Registramos declaraciones públicas y legibles por máquinas hechas por organizaciones. No observamos datos privados, ni comportamiento de usuarios, ni personas físicas.

Somos la caja negra, no el investigador. Lo que el registro significa que lo discutan otros.

El ejemplo anterior está construido a efectos ilustrativos. Se añadirá un extracto resuelto con un dominio real, verificable contra el registro público de raíces, cuando ese dominio haya acumulado un historial de observación significativo.