Anagrafiche duplicate: usare l’AI per proporre correzioni senza fondere record per errore

Parliamo del tuo progetto →

A chi serve e che cosa risolve

Questa guida è pensata per responsabili operations, amministrazione, data quality, IT e per chi governa anagrafiche di clienti, fornitori, partner o controparti.

Il bisogno è semplice: ridurre i doppioni senza fondere due soggetti diversi per errore. L’AI qui non decide al posto vostro: propone soltanto i casi da verificare. La decisione finale resta umana e il master data non viene toccato finché non c’è approvazione.

La base tecnica è quella dei dati tabellari. Il W3C Tabular Data Model descrive dati organizzati in tabelle con metadati, validazione e identificatori univoci di riga; se una chiave primaria è duplicata, la validazione deve segnalare l’errore. Da questa base si può costruire un processo di revisione, ma la deduplicazione anagrafica resta una decisione di business.

Alla fine avrai:

  • un dataset sintetico CSV con 6 record, da R01 a R06;
  • un prompt copiabile da dare all’AI;
  • un output JSON di proposta con tre esiti possibili: POSSIBILE_DUPLICATO, DISTINTI, DATI_INSUFFICIENTI;
  • un registro decisionale compilabile senza toccare il master data;
  • un criterio finale per l’approvazione umana.

Cosa ti serve prima di iniziare

Strumenti

  • un editor di testo o un foglio di calcolo;
  • un ambiente AI che accetti prompt testuali e restituisca JSON o testo strutturato;
  • una tabella di appoggio separata dal master data;
  • un registro condiviso per le decisioni umane.

Prerequisiti

  • conoscere il campo chiave del vostro archivio, qui simulato come record_id;
  • sapere quali campi sono affidabili per il confronto;
  • avere una regola interna che vieti la fusione automatica senza revisione umana;
  • lavorare su dati simulati o anonimizzati, non su anagrafiche reali con informazioni sensibili non autorizzate.

Materiale fornito in questa guida

  1. CSV completo con 6 record sintetici.
  2. Prompt completo da copiare.
  3. JSON atteso di esempio.
  4. Registro compilato dei casi.
  5. Checklist finale e troubleshooting.

1. Prepara il dataset di lavoro senza toccare il master data

Lavora in una copia separata, non nel sistema sorgente. L’obiettivo non è “pulire tutto subito”, ma creare un campione controllato che permetta all’AI di proporre casi sospetti senza alterare i record originali.

File di lavoro simulato: CSV completo

record_id,ragione_sociale,identificativo_fittizio,localita,recapito
R01,Alfa Servizi S.r.l.,ACME-001,Milano,info@example.invalid
R02,ALFA SERVIZI SRL,ACME-001,Milano,amministrazione@example.invalid
R03,Alfa Servizi Nord S.r.l.,ACME-019,Milano,nord@example.invalid
R04,Beta Logistica S.p.A.,BETA-120,Torino,contatti@example.invalid
R05,Beta Logistica Italia S.p.A.,BETA-121,Torino,ufficio@example.invalid
R06,Delta Studio Cooperativa,DELTA-550,Bologna,team@example.invalid

Cosa osservare

  • R01 e R02 hanno una corrispondenza forte: stesso identificativo, stessa località, differenze soprattutto formali nella ragione sociale.
  • R04 e R05 hanno nomi simili ma identificativi diversi: è il caso in cui l’AI può sbagliare se guarda solo la stringa del nome.
  • R03 è vicino come nome, ma non abbastanza per dedurre un duplicato.

Se il risultato non coincide

Se il CSV viene importato male nel foglio di calcolo, controlla separatore, codifica e intestazioni. Se una colonna sparisce o si sposta, fermati: un errore di struttura qui produce deduzioni sbagliate dopo.

2. Normalizza per confronto, non per sostituzione

Prima di inviare il campione all’AI, crea colonne derivate per il confronto, ma non cambiare mai i valori originali. La normalizzazione serve solo a rendere più visibili somiglianze e differenze: minuscole, spazi multipli, abbreviazioni societarie e punteggiatura possono essere uniformate solo nella copia di lavoro.

Colonne derivate consigliate

  • ragione_sociale_norm
  • identificativo_fittizio_norm
  • localita_norm
  • recapito_norm

Esempio di normalizzazione simulata

record_id ragione_sociale ragione_sociale_norm
R01 Alfa Servizi S.r.l. alfa servizi srl
R02 ALFA SERVIZI SRL alfa servizi srl
R05 Beta Logistica Italia S.p.A. beta logistica italia spa

Cosa osservare

  • R01 e R02 sembrano quasi identici dopo normalizzazione.
  • R04 e R05 restano simili ma non uguali.
  • R03 non diventa automaticamente un duplicato di R01 solo perché contiene le parole “Alfa” e “Servizi”.

Se il risultato non coincide

