App IO, una dieresi blocca la patente: perché il vero problema è nei database

Una lettera con due puntini basta a bloccare la patente digitale sull’app IO. La segnalazione riguarda diversi cittadini dell’Alto Adige con nomi o cognomi contenenti ä, ö oppure ü: durante l’aggiunta del documento compare il messaggio generico “problema anagrafe” e la procedura si interrompe anzitempo. Il comportamento anomalo appare strettamente legato alla coerenza dei dati personali conservati dalle differenti amministrazioni.

La vicenda arriva mentre Documenti su IO, la componente italiana del portafoglio digitale pubblico, ha ormai raggiunto una diffusione davvero importante.

La funzione, aperta progressivamente nel 2024 e poi resa disponibile a tutti i maggiorenni, permette di aggiungere all’app la patente di guida, la tessera sanitaria e la Carta Europea della Disabilità. Secondo i dati diffusi dal Dipartimento per la trasformazione digitale, le sole patenti aggiunte avevano già superato quota 9 milioni. Numeri che rendono meno tollerabile un errore capace di escludere una parte della popolazione sulla base dell’ortografia del nome.

Il caso ha anche una dimensione storica. Le Pubbliche Amministrazioni italiane hanno costruito i propri archivi in epoche diverse, usando software, codifiche e regole di trascrizione non sempre compatibili. I problemi restano nascosti finché ogni banca dati lavora per conto proprio; affiorano quando un servizio digitale prova a collegarle in tempo reale. La patente aggiunta all’app IO non crea una nuova identità: deve dimostrare che la persona riconosciuta tramite SPID o CIE corrisponde senza ambiguità all’intestatario del documento registrato presso la Motorizzazione.

Perché la patente digitale si blocca nell’app IO

Numerose persone con caratteri tipici della lingua tedesca non riescono ad attivare la patente digitale attraverso l’app IO. La Provincia autonoma di Bolzano conosce il problema almeno dall’inizio del 2026 e avrebbe già coinvolto il Ministero dell’Interno; al momento della segnalazione, però, non risultava una data precisa per la risoluzione dell’anomalia.

L’ipotesi più immediata attribuiva il malfunzionamento all’app IO e alla sua incapacità di gestire i caratteri speciali. Il codice dell’applicazione, del backend e dei componenti del wallet non sembra contenere filtri che eliminano o rifiutano le vocali con segni diacritici. IO usa principalmente il codice fiscale per identificare l’utente e richiedere alla Motorizzazione i dati della patente; nome e cognome arrivano dai sistemi dell’ente titolare del documento.

Il codice fiscale, pur essendo un identificativo essenziale, non elimina la necessità di verificare la corrispondenza anagrafica.

Nel processo di emissione del documento digitale, il sistema della Motorizzazione può confrontare i dati presenti nella propria anagrafica con quelli associati alla persona nei registri nazionali. Basta una differenza nel nome, nel secondo nome, nel luogo di nascita o nella rappresentazione di un carattere perché il controllo fallisca.

Un cittadino registrato in ANPR (Anagrafe Nazionale) come “Müller”, per esempio, potrebbe comparire nell’archivio della Motorizzazione come “Muller” oppure “Mueller”. Le tre forme risultano comprensibili per un essere umano, ma per un software sono stringhe differenti.

Senza una regola comune di normalizzazione o una tabella certa di equivalenza, il sistema non può decidere in autonomia se si tratti della stessa persona.

UTF-8 da solo non risolve il problema

In tanti hanno tirato in ballo UTF-8, la codifica Unicode usata ormai dalla maggior parte delle applicazioni web, capace di rappresentare ä, ö, ü e migliaia di altri caratteri senza tentennamenti. Limitarsi a migrare una colonna da una vecchia codifica a UTF-8 non garantisce che due anagrafiche tornino a coincidere.

UTF-8 permette di scrivere correttamente “Müller”; non impedisce però che un dato importato in passato contenga “Muller” o “Mueller”: tutte e tre le stringhe sono perfettamente valide in Unicode. Il problema, quindi, non riguarda soltanto la possibilità tecnica di memorizzare un carattere, ma la scelta di quale forma considerare ufficiale e di come trattare le varianti storiche.

