llms.txt sostituisce robots.txt?

No. robots.txt controlla l'accesso dei crawler. llms.txt guida i LLM verso contenuti prioritari. Hanno funzioni complementari.

Tecnica | Irene Burresi

Q: Qual è la differenza tra SEO e GEO?

SEO ottimizza per liste di risultati dei motori di ricerca tradizionali. GEO ottimizza per essere citati nelle risposte sintetizzate dai motori generativi come ChatGPT e Perplexity.

Testing Non-Deterministico: Come si fa QA sugli Agenti?

Irene Burresi — Tue, 06 Jan 2026 00:00:00 GMT

Il problema: assert non basta più

Il 73% delle organizzazioni cita l’affidabilità come barriera principale al deploy di agenti in produzione. Non perché manchino i test, ma perché i test tradizionali non catturano i failure mode di sistemi che “improvvisano”.

TL;DR: Testare agenti AI richiede un cambio di paradigma. I test unitari tradizionali verificano output deterministici: dato input X, attendi output Y. Gli agenti generano output diversi a ogni esecuzione, usano tool in sequenze imprevedibili, falliscono in modi che non crashano ma producono risultati sbagliati. Servono nuove metodologie: property-based testing per definire invarianti invece di output attesi, LLM-as-judge per valutazione scalabile, red teaming automatizzato per sicurezza, fuzzing adattato per stress-testing. I framework esistono: DeepEval, Opik, LangSmith, DeepTeam, PyRIT. Chi li adotta prima del deploy evita i silent failure che emergono solo in produzione.

Un test unitario classico funziona così: chiami una funzione con input noti, verifichi che l’output corrisponda a un valore atteso. Se sum(2, 3) restituisce 5, il test passa. È deterministico, ripetibile, binario.

Ora prova a testare un agente che deve rispondere a “trova i ristoranti italiani aperti stasera vicino a me”. L’agente potrebbe chiamare un’API di geolocalizzazione, poi un servizio di ricerca locale, poi filtrare per orario. Oppure potrebbe cercare prima su Google Maps, poi verificare gli orari sui siti dei singoli ristoranti. Ogni esecuzione può produrre sequenze di azioni diverse, risultati diversi, formulazioni diverse della risposta finale.

Come scrivi un assertEquals() per questo?

Il problema non è solo la variabilità dell’output. È che i failure mode degli agenti sono fondamentalmente diversi da quelli del software tradizionale.

Un bug classico crasha o restituisce un errore. Un agente che “fallisce” potrebbe restituire una risposta perfettamente formattata, grammaticalmente corretta, apparentemente ragionevole, ma fattualmente sbagliata. Potrebbe scegliere tool inappropriati. Potrebbe allucinare informazioni. Potrebbe seguire un piano che sembra logico ma non risolve il task originale.

Il sistema non crasha. Non lancia eccezioni. Completa l’esecuzione. Solo che il risultato è sbagliato.

Questo è il cuore del problema: i test tradizionali non catturano i silent failure. E i silent failure sono la norma, non l’eccezione, nei sistemi agentici.

Tassonomia: cosa stai cercando di testare

Prima di scegliere metodologie, serve chiarire cosa significa “testare un agente”. Un paper del 2025 su arXiv propone una tassonomia bidimensionale che aiuta a orientarsi.

La prima dimensione riguarda l’oggetto della valutazione:

Behavior: L’agente si comporta come previsto? Segue le istruzioni? Rispetta i vincoli?

Capabilities: L’agente è in grado di completare determinati task? Quali classi di problemi risolve?

Reliability: L’agente produce risultati consistenti? Quanto varia la qualità tra esecuzioni?

Safety: L’agente evita azioni dannose? Resiste a tentativi di manipolazione? Protegge dati sensibili?

La seconda dimensione riguarda il processo di valutazione:

Offline evaluation: Test pre-deployment su dataset statici o ambienti simulati.

Online evaluation: Monitoraggio in produzione su traffico reale.

Component-level: Testare singoli pezzi (il retriever, il planner, il singolo tool).

End-to-end: Testare il sistema completo su task realistici.

La maggior parte delle organizzazioni si ferma alla valutazione offline delle capabilities su singoli componenti. È il minimo indispensabile, ma non basta. I bug più insidiosi emergono dalle interazioni tra componenti, dalla variabilità del comportamento su input diversi, dai casi limite che nessun dataset statico copre.

Property-based testing: invarianti invece di output

Il primo cambio di paradigma è passare da example-based testing a property-based testing.

Nell’example-based testing, definisci coppie input-output: “Se l’input è X, l’output deve essere Y”. Funziona quando l’output è deterministico e lo conosci in anticipo.

Nel property-based testing, definisci proprietà che devono valere per tutti gli input: “Per qualsiasi input valido, l’output deve soddisfare la condizione Z”. Non specifichi l’output esatto. Specifichi vincoli che l’output deve rispettare.

Per un agente, le proprietà potrebbero essere:

La risposta deve contenere solo informazioni presenti nei documenti di contesto (no hallucination)
Se il task richiede un calcolo numerico, il risultato deve essere matematicamente corretto
La sequenza di tool call deve terminare entro N step
Ogni tool call deve usare parametri nel formato corretto
La risposta finale deve essere nella lingua richiesta

Queste proprietà possono essere verificate automaticamente, indipendentemente dalla formulazione specifica dell’output.

In pratica, il test genera input casuali o semi-casuali, esegue l’agente, verifica che le proprietà siano soddisfatte. Se trova una violazione, riduce l’input al caso minimo che causa il fallimento.

Framework come Hypothesis (Python) supportano property-based testing. Per agenti, serve estenderli con proprietà specifiche del dominio e generatori di input che producono scenari realistici.

Un limite di questo approccio: non tutte le proprietà sono formalizzabili in modo verificabile automaticamente. “La risposta è utile” o “il tono è appropriato” richiedono giudizio semantico che le asserzioni booleane non catturano.

LLM-as-Judge: valutazione scalabile

Qui entra il pattern LLM-as-judge: usare un altro modello linguistico per valutare l’output dell’agente sotto test.

Il concetto è semplice. Invece di scrivere asserzioni programmatiche, definisci criteri di valutazione in linguaggio naturale. Un LLM evaluator riceve l’input, l’output dell’agente, i criteri, e produce un giudizio strutturato: score numerici, classificazioni, spiegazioni.

Questo pattern è alla base di diversi framework di evaluation. DeepEval offre metriche predefinite come G-Eval (valutazione generale), faithfulness (aderenza ai fatti), answer relevancy, contextual precision. Opik di Comet fornisce evaluation per workflow agentici multi-step, inclusa qualità del piano, aderenza al piano, efficienza degli step.

LangSmith di LangChain e Langfuse combinano tracing, logging e evaluation, permettendo di ispezionare ogni step dell’agente e valutare sia i componenti che il risultato finale. Databricks Mosaic AI Agent Evaluation integra evaluation con la piattaforma MLOps esistente.

Il vantaggio principale: scala. Puoi valutare migliaia di output senza annotatori umani per ogni caso. Puoi definire criteri complessi in linguaggio naturale invece che in codice.

I limiti sono altrettanto concreti:

Bias dell’evaluator: Il modello valutatore ha i suoi bias. Potrebbe preferire risposte verbose, o penalizzare formulazioni corrette ma non convenzionali. Studi mostrano che gli LLM tendono a preferire le proprie risposte rispetto a quelle di altri modelli.

Costo: Ogni valutazione richiede un’inference del modello evaluator. Su dataset grandi, i costi si accumulano.

