Entitetsupplösning blir AI-infrastruktur, inte datarengöring

För ett tag sedan såg jag en AI-agent ge ett självsäkert felaktigt svar av en helt ointressant anledning. Ett företag hade två poster för samma företagskund. Den ena innehöll det gamla handelsnamnet och en finanskontakt. Den andra innehöll det nya juridiska namnet som företaget antagit efter en förvärv, tillsammans med en annan faktureringsadress. Agenten fick en enkel fråga: är detta konto i gott skick? Den hittade en post, såg inga förfallna fakturor och sa ja. De förfallna fakturorna var registrerade under det andra namnet.

Ingenting var hallucinerat. Modellen resonerade rent över de data den fick. Data händer att beskriva två kunder där det i verkligheten finns en. Felet var inte i språkmodellen. Det var i kopplingen.

Jag har börjat tro att detta är en av de mest underskattade riskerna inom företags-AI och en av de minst diskuterade. Vi pratar oändligt om modellens noggrannhet, promptdesign och styrning. Vi pratar mycket mindre om huruvida systemet faktiskt vet vilken verklig kund, leverantör eller konto det agerar på. Den frågan har ett namn. Det kallas entitetsupplösning, och efter sextio år i bakgrunden förvandlas det tyst till en del av levande infrastruktur.

Problemet ändrade tempus

Under större delen av sin arbetsliv har “är dessa två poster samma enhet?” varit en rengöringsfråga. Du körde den i batch, enligt schemat, någonstans inuti ett masterdatahanteringsprogram, ett lager eller en analyspipeline. Det var aldrig perfekt, men det var överlevningsdugligt, eftersom utdata var en rapport som någon läste nästa vecka. Om två poster för samma leverantör inte sammanfogades, blev en utgiftssiffra lite fel, en analytiker lade märke till det och det fixades i nästa körning. Systemet hade ett utrymme i sig. Tiden absorberade felen.

En AI-agent tar bort det utrymmet. Den ändrar tempus för frågan från “till slut” till “nu”. När en agent är på väg att godkänna en återbetalning, dirigera ett ärende, uppdatera en profil eller svara på en fråga om regelefterlevnad, är den upplösta entiteten inte längre en rapport som matar en instrumentpanel. Den matar en åtgärd. Kostnaden för en felaktig koppling flyttas från en siffra som är lite fel till något som händer i världen, omedelbart, och ofta utan någon mänsklig inblandning för att fånga det.

Det är den förändringen som är värd att sitta med. Det underliggande problemet är gammalt och väl förstått. Vad som är nytt är att vi har kopplat det direkt till system som agerar på egen hand.

1960-talets statistikproblem

Entitetsupplösning anlände inte med stora språkmodeller. Den anlände med hålkort. 1959 publicerade H. B. Newcombe och hans kollegor en kort artikel i Science om automatisk länkning av viktiga register, där de beskrev hur en dator kunde bestämma om en födelsepost och ett äktenskapsregister hänvisade till samma person. Ett decennium senare gav Ivan Fellegi och Alan Sunter idén en formell matematisk teori, som definierade de tre resultaten som varje matchningssystem fortfarande producerar idag: en länk, en icke-länk och en möjlig länk som en person behöver granska.

Det finns en detalj i den här härstamningen som är värd att fokusera på, eftersom det är den del som människor oftast får fel. Postlänkning var aldrig bara exakt matchning på en e-postadress eller en delad ID. Från början var det probabilistiskt. Det vägde bevisen för att två poster var överens om ett efternamn, ett datum, en plats och producerade en poäng, eftersom mänskligt inmatade data är smutsigt och exakta nycklar misslyckas konstant. Modern entitetsupplösning fungerar fortfarande på det här sättet. Den kombinerar deterministiska regler, där en delad stabil identifierare är avgörande, med probabilistiska och fuzzy maskinlärningsmatchning som hanterar stavfel, smeknamn, omvända fält, förkortningar och de dussintals små sätt som samma person eller företag dyker upp olika på olika system. En bra översikt av fältet spårar en oavbruten linje från de där 1950-talets viktiga register till kluster- och maskinlärningsmetoderna som används nu.

Vad som verkligen har förändrats är när vi behöver svaret. Forskare skrev om att lösa enheter vid frågetid, snarare än enbart i förväg, långt innan den nuvarande AI-vågen. Då var det en intressant optimering. Nu är det närmare ett krav.

Varför agenter förvandlar det till infrastruktur

