Il database di Dun & Bradstreet non era fatto per gli AI agent. Così lo hanno ricostruito.

Dun & Bradstreet ha passato oltre 180 anni a costruire il suo database commerciale. Il Commercial Graph copre 642 milioni di aziende, con relazioni, gerarchie e profili di rischio. Era stato pensato per persone: analisti del credito, risk manager, professionisti delle vendite, capaci di aspettare i risultati delle query e districarsi tra corrispondenze ambigue.

Gli AI agent non sanno fare nessuna di queste cose.

Quando i clienti di D&B hanno iniziato a inserire agenti nei flussi di lavoro di credito, approvvigionamento e supply chain, il Commercial Graph — che serviva fedelmente quasi 200.000 clienti in tutto il mondo — è diventato un problema. I sistemi costruiti per analisti umani avevano l’architettura sbagliata per le macchine. Così D&B ha ricostruito tutto.

“Dobbiamo pensare agli agent come a una nuova categoria di consumatori”, ha detto Gary Kotovets, Chief Data and Analytics Officer di Dun & Bradstreet, a VentureBeat. “Non più solo analisti del credito o professionisti delle vendite, ma anche gli agenti di questi clienti.”

Cosa si è rotto quando gli agent hanno iniziato a fare domande

Il Commercial Graph non era un database singolo. Era un insieme di sistemi separati, costruiti per casi d’uso e mercati diversi, tenuti insieme da integrazioni personalizzate. Gli analisti umani navigavano quella frammentazione con query SQL o interfacce predefinite. Gli agent non potevano.

La scala del problema era enorme. In cinque anni il database è quasi raddoppiato, passando da oltre 300 milioni a più di 642 milioni di record aziendali, con 11.000 campi per record. D&B esegue circa 100 miliardi di controlli di qualità al mese mentre i record attraversano i suoi sistemi. Fare query con latenza sub-secondo — come richiedono gli agent — su un’architettura frammentata era impossibile.

Anche le relazioni tracciate dal grafo erano sbagliate. I sistemi legacy registravano connessioni statiche: un CEO collegato a un’azienda, punto. Gli agent che lavorano su valutazioni del credito o rischi di terze parti hanno bisogno di relazioni dinamiche: quando quel CEO si sposta in un’altra azienda, la sua storia segue? Quando una cambia proprietà, come si propaga nella gerarchia aziendale? Prima erano domande che richiedevano lavoro manuale. Gli agent non possono aspettare.

Kotovets ha detto di aver parlato con centinaia di CDO e CIO negli ultimi sei mesi. Sentiva sempre lo stesso limite: non potevano costruire quello che volevano con l’AI perché le loro fondamenta dati non erano standardizzate, normalizzate o interrogabili da un agente.

Cosa hanno costruito

La ricostruzione è partita dalla consolidazione. D&B ha migrato i database frammentati su cloud, ridisegnato lo schema e costruito un layer di data fabric che normalizza i record tra mercati diversi mantenendo i requisiti normativi locali. Il risultato è un knowledge graph unificato che traccia miliardi di relazioni tra 642 milioni di aziende, aggiornato continuamente con processi AI.

Sopra quel grafo, D&B ha costruito un layer di accesso strutturato per gli agent. L’accesso SQL diretto — ai volumi e latenze richiesti — non era la risposta. Invece, D&B ha creato un set di strumenti e skill disponibili tramite MCP (Model Context Protocol) che impacchettano dati con contesto e indirizzano gli agent ai record giusti per ogni query. Un motore di entity resolution conferma che quando un agente chiede informazioni su un’azienda, la risposta si riferisce a un’entità verificata, non solo a un nome corrispondente.

Il problema dell’identità, da due lati

Ricostruire il grafo e aggiungere MCP ha risolto il problema del recupero dati. Ma non quello dell’identità. Gli agent non sono umani, e il modello di autenticazione costruito per utenti umani non funzionava per le macchine.

D&B ha costruito un nuovo modello di registrazione per gli agent. Ogni agente deve mapparsi a un indirizzo IP verificato e registrare una chiave di accesso individuale, trattata come identità autenticata nello stesso flusso di un utente umano.

“Abbiamo un concetto di Know Your Agent, simile al know your customer, che fa queste verifiche aggiuntive”, ha detto Kotovets.

Quello risolve il problema in entrata: sapere a quale azienda appartiene un agente e a quali dati ha diritto. Ma D&B ha risolto anche il problema in uscita: cosa succede quando il flusso multi-agente di un cliente perde traccia di quale azienda sta analizzando.

In un flusso che incatena un agente di controllo del credito, uno KYC e uno per il rischio terze parti, ognuno interroga D&B in un momento diverso. Senza un meccanismo per confermare che si riferiscano tutti alla stessa entità, il flusso può completarsi operando su record divergenti.

“Devono tornare al nostro agente di verifica per assicurarsi di parlare ancora della stessa entità”, ha detto Kotovets. “È come una stretta di mano digitale.” L’agente di verifica business di D&B può essere integrato in qualsiasi flusso come punto di riferimento persistente ed è disponibile sul protocollo A2A di Google, indipendentemente dallo strumento di orchestrazione usato dal cliente.

Quattro cose che le imprese devono fare prima di usare AI agent

La ricostruzione di D&B ha evidenziato requisiti che vanno oltre il suo stack. Le fondamenta dati vengono prima dell’infrastruttura per agent. I CDO e CIO con cui Kotovets ha parlato si scontravano sempre con lo stesso muro: non possono costruire nulla nell’AI finché i dati non sono puliti, normalizzati e consolidati. D&B aveva già quelle fondamenta. La maggior parte delle imprese no.

Progetta per relazioni dinamiche, non statiche. I sistemi aziendali registrano connessioni in un punto nel tempo: una persona appartiene a un’azienda, un cespite appartiene a una filiale. Gli agent che lavorano su credito, rischio o supply chain devono ragionare su relazioni che cambiano nel tempo. Se i dati catturano solo la linea statica, lo farà anche l’agente.

Inserisci controlli di consistenza delle entità nei flussi multi-agente. Quando più agenti toccano la stessa entità in momenti diversi, non c’è garanzia che si riferiscano allo stesso record al termine del flusso. Va progettato esplicitamente. La verifica delle entità è un requisito di design del flusso, non un guardrail opzionale.

Incorpora la provenance fin dall’inizio, non dopo. Ogni risposta prodotta da un agente deve avere un percorso tracciabile fino alla sua fonte. Nelle decisioni di credito, rischio e supply chain, il costo di un errore è concreto. La provenienza va costruita prima di scalare, non aggiunta dopo che i problemi emergono.

“Puoi sempre cliccare e vedere da dove viene, e validare fino alla fonte originale”, ha detto Kotovets. “Quella è stata la chiave per sbloccare molte altre capacità: avere quel livello di certezza in quello che abbiamo fatto.”