Entitetsløsning bliver til AI-infrastruktur, ikke datarensning

For nylig så jeg en AI-agent give et selvbevidst forkert svar af en helt banal grund. Et firma havde to poster for den samme kunde. Den ene post indeholdt det gamle handelsnavn og en finanskontakt. Den anden post indeholdt det nye lovlige navn, som firmaet havde antaget efter en fusion, samt en anden faktureringsadresse. Agenten blev spurgt om en simpel spørgsmål: Er denne konto i god stand? Den fandt en post, så ingen forfaldne fakturaer og sagde ja. De forfaldne fakturaer var registreret under det andet navn.

Intet var hallucineret. Modellen resonerede rent over de data, den fik. Dataene tilfældigt beskrev to kunder, hvor der i virkeligheden kun var én. Fejlen lå ikke i sprogmodellen. Den lå i sammenlægningen.

Jeg er begyndt at tro, at dette er en af de mest underestimerede risici i virksomheds-AI, og en af de mindst diskuterede. Vi taler uendeligt om modelpræcision, prompt-design og styring. Vi taler langt mindre om, hvorvidt et system faktisk ved, hvilken virkelige kunde, leverandør eller konto det handler om. Det spørgsmål har et navn. Det hedder entitetsløsning, og efter 60 år i baggrunden er det stille og roligt ved at blive til en del af live-infrastrukturen.

Problemet skiftede tid

I det meste af sin arbejdsliv var “er disse to poster den samme enhed?” et rensningsspørgsmål. Du kørte det i en batch, på en fast sat tid, et sted inde i et masterdatastyringsprogram, et lager eller en analytics-pipeline. Det var aldrig perfekt, men det var overleveligt, fordi outputtet var en rapport, som nogen læste næste uge. Hvis to poster for den samme leverandør ikke var sammenføjet, kom en udgiftssum forkert ud, en analytiker lagde mærke til det, og det blev rettet i næste kørsel. Systemet havde en vis fleksibilitet. Tiden absorberede fejlene.

En AI-agent fjerner den fleksibilitet. Den skifter tidsperspektivet for spørgsmålet fra “til sidst” til “nu”. Når en agent er på vej til at godkende en refusion, dirigere en sag, opdatere en profil eller besvare et compliance-spørgsmål, er den løste enhed ikke længere en del af en dashboard. Den er en del af en handling. Omkostningerne ved en forkert sammenlægning skifter fra et tal, der er lidt forkert, til noget, der sker i verden, øjeblikkeligt, og ofte uden nogen menneskelig indgriben til at fange det.

Det er det skift, der er værd at sidde med. Det underliggende problem er gammelt og velkendt. Det nye er, at vi har koblet det direkte til systemer, der handler på egen hånd.

Et statistikproblem fra 1960’erne

Entitetsløsning ankom ikke med store sprogmodeller. Den ankom med hullkort. I 1959 offentliggjorde H. B. Newcombe og hans kolleger en kort artikel i Science om automatisk sammenkædning af vigtige poster, hvor de beskrev, hvordan en computer kunne afgøre, om en fødselspost og en ægteskabspost henviser til den samme person. Et årti senere gav Ivan Fellegi og Alan Sunter ideen en formel matematisk teori, der definerer de tre resultater, som ethvert matchningssystem stadig producerer i dag: en sammenkædning, en ikke-sammenkædning og en mulig sammenkædning, som en person skal gennemgå.

Der er en detalje i den afstamning, der er værd at dvæle ved, fordi det er det, folk oftest gør forkert. Post-sammenkædning var aldrig kun en eksakt sammenligning af en e-mail-adresse eller en fælles ID. Fra begyndelsen var det probabilistisk. Det vejede beviset for, at to poster var enige om et efternavn, en dato, en placering, og producerede en score, fordi menneske-indtastet data er beskidt, og eksakte nøgler fejler konstant. Moderne entitetsløsning fungerer stadig på den måde. Den kombinerer deterministiske regler, hvor en fælles stabil identifier er afgørende, med probabilistiske og fuzzy maskinlæringsmatchning, der kan håndtere stavfejl, kælenavne, ombyttede felter, forkortelser og de mange små måder, en person eller virksomhed viser sig forskelligt på tværs af systemer. En god gennemgang af feltet tegner en uafbrudt linje fra disse 1950’ernes vigtige poster til de klusterings- og maskinlæringsmetoder, der bruges nu.

Hvad der virkelig er ændret, er, hvornår vi har brug for svaret. Forskere skrev om at løse enheder på forespørgselstidspunkt og ikke kun på forhånd, længe før den nuværende bølge af AI. Dengang var det en interessant optimering. Nu er det tættere på et krav.

Hvorfor agenter gør det til infrastruktur