De flesta företags-AI-system svarar inte från modellens minne. De hämtar. Mönstret som populariserats som retrieval-förstärkt generering har en agent som hämtar relevant sammanhang i ögonblicket av frågan och resonerar över det. Det är, i balans, en bra sak. Det grundar svar i dina data snarare än modellens utbildning.

Men det medför en konsekvens som är lätt att missa. Agenten ärver allt som hämtningssteget ger den. Om hämtning returnerar en fragmenterad kund, tre delvis poster som aldrig anslöts, kommer agenten att resonera om tre kunder. Om hämtning returnerar en felaktigt sammanfogad, två olika företag som kollapsade till en enda profil, kommer agenten att resonera om en. Den ambiguitet som redan finns i dina källsystem passerar rakt igenom och presenteras för modellen som fastställd sanning. Modellen har inget sätt att veta att kopplingen var fel, lika lite som du skulle, om du läser en snygg sammanfattning av poster du aldrig sett.

Så upplösning kan inte vara en eftertanke som körs en gång i kvartalet och hamnar i en separat tabell. Enheten måste sättas samman när data hämtas, och den aktuella upplösta vy av den måste vara hämtningsbar i ögonblicket agenten frågar. Det är en runtime-begränsning. Det beter sig mycket mer som en databas eller en autentiseringstjänst än som ett periodiskt datarengöringsprojekt, och det måste utformas, övervakas och litas på samma sätt som du skulle behandla vilket annat system din applikation anropar i realtid.

Beredskapsgapet som ingen exakt namnger

Branschen känner redan att något saknas här. Ciscos AI-beredskapsindex 2025 fann att 83 procent av organisationerna planerar att distribuera autonoma agenter, medan bara cirka en tredjedel känner att deras infrastruktur verkligen är redo för dem, och bara runt en fjärdedel känner sig utrustade för att kontrollera och styra vad dessa agenter faktiskt gör. McKinseys senaste AI-tillstånd-undersökning beskriver ett liknande gap från den andra riktningen: cirka 88 procent av organisationerna använder AI i minst en funktion, men de flesta har inte skalat det över hela företaget.

När människor förklarar det gapet, tenderar de att nå efter två ord: datakvalitet och styrning. Båda är viktiga, och ingen är valfri. Men det finns en smalare fråga som ligger under dem som ren, välstyrd data inte svarar på egen hand. Kan systemet säga vilken verklig enhet en given post hänvisar till, över alla de platser där posten lever, just nu? Du kan ha högkvalitativa data i varje enskilt system och fortfarande misslyckas med den testen, eftersom felet inte bor inuti något system. Det bor i utrymmet mellan dem, där samma kund bär tre något olika ansikten.

Vad du ska kontrollera innan du låter en agent agera

Om du behandlar entitetsupplösning som levande infrastruktur kan du inspektera det som infrastruktur. De operativa felmoderna är specifika och testbara: splittrade identiteter som borde vara en, felaktiga sammanfogningar av poster som borde förbli separata, föråldrade överlevnadsregler som fortsätter att främja en föråldrad adress, saknade bestående identifierare och agenter som ärver källsystemets ambiguitet som om det vore fastställd sanning.

En praktisk beredskapstest kräver inte en ny modell eller en ny leverantörskategori. Samla en grund-sanningssamling av enheter du verkligen förstår. Kör det genom samma hämtningsväg som din agent använder, inte en separat ren kopia byggd för demonstrationen. Mät sedan de saker som verkligen bestämmer resultaten: hur många felaktiga sammanfogningar och felaktiga splittringar, hur systemet hanterar verklig ambiguitet, var dess förtroendetrösklar sitter, när det eskalerar till en mänsklig istället för att gissa och hur rent det överlämnar till dina befintliga masterdata och styrningskontroller. Om ett team inte kan svara på dessa frågor, agerar agenten på en identitet den inte kan verifiera, och förtroendet för dess utdata är missplaceras.

Ingenting av detta ersätter masterdatahantering, styrning, kunddataplattformar eller lager. De svarar på olika frågor och de förblir nödvändiga. Styrning bestämmer vad en agent är tillåten att göra. Entitetsupplösning bestämmer vem eller vad det gör. Den första är mogen i de flesta stora organisationer. Den andra är det lager som många är på väg att upptäcka att de behöver bredvid det, i realtid, i ögonblicket de låter en agent agera snarare än att ge råd.

Agenten jag såg behövde inte en smartare modell. Den behövde veta att två namn var en kund innan den fick låta som om den var säker. När vi ger dessa system verklig auktoritet att agera, slutar den tysta, sextioåriga disciplinen att vara rengöring och börjar bli bärkraftig.