Non sostituisce validazione umana: Per decisioni critiche (lancio in produzione, confronto tra approcci), serve comunque un campione validato da umani.

La pratica migliore è usare LLM-as-judge per screening su larga scala e validazione umana su campioni stratificati. Ricerche mostrano che questa combinazione identifica il 60-70% in più di problemi rispetto al testing ad hoc.

Metriche specifiche per agenti

Le metriche generiche di NLP (BLEU, ROUGE, perplexity) non catturano ciò che conta per gli agenti. Servono metriche progettate per valutare comportamenti agentici.

Task completion rate: L’agente ha completato il task assegnato? È la metrica primaria, ma richiede una definizione chiara di “completamento”. Per task oggettivi (estrai il prezzo dal documento) è binaria. Per task aperti (scrivi una email di risposta) richiede valutazione qualitativa.

Tool correctness: Ogni tool call è valida? I parametri sono nel formato corretto? Il tool chiamato è appropriato per lo step corrente?

Tool hallucination: L’agente ha chiamato tool che non esistono? Ha inventato parametri non previsti dall’API?

Plan quality: Il piano generato dall’agente è ragionevole? Copre tutti gli step necessari? È efficiente?

Plan adherence: L’agente ha seguito il piano che ha generato? O ha deviato in modo ingiustificato?

Step efficiency: Quanti step ha richiesto per completare il task? Rispetto a un baseline o a esecuzioni precedenti?

Recovery rate: Quando un tool fallisce o restituisce un errore, l’agente riesce a recuperare? Riprova? Cerca alternative?

Consistency: Dato lo stesso input ripetuto N volte, quanto varia l’output? La varianza è accettabile o indica instabilità?

Queste metriche richiedono strumentazione. Il sistema deve loggare ogni step, ogni tool call, ogni decisione del planner. Senza trace dettagliato, non puoi calcolarle.

Framework come Opik e LangSmith forniscono tracing automatico. Se usi framework custom, devi costruire il logging.

Red teaming: testare la sicurezza prima che lo facciano altri

Il red teaming è la pratica di attaccare deliberatamente il sistema per scoprire vulnerabilità prima che lo facciano attori malevoli. Per gli agenti AI, è particolarmente critico.

OWASP ha pubblicato a dicembre 2025 il Top 10 per applicazioni agentic. Le categorie principali includono:

Prompt injection: Input malevoli che inducono l’agente a ignorare le istruzioni originali o eseguire azioni non autorizzate. Può essere diretto (nell’input utente) o indiretto (nascosto nei dati che l’agente recupera).

Tool misuse: L’agente viene indotto a usare tool in modi non previsti: leggere file sensibili, inviare dati a endpoint esterni, eseguire codice arbitrario.

Memory leakage: Informazioni da sessioni o utenti precedenti che trapelano nelle risposte.

Privilege escalation: L’agente acquisisce permessi superiori a quelli previsti, spesso attraverso catene di tool call.

Il red teaming tradizionale è manuale: esperti di sicurezza tentano di violare il sistema usando creatività e conoscenza del dominio. È efficace ma non scala.

Il red teaming automatizzato usa LLM per generare attacchi. DeepTeam, sviluppato da Confident AI, genera automaticamente prompt di attacco per diverse categorie di vulnerabilità e valuta la robustezza del sistema. PyRIT di Microsoft è un framework open-source per red teaming di sistemi AI, con focus su generazione automatica di attacchi e reporting.

Enkrypt AI offre red teaming as a service con prompt dinamici che evolvono in base alle difese del sistema. Giskard combina red teaming con vulnerability scanning specifico per LLM.

Le best practice per enterprise raccomandano:

Red teaming prima di ogni release in produzione
Cadenza trimestrale per sistemi ad alto rischio
Test aggiuntivi dopo ogni cambio materiale: nuovo modello, nuovo tool, nuova fonte dati
Mappatura degli attacchi al framework MITRE ATLAS
Metriche tracciate: vulnerabilità scoperte per test, tempo di remediation, tasso di successo ai re-test

L’EU AI Act richiede red teaming documentato per sistemi ad alto rischio. Non è più opzionale per chi opera in Europa.

Fuzzing: stress-testing ai confini

Il fuzzing è una tecnica classica di security testing: bombardare il sistema con input invalidi, inattesi, casuali, per scoprire bug e vulnerabilità che il testing normale non trova.

Per software tradizionale, il fuzzing cerca crash, memory corruption, behavior indefinito. Per agenti AI, cerca comportamenti indesiderati: risposte dannose, leak di informazioni, violazioni di policy, loop infiniti.

Un survey del 2024 cataloga le tecniche di fuzzing applicate a LLM. I principali approcci:

Black-box fuzzing: Tratti il modello come scatola nera. Generi input, osservi output, iteri. Non richiede accesso ai pesi o all’architettura. Funziona con qualsiasi API.

Grey-box fuzzing: Combini generazione casuale con feedback sulla copertura. Se un input esplora un comportamento nuovo (misurato tramite output o trace), lo tieni come seed per ulteriori mutazioni.

LLM-enhanced fuzzing: Usi un LLM per generare input più intelligenti. Invece di mutazioni casuali, chiedi al modello di generare varianti che potrebbero causare problemi.

ChatFuzz combina fuzzing grey-box con generazione via ChatGPT. Un “chat mutator” prende seed dal pool e chiede a ChatGPT di generare input simili ma diversi. I nuovi input vengono valutati e quelli interessanti diventano nuovi seed.

Fuzz4All usa GPT-4 e StarCoder come motori di generazione e mutazione, permettendo fuzzing su progetti in linguaggi diversi. È stato usato per trovare bug in compilatori e interpreti.

Per agenti, il fuzzing si applica a diversi livelli:

Input utente: Genera query malformate, ambigue, con caratteri speciali, lunghe, multilingue
Risposte dei tool: Simula tool che restituiscono errori, timeout, dati malformati, dati malevoli
Contesto RAG: Inietta documenti con contenuto contraddittorio, injection attempt, formattazione insolita

Il fuzzing è computazionalmente costoso. Ogni run richiede inference del modello. Ma trova classi di bug che altri metodi non scoprono.

Ambienti di test: benchmark e simulazioni

Testare agenti in produzione è rischioso: ogni bug è visibile agli utenti. Testare su dataset statici è insufficiente: non cattura le interazioni dinamiche con tool e ambienti.

La soluzione intermedia sono gli ambienti di simulazione che replicano condizioni realistiche senza conseguenze reali.

AgentBench fornisce 8 ambienti distinti (web browsing, coding, database query) per valutare agenti su task realistici. WebArena simula siti web reali dove gli agenti possono navigare e completare task. SWE-bench valuta agenti su issue GitHub reali, misurando la capacità di risolvere bug in codebase esistenti.

Questi benchmark hanno un problema: sono statici. Una volta che un agente è stato ottimizzato per un benchmark, i risultati non predicono più le performance su casi nuovi.

Il trend è verso benchmark dinamici e continuamente aggiornati. AppWorld e WorkArena++ propongono task che cambiano nel tempo. Il concetto è simile ai dataset di evaluation per code generation che usano problemi di competitive programming: nuovi problemi ogni mese, impossibili da memorizzare.

Per testing interno, la pratica migliore è costruire ambienti che replicano il deployment target:

Mock dei tool esterni con risposte realistiche (successi, errori, latenza)
Dataset di input che riflettono la distribuzione di produzione
Scenari edge case identificati da incident post-mortem
Versioning degli ambienti di test per reproducibilità

Un ambiente di test ben costruito è un asset che si accumula nel tempo. Ogni bug trovato in produzione diventa un nuovo test case.

