Entiteitsresolutie wordt AI-infrastructuur, niet gegevensopschoning

Een tijdje geleden keek ik naar een AI-agent die met vertrouwen een verkeerd antwoord gaf om een heel saaie reden. Een bedrijf had twee records voor dezelfde corporate klant. Eén record bevatte de oude handelsnaam en een financieel contact. De andere record bevatte de nieuwe wettelijke naam die het bedrijf had aangenomen na een overname, samen met een andere factuuradres. De agent werd een eenvoudige vraag gesteld: is deze rekening in orde? Het vond één record, zag geen achterstallige facturen en zei ja. De achterstallige facturen waren onder de andere naam opgeslagen.

Er werd niets gehallucineerd. Het model redeneerde schoon over de gegevens die het kreeg. De gegevens beschreven toevallig twee klanten waar in de echte wereld één was. De fout zat niet in het taalmodel. Het zat in de join.

Ik ben gaan denken dat dit een van de meest onderschatte risico’s is in enterprise AI, en een van de minst besproken. We praten eindeloos over modelnauwkeurigheid, promptontwerp en governance. We praten veel minder over of een systeem eigenlijk weet welke echte klant, leverancier of rekening het acteert. Die vraag heeft een naam. Het heet entiteitsresolutie, en na zestig jaar op de achtergrond verandert het stil in een stuk live-infrastructuur.

Het probleem veranderde van tijd

Voor het grootste deel van zijn werkzame leven was “zijn deze twee records dezelfde entiteit?” een schoonmaakvraag. Je liep het in een batch, op een schema, ergens binnen een master data management-programma, een warehouse of een analytics-pijplijn. Het was nooit perfect, maar het was overleefbaar, omdat de output een rapport was dat iemand de volgende week las. Als twee records voor dezelfde leverancier niet werden samengevoegd, kwam een uitgavecijfer iets verkeerd uit, een analist merkte het op en het werd in de volgende run verbeterd. Het systeem had slack in zich. Tijd absorbeerde de fouten.

Een AI-agent verwijdert die slack. Het verandert de tijd van de vraag van “uiteindelijk” naar “nu.” Wanneer een agent op het punt staat een terugbetaling goed te keuren, een zaak door te sturen, een profiel bij te werken of een compliance-vraag te beantwoorden, is de opgeloste entiteit niet langer een rapport dat iemand de volgende week leest. Het voedt een actie. De kosten van een verkeerde join veranderen van een cijfer dat iets verkeerd is naar iets dat in de wereld gebeurt, onmiddellijk, en meestal zonder een mens in de lus om het op te vangen.

Dat is de verschuiving die het waard is om bij stil te staan. Het onderliggende probleem is oud en goed begrepen. Wat nieuw is, is dat we het rechtstreeks in systemen hebben aangesloten die op eigen kracht handelen.

Een statistisch probleem uit de jaren 60

Entiteitsresolutie kwam niet met grote taalmodellen. Het kwam met ponskaarten. In 1959 publiceerden H. B. Newcombe en zijn collega’s een kort artikel in Science over de automatische koppeling van vitale records, waarin ze beschreven hoe een computer kon beslissen of een geboorterecord en een huwelijksrecord naar dezelfde persoon verwezen. Een decennium later gaven Ivan Fellegi en Alan Sunter het idee een formele wiskundige theorie, waarin ze de drie resultaten definieerden die elk matchingsysteem nog steeds produceert: een koppeling, een niet-koppeling en een mogelijke koppeling die een persoon moet controleren.

Er is een detail in die afstamming dat het waard is om bij stil te staan, omdat het het deel is dat mensen het vaakst verkeerd doen. Recordkoppeling was nooit alleen exact matchen op een e-mailadres of een gedeelde ID. Vanaf het allereerste begin was het probabilistisch. Het woog het bewijs dat twee records overeenkwamen op een achternaam, een datum, een plaats en produceerde een score, omdat door mensen ingevoerde gegevens rommelig zijn en exacte sleutels constant falen. Moderne entiteitsresolutie werkt nog steeds op deze manier. Het combineert deterministische regels, waar een gedeelde stabiele identifier beslissend is, met probabilistische en fuzzy machine-learning-matching die omgaat met typefouten, bijnamen, omgekeerde velden, afkortingen en de tientallen kleine manieren waarop dezelfde persoon of bedrijf verschillend verschijnt in systemen. Een goede overzicht van het veld volgt een ononderbroken lijn van die jaren 50-vitale records naar de clustering- en machine-learning-methoden die nu worden gebruikt.

Wat echt veranderd is, is wanneer we het antwoord nodig hebben. Onderzoekers schreven over entiteiten oplossen bij querytijd, in plaats van puur vooraf, lang voordat de huidige golf van AI. Toen was het een interessante optimalisatie. Nu is het dichter bij een vereiste.

Waarom agenten het in infrastructuur veranderen

De meeste enterprise AI-systemen antwoorden niet uit het geheugen van het model. Ze halen op. Het patroon dat populair is geworden als retrieval-augmenteerde generatie heeft een agent die relevante context ophaalt op het moment van de vraag en redeneert erover. Dit is over het algemeen een goede zaak. Het verankert antwoorden in uw gegevens in plaats van in de training van het model.

