La risoluzione delle entità sta diventando un’infrastruttura di intelligenza artificiale, non una pulizia dei dati

Un po’ di tempo fa ho visto un agente di intelligenza artificiale dare una risposta confidenziale ma completamente errata per una ragione estremamente banale. Un’azienda aveva due record per lo stesso cliente aziendale. Uno conteneva il vecchio nome commerciale e un contatto finanziario. L’altro conteneva il nuovo nome legale che l’azienda aveva adottato dopo un’acquisizione, insieme a un indirizzo di fatturazione diverso. All’agente è stata posta una semplice domanda: questo account è in buona posizione? Ha trovato un record, ha visto che non c’erano fatture scadute e ha detto sì. Le fatture scadute erano state archiviate con l’altro nome.

Nessuno ha immaginato nulla. Il modello ha ragionato in modo pulito sui dati che gli erano stati forniti. I dati si sono semplicemente riferiti a due clienti dove, nel mondo reale, ce n’era uno solo. L’errore non stava nel modello di linguaggio. Stava nel join.

Sono arrivato a pensare che questo sia uno dei rischi più sottovalutati nell’intelligenza artificiale aziendale e uno dei meno discussi. Parliamo incessantemente dell’accuratezza del modello, della progettazione della richiesta e della governance. Parliamo molto meno del fatto che un sistema sappia effettivamente quale entità del mondo reale stia agendo su. Quella domanda ha un nome. Si chiama risoluzione delle entità e, dopo sessant’anni in secondo piano, sta silenziosamente diventando un pezzo di infrastruttura attiva.

Il problema ha cambiato tempo

Per la maggior parte della sua vita lavorativa, “questi due record sono la stessa entità?” era una domanda di pulizia. La si eseguiva in batch, su un programma, all’interno di un programma di gestione dei dati principali, di un magazzino o di un flusso di analisi. Non era mai perfetta, ma era sopravvivibile, perché l’output era un report che qualcuno leggeva la settimana successiva. Se due record dello stesso fornitore non venivano uniti, un numero di spesa usciva leggermente sbagliato, un analista se ne accorgeva e veniva corretto nella prossima esecuzione. Il sistema aveva un margine di errore. Il tempo assorbiva gli errori.

Un agente di intelligenza artificiale rimuove quel margine di errore. Cambia il tempo della domanda da “alla fine” a “adesso”. Quando un agente sta per approvare un rimborso, instradare un caso, aggiornare un profilo o rispondere a una domanda di conformità, l’entità risolta non alimenta più un cruscotto. Alimenta un’azione. Il costo di un join errato passa da un numero leggermente fuori posto a qualcosa che accade nel mondo, immediatamente, e spesso senza alcun intervento umano per fermarlo.

Questo è il cambiamento che vale la pena considerare. Il problema di base è vecchio e ben compreso. Ciò che è nuovo è che lo abbiamo collegato direttamente a sistemi che agiscono da soli.

Un problema statistico degli anni ’60

La risoluzione delle entità non è arrivata con i grandi modelli di linguaggio. È arrivata con le schede perforate. Nel 1959, H. B. Newcombe e i suoi colleghi hanno pubblicato un breve articolo su Science sul collegamento automatico dei registri vitali, descrivendo come un computer potesse decidere se un registro di nascita e un registro di matrimonio si riferivano alla stessa persona. Un decennio dopo, Ivan Fellegi e Alan Sunter hanno dato all’idea una teoria matematica formale, definendo i tre risultati che qualsiasi sistema di corrispondenza produce ancora oggi: un collegamento, un non-collegamento e un collegamento possibile che una persona deve esaminare.

C’è un dettaglio in quella discendenza che vale la pena considerare, perché è la parte che le persone si sbagliano più spesso. Il collegamento dei record non è mai stato solo un abbinamento esatto su un indirizzo e-mail o un ID condiviso. Fin dall’inizio è stato probabilistico. Ha pesato le prove che due record concordavano su un cognome, una data, un luogo e ha prodotto un punteggio, perché i dati immessi dagli esseri umani sono disordinati e le chiavi esatte falliscono costantemente. La moderna risoluzione delle entità funziona ancora in questo modo. Combina regole deterministiche, dove un identificatore stabile condiviso è decisivo, con l’abbinamento probabilistico e fuzzy del machine learning che gestisce errori di battitura, soprannomi, campi trasposti, abbreviazioni e le dozzine di piccoli modi in cui la stessa persona o azienda appare diversamente attraverso i sistemi. Un buon saggio sul campo traccia una linea ininterrotta da quei registri vitali degli anni ’50 ai metodi di clustering e machine learning utilizzati ora.

Ciò che è realmente cambiato è quando abbiamo bisogno della risposta. I ricercatori scrivevano sulla risoluzione delle entità al momento della query, piuttosto che solo in anticipo, molto prima dell’attuale ondata di intelligenza artificiale. All’epoca era un’ottimizzazione interessante. Ora è più vicina a un requisito.

Perché gli agenti lo trasformano in infrastruttura