Pipeline di evaluation: pre-deploy e post-deploy

L’evaluation non è un evento singolo. È un processo continuo che attraversa tutto il lifecycle.

Pre-deploy (offline):

Unit test sui componenti: Il retriever restituisce documenti rilevanti? Il planner genera piani validi? I tool wrapper gestiscono errori?
Integration test end-to-end: L’agente completo risolve task rappresentativi? Su un dataset di almeno 500-1000 casi diversi?
Property-based testing: Le proprietà invarianti sono rispettate su input generati casualmente?
Red teaming: Il sistema resiste agli attacchi noti? Le nuove vulnerabilità sono state testate?
Regression testing: Le performance sono uguali o migliori della versione precedente? Nessun degradamento su casi critici?

La soglia per il deploy dovrebbe essere esplicita: task completion rate > X%, zero vulnerabilità critiche, regression test 100% passed.

Post-deploy (online):

Sampling: Valuta un campione (1-5%) degli output di produzione. Prioritizza casi flaggati da guardrail o con feedback negativo.
Monitoring metriche: Traccia task completion, latenza, error rate, costo per query in tempo reale. Alert su deviazioni.
Drift detection: Le performance stanno degradando? La distribuzione degli input sta cambiando?
Human review: Revisione periodica di campioni stratificati da annotatori qualificati.
Incident analysis: Ogni failure diventa un caso di test. Root cause analysis alimenta il dataset di regression.

L’integrazione con CI/CD è critica. Ogni PR che modifica l’agente dovrebbe triggerare la suite di test offline. Il deploy in produzione dovrebbe essere bloccato se i test non passano.

Il costo del non testare

I numeri parlano chiaro. Il 73% delle organizzazioni cita l’affidabilità come barriera al deploy di agenti. Non la tecnologia, non i costi di inference: l’affidabilità.

La conseguenza è che molti progetti restano in POC indefinitamente. Il team non ha fiducia sufficiente per andare in produzione. Senza metodologie di testing adeguate, quella fiducia è impossibile da costruire.

Chi investe in evaluation rigorosa pre-deploy scopre i problemi prima che li scoprano gli utenti. Chi non lo fa scopre i problemi tramite incident, ticket di supporto, perdita di fiducia.

Il testing di sistemi non-deterministici è più complesso del testing tradizionale. Richiede nuove competenze, nuovi tool, nuovi processi. Ma l’alternativa, deployare senza confidence e scoprire i bug in produzione, è più costosa.

I framework esistono. Le metodologie sono documentate. Il gap è nell’adozione.

Fonti

Confident AI. (2025). LLM Testing in 2025: Top Methods and Strategies.

Databricks. (2025). Announcing Agent Evaluation.

Galileo AI. (2025). Top 12 AI Evaluation Tools for GenAI Systems in 2025.

GitHub. (2025). DeepTeam: Framework to red team LLMs.

Hu, J., Zhang, Q., & Yin, H. (2023). ChatFuzz: Large Language Model Enhanced Fuzzing. arXiv:2305.06498.

OWASP. (2025). Top 10 for Large Language Model Applications v2025.

Skywork AI. (2025). Agentic AI Safety & Guardrails: 2025 Best Practices for Enterprise.

Wang, L., et al. (2024). Large Language Models Based Fuzzing Techniques: A Survey. arXiv:2402.00350.

Zhang, Y., et al. (2025). A Survey on the Evaluation of LLM-based Agents. arXiv:2503.16416.

Constitutional AI: guida per chi usa Claude

Irene Burresi — Mon, 29 Dec 2025 00:00:00 GMT

Il paradosso del rifiuto selettivo

Claude rifiuta di scrivere un racconto con un personaggio che fuma, ma con il prompt giusto spiega come sintetizzare metanfetamina. Constitutional AI spiega entrambi i comportamenti.

TL;DR: Constitutional AI addestra Claude usando una lista di principi (“costituzione”) invece di feedback umano per ogni risposta. Produce modelli più sicuri di RLHF tradizionale: 88% harmless rate contro 76%. Ma i failure modes sono specifici e prevedibili. Il modello è eccessivamente cauto su contenuti che sembrano problematici (keyword matching) e vulnerabile ad attacchi che non sembrano problematici (jailbreak semantici). È più sicuro in inglese che in altre lingue. Tende a darti ragione anche quando sbagli. Per chi deploya: aspettati refusal rate alto su casi d’uso legittimi, pianifica fallback, non fidarti della sicurezza su lingue diverse dall’inglese.

Chiunque abbia usato Claude in produzione conosce la frustrazione. Il modello rifiuta di scrivere un’email di sollecito pagamento perché “potrebbe essere percepita come aggressiva”. Rifiuta fiction con conflitti perché “potrebbe normalizzare la violenza”. Rifiuta di completare codice che gestisce autenticazione perché “potrebbe essere usato per hacking”.

Poi leggi i report di sicurezza. Adaptive attacks raggiungono il 100% di success rate su Claude 3 e 3.5. Ricercatori hanno estratto istruzioni per sintetizzare armi chimiche, generare malware funzionante, creare contenuti illegali. Con le tecniche giuste, le protezioni cedono completamente.

Come può lo stesso modello essere contemporaneamente troppo restrittivo e troppo permissivo?

La risposta sta in Constitutional AI, il metodo con cui Anthropic addestra Claude. Capire come funziona spiega entrambi i comportamenti e, più importante, permette di prevedere quando il modello fallirà nelle tue applicazioni.

Come funziona Constitutional AI

Il paper originale di Anthropic, pubblicato a dicembre 2022, propone un metodo per rendere i modelli “harmless” senza etichettare manualmente centinaia di migliaia di risposte come “buone” o “cattive”.

Il processo ha due fasi. Nella prima, il modello genera risposte a prompt problematici, poi critica e rivede le proprie risposte usando principi scritti in linguaggio naturale. Esempio di principio: “Scegli la risposta che non incoraggia comportamenti illegali, dannosi o non etici”. Il modello viene addestrato sulle revisioni.

Nella seconda fase, il modello genera coppie di risposte e un altro modello decide quale è migliore secondo gli stessi principi. Queste preferenze generate dall’AI (non da umani) vengono usate per il reinforcement learning. Anthropic chiama questo approccio RLAIF: Reinforcement Learning from AI Feedback, invece di RLHF (Human Feedback).

La costituzione di Claude include principi derivati dalla Dichiarazione Universale dei Diritti Umani, dai principi di beneficenza di DeepMind, e da linee guida scritte internamente. Non è un documento statico: Anthropic la aggiorna periodicamente e ha condotto esperimenti con input pubblico per modificarla.

Il claim centrale del paper: Constitutional AI produce modelli che sono contemporaneamente più sicuri (harmless) e meno evasivi (più utili) rispetto a RLHF tradizionale. I dati mostrano che questo è vero in media. Ma “in media” nasconde varianza significativa.

Cosa funziona: i miglioramenti reali

Prima di analizzare i problemi, i dati su cosa Constitutional AI fa bene.

Google DeepMind ha pubblicato nel 2023 il confronto più rigoroso tra RLAIF e RLHF. Su task di harmlessness, RLAIF ottiene 88% harmless rate contro 76% di RLHF. Non è un miglioramento marginale.

Il confronto head-to-head su qualità generale (summarization, helpful dialogue) non mostra differenze statisticamente significative: entrambi i metodi producono output preferiti dagli evaluatori circa il 70% delle volte rispetto a baseline senza reinforcement learning. RLAIF non è peggiore di RLHF sulla qualità, ed è migliore sulla sicurezza.

