CIN: con un'API pubblica gli annunci falsi sparirebbero subito
Lo Stato ha costruito una mappa con oltre 715.000 strutture, la geolocalizzazione e indicatori di anomalia. Il nome? BDSR Lens.
Il Fisco "accende il radar", titolano i giornali. Peccato che il buco più grande del sistema non stia nel radar, ma in un campo di testo.
Quello in cui l'host, su Airbnb o Booking, digita il proprio CIN. Può scriverci un codice vero, un codice inventato, il codice del vicino copiato da un altro annuncio. La piattaforma lo accetta, lo pubblica e passa oltre.
La tesi è semplice: finché i portali non saranno obbligati a verificare il CIN nel momento in cui viene inserito, ogni banca dati, per quanto sofisticata, resterà una mappa disegnata dopo che i buoi sono scappati.
E la soluzione non richiede nuove tasse né nuove task force. Richiede un'API pubblica e un comma.
La legge chiede di esporre il codice, ma non obbliga a verificarlo
Dal 1° gennaio 2025 il CIN è obbligatorio per strutture ricettive e locazioni brevi. Va esposto all'esterno dell'immobile e indicato negli annunci online.
Le piattaforme OTA chiedono il codice. Ed è qui che la norma si ferma, perché chiedere non significa controllare.
O meglio: la legge non chiede alle piattaforme di verificarlo. Il controllo è stato delegato altrove, a figure non meglio specificate:
Polizia municipale
Guardia di Finanza
Comuni
Regioni
"Altri soggetti istituzionalmente competenti"
Tutti responsabili, quindi nessuno davvero. E così all'OTA non interessa sapere se quel codice esiste, se corrisponde a quell'immobile, se appartiene a chi pubblica l'annuncio o se è stato copiato da un'altra inserzione.
Il campo è compilato, la casella è spuntata, l'annuncio va online.
Il risultato è paradossale. Il proprietario in regola ha fatto la pratica, ottenuto il CIN, appeso la targhetta al portone. L'abusivo ha fatto copia e incolla. Sull'annuncio, i due sono indistinguibili.
Il controllo a valle non può funzionare
Ora il ministero risponde con BDSR Lens, e Firenze con il web scraping, cioè la raccolta automatica degli annunci per confrontarli con gli archivi comunali.
Strumenti utili, nessuno lo nega. Ma guardiamo l'aritmetica.
Nel 2025 le segnalazioni al Fisco sugli affitti brevi hanno riguardato circa 32.000 soggetti, gli atti di verifica sono stati oltre 2.000, i ravvedimenti operosi 377. Su oltre 700.000 strutture registrate.
Come si controllano centinaia di migliaia di codici a mano, uno per uno, annuncio per annuncio? Non si controllano.
Si campiona, si incrocia, si segnala, si verifica dopo mesi. Il controllo a valle è lento, costoso e insegue un mercato che nel frattempo ha già pubblicato, incassato e magari chiuso l'annuncio.
È come piazzare gli autovelox dopo aver tolto i freni a tutte le auto.
Cos'è un'API, spiegato senza informatichese
La soluzione si chiama API, sigla che fa paura solo a chi non l'ha mai vista all'opera.
Un'API (Application Programming Interface) è semplicemente una porta attraverso cui due sistemi informatici si parlano da soli, senza che nessuno debba fare nulla a mano. Un sistema fa una domanda, l'altro risponde.
Ogni volta che paghiamo con la carta online, che un'app ci mostra il meteo o che un sito calcola le spese di spedizione, dietro c'è un'API che interroga un altro sistema e riceve una risposta in una frazione di secondo.
Applicato al CIN, il meccanismo sarebbe questo:
Il ministero del Turismo pubblica un'API collegata alla BDSR
Quando un host inserisce il CIN su una piattaforma, insieme al proprio codice fiscale, il portale interroga automaticamente il registro nazionale
Domande: questo codice esiste? È associato a questo codice fiscale? Corrisponde a questa città?
La risposta arriva in un secondo ed è binaria: ok oppure non ok
Se è non ok, l'annuncio non si pubblica. Fine.
Niente ispettori, niente scraping, niente incroci a posteriori. Il codice falso non entra nemmeno dalla porta.
Tecnicamente è facilissimo, e ci siamo arrivati da soli fin dove si poteva
Qualcuno dirà che è complicato, che servono anni, gare d'appalto, tavoli tecnici. Non è così.
Un'integrazione di questo tipo, per piattaforme che gestiscono milioni di annuncii con sistemi ben più complessi, è lavoro ordinario. Con gli strumenti di sviluppo di oggi, compresa l'intelligenza artificiale, si fa in mezza giornata.
A una condizione: che dall'altra parte ci sia una porta a cui bussare.
Ed è proprio questo il punto. Oggi un'API pubblica del ministero non esiste. Nessun sistema esterno può interrogare la BDSR in automatico e ricevere un ok o un non ok.
Così, con Hostland, la piattaforma di Vita da Host per Welcomebook e prenotazioni dirette, abbiamo fatto l'unica cosa possibile: abbiamo programmato il sistema per arrivare fin dove la tecnica oggi consente, cioè a un controllo visivo.
Con un click l'ospite, o il cliente che sta per prenotare, viene portato direttamente alla scheda pubblica della BDSR e può vedere con i propri occhi se quel CIN esiste, a che nome è registrato e in quale città.
Nessuna ricerca da fare a mano. Per l'host in regola, la trasparenza diventa un biglietto da visita.
È un passo avanti, ma è anche la dimostrazione del limite. Un controllo visivo dipende dalla buona volontà di chi guarda. Un controllo via API non dipende da nessuno: funziona sempre, su ogni annuncio, in un secondo.
Se una piccola realtà italiana riesce a spingersi fin qui partendo dai soli dati pubblici, non si capisce quale ostacolo tecnico possa impedire al ministero di pubblicare un'interfaccia ufficiale, e ai colossi delle prenotazioni di agganciarsi.
Un comma, all'italiana
In Italia le cose funzionano così: non si riscrive una legge, si aggiunge un comma. In questo caso ne basterebbe uno.
"Le piattaforme di intermediazione sono tenute a verificare, tramite l'interfaccia messa a disposizione dal ministero del Turismo, la validità del CIN e la sua corrispondenza con il codice fiscale del titolare, prima della pubblicazione dell'annuncio. Gli annunci con esito negativo non possono essere pubblicati."
L'Europa, peraltro, ci ha già messo sulla strada. Il Regolamento UE 2024/1028 chiede alle piattaforme di raccogliere i numeri di registrazione e di condividere con le autorità i dati su annunci e pernottamenti.
L'Italia ha una delle banche dati più ampie d'Europa, una copertura dei CIN oltre il 90% e un ministero che parla di interoperabilità da anni.
Manca solo l'ultimo metro: trasformare il registro da archivio da consultare a filtro che lavora da solo.
Chi ci guadagna, chi ci perde
Ci guadagnerebbe lo Stato, che smetterebbe di inseguire gli abusivi uno a uno.
Ci guadagnerebbero i Comuni e le forze di controllo, che invece di cercare aghi nel pagliaio avrebbero la certezza che ogni annuncio online corrisponde a una struttura registrata.
Ci guadagnerebbero soprattutto i piccoli proprietari in regola, oggi confusi con chi il codice se l'è inventato, e spesso raccontati come il problema invece che come la soluzione.
Ci perderebbe solo chi oggi pubblica con un codice falso o copiato. Che, a pensarci bene, è esattamente il soggetto che la super banca dati dice di voler stanare.
Resta allora una domanda, rivolta a chi scrive le norme e a chi governa le piattaforme.
Se la soluzione costa mezza giornata di lavoro, un comma e un'API, perché si preferisce costruire radar, mappe e cruscotti per controllare dopo, invece di impedire prima?
Forse perché un sistema che funziona da solo fa meno notizia di un'operazione antievasione. O forse perché qualcuno, sulle piattaforme, preferisce non sapere quanti di quei codici sono veri.