La maggior parte dei sistemi di intelligenza artificiale aziendale non risponde dalla memoria del modello. Recupera. Il modello popolarizzato come generazione aumentata dalla ricerca ha un agente che recupera il contesto rilevante al momento della domanda e ragiona su di esso. Questo è, nel complesso, una buona cosa. Radica le risposte nei tuoi dati piuttosto che nell’addestramento del modello.

Ma comporta una conseguenza che è facile perdere di vista. L’agente eredita tutto ciò che il passaggio di recupero gli consegna. Se il recupero restituisce un cliente frammentato, tre record parziali che non sono mai stati collegati, l’agente ragionerà su tre clienti. Se il recupero restituisce un’unione errata, due aziende diverse collassate in un solo profilo, l’agente ragionerà su uno. L’ambiguità già presente nei sistemi di origine viene passata direttamente e presentata al modello come fatto stabilito. Il modello non ha modo di sapere che l’unione era errata, proprio come non lo sapresti leggendo un riassunto ordinato di record che non avevi mai visto.

Quindi la risoluzione non può essere un ripensamento che si esegue una volta al quarto e atterra in una tabella separata. L’entità deve essere assemblata quando i dati vengono inghiottiti e la vista attuale risolta di essa deve essere recuperabile nel momento in cui l’agente chiede. Questo è un requisito di runtime. Si comporta molto più come un database o un servizio di autenticazione che come un progetto di pulizia dei dati periodico, e deve essere progettato, monitorato e considerato allo stesso modo in cui tratteresti qualsiasi altro sistema che la tua applicazione chiama in tempo reale.

Il divario di prontezza che nessuno sta nominando precisamente

L’industria già avverte che qualcosa manca qui. L’indice di prontezza all’intelligenza artificiale di Cisco del 2025 ha scoperto che l’83% delle organizzazioni pianifica di distribuire agenti autonomi, mentre solo circa un terzo si sente pronto con la propria infrastruttura e solo circa un quarto si sente in grado di controllare e governare cosa facciano effettivamente quegli agenti. La più recente indagine di McKinsey sullo stato dell’intelligenza artificiale descrive un divario simile dall’altra direzione: circa l’88% delle organizzazioni utilizza ora l’intelligenza artificiale in almeno una funzione, eppure la maggior parte non l’ha ancora estesa in tutta l’azienda.

Quando le persone spiegano quel divario, tendono a ricorrere a due parole: qualità dei dati e governance. Entrambe sono importanti e nessuna è facoltativa. Ma c’è una domanda più stretta che si nasconde sotto di loro che i dati puliti e ben governati non rispondono da soli. Il sistema può dire quale entità del mondo reale un determinato record si riferisce a, in tutti i luoghi in cui quel record vive, proprio adesso? Puoi tenere dati di alta qualità in ogni sistema individuale e comunque fallire in quel test, perché il fallimento non vive all’interno di un sistema. Vive negli spazi tra di loro, dove lo stesso cliente indossa tre volti leggermente diversi.

Cosa controllare prima di far agire un agente

Se si tratta la risoluzione delle entità come infrastruttura attiva, è possibile ispezionarla come infrastruttura. I modi di guasto operativi sono specifici e verificabili: identità divise che dovrebbero essere una, fusioni false di record che dovrebbero rimanere separati, regole di sopravvivenza obsolete che continuano a promuovere un indirizzo superato, identificatori persistenti mancanti e agenti che ereditano l’ambiguità del sistema di origine come se fosse verità risolta.

Un test di prontezza pratico non richiede un nuovo modello o una nuova categoria di fornitori. Assembla un set di entità di cui hai una vera comprensione. Esegui il percorso di recupero che utilizza il tuo agente, non una copia pulita separata costruita per la demo. Quindi misura le cose che decidono effettivamente gli esiti: quanti falsi abbinamenti e false divisioni, come gestisce l’ambiguità reale, dove si trovano le sue soglie di confidenza, quando si rivolge a un umano invece di indovinare e come si passa pulitamente ai tuoi controlli di gestione dei dati e governance esistenti. Se un team non può rispondere a quelle domande, l’agente sta agendo su un’identità che non può verificare e la fiducia nella sua output è mal riposta.

Nessuna di queste sostituisce la gestione dei dati principali, la governance, le piattaforme di dati dei clienti o il magazzino. Quelli rispondono a domande diverse e rimangono necessari. La governance decide cosa è consentito fare a un agente. La risoluzione delle entità decide a chi o a cosa lo sta facendo. Il primo è maturo nella maggior parte delle grandi organizzazioni. Il secondo è lo strato che molte stanno per scoprire di aver bisogno accanto a esso, in tempo reale, nel momento in cui si lascia agire un agente piuttosto che consigliare.

L’agente che ho visto non aveva bisogno di un modello più intelligente. Doveva sapere che due nomi erano un cliente prima di poter suonare sicuro. Mentre affidiamo a questi sistemi un’autorità reale per agire, quella disciplina silenziosa e vecchia di sessant’anni cessa di essere una pulizia e inizia a essere portante.