Gary Illyes spiega perché il protocollo RFC 9309 non blocca l'IA

Immaginate di aver installato una serratura elettronica sulla porta del vostro archivio aziendale. Avete impostato le regole: chi può entrare e chi deve restare fuori. Un giorno vi accorgete che, nonostante la porta sia chiusa per alcuni, i documenti contenuti all'interno sono stati fotografati, copiati e utilizzati per addestrare un modello di intelligenza artificiale concorrente. La vostra reazione naturale sarebbe quella di pensare che la serratura sia stata scassinata. In realtà, secondo l'interpretazione tecnica di Google, la serratura ha funzionato perfettamente: ha regolato chi è entrato nella stanza, ma non ha mai avuto il potere di vietare cosa fare dei documenti una volta che qualcuno, legittimamente o meno, li ha portati fuori.

L'equivoco del protocollo RFC 9309 e l'accesso ai dati

Il cuore del problema risiede in un malinteso tecnico su cosa sia effettivamente il file robots.txt. Gary Illyes, figura chiave di Google Search Relations, ha chiarito in un recente episodio della serie video The Non-Canonical Cabinet che il protocollo, come definito dallo standard RFC 9309, è esclusivamente un 'access preference protocol'.

Cosa significa per un imprenditore che gestisce asset digitali? Significa che il robots.txt dice a un crawler se può richiedere determinati URL, ma non ha alcuna autorità su ciò che accade al contenuto dopo che è stato raccolto. Il protocollo non detta le regole sull'utilizzo dei dati post-crawling. Se un bot è autorizzato a visitare una pagina, l'atto di 'leggere' il contenuto è l'obiettivo; ciò che l'azienda proprietaria del bot farà di quel testo — che sia indicizzarlo per un motore di ricerca o usarlo per il training di un LLM — esula completamente dall'ambito di applicazione dell'RFC 9309.

Analisi strategica: Questo crea un vuoto normativo tecnico. Molte aziende credono che bloccare il crawling sia equivalente a proteggere la proprietà intellettuale dall'IA. In realtà, stanno solo gestendo il traffico di rete. Se i dati sono già stati raccolti in precedenza o se il bot ha l'accesso, il robots.txt non offre alcuna protezione legale o tecnica sull'uso dei dati per l'addestramento.

Gary Illyes e il cabinet delle eccezioni tecniche

Gary Illyes non è un semplice portavoce, ma un tecnico che opera nell'intersezione tra l'indicizzazione del web e le nuove frontiere dell'IA. Insieme a Cherry Prommawin, conduce The Non-Canonical Cabinet, un format dove le domande 'edge-case' della community vengono analizzate per smontare i miti della SEO moderna.

Il ruolo di Illyes è diventato cruciale perché non si limita a spiegare le regole esistenti, ma sta attivamente cercando di scriverne di nuove. Il fatto che sia co-autore, insieme a Martin Thomson di Mozilla, di un Internet-Draft presso l'IETF (Internet Engineering Task Force) indica che Google è consapevole dell'insufficienza degli strumenti attuali. Il loro obiettivo è introdurre un modo standardizzato per dichiarare le preferenze d'uso dei contenuti all'interno del robots.txt, colmando finalmente il gap tra 'accesso' e 'utilizzo'.

Perché le regole custom e le emoji falliscono

Esiste una tendenza tra i proprietari di siti a tentare di 'comunicare' con i bot attraverso linguaggi creativi o istruzioni non standard. Alcuni inseriscono emoji (come il simbolo di divieto ⛔), ASCII art o direttive inventate per chiedere ai bot di non usare i dati per l'IA.

La realtà tecnica è brutale: queste istruzioni vengono ignorate. Il sistema di parsing di Google e di altri crawler segue rigorosamente quattro elementi supportati:

• User-Agent: identifica il bot a cui è rivolta la regola.
• Allow: indica quali parti del sito sono accessibili.
• Disallow: indica quali parti sono vietate.
• Sitemap: indica la posizione della mappa del sito.