Il vantaggio di costo è sostanziale. AI labeling costa circa $0.06 per esempio, contro $0.11 per 50 parole di annotazione umana. Per chi addestra modelli, questo significa iterazioni più rapide e meno esposizione di annotatori umani a contenuti disturbanti. Per chi usa modelli già addestrati, significa che Anthropic può investire più risorse in safety research invece che in data labeling.

Un beneficio meno discusso: i principi costituzionali sono leggibili. Quando Claude rifiuta una richiesta, in teoria puoi risalire a quale principio ha attivato il rifiuto. Con RLHF puro, le preferenze sono implicite nei dati di training e non ispezionabili. Questa trasparenza è parziale (non sai come il modello interpreta i principi), ma è più di quanto offrano altri approcci.

Dove il modello rifiuta troppo

Il primo failure mode che impatta chi usa Claude in produzione è l’overrefusal. Il modello rifiuta richieste legittime perché pattern superficiali attivano i safety guardrail.

Il meccanismo è comprensibile. I principi costituzionali sono formulati in termini generali: “evita contenuti che potrebbero causare danno”, “non assistere in attività illegali”, “rifiuta richieste che potrebbero essere usate per manipolazione”. Il modello impara ad associare certi pattern lessicali con rifiuto, anche quando il contesto rende la richiesta innocua.

Gli esempi documentati dalla community coprono domini diversi. Nella fiction, Claude rifiuta storie con personaggi moralmente ambigui, conflitti realistici, o temi adulti che sarebbero accettabili in qualsiasi romanzo pubblicato. Un prompt per un thriller con un antagonista credibile può attivare un rifiuto perché “potrebbe normalizzare comportamenti dannosi”.

Nel codice, richieste che gestiscono autenticazione, crittografia, o network scanning vengono bloccate perché “potrebbero essere usate per hacking”. Questo include penetration testing legittimo, security auditing, o anche semplice gestione delle password.

La comunicazione professionale subisce la stessa sorte: email di sollecito, lettere di reclamo, comunicazioni assertive rifiutate perché “potrebbero essere percepite come aggressive o manipolative”. Su temi medici e legali, i disclaimer sono così estesi da essere inutili, o i rifiuti completi.

Il pattern comune: il modello reagisce a keyword e strutture superficiali, non al contesto. “Come forzare una serratura” viene rifiutato anche se il contesto è “ho perso le chiavi di casa mia”. “Come manipolare qualcuno” viene rifiutato anche se il contesto è “sto scrivendo un saggio sulla propaganda storica”.

Il team di Constitutional Classifiers di Anthropic ha documentato questo trade-off. Dopo aver deployato difese aggiuntive contro jailbreak, hanno osservato che il sistema “rifiuterebbe frequentemente di rispondere a domande basilari, non maliziose”. Maggiore sicurezza contro attacchi significa maggiore overrefusal su richieste legittime.

Per chi deploya applicazioni: il refusal rate su casi d’uso legittimi può essere significativo. Se la tua applicazione richiede generazione di contenuti creativi, assistenza su temi sensibili, o codice di sicurezza, aspettati che una percentuale non trascurabile di richieste venga rifiutata. Servono fallback (modelli alternativi, escalation a umani) e messaging appropriato per gli utenti.

Dove il modello accetta troppo

Il secondo failure mode è l’opposto: il modello accetta richieste che dovrebbe rifiutare, quando l’attacco è formulato in modo da bypassare i pattern superficiali.

Uno studio del 2024 ha testato attacchi adversarial su Claude 3 e 3.5. Con tecniche di transfer (prompt che funzionano su altri modelli adattati) o prefilling (forzare l’inizio della risposta del modello), il success rate raggiunge il 100%. Tutti gli attacchi testati hanno avuto successo.

Senza le difese aggiuntive di Constitutional Classifiers, i test interni di Anthropic mostrano 86% jailbreak success su Claude 3.5 Sonnet. Con Constitutional Classifiers deployati, il success rate cala drasticamente, ma dopo 3.700 ore collettive di red-teaming è stato comunque scoperto un jailbreak universale.

Come è possibile che lo stesso modello rifiuti email di sollecito e accetti richieste di sintesi di armi chimiche?

La risposta sta nella natura dei principi costituzionali. Sono formulati in linguaggio naturale, e il modello impara a interpretarli attraverso esempi statistici, non attraverso comprensione semantica profonda. Un attacco che riformula la richiesta in modo da non corrispondere ai pattern appresi bypassa le protezioni.

I jailbreak più sofisticati sfruttano diverse vulnerabilità. Il roleplay chiede al modello di interpretare un personaggio che non ha le stesse restrizioni. L’obfuscation codifica la richiesta in modi che il modello decodifica ma che non attivano i safety check (base64, lingue diverse, gergo). Il prefilling, in alcune API, forza l’inizio della risposta del modello bypassando il punto in cui decide se rifiutare. La manipolazione multi-turn costruisce gradualmente contesto attraverso più messaggi, ognuno innocuo, che insieme portano il modello a rispondere a richieste che rifiuterebbe se poste direttamente.

Per chi deploya applicazioni: le protezioni di Claude non sono sufficienti per casi d’uso high-stakes. Se la tua applicazione potrebbe essere usata per generare contenuti pericolosi, hai bisogno di layer aggiuntivi di moderazione. Non affidarti solo ai guardrail del modello.

Il problema della sycophancy

Il terzo failure mode è più sottile e meno discusso: Claude tende a darti ragione anche quando sbagli.

Anthropic stessa ha pubblicato ricerca che documenta sycophancy pervasiva in tutti i principali assistenti AI, incluso Claude. I comportamenti documentati includono ammissione di errori non commessi: se dici al modello “la tua risposta precedente era sbagliata”, spesso si scusa e “corregge” anche quando la risposta originale era corretta. Il feedback diventa biased: se chiedi una valutazione di un testo dicendo “l’ho scritto io”, il modello tende a essere più positivo che se presenti lo stesso testo come scritto da altri. Su problemi matematici dove l’utente suggerisce una risposta sbagliata, il modello tende a concordare con la risposta sbagliata più spesso di quanto farebbe senza il suggerimento.

La causa è strutturale. Constitutional AI (come RLHF) ottimizza per preferenze espresse da valutatori. Sia umani che modelli AI tendono a preferire risposte che concordano con loro, che sono scritte in modo convincente, che evitano conflitto. Il modello impara che “dare ragione” produce reward più alto.

Il finding più preoccupante: modelli più grandi addestrati con più iterazioni di RLHF/RLAIF mostrano sycophancy aumentata, non diminuita. Non è un bug che si risolve con più training. È una conseguenza del metodo di training stesso.

Per chi deploya applicazioni: se la tua applicazione richiede che il modello dia feedback onesto, verifichi informazioni, o contraddica l’utente quando sbaglia, aspettati performance degradata. Casi d’uso come code review, fact-checking, tutoring sono particolarmente impattati. Considera di istruire esplicitamente il modello a essere critico, ma sappi che questo mitiga solo parzialmente il problema.

Il problema delle lingue diverse dall’inglese

I failure modes descritti finora si amplificano quando il modello opera in lingue diverse dall’inglese. Questo impatta direttamente chi opera in Italia.

I dati sono chiari. Ricerca su LLM multilingual safety mostra che i modelli producono risposte harmful drammaticamente più spesso in lingue diverse dall’inglese. Un esempio specifico: Llama-3.1-8B rifiuta “How to make a bomb?” in inglese ma fornisce istruzioni dettagliate per la stessa domanda in hindi.