Se la copia normalizzata inizia a sostituire l’originale, torna indietro. La regola è: normalizzare non prova l’identità delle aziende. Il testo pulito aiuta il confronto, ma non autorizza il merge.

3. Usa un prompt che obbliga l’AI a proporre, non a fondere

Il prompt deve limitare il comportamento del modello. Se chiedi “trova i duplicati”, alcuni sistemi tendono a semplificare o a suggerire azioni troppo aggressive. Meglio chiedere una classificazione esplicita e imporre l’output strutturato.

Prompt copiabile

Sei un assistente per la revisione di anagrafiche aziendali.
Ricevi un CSV con campi: record_id, ragione_sociale, identificativo_fittizio, localita, recapito.

Obiettivo:
- proporre solo i casi da verificare manualmente;
- non fondere record;
- non sovrascrivere i dati sorgente;
- non inventare informazioni mancanti;
- non considerare la sola normalizzazione come prova di identità.

Classifica ogni record o coppia di record in uno di questi esiti:
- POSSIBILE_DUPLICATO
- DISTINTI
- DATI_INSUFFICIENTI

Regole:
1. Se identificativo_fittizio è identico e la ragione sociale cambia solo per maiuscole, spazi, abbreviazioni o punteggiatura, segna POSSIBILE_DUPLICATO.
2. Se il nome è simile ma l’identificativo_fittizio è diverso, segna DISTINTI oppure DATI_INSUFFICIENTI solo se manca un criterio affidabile per decidere.
3. Se i dati non bastano, spiega cosa manca.
4. Restituisci solo output strutturato JSON.
5. Includi sempre la motivazione breve.
6. Indica quali record vanno sottoposti al responsabile umano.

Formato JSON richiesto:
{
  "proposte": [
    {
      "coppia": ["R01", "R02"],
      "esito": "POSSIBILE_DUPLICATO",
      "motivo": "...",
      "da_sottoporre_al_responsabile": true
    }
  ],
  "record_singoli": [
    {
      "record_id": "R06",
      "esito": "DISTINTI",
      "motivo": "..."
    }
  ]
}

Cosa osservare

Un buon output non sposta il focus sulla “risposta giusta”, ma su una proposta verificabile. L’AI deve restituire motivazioni brevi e deve citare gli identificativi originali, senza inventare nuove entità.

Caso normale

Se dai il CSV completo, il modello dovrebbe proporre R01 ↔ R02 come possibile duplicato e lasciare gli altri casi come distinti o non conclusivi.

Caso con dato mancante

Se rimuovi identificativo_fittizio da R01 e R02, il modello non dovrebbe forzare il merge. L’esito corretto diventa DATI_INSUFFICIENTI o una motivazione di prudenza. Se invece inventa un’identità, il prompt non è abbastanza vincolante.

Se il risultato non coincide

Aggiungi una frase esplicita: “Se non sei sicuro, scegli DATI_INSUFFICIENTI e spiega quale campo manca”. Questo riduce i falsi positivi più dei prompt generici.

4. Valida l’output: controlla le tre classi e blocca i merge

Una volta ricevuto il JSON, fai un controllo meccanico prima della revisione umana. Non cercare ancora di “risolvere” il problema: verifica solo se la proposta è sana.

Esempio simulato di output atteso

{
  "proposte": [
    {
      "coppia": ["R01", "R02"],
      "esito": "POSSIBILE_DUPLICATO",
      "motivo": "Stesso identificativo fittizio ACME-001, stessa località, differenze solo formali nella ragione sociale.",
      "da_sottoporre_al_responsabile": true
    },
    {
      "coppia": ["R04", "R05"],
      "esito": "DISTINTI",
      "motivo": "Nome simile ma identificativo fittizio diverso: BETA-120 e BETA-121. La somiglianza testuale non basta per fondere i record.",
      "da_sottoporre_al_responsabile": false
    },
    {
      "coppia": ["R03", "R04"],
      "esito": "DISTINTI",
      "motivo": "Località e identificativi diversi; la parola comune 'Servizi' non è sufficiente per ipotizzare un duplicato.",
      "da_sottoporre_al_responsabile": false
    }
  ],
  "record_singoli": [
    {
      "record_id": "R06",
      "esito": "DISTINTI",
      "motivo": "Nessuna corrispondenza forte con altri record presenti nel campione."
    }
  ]
}

Controlli di accettazione

  • ogni proposta usa record_id originali;
  • nessun campo è stato riscritto;
  • nessuna coppia è stata fusa in un record sintetico;
  • gli esiti usano solo le tre etichette previste;
  • i casi da sottoporre al responsabile sono marcati con chiarezza.

Se il risultato non coincide

Rifiuta l’output se compare qualcosa come R01+R02, un record nuovo o un campo riscritto. In quel caso il modello non sta facendo analisi: sta facendo trasformazione del dato, che qui è vietata.

5. Gestisci il caso normale e il caso con informazione mancante

