Dun & Bradstreet har taget sin berømte Commercial Graph, den med 642 millioner virksomhedsregistre, og bygget den om. Ikke fordi dataene var dårlige. Tværtimod. Men fordi alt var designet til mennesker, der kan vente, afklare tvetydigheder og slå op igen i morgen. AI‑agenter kan ikke. De går i stå efter 800 millisekunder og spørger ikke pænt igen.
Vi hørte første gang om ændringen via VentureBeat, og det er ikke en lille justering. D&B har flyttet fra en samling af systemer til et samlet, agent‑venligt knowledge graph‑lag. Samme data, ny form, nye grænseflader. For at passe ind i produktion med agenter, der træffer beslutninger i kredit, procurement og supply chain.
Hvor stort er det egentlig
D&Bs Commercial Graph dækker 642 millioner virksomheder på globalt plan. Relationer, hierarkier, risikoprofiler. Ifølge D&B er der omkring 11.000 felter per post. Det er massivt. De kører omtrent 100 milliarder datakvalitetschecks pr. måned, mens posterne flyder gennem systemerne. Og det hele har serviceret tæt på 200.000 kunder, før rebuildet overhovedet gik i gang.
Det er tal, der er svære at sætte i perspektiv. Jeg noterede mig bare, da vi testede et lille udsnit for en kunde sidste år, at CSV’en vejede som en mursten, og min blæser i Mac’en lød som metroen ved Nørreport kl. 8. Ikke særligt videnskabeligt. Men man forstår presset på latenstid.
Hvorfor menneskedesign var et problem for agenter
Ifølge VentureBeat var den oprindelige arkitektur ikke én samlet database, men en mosaik af systemer stykket sammen med specialintegrationer. Det er fint for mennesker, som kan bruge tid på at hoppe mellem interfaces, køre en SQL, ringe til kollegaen i Polen og løse en match‑tvivl. Agenter gør ingen af delene. De kræver sub‑sekund svartid og entydige svar.
Et andet problem var relationernes natur. De var i høj grad statiske. En CEO var forbundet til en virksomhed. Punktum. Men i agent‑workflows er relationer dynamiske: skifter CEO, hvor følger track record hen. Når et datterselskab skifter ejer, hvordan slår det ud i hele hierarkiet. Før løste en analytiker det som særkørsel. Agenter venter ikke på særkørsler.
Hvad D&B faktisk byggede om
D&B konsoliderede til skyen, redesignede skemaet, lagde et data‑fabric‑lag ovenpå og samlede det hele i et unified knowledge graph. Sådan beskrives det i artiklen. Målet var normaliserede poster på tværs af markeder, uden at tabe lokale regler og krav til datasuverænitet eller compliance.
Ovenpå grafen kom et struktureret adgangslag rettet mod agenter. Ikke rå SQL i stor skala, men veldefinerede grænseflader til de mest almindelige opgaver. Og bag hver forespørgsel sidder en match‑ og entitetsopløsningsmotor, så et firmanavn ikke bare matcher på lydlighed, men på verificeret entitet. Det er i øvrigt præcis der, vi har set flest fejl i produktion hos kunder.
Data fabric, normalisering og agent‑spørgbarhed i praksis
Lad os være ærlige. Begreberne flyver hurtigt. Et data fabric, som D&B beskriver det, er et tværlag, der ensretter adgang, governance og katalog på tværs af kilder. I praksis betyder det standardiserede skemaer, centrale politikker og ensartede nøgler, så det samme CVR‑lignende id betyder det samme, uanset om du rammer kredit, salg eller risiko.
At normalisere poster betyder at fjerne duplikater, standardisere felter og sikre konsistente relationer. Hos D&B taler vi om 11.000 felter per post. Det kræver governance, ikke heltemod. Agent‑spørgbarhed er i bund og grund forudsigelige svar med lav latenstid, klare fejltilstande og deterministisk entitetsopløsning. Tradeoffet er klassisk: mere konsistens og berigelse kan øge latenstid og omkostning. Man betaler for orden.
Sub‑sekund svartid og de realistiske kompromiser
VentureBeat beskriver målet om sub‑sekund. Vi ved ikke, om det gælder alle forespørgsler og alle regioner. Der er ingen åbne benchmarks. Sandsynligt billede fra vores egen drift: cache og materialiserede udsnit til simple opslag, mens komplekse relationelle hop forbliver langsommere eller rulles som batch‑forberedte svar. Det er fint, hvis man bygger sine agent‑playbooks derefter.
Og ja, realtid koster. Streaming og kontinuerlig enrichment presser compute. Men når man fjerner manuelle reviews i storskala kredit eller leverandør‑screening, flytter regnestykket sig ofte positivt. Ikke altid. Vi har sagt nej til realtid hos en finanskunde, der kun modtog leverandørændringer én gang dagligt. Ingen grund til evig strøm, når kilden drypper.
Hvad ændrer sig for kunderne
Når grafen bliver agent‑venlig, går automationen fra talk til praksis. Procurement‑bots kan slå leverandører op, vurdere risiko og eskalere kun de uklare sager. Kreditassistenter kan hente nøgletal, ejerskabskæder og negativ hændelseshistorik, og lave en udkast‑beslutning på sekunder. Tredjeparts‑risk kan køre kontinuerligt i baggrunden i stedet for kvartalsvise rapporter.
Workflows skal dog omlægges. API‑gateways skal kunne håndtere spikes fra agenter. Caching skal være bevidst designet: hvornår må data være 5 minutter gamle, hvornår ikke. SLA’er bliver skarpere, for nu sidder en agent og venter. Og supporten ændrer karakter, fordi incidents ikke kan vente på menneskelig triage. Observability skal ned på felt‑niveau med entitets‑proveniens og versioner.
Implementeringsknaster der typisk vælter vognen
Governance: Når relationer bliver dynamiske, skal hver ændring have kilde, tidsstempel og begrundelse. Ellers kan man ikke forklare beslutningerne bagefter. API‑design: Et rent REST‑lag er sjældent nok; kunder ender ofte med en blanding af veldefinerede endpoints, søge‑endpoints og et event‑feed til ændringer.
Embeddings kontra relationelle forespørgsler: Semantiske søgninger er stærke til fuzzy match, men entitetsidentitet og hierarkier kræver hårde nøgler. Den hybride arkitektur opstår af sig selv. Omkostning og compute: Kontinuerlig kvalitetssikring, match‑tuning og retraining sluger budget. Rul frem, men hav en rollback og en migrationssti for skemaversioner. Der er altid et felt, der ikke skulle have været udfaset i tirsdags.
Snillds erfaring fra felten
Vi har set den samme historie hos tre store kunder det sidste år. Data var bygget til rapporter, ikke til agenter. I én bank forsøgte vi at automatisere kreditgrænser for erhverv. Første uge i produktion gav fine svar kl. 10 og timeouts kl. 13, fordi match‑engine og notifikationskø trak i hver sin retning. Løsningen blev triviel i bagklogskab: materialiseret entitetsindeks kl. 5 og en strammere backoff‑strategi.
Et andet sted, i logistik, brændte vi fingrene på tværregionale regler. De lokale compliance‑krav gjorde, at samme leverandør havde forskellige synligheder i to regioner. Uden et fabric‑lag, der bar reglerne med, gik agenterne i ring. Det er det rigtige i D&B’s tilgang, efter min mening: compliance må ligge i data‑laget, ikke i 27 klienter.
Konkurrence og økosystemet omkring agenter
D&B er ikke alene om at bygge om for agenter. Det hører vi igen og igen i netværket. VentureBeat citerer Gary Kotovets for, at han har talt med hundreder af CDO’er og CIO’er, som famler med samme rod: grunddata der ikke er standardiseret, normaliseret eller spørgbar for maskiner. Det er genkendeligt, også i Norden.
Parallelt rører platformene på sig. OpenAI åbner nu et Applied AI Lab i Singapore, og landet opdaterer rammer for agentisk AI. Ikke noget bevis for D&B’s påstande naturligvis, men et tegn i retning af mere agent‑drift i produktionen. Flere virksomheder vil forvente, at deres dataudbydere leverer agent‑klare feeds og identitetsmodeller.
Sikkerhed, identitet og compliance i maskineland
Én menneskelig konto skalerer ikke til tusind små agenter. Ifølge VentureBeat indfører D&B en særskilt registrerings- og nøglemodel for agentadgang, koblet ind i samme governance‑pipeline som mennesker. Det giver mening. Når maskiner er forbrugere, bliver de også aktører med ansvar.
Compliance følger efter. Hvis regionale regler siger, at enkelte felter skal sløres eller kun må bruges i bestemte formål, må data‑laget selv håndhæve det. Det er her, provenance, audit‑logs og politikker per felt bliver forskellen på et lækkert demo og en løsning, der kan blive stående i revisionen. Jeg blev faktisk i tvivl om, hvordan D&B håndterer historik helt ned i relationernes slæbespor, når en leder skifter selskab. Det står ikke udfoldet.
Økonomi og produktformer der giver mening
Når et knowledge graph bliver agent‑venligt, ændrer forretningen sig. API‑first er oplagt, men kunder vil også spørge efter streaming af ændringer, event‑feeds, måske endda embeddings‑som‑tjeneste for bedre match og kontekst. Spørgsmålet er prisen. VentureBeat siger ikke, hvordan D&B vil prissætte det nye. Vi forventer differentierede SLA‑pakker og forbrugsbaserede modeller, fordi latenstid og throughput er det nye guld.
Man kan også forestille sig nye SLA‑parametre: entitetsopløsnings‑nøjagtighed, maksimale fejlprocenter for felter i bestemte domæner, og klare SLO’er for propagation af ejerskabsændringer. Ikke pynt. Det er det, agenterne bygger antagelser på.
Tre korte råd hvis du selv står med en stor kommerciel graf
Først, lav en nøgtern datamodenhedsvurdering. Hvor mange felter er faktisk i spil, hvor mange er dubletter, og hvad er jeres entitetsnøgler. Derefter en prøvebelastning mod realistiske agent‑workloads. Ikke Hello World, men 90. percentil‑forespørgslerne. Tredje, sæt governance‑værn før I går i produktion: provenance, versionsstyring af skema og politikker for caching og tilbageførsel.
Og ja, byg et lille POC. I to uger, ikke to måneder. Fald i det første hul, mens faldet stadig er lavt. Det er sjovere sådan. Eller, mindre smertefuldt.
Det vi stadig ikke ved
Der er åbne spørgsmål. Vi har ingen offentlige arkitekturdiagrammer fra D&B. Ingen konkrete valg af database‑motorer, indeksstrategier eller caching‑lag. Sub‑sekund løfterne er ikke underbygget med benchmarks på tværs af query‑typer og regioner. Hvordan håndteres historik og provenance, når relationer er dynamiske. Og hvad med prissætning, når agent‑venlige API’er eller streams bliver normen.
Det er fair at bede om en teknisk hvidbog eller et datasheet. Indtil da må vi læse det pragmatisk: D&B har flyttet en menneskeorienteret gigant til en mere maskine‑tolerant form. Det er i sig selv en stor bedrift. Resten står og falder med implementeringen hos kunderne.
Konklusion uden pynt
For os er læringen klar. Verdensklasse‑data er ikke nok, hvis arkitekturen taler menneske. Når kunder skubber agenter ind i beslutninger, skal data være normaliserede, spørgbare og hurtige. D&B’s rebuild går i den retning og adresserer de rigtige smerter: fragmentering, identitet, entitetsopløsning, compliance.
Start småt, mål latenstid og kvalitet på rigtige forespørgsler, og byg governance ind fra begyndelsen. Man opdager først forskellen, når man sidder med det i hænderne.
Kilder og noter
Primær kilde: VentureBeat, “D&B’s database of 642 million businesses was built for humans, not AI agents. So they rebuilt it.” Artiklen dækker størrelsen på Commercial Graph, vækst fra 300+ mio. til 642 mio. poster over fem år, ca. 11.000 felter pr. post, ca. 100 mia. kvalitetstjek pr. måned, samt citater og vurderinger fra Gary Kotovets om agent‑behov og rebuild‑årsag.
Ekstra perspektiv: Nyheden om OpenAI’s Applied AI Lab i Singapore og opdaterede rammer for agentisk AI bruges her alene som kontekst for øget agent‑adoption, ikke som dokumentation for D&B‑påstande.
Snillds erfaringer: De konkrete implementeringsobservationer er anonymiserede og baseret på vores egne projekter. De understøtter ikke D&B’s faktapåstande, men forklarer praktiske konsekvenser i enterprise‑miljøer.