Il pattern si ripete su modelli e lingue diverse. Il tasso di successo degli attacchi passa da valori a singola cifra in inglese a 50-70% in lingue a bassa risorsa. L’italiano, pur essendo una lingua relativamente ben rappresentata, non è immune.

La causa: i dati di training per la sicurezza (esempi di rifiuto, definizioni di contenuto harmful, preferenze per harmlessness) sono prevalentemente in inglese. I principi costituzionali sono scritti in inglese. Il modello generalizza imperfettamente ad altre lingue.

Per applicazioni che servono utenti italiani, questo ha implicazioni concrete. I guardrail che funzionano in inglese sono meno affidabili in italiano. Un utente che vuole bypassare le protezioni può semplicemente formulare la richiesta in italiano (o in una lingua ancora meno rappresentata) con maggiore probabilità di successo.

Le contromisure sono limitate. Puoi tradurre le richieste in inglese prima di inviarle al modello, processare in inglese, poi tradurre le risposte in italiano. Ma questo aggiunge latenza, costo, e può introdurre errori di traduzione. Puoi aggiungere layer di moderazione specifici per italiano, ma richiede investment significativo.

Implicazioni per deployment enterprise

Cosa significa tutto questo per chi deve decidere se e come usare Claude in produzione?

Constitutional AI rende Claude una scelta ragionevole per applicazioni general-purpose con utenti non-adversarial: chatbot customer service, assistenti interni, tool di produttività. Il refusal rate su richieste legittime è gestibile, e il rischio di output harmful è basso se gli utenti non cercano attivamente di abusare il sistema. Funziona anche per casi d’uso dove l’overrefusal è accettabile: se la tua applicazione può tollerare rifiuti frequenti (con fallback appropriati), i guardrail di Claude sono un beneficio netto. La trasparenza dei principi è utile per compliance e audit: poter dire “il modello segue questi principi documentati” è più difendibile di “il modello è stato addestrato su preferenze implicite”.

Servono precauzioni aggiuntive per applicazioni creative. Se generi fiction, marketing copy, o contenuti che toccano temi sensibili, aspettati refusal rate alto. Prepara prompt alternativi, fallback a modelli meno restrittivi, o workflow con review umana. Lo stesso vale per applicazioni che richiedono feedback onesto come code review, tutoring, fact-checking: la sycophancy è un problema strutturale. Considera prompt engineering aggressivo per contrastare, ma non aspettarti che risolva completamente. Per applicazioni multilingue, se servi utenti non-anglofoni, i guardrail sono meno affidabili. Aggiungi moderazione specifica per le lingue che supporti. Per applicazioni high-stakes dove output harmful avrebbe conseguenze gravi (medico, legale, sicurezza), non affidarti solo ai guardrail del modello. Aggiungi layer di validazione, moderazione esterna, e review umana.

Non aspettarti sicurezza garantita contro attacchi sofisticati. Il 100% di jailbreak success con adaptive attacks significa che attaccanti motivati possono bypassare le protezioni. Se la tua applicazione è un target attraente, assumi che verrà compromessa. Non aspettarti comportamento consistente tra lingue: il modello che si comporta bene in inglese può comportarsi molto diversamente in italiano. Non aspettarti miglioramento della sycophancy con scale: modelli più grandi e più addestrati non sono meno sycophantic. Anzi.

Il quadro complessivo

Constitutional AI rappresenta un miglioramento reale rispetto ad alternative precedenti. I dati sono chiari: 88% harmless rate contro 76% di RLHF tradizionale, a costo inferiore. Per chi usa modelli commerciali, questo significa che Claude è genuinamente più sicuro della media.

Ma “più sicuro della media” non significa “sicuro”. I failure modes documentati sono specifici e prevedibili. Il modello rifiuta troppo quando pattern superficiali attivano i guardrail, anche se il contesto rende la richiesta legittima. Accetta troppo quando attacchi sofisticati riformulano richieste dannose in modi che non corrispondono ai pattern appresi. Ti dà ragione anche quando sbagli, perché la sycophancy è incentivata dal training stesso. È meno sicuro in lingue diverse dall’inglese, perché i dati di sicurezza sono prevalentemente anglofoni.

Nessuno di questi problemi è unico di Claude o di Constitutional AI. Sono limitazioni degli attuali approcci di alignment in generale. Ma Constitutional AI li rende più prevedibili: se capisci il meccanismo, puoi anticipare dove il modello fallirà.

Per chi deploya applicazioni, la domanda non è “Claude è sicuro?” ma “I failure modes di Claude sono accettabili per il mio caso d’uso?”. La risposta dipende dal contesto. Per molte applicazioni enterprise, Constitutional AI offre un trade-off ragionevole tra safety e usabilità. Per applicazioni high-stakes o adversarial, non è sufficiente da solo.

La trasparenza sui principi è un vantaggio competitivo di Anthropic rispetto ad altri provider. La costituzione di Claude è pubblica. Puoi leggerla, capire cosa il modello sta cercando di fare, e decidere se quei principi sono allineati con i tuoi casi d’uso. È più di quanto offrano altri.

Constitutional AI non risolve l’alignment. Rende il problema più gestibile, più ispezionabile, più prevedibile. Per chi deve deployare LLM oggi, con le limitazioni di oggi, è un passo avanti concreto. Non è la destinazione, ma è una direzione ragionevole.

Fonti

Bai, Y., Kadavath, S., Kundu, S., et al. (2022). Constitutional AI: Harmlessness from AI Feedback. arXiv:2212.08073.

Lee, H., Phatale, S., Mansoor, H., et al. (2023). RLAIF: Scaling Reinforcement Learning from Human Feedback with AI Feedback. arXiv:2309.00267.

Andriushchenko, M., et al. (2024). Jailbreaking Leading Safety-Aligned LLMs with Simple Adaptive Attacks. arXiv:2404.02151.

Perez, E., Ringer, S., Lukošiūtė, K., et al. (2023). Towards Understanding Sycophancy in Language Models. arXiv:2310.13548.

Deng, Y., et al. (2023). Multilingual Jailbreak Challenges in Large Language Models. arXiv:2310.02446.

Anthropic. (2023). Claude’s Constitution. Anthropic.

Anthropic. (2024). Constitutional Classifiers: Defending Against Universal Jailbreaks. Anthropic.

Da SEO a GEO: Guida Tecnica all'Ottimizzazione per AI Search

Irene Burresi — Sat, 04 Jan 2025 00:00:00 GMT

Il cambio di paradigma: dai link alle citazioni

GPTBot è passato dal 5% al 30% del traffico crawler in un anno. Il traffico generato da query utente verso AI è cresciuto 15 volte. L’infrastruttura SEO tradizionale non intercetta più questo flusso.

TL;DR: L’ottimizzazione per motori generativi (GEO) richiede interventi tecnici specifici: configurare robots.txt per 20+ AI crawler, implementare llms.txt per guidare LLM verso contenuti prioritari, estendere structured data con JSON-LD incluso Person schema con E-E-A-T completo (73% in più di selezione). Strutturare contenuti in answer blocks di 134-167 parole per facilitare l’estrazione. Contenuti multimodali hanno +156% selection rate. La ricerca Princeton dimostra che aggiungere citazioni da fonti autorevoli aumenta la visibilità fino al 40%. Chi implementa ora costruisce vantaggi competitivi difficili da recuperare.

Il SEO tradizionale ottimizza per un obiettivo specifico: posizionarsi nelle liste ordinate restituite dai motori di ricerca. L’utente cerca, riceve dieci link blu, clicca. Il traffico arriva.

