Robots.txt y entrenamiento de IA: una sola señal para decir no (y las maldiciones de los copistas)

El 30 de octubre OpenAI anunció que respetará una señal robots.txt compartida con la que los responsables de un sitio comunican sus preferencias sobre el entrenamiento de IA a los proveedores que se adhieran. Si tienes una web de empresa, con catálogos, fichas y artículos que un modelo podría leer, merece cinco minutos. Pero ojo con lo que promete y lo que no.

Qué ha pasado, sin adornos

El comunicado de OpenAI, en el resumen de su propio feed, dice que la empresa respetará una señal robots.txt compartida, pensada para que un sitio declare sus preferencias una sola vez. Para los detalles técnicos y los plazos conviene mirar la página oficial, que cuando la consulté no era legible para todos los clientes: por eso no cuento nada que no haya podido verificar.

La base técnica, en cambio, es pública. Ese mismo 30 de octubre apareció en el registro del IETF un borrador individual, Machine-Readable Training Preference Signal, firmado por Kevin Kelley, de Anthropic. El documento aclara que no está respaldado por el IETF y no tiene valor formal. Caduca el 3 de mayo de 2027.

Cómo funcionaría

El robots.txt es el archivo donde un sitio da indicaciones a los programas que lo visitan, según el Protocolo de Exclusión de Robots (RFC 9309). El borrador no inventa reglas nuevas: usa un grupo "User-Agent" con un nombre especial, __usage_ai-training. Un ejemplo del borrador:

User-Agent: __usage_ai-training
Disallow: /
Allow: /press-kit/

Significa: prefiero que ningún contenido sirva para entrenar una IA, salvo la carpeta /press-kit/. Un detalle útil: los grupos genéricos User-Agent: * no valen para esta señal; hay que escribirla de forma explícita. El trabajo de estandarización más amplio corresponde al grupo AI Preferences del IETF, que se ocupa del vocabulario y de cómo asociar preferencias a los contenidos.

Lo que no garantiza

• No es un estándar. Es un borrador individual y el vocabulario puede cambiar.
• Es voluntario. El propio RFC 9309 recuerda que estas reglas "no son una forma de autorización de acceso".
• No es una regla de rastreo. Para limitar rastreadores concretos siguen haciendo falta sus grupos específicos.
• Los acuerdos privados pueden prevalecer, dice el borrador.
• No dice nada de los datos ya recogidos: no es un borrado.

El caso medieval: la maldición al final del libro

Y diréis: ¿qué pinta aquí la Edad Media? Pinta. Cuando un libro costaba meses de trabajo a un copista, la forma de protegerlo era escribir, normalmente al final, en el colofón, una maldición: quien lo robe, que sea excomulgado, herido por el anatema. Se conservan cientos; la más antigua citada en las colecciones procede del monasterio de San Galo, en el año 880, y otra cierra una Biblia de 1172 que hoy está en la British Library. Marc Drogin reunió muchas en Anathema! (1983). Cuidado, eso sí: la famosa maldición "de San Pedro de Barcelona" es una broma del siglo XX.

La clave es esta: la maldición era una declaración de preferencia, escrita donde la leía quien abría el libro. Funcionaba con quien respetaba a la Iglesia, no con quien no la temía. Pues bien, vuestro robots.txt de hoy está en ese colofón: dice lo que preferís, pero no pone un candado. Para los datos realmente reservados hacen falta accesos protegidos, no una etiqueta.