Perché gli assistenti AI allucinano gli indirizzi (e come i dati geo verificati risolvono il problema)

TL;DR: Gli assistenti AI inventano indirizzi plausibili ma sbagliati con tassi che vanno dal 6 % per gli hotel di catena al 38 % per le case vacanza indipendenti. La soluzione non è correggere il modello. Pubblica una ground truth univoca usando il markup Schema.org Place, coordinate verificate e un identificatore esterno canonico, poi mantieni questa verità coerente su ogni piattaforma in cui l'attività compare.

Chiedi a ChatGPT l'indirizzo di un hotel tre stelle a Porto e molto probabilmente ti risponderà con un nome di via, un numero civico e un CAP. La risposta sembrerà sicura. Per le grandi catene sarà quasi sempre corretta. Per l'hotel boutique indipendente due strade più in là, la risposta ha una probabilità significativa di essere sbagliata.

Non è un caso limite raro. È un output prevedibile del modo in cui i language model generano testo, e ha conseguenze dirette per chiunque abbia un business che dipende dall'essere trovato in un luogo preciso.

La meccanica di un'allucinazione di localizzazione

Un language model non memorizza un database di indirizzi. Memorizza una distribuzione statistica sui token. Quando gli viene chiesto un indirizzo, prevede una sequenza di token che assomiglia a un indirizzo per quel tipo di struttura in quella città.

Se i dati di training contenevano l'indirizzo reale molte volte, in modo coerente e da fonti autorevoli, la previsione converge sulla stringa corretta. Se l'indirizzo compariva raramente, in modo incoerente o per nulla, il modello interpola. Sceglie una via che suona adatta al quartiere, un numero che si incastra nell'isolato, un CAP che corrisponde al pattern locale.

L'output è grammaticalmente valido, geograficamente plausibile e spesso completamente sbagliato.

Sample audit: tassi di allucinazione per tipo di query

Abbiamo eseguito 500 query di localizzazione su tre assistenti AI di riferimento ad aprile 2026. Ogni query chiedeva l'indirizzo di una struttura specifica. Le risposte sono state confrontate con l'indirizzo verificato della struttura registrato in MapAtlas GeoEnrich.

La tabella seguente mostra la quota di risposte che contiene almeno un errore di indirizzo rilevante (via sbagliata, numero sbagliato, CAP sbagliato o città sbagliata). I numeri sono indicativi e specifici di questo campione.

Tipo di query	ChatGPT	Perplexity	Gemini
Hotel di catena	6%	4%	7%
Hotel boutique indipendente	19%	14%	22%
Casa vacanza	38%	29%	41%
Ristorante indipendente	24%	18%	27%
Monumento o attrazione	9%	5%	8%

Source: MapAtlas sample audit, aprile 2026, n=500 query.

Emergono due pattern. Primo, il tasso di allucinazione cresce con la rarità e l'incoerenza della presenza web della struttura. Le case vacanza, che spesso vivono su un'unica piattaforma di listing senza un sito proprio, sono le più colpite. Secondo, Perplexity allucina meno in modo sistematico, probabilmente perché il suo livello di retrieval ancora più risposte a fonti live invece che alla memoria parametrica.

Un esempio pratico

Query inviata ad aprile 2026: "Qual è l'indirizzo della guesthouse Casa do Vale a Porto?"

Risposta allucinata da un assistente di primo piano:

Casa do Vale si trova in Rua de Santa Catarina 142, 4000-442 Porto, Portogallo.

Risposta verificata dai registri della struttura stessa e da MapAtlas Geocoding:

Casa do Vale, Rua do Vale 38, 4200-512 Porto, Portogallo.

Via sbagliata, CAP sbagliato, lato sbagliato della città. La risposta allucinata porta l'ospite in un'area commerciale a tre chilometri dalla guesthouse reale. L'errore non è casuale. Rua de Santa Catarina è la via commerciale più famosa di Porto e appare in abbondanza nei dati di training per le query di alloggi a Porto. Il modello ha ripiegato sulla prior statistica più forte per quella città.

