De database van D&B met 642 miljoen bedrijven is gebouwd voor mensen, niet voor AI-agenten. Dus hebben ze het herbouwd.

Dun & Bradstreet heeft meer dan 180 jaar besteed aan het opbouwen van een uitgebreide commerciële database. De Commercial Graph, die 642 miljoen bedrijven en hun relaties, bedrijfshiërarchieën en risicoprofielen omvat, is ontworpen voor mensen. Kredietanalisten, risicomanagers en verkoopprofessionals die konden wachten op de resultaten van zoekopdrachten en dubbelzinnige entiteitsmatches konden verwerken. AI-agenten kunnen al deze dingen niet doen.

Toen de klanten van D&B agenten begonnen te betrekken bij krediet-, inkoop- en supply chain-workflows, werd de Commercial Graph, die op betrouwbare wijze bijna 200.000 klanten wereldwijd had bediend, een probleem. De systemen die waren gebouwd om menselijke analisten te dienen, hadden de verkeerde architectuur voor machines. Dus D&B herbouwd.

“We moeten agenten beschouwen als onze nieuwe consumentencategorie, die evolueert van onze standaard kredietanalisten of verkoop- en marketingprofessionals, enzovoort, naar nu ook de agenten van deze klanten bedienen”, vertelde Gary Kotovets, Chief Data and Analytics Officer bij Dun & Bradstreet, aan VentureBeat.

Wat er kapot ging toen agenten vragen begonnen te stellen

De Commercial Graph was geen enkele database. Het was een verzameling afzonderlijke systemen, gebouwd voor verschillende gebruiksscenario’s en verschillende markten, bij elkaar gehouden door aangepaste integraties. Menselijke analisten hebben door die fragmentatie genavigeerd via SQL-query’s of vooraf gebouwde interfaces. Agenten konden dat niet.

De omvang van de onderliggende gegevens verergerde het probleem. Volgens D&B is de database in vijf jaar bijna verdubbeld, van ruim 300 miljoen naar ruim 642 miljoen bedrijfsrecords, met 11.000 velden per record. Het bedrijf voert nu ongeveer 100 miljard gegevenskwaliteitscontroles per maand uit terwijl de gegevens door zijn systemen gaan. De vraag die agenten bij de latentie van minder dan een seconde nodig hebben, was in een gefragmenteerde architectuur niet werkbaar.

De relaties die de grafiek bijhield, waren ook van het verkeerde soort. Oudere systemen registreerden statische verbindingen tussen entiteiten. Een CEO werd aan een bedrijf gekoppeld. Dat was de lijn. Agenten die zich bezighouden met kredietbeoordelingen of risico’s van derden hebben dynamische relaties nodig: wanneer die CEO naar een nieuw bedrijf vertrekt, welke organisatie volgt dan hun trackrecord? Wanneer een dochteronderneming van eigenaar verandert, hoe verspreidt zich dat dan binnen de bedrijfshiërarchie? Voor die vragen was voorheen maatwerk van analisten nodig. Agenten kunnen niet wachten op analistenwerk op maat.

Het bredere probleem is niet uniek voor D&B. Kotovets zei dat hij de afgelopen zes maanden met honderden CDO’s en CIO’s heeft gesproken en consequent dezelfde beperking heeft gehoord: ze konden niet bouwen wat ze wilden in AI, omdat hun databasis niet gestandaardiseerd, genormaliseerd of door agenten te doorzoeken was. D&B had die basis, die decennialang was opgebouwd om menselijke analisten te dienen. Het moest nog worden herbouwd voor agenten.

Wat ze daadwerkelijk hebben gebouwd

De wederopbouw begon met consolidatie. D&B migreerde zijn gefragmenteerde databases naar de cloudinfrastructuur, herontworpen het onderliggende schema en bouwde een datafabric-laag die records in verschillende markten normaliseert, terwijl de regionale nalevingsvereisten behouden blijven. Het resultaat is een uniforme kennisgrafiek die miljarden relaties bij 642 miljoen bedrijven bijhoudt, voortdurend bijgewerkt en verrijkt door AI-gestuurde gegevensverwerking.

Bovenop die grafiek heeft D&B een gestructureerde toegangslaag voor agenten gebouwd. Ruwe SQL-toegang tot queryvolumes en latentievereisten van agenten was niet de oplossing. In plaats daarvan creëerde D&B een reeks tools en vaardigheden die via MCP beschikbaar zijn en die gegevens met context bundelen en agenten naar de juiste records leiden voor specifieke vragen. Achter elke zoekopdracht zit een engine voor het oplossen van overeenkomsten en entiteiten, die bevestigt dat wanneer een agent naar een bedrijf vraagt, het antwoord wordt omgezet in een geverifieerde, specifieke entiteit in plaats van in een naammatch.