Qualsiasi altra riga, inclusa una ipotetica direttiva come 'No-AI-Chicken-Training' (esempio usato nel video di Google), viene semplicemente scartata. Il parser non restituisce un errore; elimina silenziosamente la riga e procede. Se volete tenere fuori un crawler di IA specifico, l'unica strada percorribile è targetizzare esplicitamente il suo user-agent token. Se non conoscete il token esatto, il vostro tentativo di blocco è nullo.

Un ulteriore dettaglio tecnico riguarda l'internazionalizzazione: Cherry Prommawin ha raccomandato di scrivere i percorsi delle regole non in lingua inglese utilizzando la 'percent-encoding'. Senza questa codifica, molti crawler, eccetto quelli di Google, potrebbero non interpretare correttamente i percorsi, rendendo le regole di blocco inefficaci.

Il nuovo standard per le preferenze di utilizzo

Poiché l'RFC 9309 permette ai crawler di decidere autonomamente come processare i record che cadono fuori dallo scope del protocollo, l'attuale ecosistema è frammentato. Ogni azienda di IA decide cosa rispettare e cosa ignorare.

Il progetto IETF guidato da Illyes e Thomson mira a trasformare il robots.txt da semplice 'vigile urbano' a 'contratto di utilizzo'. L'idea è di aggiungere regole standardizzate che permettano ai proprietari dei siti di esprimere preferenze esplicite sull'uso dei dati per l'IA. Questo sposterebbe il piano dal tecnico al normativo: una volta che esiste uno standard, l'inosservanza di tale standard potrebbe avere implicazioni legali più pesanti rispetto all'attuale ignoranza di una riga di testo non standard.

Analisi di business: Per le imprese, questo significa che l'attuale strategia di 'difesa' dei contenuti è temporanea. Il vero punto di svolta sarà l'adozione di questo nuovo standard. Le aziende dovranno decidere se chiudere completamente i rubinetti dei dati (perdendo visibilità nei motori di ricerca AI) o negoziare l'accesso attraverso questi nuovi protocolli.

Proprietà intellettuale tra AI Act e crawler

L'analisi di Google mette in luce una vulnerabilità sistemica per le imprese europee. Mentre l'AI Act dell'Unione Europea introduce obblighi di trasparenza sui dati utilizzati per l'addestramento dei modelli, lo strumento tecnico per impedire tale raccolta (il robots.txt) è strutturalmente inadeguato.

In Italia e in Europa, le imprese si trovano in una posizione di asimmetria informativa. Se un crawler di un'IA straniera ignora le preferenze non standard di un sito italiano, l'impresa ha pochi strumenti tecnici per impedirlo in tempo reale, se non il blocco totale dell'IP o l'uso di firewall avanzati che però rischiano di penalizzare l'indicizzazione organica.

Il rischio è che l'AI Act fornisca una protezione legale 'ex post' (possibilità di sanzionare o chiedere la rimozione), ma non una protezione tecnica 'ex ante'. La dipendenza da standard gestiti da entità come l'IETF o influenzati da giganti come Google e Mozilla rende la sovranità dei dati aziendali estremamente fragile.

Per monitorare l'evoluzione di questo scenario, gli imprenditori dovrebbero osservare tre indicatori verificabili:

1. La pubblicazione ufficiale del draft IETF sulle preferenze d'uso dell'IA (data di rilascio della specifica finale).
2. L'integrazione di queste nuove direttive nei termini di servizio di Google e OpenAI.
3. L'eventuale inserimento di requisiti tecnici di 'opt-out' standardizzati all'interno delle linee guida applicative dell'AI Act.

Sintesi tecnica per il management

In definitiva, la lezione di Gary Illyes è un monito: non affidate la vostra proprietà intellettuale a 'trucchi' nel file robots.txt. La protezione dei dati nell'era dell'IA richiede una strategia che vada oltre la semplice configurazione di un file di testo, spostandosi verso una gestione consapevole degli user-agent e un'attenzione costante agli standard internazionali di rete.

Domande frequenti

Fonti: Searchenginejournal, Semasocial, Ppc ·