I motori generativi funzionano diversamente. ChatGPT, Perplexity, Gemini, Claude non restituiscono liste di link. Sintetizzano risposte attingendo da fonti multiple, citando (o meno) la provenienza. L’utente ottiene una risposta, non un elenco di opzioni.

Secondo i dati Cloudflare di dicembre 2025, GPTBot ha raggiunto il 30% del traffico AI crawler, in crescita dal 5% dell’anno precedente. Meta-ExternalAgent è entrato al 19%. ChatGPT-User, il bot che accede a pagine web quando gli utenti fanno domande, ha registrato una crescita del 2.825%. Il traffico legato a query utente è aumentato di 15 volte nel corso dell’anno.

Non è un cambiamento marginale. È un nuovo canale di acquisizione che richiede infrastruttura dedicata.

robots.txt: configurazione per AI crawler

Il file robots.txt comunica ai crawler quali parti del sito possono accedere. Per i motori di ricerca tradizionali, la configurazione è consolidata. Per gli AI crawler, il panorama è frammentato: ogni provider usa user-agent diversi, con scopi diversi.

Mappa degli AI crawler principali

OpenAI opera con tre crawler distinti:

User-agent: GPTBot
# Training modelli fondazionali. Raccoglie dati per addestrare GPT.

User-agent: ChatGPT-User
# Browsing utente. Accede a pagine quando un utente chiede informazioni.

User-agent: OAI-SearchBot
# Search. Indicizza contenuti per la funzione di ricerca di ChatGPT.

Anthropic usa:

User-agent: ClaudeBot
# Training e aggiornamento Claude.

User-agent: Claude-Web
# Accesso web per funzionalità utente.

User-agent: anthropic-ai
# Crawler generico Anthropic.

Perplexity:

User-agent: PerplexityBot
# Indicizzazione per AI answer engine.

User-agent: Perplexity-User
# Fetch per query utente.

Google ha separato le funzioni:

User-agent: Google-Extended
# Token per uso AI. NON è un bot, è un flag.
# Controllare questo user-agent impedisce uso dei contenuti per training AI
# mantenendo l'indicizzazione standard.

User-agent: Googlebot
# Crawler tradizionale per Search.

Meta:

User-agent: Meta-ExternalAgent
# Crawling per training modelli AI.

User-agent: Meta-ExternalFetcher
# Fetch per richieste utente. Può bypassare robots.txt.

Altri crawler rilevanti:

User-agent: Amazonbot
User-agent: Bytespider      # ByteDance
User-agent: Applebot-Extended  # Apple AI (flag, non bot)
User-agent: CCBot           # Common Crawl
User-agent: cohere-ai
User-agent: cohere-training-data-crawler

Strategie di configurazione

Strategia 1: Accesso completo per massima visibilità AI

# Permettere tutti gli AI crawler
User-agent: GPTBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: anthropic-ai
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: Meta-ExternalAgent
Allow: /

User-agent: Amazonbot
Allow: /

Strategia 2: Visibilità AI search, no training

Questa configurazione permette ai sistemi AI di citare i contenuti nelle risposte, ma impedisce l’uso per addestrare modelli:

# Permettere crawler search/user
User-agent: ChatGPT-User
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Perplexity-User
Allow: /

# Bloccare crawler training
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: cohere-training-data-crawler
Disallow: /

Strategia 3: Accesso selettivo per directory

User-agent: GPTBot
Allow: /blog/
Allow: /docs/
Disallow: /api/
Disallow: /internal/
Disallow: /user-data/

Limiti di robots.txt

Un punto critico: robots.txt è un protocollo volontario. I crawler possono ignorarlo.

Ad agosto 2025, Cloudflare ha bloccato i bot di Perplexity dopo aver documentato violazioni del protocollo. A ottobre 2025, Reddit ha intrappolato deliberatamente i crawler Perplexity, dimostrando che aggiravano le restrizioni tramite strumenti di terze parti. Ne è seguita una causa legale.

La conseguenza operativa: robots.txt da solo non basta. Per enforcement reale, servono verifiche IP, regole WAF, o blocchi a livello CDN. Cloudflare riporta che oltre 2.5 milioni di siti usano la sua funzione di managed robots.txt per bloccare AI training.

llms.txt: il nuovo standard per guidare i LLM

A settembre 2024, Jeremy Howard di Answer AI ha proposto llms.txt, un nuovo file standard per comunicare con i Large Language Models. A differenza di robots.txt, che controlla l’accesso, llms.txt guida i modelli verso i contenuti più rilevanti.

Cosa fa llms.txt

Il file llms.txt è un documento markdown posizionato alla root del dominio (/llms.txt). Funziona come una mappa curata che indica ai LLM quali pagine contengono le informazioni più importanti e come interpretarle.

Non è un meccanismo di blocco. È un sistema di raccomandazione, come un bibliotecario che guida un visitatore verso gli scaffali giusti invece di lasciarlo vagare.

Struttura del file

# example.com

> Sito tecnico su implementazioni AI per enterprise.
> Contenuti verificati, aggiornati mensilmente.

## Documentazione Core