De fleste virksomheds-AI-systemer besvarer ikke fra modellens hukommelse. De henter. Mønsteret, der er populært som hentningsforstærket generering, har en agent, der henter relevant kontekst i øjeblikket for spørgsmålet og resonere over det. Det er, på balance, en god ting. Det grundlægger svarene i jeres data snarere end i modellens træning.

Men det medfører en konsekvens, der er let at overse. Agenten arver alt, hvad hentningstrinet giver den. Hvis hentning returnerer en fragmenteret kunde, tre delvise poster, der aldrig er forbundet, vil agenten resonere over tre kunder. Hvis hentning returnerer en forkert sammenføjet, to forskellige virksomheder sammenføjet til en enkelt profil, vil agenten resonere over én. Den tvetydighed, der allerede sidder i jeres kilde-systemer, overføres direkte og præsenteres for modellen som en fastsat sandhed. Modellen har ingen mulighed for at vide, at sammenlægningen var forkert, ligesom du ikke ville, hvis du læste en pæn sammenfatning af poster, du aldrig havde set.

Så løsning kan ikke være en eftertanke, der kører en gang om kvartalet og lander i en separat tabel. Enheden skal samles, når data indtages, og den aktuelle løste visning af den skal være tilgængelig i øjeblikket, agenten spørger. Det er en runtime-afhængighed. Det opfører sig langt mere som en database eller en autentificeringstjeneste end som et periodisk data-rengøringsprojekt, og det skal være designet, overvåget og betroet på samme måde, som du ville behandle ethvert andet system, din applikation kalder i realtid.

Det beredskabsgap, som ingen nævner præcist

Branchen føler allerede, at noget mangler her. Ciscos AI-beredskabsindeks 2025 fandt, at 83 procent af organisationerne planlægger at implementere selvstændige agenter, mens kun omkring en tredjedel føler, at deres infrastruktur er ægte parat til det, og kun omkring en fjerdedel føler sig udstyret til at kontrollere og styre, hvad disse agenter faktisk gør. McKinseys seneste AI-tilstand-undersøgelse beskriver et lignende gap fra den anden side: omtrent 88 procent af organisationerne bruger i dag AI i mindst én funktion, men de fleste har ikke skaleret det på tværs af virksomheden.

Når folk forklarer dette gap, når de ofte hen til to ord: datakvalitet og styring. Begge er vigtige, og ingen af dem er valgfri. Men der er et smallere spørgsmål, der ligger under dem, som rent, velstyret data ikke selv besvarer. Kan systemet fortælle, hvilken virkelig enhed en given post refererer til, på tværs af alle de steder, hvor posten lever, lige nu? Du kan have højkvalitetsdata i hvert enkelt system og alligevel fejle denne test, fordi fejlen ikke bor i noget enkelt system. Den bor i mellemrummene mellem dem, hvor den samme kunde bærer tre lidt forskellige ansigter.

Hvad du skal tjekke, før du lader en agent handle

Hvis du behandler entitetsløsning som live-infrastruktur, kan du inspicere den som infrastruktur. De operationelle fejltyper er specifikke og testbare: split-personligheder, der skal være én, forkerte sammenføjninger af poster, der skal forblive adskilt, forældede overlevelsesregler, der stadig fremhæver en afløst adresse, manglende bestående identifikatorer og agenter, der arver kilde-systemets tvetydighed, som om det var en fastsat sandhed.

En praktisk beredskabs-test kræver ikke en ny model eller en ny leverandørkategori. Saml en grund-sandheds-sæt af enheder, du virkelig forstår. Kør det gennem den samme hentningssti, din agent bruger, ikke en separat ren kopi bygget til demo-formålet. Mål derefter de ting, der faktisk afgør resultaterne: hvor mange forkerte sammenføjninger og forkerte split, hvordan systemet håndterer ægte tvetydighed, hvor dens tillidsgrænser sidder, hvornår den eskalerer til et menneske i stedet for at gætte, og hvordan den rengøres til jeres eksisterende masterdata og styringskontroller. Hvis et hold ikke kan besvare disse spørgsmål, handler agenten på en identitet, den ikke kan verificere, og tilliden til dens output er misplaceret.

Ingenting her erstatter masterdatastyring, styring, kunde-data-platforme eller lageret. Disse besvarer andre spørgsmål og forbliver nødvendige. Styring afgør, hvad en agent er tilladt at gøre. Entitetsløsning afgør, hvem eller hvad det handler om. Den første er moden i de fleste store organisationer. Den sidste er laget, mange er på vej til at opdage, de har brug for ved siden af, i realtid, øjeblikket de lader en agent handle i stedet for at rådgive.

Agenten, jeg så, havde ikke brug for en klogere model. Den havde brug for at vide, at to navne var én kunde, før den var tilladt at lyde sikker. Da vi giver disse systemer reel myndighed til at handle, holder den stille, 60 år gamle disciplin op med at være rensning og begynder at bære last.