Maar het heeft een gevolg dat gemakkelijk over het hoofd kan worden gezien. De agent erft alles wat de ophaalstap het geeft. Als ophalen een gefragmenteerde klant retourneert, drie gedeeltelijke records die nooit zijn verbonden, zal de agent redeneren over drie klanten. Als ophalen een verkeerd samengevoegde retourneert, twee verschillende bedrijven samengevoegd in één profiel, zal de agent redeneren over één. De ambiguïteit die al in uw bronsystemen zit, wordt rechtstreeks doorgegeven en aan het model gepresenteerd als vastgestelde feit. Het model heeft geen manier om te weten dat de join verkeerd was, net zoals u dat zou weten als u een nette samenvatting van records zou lezen die u nooit eerder had gezien.

Dus resolutie kan geen afterthought zijn dat een keer per kwartaal draait en in een aparte tabel terechtkomt. De entiteit moet worden samengesteld wanneer gegevens worden opgenomen, en de huidige opgeloste weergave ervan moet op het moment dat de agent vraagt oproepbaar zijn. Dat is een runtime-afhankelijkheid. Het gedraagt zich veel meer als een database of een authenticatiedienst dan als een periodiek data-schoonmaakproject, en het moet op dezelfde manier worden ontworpen, gecontroleerd en vertrouwd als u zou doen met elk ander systeem dat uw toepassing in real-time aanroept.

De gereedheidskloof die niemand precies noemt

De industrie voelt al dat er iets ontbreekt. Cisco’s AI Readiness Index 2025 vond dat 83 procent van de organisaties van plan zijn autonome agenten te implementeren, terwijl slechts ongeveer een derde voelt dat hun infrastructuur echt klaar is voor hen, en slechts ongeveer een kwart zich in staat voelt om te controleren en te reguleren wat die agenten eigenlijk doen. McKinsey’s meest recente State of AI-onderzoek beschrijft een soortgelijke kloof vanuit de andere richting: ongeveer 88 procent van de organisaties gebruikt nu AI in tenminste één functie, maar de meeste hebben het nog niet geschaald over het hele bedrijf.

Wanneer mensen die kloof verklaren, grijpen ze vaak naar twee woorden: gegevenskwaliteit en governance. Beide zijn belangrijk, en geen van beiden is optioneel. Maar er is een smallere vraag die onder hen zit die schone, goed gereguleerde gegevens op zichzelf niet beantwoordt. Kan het systeem vertellen welke echte entiteit een bepaald record verwijst, overal waar dat record leeft, op dit moment? U kunt hoge kwaliteit gegevens in elk afzonderlijk systeem hebben en toch deze test niet doorstaan, omdat de fout niet in een van de systemen zit. Het zit in de ruimtes tussen hen, waar dezelfde klant drie iets verschillende gezichten draagt.

Wat te controleren voordat u een agent laat handelen

Als u entiteitsresolutie behandelt als live-infrastructuur, kunt u het controleren als infrastructuur. De operationele foutmodi zijn specifiek en testbaar: gespleten identiteiten die één moeten zijn, valse samenvoegingen van records die gescheiden moeten blijven, verouderde overlevingsregels die een ingetrokken adres blijven promoten, ontbrekende persistente identificatoren, en agenten die bron-systeemambiguïteit erven alsof het een opgeloste waarheid was.

Een praktische gereedheidstest vereist geen nieuw model of een nieuwe leverancierscategorie. Verzamel een grondwaarheidsset van entiteiten die u echt begrijpt. Voer het uit via dezelfde ophaalpad die uw agent gebruikt, niet een aparte schone kopie die is gebouwd voor de demo. Meet dan de dingen die de resultaten echt bepalen: hoeveel valse samenvoegingen en valse splitsingen, hoe het systeem omgaat met echte ambiguïteit, waar de vertrouwensdrempels zitten, wanneer het wordt doorgestuurd naar een mens in plaats van te gokken, en hoe schoon het wordt overgedragen aan uw bestaande master data en governance-controles. Als een team deze vragen niet kan beantwoorden, handelt de agent op een identiteit die het niet kan verifiëren, en is vertrouwen in de output misplaatst.

Geen van dit alles vervangt master data management, governance, customer data platforms of het magazijn. Die beantwoorden andere vragen en blijven noodzakelijk. Governance beslist wat een agent mag doen. Entiteitsresolutie beslist wie of wat het doet. Het eerste is volwassen in de meeste grote organisaties. Het tweede is de laag die veel op het punt staan te ontdekken dat ze ernaast nodig hebben, in real-time, op het moment dat ze een agent laten handelen in plaats van adviseren.

De agent die ik zag had geen slimmer model nodig. Het moest weten dat twee namen één klant waren voordat het mocht klinken alsof het zeker was. Als we deze systemen echte autoriteit geven om te handelen, stopt die stille, zestig jaar oude discipline met schoonmaken en begint het met belastbaar zijn.