D&B loste de identiteit van agenten vanuit beide richtingen op

Het opnieuw opbouwen van de grafiek en het toevoegen van MCP-toegang loste het probleem op met het ophalen van gegevens. Het loste het identiteitsprobleem niet op. Agenten zijn geen mensen, en het authenticatiemodel dat voor menselijke gebruikers is gebouwd, strekte zich niet uit tot machines.

D&B bouwde een nieuw registratiemodel voor agenten. Ze moeten een geverifieerd IP-adres koppelen en een individuele toegangssleutel registreren, die wordt behandeld als een geverifieerde identiteit in dezelfde pijplijn als een menselijke gebruiker.

“We hebben eigenlijk een concept van Know Your Agent, vergelijkbaar met ‘Ken uw klant’, dat deze aanvullende verificaties uitvoert”, zei Kotovets.

Dat lost het inkomende probleem op: weten tot welk bedrijf een agent behoort en welke gegevens hij mag opvragen. Maar D&B heeft ook gebouwd voor het uitgaande probleem: wat er gebeurt als de eigen multi-agentworkflow van een klant niet meer weet welk bedrijf hij analyseert.

In een workflow die een kredietcontroleagent, een KYC-agent en een externe risicoagent aan elkaar koppelt, ondervraagt ​​elk D&B in een andere stap. Zonder een mechanisme om te bevestigen dat ze allemaal naar dezelfde entiteit verwijzen, kan een workflow worden voltooid terwijl met uiteenlopende records wordt gewerkt.

“Ze moeten terugkomen naar onze verificatieagent om er zeker van te zijn dat ze nog steeds met elkaar over dezelfde entiteit praten”, zei Kotovets. “Het lijkt in zekere zin bijna op een digitale handdruk.”

De bedrijfsverificatieagent van D&B kan als permanent referentiepunt in elke workflow worden ingebed en is beschikbaar via het A2A-protocol van Google, ongeacht welke orkestratietool een klant gebruikt.

Vier dingen die bedrijven goed moeten regelen voordat ze AI-agenten inzetten

De herbouw bracht eisen aan het licht die verder gaan dan de eigen stack van D&B.

1. Gegevensverzamelingen komen vóór agentinfrastructuur. De CDO’s en CIO’s waarmee Kotovets de afgelopen zes maanden sprak, stuitten consequent op dezelfde muur: ze kunnen niet bouwen wat ze willen in AI totdat hun gegevens schoon, genormaliseerd en geconsolideerd zijn. D&B had die basis al. De meeste ondernemingen doen dat niet, en zullen dat ook merken.

2. Ontwerp voor dynamische relaties, niet voor statische relaties. Enterprise-datasystemen registreren doorgaans point-in-time-verbindingen: een persoon behoort tot een bedrijf, een asset behoort tot een dochteronderneming. Agenten die zich bezighouden met krediet-, risico- of supply chain-beslissingen moeten redeneren over relaties die in de loop van de tijd veranderen. Als de onderliggende gegevens alleen de statische lijn vastleggen, zal de agent dat ook doen.

3. Bouw controles op de consistentie van entiteiten in workflows voor meerdere agenten. Wanneer meerdere agenten bij verschillende stappen dezelfde entiteit aanraken, is er geen garantie dat ze allemaal naar hetzelfde record verwijzen tegen de tijd dat de workflow is voltooid. Er moet expliciet rekening worden gehouden met die kloof. Entiteitsverificatie is een vereiste voor het ontwerp van de workflow, en geen optionele vangrail.

4. Integreer afkomst vanaf het begin, niet als een bijzaak. Elk door een agent geproduceerd antwoord moet een traceerbaar pad terug naar de bron bevatten. Bij beslissingen op het gebied van krediet, risico en supply chain zijn de kosten van een fout concreet. Lineage moet worden ingebouwd voordat er wordt geschaald, en niet worden toegevoegd nadat problemen aan het licht komen.

“Je kunt altijd klikken en zien waar het vandaan komt, en het valideren tot aan de oorspronkelijke bron”, zei Kotovets. “Dat is voor ons de sleutel geweest bij het ontsluiten van veel andere mogelijkheden, omdat we dat niveau van zekerheid hebben in de dingen die we hebben gedaan.”