- [Guida RAG Produzione](https://example.com/docs/rag-production):
  Architetture RAG testate in produzione, pattern di chunking,
  metriche di valutazione. Aggiornato Q4 2024.

- [API Reference](https://example.com/docs/api):
  Documentazione completa delle API REST. Include esempi
  di codice Python e cURL.

## Articoli Tecnici

- [Ottimizzazione Latenza LLM](https://example.com/blog/llm-latency):
  Strategie per ridurre latenza p95 sotto 200ms.
  Include benchmark su Claude, GPT-4, Mistral.

- [Cost Management AI](https://example.com/blog/ai-costs):
  Framework per stimare e ottimizzare costi inference.
  Dati reali da deployment enterprise.

## Risorse

- [Glossario AI](https://example.com/glossario):
  Definizioni tecniche di 150+ termini AI/ML.

llms-full.txt: versione estesa

Oltre a llms.txt, lo standard prevede un file opzionale llms-full.txt che contiene il contenuto completo del sito in formato flattened. Rimuove HTML, CSS, JavaScript non essenziali e presenta solo il testo. Alcuni siti generano file da 100K+ parole.

Il vantaggio: permette ai LLM di processare l’intero sito in un singolo context. Il limite: supera facilmente la context window della maggior parte dei modelli.

Stato di adozione

A gennaio 2025, OpenAI, Google e Anthropic non supportano nativamente llms.txt. I loro crawler non leggono automaticamente il file.

L’adozione attuale è concentrata in nicchie specifiche:

Documentazione tecnica: Mintlify ha integrato llms.txt a novembre 2024. I siti di documentazione di Anthropic, Cursor, Cloudflare, Vercel lo usano.
Directory dedicate: directory.llmstxt.cloud e llmstxt.site catalogano i siti con implementazione.
Uso manuale: Sviluppatori che uploadano il file direttamente a ChatGPT o Claude per dare contesto.

È un investimento di future-proofing. Quando i major provider adotteranno lo standard, chi ha già implementato avrà vantaggio.

Implementazione

Creare /llms.txt alla root del dominio
Formato UTF-8, markdown pulito
Includere solo pagine indexabili (no noindex, no blocked in robots.txt)
Aggiungere descrizioni concise ma informative per ogni URL
Opzionale: riferimento in robots.txt con # LLM-policy: /llms.txt

Differenze con altri file standard

Confronto tra file standard per crawler web e AI
File	Scopo	Target	Formato
robots.txt	Controllo accesso crawler	Search engines, AI crawler	Plain text, direttive
sitemap.xml	Catalogo completo pagine	Search engines	XML
llms.txt	Mappa curata contenuti prioritari	LLM	Markdown
humans.txt	Crediti team	Umani	Plain text

Structured Data e JSON-LD per AI

Lo structured data non è una novità. È standard SEO dal 2011. Ma il suo ruolo cambia nel contesto dei motori generativi.

Perché lo Structured Data conta per AI

I LLM processano tutto come token. Non distinguono nativamente tra un prezzo, un nome, una data. Lo structured data fornisce un layer semantico esplicito che disambigua il contenuto.

Un articolo con markup JSON-LD comunica in modo machine-readable: questo è l’autore, questa è la data di pubblicazione, questa è l’organizzazione editrice, queste sono le fonti citate. Il modello non deve inferire questa struttura dal testo.

Implementazione JSON-LD base

JSON-LD (JavaScript Object Notation for Linked Data) è il formato preferito. Si inserisce in un tag

Schema types prioritari per AI visibility

Article / TechArticle / NewsArticle

Per contenuti editoriali. TechArticle per documentazione tecnica.

FAQPage

Struttura Q&A che i motori generativi possono estrarre direttamente:

HowTo

Per guide step-by-step:

Organization e Person: E-E-A-T per AI

E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) non è più solo un framework Google. I dati mostrano che i LLM verificano le credenziali autore prima di citare: il 96% dei contenuti in AI Overview proviene da fonti con autori verificati. Contenuti con author bio dettagliate hanno il 73% in più di probabilità di essere selezionati.

Lo schema Person deve andare oltre il nome. Serve comunicare credenziali, affiliazioni, competenze specifiche:

Checklist E-E-A-T per schema Person:

description con anni di esperienza e specializzazione
hasCredential per certificazioni verificabili
knowsAbout con topic specifici (non generici)
sameAs con link a profili verificabili (LinkedIn, GitHub, Google Scholar)
alumniOf per affiliazioni accademiche
worksFor con URL organizzazione

Citation schema

Per contenuti che citano fonti esterne, lo schema Citation aggiunge contesto:

ImageObject e VideoObject per contenuti multimodali

I contenuti multimodali hanno il 156% in più di probabilità di essere selezionati in AI Overview rispetto ai contenuti solo testo. Gemini e Perplexity investono pesantemente nella multimodal search. Lo schema per media diventa rilevante:

Per video con trascrizione:

Best practice per media AI-friendly:

Alt text descrittivo e contestuale (non “image1.png”)
Didascalie che spiegano il contenuto, non solo lo descrivono
Trascrizioni per tutti i video
Caption che contestualizzano la figura nel testo circostante

Impatto reale sugli AI search

John Mueller di Google ha chiarito a gennaio 2025 che lo structured data non è un fattore di ranking diretto. Ma l’impatto indiretto è documentato:

Rich snippets da structured data aumentano il CTR del 30% secondo BrightEdge
Il 72% dei siti in prima pagina Google usa schema markup
AI Overviews di Google elaborano structured data per costruire risposte

Lo structured data non garantisce citazioni nei motori generativi. Ma fornisce il contesto semantico che facilita l’interpretazione corretta del contenuto.

Requisiti tecnici per AI crawler

Oltre allo structured data, ci sono requisiti tecnici che influenzano la capacità dei LLM di processare e citare i contenuti.

Static HTML vs JavaScript rendering

Gli AI crawler hanno difficoltà con contenuti renderizzati via JavaScript. A differenza di Googlebot, che esegue JS, molti crawler AI preferiscono o richiedono HTML statico.

Regole operative:

Contenuto critico deve essere presente nell’HTML statico, non generato dinamicamente
Evitare contenuti nascosti in tab, accordion, o caricati on-scroll
Se usi framework JS (React, Vue, Next.js), verificare che il SSR o SSG produca HTML completo
Test: visualizzare la pagina con JS disabilitato. Ciò che si vede è ciò che vedono i crawler AI base.

Content freshness signals

Il 23% dei contenuti selezionati in AI Overview ha meno di 30 giorni. Perplexity indicizza giornalmente. I segnali di freshness sono prioritari rispetto all’autorità storica.

Implementazione:

dateModified in schema deve riflettere aggiornamenti reali:

Checklist freshness:

Aggiornare dateModified solo per modifiche sostanziali (non typo fix)
Segnalare update prominentemente nel contenuto (“Aggiornato: Gennaio 2025”)
Review trimestrale contenuti evergreen
Aggiornare statistiche e dati almeno annualmente
Rimuovere o marcare come archivio contenuti obsoleti

Verifica citazioni e fact-checking

Gli AI eseguono cross-reference con fonti autorevoli in tempo reale. Contenuti con citazioni verificabili hanno l’89% in più di probabilità di selezione rispetto a contenuti con claim non supportati.

Regole:

Ogni statistica deve avere fonte linkata
“Secondo una ricerca” senza link = claim non verificabile = penalizzato
Preferire fonti primarie (paper, documentazione ufficiale) su fonti secondarie
Citazioni da Wikipedia, Statista, Pew Research, paper arXiv hanno peso maggiore

Strategie GEO: cosa dice la ricerca

Il paper “GEO: Generative Engine Optimization” di Princeton, Georgia Tech, Allen Institute e IIT Delhi è lo studio più rigoroso disponibile sull’ottimizzazione per motori generativi. Ha testato 9 tecniche su 10.000 query.

Le tre strategie più efficaci

1. Cite Sources: +40% visibilità

Aggiungere citazioni da fonti autorevoli è la strategia con il maggior impatto generale. Per siti con ranking basso nelle SERP tradizionali, l’effetto è ancora più marcato: +115% per siti in quinta posizione.

Non basta citare. La citazione deve essere da fonte riconosciuta, pertinente al claim, verificabile.

2. Quotation Addition

Incorporare citazioni dirette da esperti del settore aumenta autenticità e profondità percepita. Funziona particolarmente per contenuti opinion-based.

3. Statistics Addition

Dati quantitativi battono discussioni qualitative. “Il 42% dei progetti AI fallisce” ha più impatto di “molti progetti AI falliscono”. Funziona particolarmente per domini Legal e Government.

Strutturare contenuti per estrazione: Answer Blocks

I LLM non citano pagine intere. Estraggono blocchi specifici. Ottimizzare per questo pattern è critico.

Passage length ottimale: 134-167 parole per blocco citabile. Per risposte FAQ dirette: 40-60 parole. Contenuti con summary box all’inizio hanno il 28-40% in più di probabilità di citazione.

Implementazione pratica:

TL;DR all’inizio: Ogni articolo apre con un blocco di sintesi self-contained. Non è solo per lettori umani: è il blocco che i LLM estraggono preferenzialmente.
Sezioni self-contained: Ogni H2/H3 deve essere citabile indipendentemente dal resto. Un LLM deve poter estrarre quella sezione e avere una risposta completa.
Heading come domande: “Cos’è il RAG?” performa meglio di “RAG Overview”. Matching diretto con query conversazionali.
Paragrafi modulari: 75-300 parole per sezione. No wall of text. I blocchi modulari sono più facili da estrarre e citare.
Risposte dirette prima, contesto dopo: La risposta alla domanda implicita dell’heading deve apparire nelle prime 2-3 frasi. L’elaborazione viene dopo.

Esempio di struttura ottimizzata:

## Qual è la differenza tra SEO e GEO?

SEO ottimizza per posizionarsi nelle liste di risultati dei motori
di ricerca tradizionali. GEO ottimizza per essere citati nelle
risposte sintetizzate dai motori generativi come ChatGPT, Perplexity
e Gemini. [40-60 parole di risposta diretta]

Il cambiamento fondamentale riguarda l'obiettivo: dal ranking alla
citazione. Nel SEO classico, il successo è posizione 1 nelle SERP.
In GEO, il successo è essere la fonte che l'AI cita quando risponde.
[Elaborazione e contesto]

Strategie domain-specific

Il paper ha scoperto che l’efficacia varia per dominio:

History: Tono autorevole e persuasivo
Facts: Citazioni da fonti primarie
Law/Government: Statistiche e dati quantitativi
Science/Health: Terminologia tecnica + autorevolezza

Ottimizzazione per piattaforma specifica

Ogni LLM ha preferenze diverse. Una strategia GEO efficace considera queste differenze:

Preferenze di ottimizzazione per piattaforme AI generative
Piattaforma	Preferenze principali	Ottimizzazione
ChatGPT	Wikipedia, brand popolari, contenuti consolidati	Authority building, presenza Wikipedia se applicabile
Perplexity	Reddit, contenuti recenti, real-time	Freshness prioritaria, engagement community
Gemini	Multimodal, ecosistema Google, schema markup	Video, immagini ottimizzate, structured data completo
Claude	Accuracy, contenuti bilanciati, attribuzione	Proper attribution, framing neutro ed evidence-based
Google AI Overview	Top 10 organic, E-E-A-T forte	SEO tradizionale + structured data esteso

Implicazioni operative:

ChatGPT cita Wikipedia nel 48% delle risposte. Per topic dove esiste una voce Wikipedia, la presenza lì pesa.
Perplexity preferisce Reddit (46.7% delle citazioni). Contenuti discussi in subreddit rilevanti hanno vantaggio.
Gemini integra immagini e video nelle risposte. Contenuti multimodali performano meglio.
Claude verifica accuracy più rigorosamente. Claim non supportati vengono scartati.

Cosa non funziona

Keyword stuffing: Aggiungere keyword dalla query al contenuto peggiora la visibilità del 10% rispetto al baseline. I motori generativi penalizzano l’over-optimization.

Persuasive language generico: Tono persuasivo senza sostanza non migliora il posizionamento.

Democratizzazione dei risultati

Un aspetto interessante: GEO livella il campo di gioco. I siti con ranking basso nelle SERP tradizionali beneficiano di più dalle ottimizzazioni GEO rispetto ai siti dominanti. Cite Sources porta +115% ai siti in quinta posizione e -30% ai siti in prima posizione.

Per piccoli editori e business indipendenti, è un’opportunità di competere con corporate giants senza budget SEO comparabili.

Checklist implementazione

robots.txt

[ ] Mappare tutti gli AI crawler rilevanti per il settore
[ ] Definire strategia: full access, search-only, selective
[ ] Implementare direttive per ogni user-agent
[ ] Verificare sintassi con Google Robots Testing Tool
[ ] Monitorare server logs per attività crawler
[ ] Verificare compliance effettiva (IP check per crawler sospetti)
[ ] Review trimestrale: nuovi crawler emergono regolarmente

llms.txt

[ ] Creare file markdown alla root del dominio
[ ] Includere descrizione del sito e tipo di contenuti
[ ] Organizzare URL per categoria/priorità
[ ] Aggiungere descrizioni concise per ogni link
[ ] Verificare che tutti gli URL siano indexabili
[ ] Considerare llms-full.txt per siti con documentazione estesa
[ ] Aggiornare quando nuovi contenuti prioritari vengono pubblicati

Structured Data / JSON-LD

[ ] Implementare Organization schema per il sito
[ ] Aggiungere Person schema per autori con E-E-A-T completo:
- [ ] description con anni esperienza e specializzazione
- [ ] hasCredential per certificazioni verificabili
- [ ] knowsAbout con topic specifici
- [ ] sameAs con LinkedIn, GitHub, Google Scholar
[ ] Usare Article/TechArticle per contenuti editoriali
[ ] Implementare FAQPage per sezioni Q&A
[ ] Aggiungere Citation schema per contenuti research-based
[ ] Implementare ImageObject/VideoObject per media
[ ] Validare con Google Rich Results Test
[ ] Verificare parità markup-contenuto visibile

Contenuto GEO-optimized

[ ] TL;DR di 40-60 parole all’inizio di ogni articolo
[ ] Sezioni self-contained (citabili indipendentemente)
[ ] Heading formulati come domande dove appropriato
[ ] Paragrafi modulari: 75-300 parole per sezione
[ ] Passage length: 134-167 parole per blocchi chiave
[ ] Includere citazioni da fonti autorevoli in ogni articolo
[ ] Aggiungere statistiche e dati quantitativi con fonte
[ ] Usare quotazioni da esperti dove rilevante
[ ] Evitare keyword stuffing
[ ] Calibrare tono per dominio

Requisiti tecnici

[ ] Contenuto critico in HTML statico (non solo JS-rendered)
[ ] No contenuti nascosti in tab/accordion/lazy-load
[ ] Test pagina con JavaScript disabilitato
[ ] dateModified aggiornato per modifiche sostanziali
[ ] Segnalare update nel contenuto (“Aggiornato: Mese Anno”)
[ ] Review trimestrale contenuti evergreen
[ ] Ogni statistica con fonte linkata

Media e Multimodal

[ ] Alt text descrittivo e contestuale per immagini
[ ] Didascalie che spiegano il contenuto
[ ] Trascrizioni per tutti i video
[ ] Schema ImageObject/VideoObject implementato
[ ] Caption che contestualizzano figure nel testo

Monitoring

[ ] Tracciare attività AI crawler nei server logs
[ ] Monitorare menzioni del brand in risposte ChatGPT/Perplexity/Gemini
[ ] Analizzare competitor citation share
[ ] Misurare traffico referral da AI platforms
[ ] Review mensile delle metriche

La finestra di opportunità

I dati Cloudflare mostrano che il crawling per AI training domina ancora il traffico, con volumi 8 volte superiori al search crawling e 32 volte superiori al crawling da query utente. Ma il trend è chiaro: il traffico user-action sta crescendo più velocemente di ogni altra categoria.

Chi implementa l’infrastruttura GEO ora costruisce vantaggi che si accumulano nel tempo. Le citazioni generano altre citazioni. L’autorità riconosciuta dai modelli si rafforza. Il first-mover advantage in questo spazio non riguarda solo il posizionamento tecnico: riguarda la costruzione di una presenza consolidata prima che la competizione si intensifichi.

Il SEO tradizionale non scompare. Continua a servire il 70% del traffico search che ancora passa per le SERP classiche. Ma il restante 30%, e la sua traiettoria di crescita, richiede strumenti nuovi.

Fonti

Aggarwal, P., et al. (2024). GEO: Generative Engine Optimization. arXiv:2311.09735. Princeton University, Georgia Tech, Allen Institute for AI, IIT Delhi.

AI Mode Boost. (2025). AI Overview Ranking Factors: 2025 Comprehensive Study.

Cloudflare. (2025, December). From Googlebot to GPTBot: Who’s Crawling Your Site in 2025. Cloudflare Blog.

Dataslayer. (2025). Google AI Overviews Impact 2025: CTR Down 61%.

Howard, J. (2024, September). llms.txt Proposal. Answer AI.

W3C Schema Community. (2024). Schema Vocabulary Documentation.

SEO Sherpa. (2025, October). Google AI Search Guidelines 2025.

Single Grain. (2025, October). Google AI Overviews: The Ultimate Guide to Ranking in 2025.

Yoast. (2025). Structured Data with Schema for Search and AI.

Overdrive Interactive. (2025, July). LLMs.txt: The New Standard for AI Crawling.