Wenn ein KI-Agent einen Kunden aktualisiert, eine Bestellung zuordnet oder eine Entscheidung vorbereitet, ist eine Frage entscheidend: Weiß der Agent wirklich, welche Entität gemeint ist?
In vielen Unternehmen lautet die Antwort: wahrscheinlich nicht. Ein Kunde existiert im CRM, im ERP, im Support-Tool und vielleicht zusätzlich in einer Marketing-Plattform. Namen weichen leicht ab, Adressen sind unterschiedlich gepflegt, E-Mail-Adressen ändern sich, alte Accounts bleiben bestehen und neue Datensätze werden bei jedem Systemwechsel angelegt. Für Menschen ist diese Unordnung oft handhabbar, weil sie Kontext kennen und im Zweifel nachfragen. Ein Agent nimmt den Datensatz, den er findet – und handelt darauf.
Genau hier liegt der Unterschied zwischen Datenzugriff und Entitätsverständnis. Ein Agent kann technisch alle relevanten Systeme erreichen und trotzdem am falschen Record handeln. Aus einem Stammdatenproblem wird dann eine falsche Aktion: Der falsche Kunde wird aktualisiert, eine Bestellung wird dem falschen Account zugeordnet oder eine Entscheidung basiert auf einem unvollständigen Teilprofil. Und wenn die Architektur keine Rückfrage oder Eskalation vorsieht, führt der Agent die Aktion einfach aus.
Warum Stammdaten bei Agenten kritischer werden
Stammdaten waren auch vor KI-Agenten wichtig. Kunden, Produkte, Lieferanten, Standorte oder Verträge mussten schon immer sauber gepflegt werden. Der Unterschied liegt darin, was ein Agent mit diesen Daten macht.
Ein Reporting-Dashboard kann einen doppelten Kunden sichtbar machen. Ein Mensch erkennt die Auffälligkeit vielleicht und korrigiert sie. Ein Agent kann dagegen auf Basis dieses doppelten Kunden eine Folgeaktion auslösen. Er erstellt eine Antwort, aktualisiert ein Feld, startet einen Workflow oder leitet eine Anfrage weiter. Wenn die zugrunde liegende Entität falsch aufgelöst wurde, wird der Fehler operativ.
Agenten verschärfen dieses Problem, weil sie Kontext aus mehreren Systemen zusammenführen. Sie lesen Kundendaten aus dem CRM, Zahlungsinformationen aus dem ERP, frühere Tickets aus dem Support-System und Kampagneninformationen aus dem Marketing-Tool. Wenn diese Systeme unterschiedliche Versionen derselben Entität enthalten, muss klar sein, welche Sicht für den Agenten maßgeblich ist.
Das ist nicht primär ein Integrationsproblem. Hier geht es um etwas Spezifischeres: die Frage, ob ein Agent die richtige Entität erkennt, bevor er handelt.
Golden Record statt zufälliger Treffer
Ein Golden Record ist die konsolidierte, fachlich führende Sicht auf eine Entität. Er beschreibt nicht einfach den technisch neuesten Datensatz, sondern die vertrauenswürdigste Zusammenführung relevanter Informationen. Für einen Kunden kann das bedeuten: Die Kundennummer kommt aus dem ERP, die bevorzugte E-Mail-Adresse aus dem CRM, der aktuelle Supportstatus aus dem Ticketing-System und die Einwilligung für Kommunikation aus dem Consent-Management.
Für KI-Agenten ist dieser Golden Record entscheidend, weil er verhindert, dass der Agent zufällig mit einem Teilprofil arbeitet. Wenn ein Agent eine Kundenanfrage bearbeitet, sollte er nicht selbst aus drei widersprüchlichen Records ableiten müssen, welcher davon vermutlich richtig ist. Er sollte auf eine aufgelöste Sicht zugreifen, die bereits festlegt, welche Entität gemeint ist und welche Attribute aus welchem System führend sind.
Das bedeutet nicht, dass jede Organisation sofort ein vollständiges Master-Data-Management-Programm für alle Datenobjekte braucht. Für Agenten reicht oft ein pragmatischer Einstieg: Welche Entitäten sind für den konkreten Use Case kritisch? Bei einem Service-Agenten sind das meist Kunden, Verträge, Orders und Tickets. Bei einem Einkaufs-Agenten eher Lieferanten, Produkte, Verträge und Standorte.
Entscheidend ist, dass der Agent nicht gegen rohe, widersprüchliche Systemdaten arbeitet, sondern gegen eine fachlich aufgelöste Sicht.
Entity Resolution: Wie Systeme erkennen, was zusammengehört
Entity Resolution beschreibt den Prozess, mit dem Datensätze aus verschiedenen Quellen derselben realen Entität zugeordnet werden. In der Praxis ist das selten trivial. Zwei Kunden können denselben Namen haben. Ein Unternehmen kann mehrere Standorte nutzen. Eine Person kann verschiedene E-Mail-Adressen verwenden. Ein Lieferant kann im ERP anders geschrieben sein als im CRM.
Matching kann deterministisch oder probabilistisch erfolgen. Deterministisches Matching arbeitet mit klaren Regeln: gleiche Kundennummer, gleiche Steuer-ID, gleiche Vertragsnummer. Wenn der Schlüssel stabil und eindeutig ist, ist diese Methode stark. In vielen gewachsenen Systemlandschaften fehlen solche Schlüssel aber oder sie werden nicht überall gleich verwendet.
Probabilistisches Matching bewertet Ähnlichkeiten. Name, Adresse, Telefonnummer, E-Mail, Geburtsdatum oder Unternehmenskennung werden kombiniert, um eine Wahrscheinlichkeit zu berechnen, dass zwei Records zusammengehören. Das ist flexibler, aber weniger eindeutig. Deshalb braucht es Match-Scores und klare Regeln, was bei Unsicherheit passiert.
Für KI-Agenten ist genau dieser Punkt zentral. Ein Agent sollte nicht raten, wenn die Entität unsicher ist. Wenn der Match-Score niedrig ist oder mehrere mögliche Treffer ähnlich wahrscheinlich sind, sollte der Agent stoppen, nachfragen oder an einen Menschen eskalieren. Unsicherheit bei der Entität darf nicht zu automatischer Handlung führen.
Stabile Entitäts-IDs als Anker
Der wichtigste technische Anker für Agenten ist eine stabile Entitäts-ID. Sie verbindet die aufgelöste Entität über Systeme hinweg. Ohne eine solche ID bleibt jeder Systemaufruf anfällig für Mehrdeutigkeiten.
Eine stabile Kunden-ID bedeutet nicht zwingend, dass alle Systeme dieselbe interne ID verwenden müssen. In der Praxis kann es eine zentrale Master-ID geben, die auf lokale IDs in CRM, ERP, Support und Marketing verweist. Wichtig ist, dass der Agent mit dieser aufgelösten Master-ID arbeitet und nicht jedes Mal neu entscheiden muss, welcher Rohdatensatz gemeint ist.
In der Praxis entscheidet genau dieser Punkt oft darüber, ob eine Aktion nur technisch erfolgreich ist oder auch fachlich korrekt. Wenn ein Agent einen Kundenstatus aktualisiert, sollte klar sein, ob diese Aktualisierung den Golden Record betrifft, einen lokalen CRM-Record oder einen veralteten Dubletten-Datensatz. Ohne stabile ID kann eine technisch erfolgreiche Aktion fachlich falsch sein.
Für agentische Systeme sollte gelten: Erst Entität auflösen, dann handeln. Der Agent sollte seine Aktionen an eine eindeutige Entität binden, nicht an den erstbesten Record, der in einer Suche auftaucht.
System of Record: Wer ist für welches Attribut führend?
Ein Golden Record entsteht nicht dadurch, dass ein System pauschal immer recht hat. In vielen Unternehmen ist je nach Attribut ein anderes System führend. Das ERP kann für Rechnungsstatus und Kundennummer maßgeblich sein, das CRM für Account-Owner und Beziehungshistorie, das Consent-System für Kommunikationsfreigaben und das Support-Tool für aktuelle Eskalationen.
Für Agenten muss diese Hoheit explizit sein. Wenn ein Agent entscheiden soll, ob ein Kunde kontaktiert werden darf, reicht es nicht, eine E-Mail-Adresse im CRM zu finden. Er muss wissen, ob die Kommunikationsfreigabe aktuell ist und aus welchem System sie kommt. Wenn ein Agent eine Lieferadresse verwendet, muss klar sein, ob die Adresse aus dem Kundenprofil, der konkreten Order oder einem separaten Versandprozess führend ist.
Diese Regeln heißen oft Survivorship-Regeln. Sie legen fest, welches Attribut aus welcher Quelle übernommen wird, wenn mehrere Systeme unterschiedliche Werte liefern. Ohne solche Regeln kann ein Agent widersprüchliche Daten entweder ignorieren, falsch kombinieren oder sich auf die falsche Quelle verlassen.
Für Menschen sind solche Unterschiede oft Erfahrungswissen. Für Agenten müssen sie systematisch abgebildet werden.
Confidence Scores und der Stopp bei Unsicherheit
Entity Resolution sollte nicht nur einen Treffer liefern, sondern auch ausdrücken, wie sicher dieser Treffer ist. Ein Match mit 99 Prozent Confidence ist anders zu behandeln als ein Match mit 72 Prozent. Bei Menschen kann ein niedriger Confidence-Wert ein Hinweis sein, genauer hinzuschauen. Bei Agenten muss daraus eine klare Handlungsregel entstehen.
Für kritische Aktionen sollte ein Agent nur mit aufgelösten Entitäten oberhalb eines definierten Schwellenwerts arbeiten. Unterhalb dieses Werts sollte er nicht automatisch aktualisieren, auslösen oder entscheiden. Stattdessen kann er eine Rückfrage stellen, einen Review erzeugen oder den Fall an einen Menschen übergeben.
Das ist kein allgemeines Human-in-the-Loop-Thema, sondern eine konkrete Regel für Entity Resolution. Der Agent stoppt nicht, weil der gesamte Prozess unsicher ist, sondern weil die Zuordnung der Entität nicht belastbar genug ist.
Ein einfaches Muster kann so aussehen:
| Match-Situation | Verhalten des Agenten |
|---|---|
| Eindeutige ID vorhanden | Aktion darf im definierten Scope fortgesetzt werden |
| Hoher Match-Score | Aktion möglich, falls keine weiteren Risikosignale vorliegen |
| Mittlerer Match-Score | Rückfrage oder menschlicher Review |
| Mehrere ähnliche Treffer | Keine automatische Aktion |
| Kein belastbarer Treffer | Neuen Fall erstellen, aber keine Entität aktualisieren |
Diese Schwellenwerte müssen pro Use Case definiert werden. Eine Marketing-Segmentierung kann andere Grenzen haben als eine Zahlungsfreigabe oder eine Vertragsänderung.
Ein DACH-Beispiel: Der dreifache Kunde
Ein typisches DACH-Szenario: Ein B2B-Kunde existiert dreimal. Im CRM als Müller Maschinenbau GmbH, im ERP als Mueller Maschinenbau GmbH & Co KG, im Support-Tool als Müller MB. Die Adresse ist in zwei Systemen leicht unterschiedlich, die zentrale E-Mail-Adresse wurde vor einem Jahr geändert, und eine alte Kundennummer geistert noch durch historische Tickets.
Ein KI-Agent soll eine Supportanfrage zusammenfassen und den Accountstatus aktualisieren. Er findet drei Treffer. Einer hat die aktuellen Supporttickets, ein anderer den korrekten Zahlungsstatus, der dritte ist im CRM dem richtigen Account-Manager zugeordnet. Drei Teilprofile, drei verschiedene Wahrheiten. Wenn der Agent auf einem davon arbeitet, kann die Aktion formal erfolgreich sein – und fachlich trotzdem falsch.
Die Lösung liegt nicht darin, dem Agenten einfach mehr Systemzugriff zu geben. Er braucht eine aufgelöste Entität. Der Golden Record verbindet die drei lokalen Records über eine stabile Master-ID, definiert führende Attribute und markiert unsichere oder widersprüchliche Felder. Der Agent arbeitet dann gegen diese aufgelöste Sicht. Wenn die Zuordnung unsicher ist, aktualisiert er keinen Datensatz, sondern erzeugt einen Review-Fall.
So wird aus einem diffusen Stammdatenproblem eine kontrollierbare Regel: keine automatische Handlung ohne belastbare Entitätsauflösung.
Pragmatischer Einstieg für Unternehmen
Der Einstieg muss nicht mit einem umfassenden MDM-Programm für alle Datenobjekte beginnen. Sinnvoller ist ein use-case-orientierter Start. Unternehmen sollten zuerst die Entitäten identifizieren, auf denen ein Agent tatsächlich handelt. Für einen Customer-Service-Agenten sind das wahrscheinlich Kunde, Vertrag, Bestellung und Ticket. Für einen Finance-Agenten können es Lieferant, Rechnung, Kostenstelle und Freigabeprozess sein.
Danach sollte geklärt werden, welches System für welche Attribute führend ist. Nicht jedes Feld braucht sofort eine perfekte Regel. Kritisch sind die Attribute, die der Agent für Entscheidungen oder Aktionen verwendet. Genau dort braucht es Source-of-Truth-Regeln, Matching-Logik, Confidence-Schwellen und klare Stopps bei Unsicherheit.
Wichtig ist auch, stabile IDs durchzuziehen. Wenn der Agent eine Entität in mehreren Systemen nutzt, sollte diese Verbindung nicht über Namen, E-Mail-Adressen oder unscharfe Suche hergestellt werden. Eine Master-ID oder ein belastbares Mapping ist deutlich stabiler.
Der letzte Schritt ist die Anbindung des Agenten an die aufgelöste Sicht. Er sollte möglichst nicht direkt gegen rohe Dubletten arbeiten, sondern gegen einen Service, eine View oder ein Datenprodukt, das die Entitätsauflösung bereits enthält.
Die eigentliche Lehre für Agenten
KI-Agenten brauchen nicht nur Datenzugriff. Sie brauchen Entitätsklarheit. Ein Agent, der den falschen Kunden, das falsche Produkt oder den falschen Lieferanten erwischt, kann technisch korrekt handeln und trotzdem fachlich Schaden erzeugen.
Deshalb sollten Unternehmen Stammdaten, Golden Records und Entity Resolution nicht als altes Data-Management-Thema abtun. Für agentische Systeme werden sie zu einer Sicherheits- und Betriebsfrage. Je mehr ein Agent handeln darf, desto wichtiger wird die eindeutige Antwort auf eine einfache Frage: Über wen oder was sprechen wir gerade?
Für uns gehört Entity Resolution deshalb früh in die Architekturarbeit rund um KI-Agenten. Tools, Datenzugriff und Automatisierung bringen wenig, wenn nicht klar ist, auf welche Entität sich eine Aktion bezieht. In Salesforce- und Enterprise-Umgebungen können Data Cloud, MuleSoft und bestehende MDM-Ansätze Bausteine dafür sein. Entscheidend bleibt aber die fachliche Regel: Der Agent sollte erst handeln, wenn die Entität eindeutig genug ist.