Entitetsløsning blir AI-infrastruktur, ikke datarengjøring

For en stund siden så jeg en AI-agent gi et selvbevisst feil svar av en helt vanlig grunn. Et firma hadde to poster for samme kunde. Den ene posten inneholdt det gamle handelsnavnet og en finansekontakt. Den andre posten inneholdt det nye juridiske navnet selskapet hadde tatt etter en fusjon, samt en annen fakturaadresse. Agenten ble spurt en enkel spørsmål: er denne kontoen i god stand? Den fant en post, så ingen forfalte fakturaer og sa ja. De forfalte fakturaene var registrert under det andre navnet.

Ingenting var hallucinert. Modellen resonnerte rent over dataene den hadde fått. Dataene skjedde bare å beskrive to kunder der det i virkeligheten var en. Feilen lå ikke i språkmodellen. Den lå i sammenføyningen.

Jeg har kommet til å tenke at dette er en av de mest undervurderte risikoene i bedrifts-AI, og en av de minst diskuterte. Vi snakker uendelig om modellnøyaktighet, promptdesign og styring. Vi snakker mye mindre om om systemet faktisk vet hvilken virkelige kunde, leverandør eller konto det handler om. Det spørsmålet har et navn. Det kalles entitetsløsning, og etter seksti år i bakgrunnen er det stille og rolig blitt en del av live-infrastrukturen.

Problemet endret tid

For det meste av sin arbeidsliv har “er disse to postene samme enhet?” vært et rengjørings-spørsmål. Du kjørte det i en batch, på en plan, et sted inne i et master data management-program, et lager eller en analytics-pipeline. Det var aldri fullkommen, men det var overlevbart, fordi utdata var en rapport noen leste neste uke. Hvis to poster for samme leverandør ikke ble slått sammen, kom en utgiftsfigur ut litt feil, en analytiker merket det og det ble fikset i neste kjør. Systemet hadde slakk i det. Tiden absorberte feilene.

En AI-agent fjerner den slakken. Den endrer spørsmålets tid fra “til slutt” til “nå”. Når en agent er på vei til å godkjenne en refusjon, dirigere en sak, oppdatere en profil eller svare på et samsvarsspørsmål, er den løste enheten ikke lenger en del av en rapport. Den er en del av en handling. Kostnaden av en feil sammenføyning går fra et tall som er litt feil til noe som skjer i verden, umiddelbart, og ofte uten noen menneskelig kontroll til å fange det.

Det er skiftet verdt å sitte med. Det underliggende problemet er gammelt og godt forstått. Hva som er nytt er at vi har koblet det direkte til systemer som handler på egen hånd.

Et 1960-talls statistikkproblem

Entitetsløsning kom ikke med store språkmodeller. Den kom med hullkort. I 1959 publiserte H. B. Newcombe og hans kolleger en kort artikkel i Science om automatisk sammenkobling av viktige poster, som beskrev hvordan en datamaskin kunne bestemme om en fødselspost og en ekteskapspost refererte til samme person. Et tiår senere ga Ivan Fellegi og Alan Sunter ideen en formell matematisk teori, som definerte de tre resultater ethvert sammenkoblingssystem fremdeles produserer i dag: en kobling, en ikke-kobling og en mulig kobling som en person må gjennomgå.

Det er en detalj i den linjen som er verdt å dvile på, fordi det er det folk oftest får feil. Post-sammenkobling var aldri bare eksakt sammenføyning på en e-postadresse eller en felles ID. Fra begynnelsen var det probabilistisk. Det vurderte bevisene for at to poster var enige om en etternavn, en dato, en plass og produserte en score, fordi menneske-innputtede data er uordentlige og eksakte nøkler svikter konstant. Moderne entitetsløsning fungerer fortsatt på denne måten. Den kombinerer deterministiske regler, der en felles stabil identifikator er avgjørende, med probabilistiske og fuzzy maskinlærings-sammenføyning som håndterer skrivefeil, kallenavn, omvendte felt, forkortelser og de mange små måtene samme person eller selskap viser seg forskjellig på tvers av systemer. En god oversikt over feltet sporer en uavbrutt linje fra disse 1950-talls viktige postene til klustering- og maskinlærings-metodene som brukes nå.

Hva som virkelig har endret seg er når vi trenger svaret. Forskere skrev om å løse enheter på spørsmålstid, snarere enn bare på forhånd, lenge før den nåværende bølgen av AI. Da var det en interessant optimalisering. Nå er det nærmere et krav.

Hvorfor agenter gjør det til infrastruktur