Perché i dati strutturati cambiano il risultato

Una pagina listing con un blocco JSON-LD Place o LodgingBusiness ben formato offre al modello qualcosa da estrarre invece che da inventare.

{
  "@context": "https://schema.org",
  "@type": "LodgingBusiness",
  "name": "Casa do Vale",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Rua do Vale 38",
    "postalCode": "4200-512",
    "addressLocality": "Porto",
    "addressCountry": "PT"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 41.1621,
    "longitude": -8.5937
  },
  "identifier": {
    "@type": "PropertyValue",
    "propertyID": "wikidata",
    "value": "Q00000000"
  }
}

Tre caratteristiche di questo blocco contano per ridurre le allucinazioni:

Campi strutturati. Il modello non deve fare il parsing di una frase. Via, CAP, città e paese sono chiavi separate.
Coordinate che corrispondono all'indirizzo. Un crawler può verificare che latitudine e longitudine ricadano nel poligono del CAP. Le discrepanze segnalano i dati come a bassa confidenza.
Un identificatore esterno stabile. Wikidata o un Google Place ID collegano la listing a un'entità canonica. Il modello può riconciliare l'indirizzo con una fonte autorevole invece di affidarsi alla frequenza nei dati di training.

Quando queste tre condizioni sono soddisfatte, l'estrazione sostituisce la generazione. La probabilità di una risposta allucinata cala nettamente.

Il livello di coerenza NAP

Lo schema sulla pagina listing è necessario ma non sufficiente. I sistemi AI confrontano l'indirizzo con altre fonti pubbliche: Google Business Profile, OpenStreetMap, Yelp, Tripadvisor, piattaforme di booking e il web aperto. Quando queste non concordano, la confidenza scende e il modello tende di più a mitigare o a generare.

È per questo che la coerenza NAP (Name, Address, Phone) tra le piattaforme è un predittore di citazione più forte di qualunque singolo segnale. Una listing con uno schema perfettamente formato ma un indirizzo in conflitto su Google Business Profile performerà comunque male. Vedi coerenza NAP per la ricerca AI per la meccanica.

Cosa tende a ridurre il rischio di allucinazione

Quattro misure spostano più di tutte l'ago della bilancia negli audit che abbiamo condotto:

1. Pubblica coordinate verificate accanto all'indirizzo. Un indirizzo scritto è una stringa. Le coordinate sono un fatto verificabile. MapAtlas Geocoding converte indirizzi grezzi in latitudine e longitudine precise su larga scala, segnalando gli input che non risolvono in modo pulito.

2. Incapsula i fatti di localizzazione in JSON-LD. I type Place, LodgingBusiness, Hotel, Restaurant e LocalBusiness accettano tutti i campi address, geo e identifier. I campi mancanti sono proprio il punto in cui il modello inizia a indovinare.

3. Riconcilia con un identificatore canonico. Collega la listing a un QID Wikidata o a un Google Place ID. In questo modo i sistemi AI dispongono di una primary key per la deduplica tra fonti.

4. Arricchisci con contesto di prossimità. Le allucinazioni non si limitano al campo indirizzo. I modelli inventano anche monumenti vicini, fermate del trasporto e tempi di percorrenza a piedi. I dati di prossimità verificati, generati da MapAtlas GeoEnrich, ancorano anche queste affermazioni. Le FAQ specifiche per la location sono una superficie efficace per esporre questi dati.

Il costo business di un indirizzo allucinato

Un indirizzo sbagliato mostrato da un assistente AI non mette solo in imbarazzo il modello. Manda un cliente reale nel posto sbagliato. Gli effetti a valle si sommano:

Una prenotazione cancellata o, peggio, un no-show.
Una recensione negativa che cita la location sbagliata, che diventa poi dato di training per la generazione successiva del modello.
Una confidenza di citazione ridotta per la listing in futuro, perché il web pubblico contiene ora segnali contraddittori.