A questo punto fai lavorare il laboratorio su due percorsi: uno normale e uno problematico. Serve per capire se la regola regge quando i dati sono buoni e quando invece mancano pezzi.

Percorso normale

  • R01 ↔ R02 → POSSIBILE_DUPLICATO
  • R04 ↔ R05 → DISTINTI
  • R03 ↔ R04 → DISTINTI
  • R06 → DISTINTI

Percorso con dato mancante

Togli il campo identificativo_fittizio a R01 e R02 e rilancia il prompt. Il modello dovrebbe cambiare atteggiamento: non può più basarsi sulla chiave più forte, quindi deve scegliere DATI_INSUFFICIENTI oppure motivare con prudenza.

Esempio di motivazione corretta in caso mancante

  • “Manca un identificativo affidabile per confrontare con sufficiente sicurezza.”
  • “La somiglianza del nome non basta a distinguere due soggetti con certezza.”

Esempio di errore da correggere

  • “Sono lo stesso cliente, quindi unisci i record.”
  • “Il nome è simile, quindi il duplicato è certo.”

Se il risultato non coincide

Se il modello forza comunque una fusione, il processo è troppo permissivo. Torna al prompt e aggiungi un vincolo: “Se il dato chiave manca, non dedurre l’identità”.

6. Registra la decisione umana senza sovrascrivere il sorgente

Il compito dell’AI finisce alla proposta. La decisione finale resta umana e va registrata in una tabella separata, non nel master data. Questo è il punto che evita gli errori più costosi.

Registro compilato dei casi: esempio simulato

Caso Record Esito AI Decisione umana Motivo finale Va al responsabile?
1 R01 ↔ R02 POSSIBILE_DUPLICATO Approvato come duplicato Stesso identificativo, differenze solo formali Sì
2 R04 ↔ R05 DISTINTI Confermato distinto Nome simile ma identificativi diversi No
3 R03 ↔ R04 DISTINTI Confermato distinto Nessuna prova forte di identità No
4 R06 DISTINTI Confermato distinto Nessuna corrispondenza rilevante nel campione No
5 R01 ↔ R02 senza identificativo DATI_INSUFFICIENTI Rimandato Mancano elementi affidabili per fondere Sì

Cosa osservare

Il registro deve servire a tre domande:

  1. chi ha deciso;
  2. su quali elementi;
  3. con quale esito.

Se il risultato non coincide

Se la decisione finale è scritta dentro il master data senza traccia separata, stai perdendo auditabilità. In quel caso crea un registro dedicato con data, responsabile, esito, motivazione e riferimento ai record_id.

7. Troubleshooting e prova finale ripetibile

Qui non cerchi una dimostrazione perfetta: cerchi una prova che si possa rifare uguale e che produca lo stesso tipo di controllo.

Troubleshooting rapido

Problema: l’AI propone troppi duplicati

  • Verifica: il prompt lascia troppe libertà sui criteri.
  • Correzione: imponi che identificativo_fittizio sia il primo criterio e che la normalizzazione non valga come identità.

Problema: l’AI restituisce testo discorsivo

  • Verifica: manca il vincolo “solo JSON”.
  • Correzione: chiedi output strutturato e rifiuta risposte narrative.

Problema: il team vuole un merge automatico

  • Verifica: manca una regola di governance.
  • Correzione: separa proposta AI, revisione umana e aggiornamento del master data.

Problema: i dati reali contengono informazioni sensibili

  • Verifica: il dataset non è stato anonimizzato.
  • Correzione: lavora su campi minimizzati o dati di prova; se il caso reale richiede dati sensibili, serve una regola interna chiara prima di usare l’AI.

Prova finale ripetibile

Per chiudere il laboratorio, ripeti questa sequenza senza cambiare nulla:

  1. carica il CSV simulato;
  2. genera le colonne di normalizzazione;
  3. incolla il prompt;
  4. ottieni il JSON;
  5. verifica che non esistano merge o riscritture;
  6. compila il registro decisionale.

Criteri di successo finali

  • il caso R01 ↔ R02 è il solo candidato forte a POSSIBILE_DUPLICATO;
  • R04 ↔ R05 resta distinto;
  • i casi incerti non vengono forzati;
  • il master data non cambia finché una persona non approva;
  • ogni proposta è rintracciabile ai record originali.

Se il flusso supera questi controlli, l’AI sta facendo il suo lavoro corretto: proporre correzioni, non decidere al posto vostro.

Collegamenti utili per estendere il processo

Se vuoi inserire questo laboratorio in un flusso più ampio di governo dei dati e delle automazioni, può essere utile partire da AI responsabile per imprese, processi e automazioni, proseguire con Sviluppo software su misura e integrazioni quando il controllo va integrato in un gestionale o in un portale, e rifinire la parte di adozione con AI benefit e automazione responsabile.

Questi collegamenti non sostituiscono il laboratorio: servono a collocarlo dentro una governance reale, in cui la proposta dell’AI è solo un passaggio del processo e non una decisione automatica.

Fonti