De fleste bedrifts-AI-systemer svarer ikke fra modellens minne. De henter. Mønsteret som er populært som henting-forsterket generering har en agent som henter relevante kontekst i øyeblikket spørsmålet stilles og resonnere over det. Dette er, på balance, en god ting. Det grunner svarene i dine data snarere enn modellens trening.

Men det medfører en konsekvens som er lett å overse. Agenten arver hva hentingssteget gir den. Hvis henting returnerer en fragmentert kunde, tre delvise poster som aldri ble koblet sammen, vil agenten resonnere over tre kunder. Hvis henting returnerer en feil koblet sammen, to forskjellige selskaper kollapset til en enkelt profil, vil agenten resonnere over en. Usikkerheten som allerede sitter i dine kilde-systemer blir overført rett gjennom og presentert for modellen som en fast sannhet. Modellen har ingen måte å vite sammenføyningen var feil, like lite som du ville, leser en ryddig sammenfatning av poster du aldri hadde sett.

Så løsning kan ikke være en ettertanke som kjøres en gang i kvartalet og lander i en separat tabell. Enheten må bli satt sammen når data innhentes, og den nåværende løste visningen av den må være hentbar i øyeblikket agenten spør. Det er en kjøretids-avhengighet. Det oppfører seg mye mer som en database eller en autentiserings-tjeneste enn som et periodisk data-rengjøringsprosjekt, og det må bli designet, overvåket og betrodd på samme måte du ville behandle ethvert annet system din applikasjon kaller i sanntid.

Den beredskaps-gapet ingen navngir nøyaktig

Bransjen føler allerede at noe mangler her. Ciscos AI-beredskapsindeks 2025 fant at 83 prosent av organisasjonene planlegger å distribuere autonome agenter, mens bare omkring en tredjedel føler at deres infrastruktur virkelig er klar for dem, og bare omkring en fjerdedel føler seg utstyrt til å kontrollere og styre hva disse agentene faktisk gjør. McKinseys siste AI-tilstand-undersøkelse beskriver en lignende gap fra den andre siden: omtrent 88 prosent av organisasjonene bruker nå AI i minst en funksjon, men de fleste har ikke skalert det over hele bedriften.

Når folk forklarer det gapet, tenderer de å nå til to ord: datakvalitet og styring. Begge er viktige, og ingen av dem er valgfrie. Men det er et smalere spørsmål som ligger under dem som ren, godt styrt data ikke svare på av seg selv. Kan systemet si hvilken virkelige enhet en gitt post refererer til, på tvers av alle steder den posten bor, nå? Du kan holde høykvalitetsdata i hvert enkelt system og likevel feile den testen, fordi feilen ikke bor inne i noen enkelt system. Den bor i mellomrommene mellom dem, hvor samme kunde bærer tre litt forskjellige ansikter.

Hva å sjekke før du lar en agent handle

Hvis du behandler entitetsløsning som live-infrastruktur, kan du inspisere det som infrastruktur. De operative feilmodusene er spesifikke og testbare: splittede identiteter som burde være en, feil sammenføyninger av poster som burde forbli adskilte, utdaterte overlevelsesregler som fortsatt fremmer en erstattet adresse, manglende varige identifikatorer og agenter som arver kilde-system-usikkerhet som om det var løst faktum.

En praktisk beredskapstest trenger ikke en ny modell eller en ny leverandør-kategori. Sammenstill en bakgrunns-sannhet-samling av enheter du virkelig forstår. Kjør det gjennom samme hentings-sti din agent bruker, ikke en separat ren kopi bygget for demoen. Deretter måle tingene som virkelig bestemmer resultater: hvor mange feil sammenføyninger og feil splitt, hvordan systemet håndterer ekte usikkerhet, hvor dens tillitsnivåer sitter, når den eskalerer til en menneskelig i stedet for å gjette, og hvordan det håndterer over til dine eksisterende master data og styringskontroller. Hvis et team ikke kan svare på disse spørsmålene, handler agenten på en identitet den ikke kan verifisere, og tillit til utdata er misplassert.

Ingenting av dette erstatter master data-styring, styring, kunde-data-plattformer eller lageret. Disse svare på forskjellige spørsmål, og de forblir nødvendige. Styring bestemmer hva en agent er tillatt å gjøre. Entitetsløsning bestemmer hvem eller hva det gjør det til. Den første er moden i de fleste store organisasjoner. Den andre er laget mange er på vei til å oppdage de trenger ved siden av det, i sanntid, øyeblikket de lar en agent handle snarere enn råd.

Agenten jeg så trengte ikke en smartere modell. Den trengte å vite at to navn var en kunde før den var tillatt å høres sikker. Når vi gir disse systemene virkelig autoritet til å handle, stopper den stille, seksti år gamle disiplinen å være rengjøring og begynner å bli bærende.