L'asimmetria è rilevante. Un indirizzo allucinato danneggia la listing anche quando la listing in sé è innocente. La soluzione non è correggere direttamente il modello, cosa impossibile, ma rendere la verità di base così inequivocabile che il modello non abbia più motivo di generare.

Come verificare la tua esposizione

Il MapAtlas AEO Checker gratuito valuta una listing su 29 segnali strutturati, tra cui schema dell'indirizzo, presenza di coordinate, coerenza NAP e identificatori esterni. Le listing che superano questi check hanno una probabilità molto più bassa di essere rappresentate male nelle risposte AI. Quelle che falliscono sono proprio quelle in cui il modello è costretto a indovinare.

Le allucinazioni di localizzazione non sono una stranezza di un singolo assistente. Sono una conseguenza prevedibile del training su un web aperto in cui la stessa attività compare con indirizzi leggermente diversi su decine di fonti. La soluzione è pubblicare un'unica verità di base in un formato che i sistemi AI possono estrarre, e mantenerla coerente ovunque l'attività sia rappresentata.

Letture correlate:

Domande frequenti

Cos'è un'allucinazione di indirizzo da parte di un AI?

Un'allucinazione di indirizzo da parte di un AI si verifica quando un large language model restituisce un indirizzo stradale, un CAP o delle coordinate specifiche che sembrano plausibili ma non corrispondono al luogo reale dell'attività, del monumento o della proprietà descritta. Non si tratta di un banale errore di arrotondamento. Il modello ha sintetizzato un indirizzo che non esiste, appartiene a un'altra struttura o unisce una strada vera con la città sbagliata. Per le listing è particolarmente dannoso, perché l'utente può spostarsi nel posto sbagliato prima di accorgersi che la risposta era inventata.

Perché gli assistenti AI allucinano gli indirizzi?

I language model generano testo prevedendo il token successivo più probabile, non cercando fatti in un database. Quando un indirizzo è poco rappresentato, incoerente sul web o bloccato al crawling, il modello colma il vuoto con una stringa statisticamente plausibile: un nome di via che suona giusto per la città, un pattern di CAP coerente con la regione, un numero civico tipico. Senza una fonte strutturata di verità su cui ancorare la risposta, il modello non ha alcun meccanismo per distinguere un fatto memorizzato da uno generato.

Con quale frequenza si verificano le allucinazioni di localizzazione nella pratica?

In un sample audit condotto da MapAtlas ad aprile 2026 su 500 query di localizzazione relative a hotel, case vacanza, ristoranti e monumenti, i tassi di allucinazione a livello di indirizzo sono andati da circa il 6% per le catene alberghiere note fino al 38% per le case vacanza indipendenti. Le query generiche sui monumenti sono andate meglio, quelle long tail sulle listing peggio. Il tasso è indicativo e varia in base a modello, lingua e freschezza dei dati sottostanti, ma lo schema è costante: meno dati strutturati espone una struttura, più il modello inventa.

I dati strutturati Schema.org riducono le allucinazioni?

Sì, a condizione che i dati siano verificati e coerenti tra le fonti. Pubblicare un blocco JSON-LD Place o LodgingBusiness con coordinate geografiche accurate, un indirizzo postale validato e riferimenti incrociati a identificatori autorevoli come Wikidata o Google Place ID fornisce al modello un ancoraggio di verità che può estrarre e citare. Uno schema incoerente, ad esempio con coordinate che non corrispondono all'indirizzo scritto, tende ad abbassare la confidenza invece che alzarla.

Come verifico le mie listing per il rischio di allucinazione?

Esegui l'URL della listing sul MapAtlas AEO Checker gratuito su mapatlas.eu/ai-seo-checker. Il checker valuta 29 segnali strutturati che i sistemi AI usano per ancorare i fatti di localizzazione, tra cui coordinate geografiche, schema Place, coerenza NAP tra le piattaforme e presenza di campi di contesto di prossimità. Le pagine prive di questi segnali ottengono un punteggio di rischio di allucinazione alto perché il modello è costretto a indovinare invece di estrarre.