Robots.txt e addestramento AI: un segnale solo per dire no (e le maledizioni dei copisti)

Il 30 ottobre OpenAI ha annunciato che rispetterà un segnale robots.txt condiviso con cui i gestori dei siti comunicano le loro preferenze sull'addestramento AI ai fornitori che aderiscono. Per chi ha un sito aziendale, e quindi cataloghi, schede e articoli che un modello potrebbe leggere, è una notizia che merita cinque minuti. Ma attenzione a cosa promette e a cosa no.

Cosa è successo, senza ricamare

Il comunicato di OpenAI, nella sintesi pubblicata sul suo feed, dice che l'azienda onorerà un segnale robots.txt condiviso, pensato per far dichiarare a un sito le proprie preferenze una volta sola. Per i dettagli tecnici e i tempi conviene guardare la pagina ufficiale, che quando ho controllato non era leggibile da tutti i client: non riporto quindi nulla che non abbia potuto verificare.

La base tecnica, invece, è pubblica. Lo stesso 30 ottobre è comparsa nel registro dell'IETF una bozza individuale, Machine-Readable Training Preference Signal, firmata da Kevin Kelley di Anthropic. Il documento precisa di non essere approvato dall'IETF e di non avere "valore formale". Scade il 3 maggio 2027.

Come funzionerebbe

Il robots.txt è il file in cui un sito dà indicazioni ai programmi che lo visitano, secondo il Robots Exclusion Protocol (RFC 9309). La bozza non inventa nuove regole: usa un gruppo "User-Agent" con un nome speciale, __usage_ai-training. Un esempio dalla bozza:

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

Significa: preferisco che nessun contenuto serva ad addestrare un'AI, tranne la cartella /press-kit/. Un dettaglio utile: i gruppi generici con User-Agent: * non valgono per questo segnale, va scritto in modo esplicito. Il lavoro di standardizzazione più ampio è quello del gruppo AI Preferences dell'IETF, che si occupa di vocabolario e modi per associare le preferenze ai contenuti.

Cosa non garantisce

• Non è uno standard. È una bozza individuale, e il vocabolario può cambiare.
• È volontario. Lo stesso RFC 9309 ricorda che queste regole "non sono una forma di autorizzazione all'accesso".
• Non è una regola di scansione. Per limitare i singoli programmi di scansione servono ancora i loro gruppi specifici.
• Accordi privati possono prevalere, dice la bozza.
• Dei dati già raccolti non dice nulla: non è una cancellazione.

Il caso medievale: la maledizione in fondo al libro

E voi direte: ma cosa c'entra il Medioevo? C'entra. Quando un libro costava mesi di lavoro di un copista, il modo di proteggerlo era scrivere, di solito in fondo, nel colophon, una maledizione: chi lo ruba sia scomunicato, sia colpito dall'anatema. Ne sono sopravvissute centinaia; la più antica citata dalle raccolte viene dal monastero di San Gallo, nell'880, e un'altra chiude una Bibbia del 1172 oggi alla British Library. Marc Drogin ne raccolse moltissime nel libro Anathema! (1983). Attenzione però: la celebre maledizione "di San Pedro di Barcellona" è una burla novecentesca.

Il punto è questo: la maledizione era una dichiarazione di preferenza, scritta nel posto dove la leggeva chi apriva il libro. Funzionava con chi rispettava la Chiesa, non con chi non la temeva. Ecco, il vostro robots.txt oggi è in quel colophon: dice cosa preferite, ma non mette un lucchetto. Per i dati davvero riservati servono accessi protetti, non un'etichetta.