C’è poi una sottigliezza meno evidente. Unicode consente in alcuni casi di rappresentare lo stesso carattere visivo in modi diversi: come singolo punto di codice precomposto oppure come lettera base seguita da un segno combinante. Una “ü”, per esempio, può comparire come U+00FC oppure come “u” classica U+0075 più dieresi combinante U+0308. A video il risultato appare identico; un confronto eseguito senza normalizzazione Unicode potrebbe però considerare differenti le due sequenze.

Gli standard Unicode prevedono forme normalizzate come NFC e NFD proprio per ridurre simili ambiguità; in un sistema anagrafico, tuttavia, normalizzare la codifica non significa autorizzarsi a cambiare l’ortografia legale. Trasformare “Müller” in “Muller” elimina informazione; convertirlo in “Mueller” applica invece una traslitterazione linguistica che può risultare appropriata in alcuni documenti, ma non necessariamente in ogni archivio amministrativo.

Come andrebbero corretti gli archivi della Motorizzazione

Un intervento efficace dovrebbe partire da una verifica delle anagrafiche storiche. Prima occorre individuare le discrepanze più frequenti: diacritici eliminati, umlaut traslitterati, apostrofi sostituiti, doppi nomi mancanti, vecchie denominazioni degli Stati di nascita e codici territoriali non più validi. Poi bisogna classificare i casi in base al rischio.

Le corrispondenze più ovvie possono essere risolte usando codice fiscale, data e luogo di nascita, numero della patente e identificativi ANPR. Le situazioni ambigue devono invece arrivare a un operatore, con strumenti che mostrino chiaramente le differenze e consentano di correggere il dato senza costringere il cittadino a rifare il documento a proprie spese.

Sul piano applicativo servono confronti consapevoli di Unicode. Le stringhe andrebbero riportate nella stessa forma, per esempio NFC, prima della verifica tecnica; le traslitterazioni linguistiche dovrebbero restare separate dal valore legale del nome. Eliminare indiscriminatamente accenti e diacritici sarebbe una scorciatoia pericolosa, perché potrebbe trasformare cognomi differenti nella stessa sequenza ASCII.

Anche il messaggio mostrato dall’app merita attenzione. “Problema anagrafe” non spiega quale ente possiede il dato incoerente, quale attributo non coincide e come chiedere la rettifica. Per ragioni di sicurezza non è opportuno esporre dettagli eccessivi, ma l’utente dovrebbe almeno ricevere un codice di errore, l’indicazione dell’amministrazione competente e una procedura digitale per aprire la segnalazione.

Perché non basta usare sempre il codice fiscale

La soluzione apparentemente più semplice consiste nell’abbandonare il confronto tra nome e cognome e usare soltanto un identificativo stabile. È un principio corretto nella progettazione dei database: una persona non dovrebbe avere come chiave primaria il proprio nome, perché esistono omonimi, variazioni ortografiche e cambi anagrafici.

Il codice fiscale presenta però alcuni limiti: deriva da nome, cognome, data, sesso e luogo di nascita; può contenere lettere sostitutive per risolvere i casi di omocodia e, in presenza di dati errati o rettificati, richiede procedure di aggiornamento.

Il database di ANPR non nasce con il limite delle sole lettere ASCII: le specifiche tecniche prevedono l’uso di UTF-8 e pubblicano tabelle dedicate ai caratteri diacritici, con indicazioni sulle possibili traslitterazioni. Tra i caratteri contemplati figurano proprio le vocali usate nei nomi tedeschi.

ANPR dispone inoltre di identificativi interni non costruiti a partire dal nome. Collegare stabilmente l’anagrafica della Motorizzazione a un identificativo univoco nazionale ridurrebbe molti problemi, ma richiederebbe regole di interoperabilità, migrazioni controllate e procedure per gestire i record che non trovano una corrispondenza certa. Non è un’aggiunta da fare con una colonna aggiunta in modo improvvisato.

La soluzione più robusta combina più elementi: un identificatore non ambiguo per il collegamento, il mantenimento della grafia legale originale e controlli sugli attributi anagrafici che non dipendano da una semplice uguaglianza carattere per carattere. Nei casi dubbi serve un processo di riconciliazione assistito, non il blocco definitivo dell’utente dietro un criptico messaggio generico.