So verhindern Sie, dass KI-Agenten auf veralteten oder fragmentierten Kundendaten handeln

Von Steven Renwick, CEO und Mitgründer, Tilores.

Kurzfassung: Verhindern Sie, dass KI-Agenten auf veralteten oder fragmentierten Kundendaten handeln, indem Sie die Kundenkontextschicht in Ordnung bringen, bevor das Modell überhaupt denkt. Fragmentierte Datensätze erkennen, beim Ingest auflösen, zur Abfragezeit den aktuellen aufgelösten Kundenkontext abrufen und Änderungen aus den Quellsystemen fortlaufend in den aufgelösten Datensatz zurückspielen.

Geben Sie KI-Agenten einen aktuellen, aufgelösten Kundenkontext: Buchen Sie eine Demo, um Echtzeit-Identity-Resolution auf Ihren Daten zu sehen, oder holen Sie sich den Evaluation Build, um es lokal zu testen – und werfen Sie danach einen Blick auf Tilores IdentityRAG, das Retrieval-Muster dahinter.

Der Prozess in vier Schritten

1. Fragmentierung erkennen, bevor der Agent sie sieht. Doppelte, veraltete und widersprüchliche Kundendatensätze in CRM, Support, Billing, Marketing und Produktsystemen identifizieren, bevor sie für das Retrieval infrage kommen.
2. Kundendatensätze beim Ingest auflösen. Eingehende Datensätze an die Identity-Resolution-Schicht übergeben, sie mit deterministischen Regeln und probabilistischem bzw. unscharfem Matching der richtigen Entität zuordnen und die Belege aufbewahren.
3. Zur Abfragezeit den aktuellen aufgelösten Kontext abrufen. Dem Agenten ein kontrolliertes Werkzeug für die Abfragezeit geben, das den bereits aufgelösten Kundenkontext zurückliefert – und nicht rohe Fragmente aus jedem Quellsystem.
4. Den aufgelösten Kontext aktuell halten. Änderungen, Löschungen, Auftrennungen und Korrekturen aus den Quellsystemen erneut übermitteln, damit sich der aufgelöste Datensatz mit dem Kundenzustand mitverändert.

Wie verhindert man, dass KI-Agenten veraltete Kundendaten verwenden?

Das verlässliche Muster besteht darin, das Sprachmodell nicht länger als den Ort zu behandeln, an dem Kundenidentitäten repariert werden. Der Agent sollte einen aktuellen, aufgelösten Kundenkontext erhalten, den die Identitätsschicht bereits zusammengestellt hat.

Retrieval-Augmented Generation, wie Lewis et al. es im ursprünglichen RAG-Paper beschreiben, gibt einem Modell zum Zeitpunkt der Generierung externen Kontext mit. Das hilft nur, wenn der abgerufene Kontext der richtige ist. Liefert das Retrieval fünf veraltete oder unvollständige Kundenfragmente, schreibt das Modell trotzdem eine selbstbewusste Antwort aus den falschen Fakten.

Für kundenbewusste Agenten hat die Kontextschicht zwei Aufgaben. Erstens: Datensätze vor dem Retrieval auflösen. Zweitens: den aktuellen aufgelösten Kontext abrufen, wenn der Agent eine Frage stellt. Die Tilores-Dokumentation zu Regeln beschreibt den Assembly-Prozess nach der Übermittlung von Datensätzen, während die Tilores-API-Referenz zeigt, wie Such- und Entitätsabfragen Records, Edges, Duplikate, hits, score und hitScore zurückliefern.

Woran erkennt man veraltete oder fragmentierte Kundendaten?

Meist sehen Sie das Problem, bevor Sie es benennen können:

• Derselbe Kunde erscheint als getrennte Datensätze in CRM, Billing, Support und Marketing.
• Der Agent antwortet anhand einer alten E-Mail-Adresse, einer alten Anschrift, eines geschlossenen Kontos oder eines früheren Tarifs.
• Zwei Systeme sind sich über Kontostatus, Einwilligung, Risikostatus oder Berechtigungen uneinig.
• Die Suche liefert mehrere plausible Personen mit demselben Namen oder derselben Firma.
• Ein Servicemitarbeiter muss in einem weiteren System nachsehen, weil sich die KI-Antwort unvollständig anfühlt.
• Der Agent gibt eine geschliffene Antwort, kann aber nicht zeigen, welcher Quelldatensatz die Aussage aktuell macht.

Das sind keine Prompt-Probleme. Es sind Probleme der Datenzusammenführung und des Retrievals. Eine schärfere Anweisung kann einem Agenten sagen, er solle vorsichtig sein – sie kann aber veraltete Quelldaten nicht aktuell machen und Kundenfragmente nicht mehr zusammenführen, wenn sie bereits im Kontextfenster gelandet sind.

Warum sollte Fragmentierung erkannt werden, bevor ein Agent Kontext abruft?

Die Erkennung gehört nach vorne, weil Retrieval ein verengender Schritt ist. Sobald der Agent die falschen Fragmente erhalten hat, muss das Modell erschließen, welche zusammengehören, welche alt sind und welche zu ignorieren sind. Für Kundendaten ist das eine fragile Kontrolle.

Suchen Sie zunächst nach doppelten Identifikatoren, widersprüchlichen Zeitstempeln, veralteten Quellfeldern, gemeinsam genutzten Haushalts- oder Firmenkennungen und Teildatensätzen, die erst nützlich werden, wenn sie mit einer anderen Quelle verknüpft sind. Das nützliche Ergebnis ist kein vager Datenqualitätswert. Es ist eine Weichenstellung: automatisch auflösen, zur Prüfung weiterleiten, eine fehlerhafte Zusammenführung auftrennen oder den Agenten am Handeln hindern.

Das AI Risk Management Framework des NIST nennt Validität und Zuverlässigkeit als Kernmerkmale vertrauenswürdiger KI-Systeme. In Kundenprozessen hängt die Zuverlässigkeit stark davon ab, ob das Modell auf aktuellen und korrekt verknüpften Kundenfakten aufsetzt.

Wie sollten Datensätze beim Ingest aufgelöst werden?

Datensätze sollten an die Identity-Resolution-Schicht übergeben werden, sobald sie eintreffen oder sich ändern. Auflösung und Zusammenführung geschehen beim Ingest. Die Abfragezeit dient dem Abruf des bereits aufgelösten Kundenkontexts.

Reduzieren Sie Matching nicht auf exakte Schlüssel. Produktive Identity Resolution nutzt deterministische Regeln, wo starke Identifikatoren vorliegen, und probabilistisches oder unscharfes ML-Matching dort, wo reale Datensätze bei Namen, Adressen, E-Mail-Adressen, Telefonnummern oder Geräten voneinander abweichen. Das Fellegi-Sunter-Modell ist der klassische Bezugspunkt für probabilistisches Record Linkage; moderne Systeme ergänzen es um Workflow-Steuerung, Graphverarbeitung, Prüfpfade und operative APIs.

In Tilores werden Datensätze nach der Übermittlung während der Assembly zu Entitäten verbunden. Regeln definieren, wie Datensätze verknüpft werden, und die entstehende Entität trägt Records und Edges, die erklären, warum Daten zusammengehören. Diese Belege sind wichtig, denn ein Agenten-Workflow muss wissen, ob er es mit einem sauberen einzelnen Kunden, einer schwachen Übereinstimmung oder einem prüfbedürftigen Fall zu tun hat.

Die entscheidende Grenze lautet: Der Agent baut die Entität nicht während des Gesprächs zusammen. Die Identitätsschicht hat diese Arbeit bereits erledigt. Der Agent fragt den aufgelösten Kontext ab und erhält nur das, was der Workflow ihm zur Nutzung erlaubt.

Wie sollte ein Agent zur Abfragezeit den aktuellen aufgelösten Kontext abrufen?

Geben Sie dem Agenten ein einziges kontrolliertes Werkzeug für den Kundenkontext. Es nimmt Identifikatoren aus dem Gespräch entgegen, fragt die aufgelöste Identitätsschicht ab und liefert ein abgegrenztes Kontextobjekt zurück.

Ein brauchbares Kontextobjekt enthält die ID der aufgelösten Entität, die Zahl der Kandidaten, die freigegebenen Kundenfelder, die IDs der Quellsysteme, die Match-Belege, Aktualitätsindikatoren und eine Handlungsrichtlinie. Das Modell darf die Antwort formulieren, aber der Workflow entscheidet, ob die Belege eine Antwort zulassen, ob nach einem weiteren Identifikator gefragt oder eskaliert werden soll.

Die Tilores-API-Referenz zeigt den Unterschied zwischen Entitätsabruf und Suche. Entitätsabfragen liefern die Records und Edges einer bekannten Entität. Suchabfragen können Kandidatenentitäten mit hits, score und hitScore zurückgeben, wobei score die Gesamtqualität der Übereinstimmung innerhalb der Entität widerspiegelt und hitScore die Übereinstimmung mit den übermittelten Suchparametern. Diese Signale sollten in die Weichenstellung einfließen. Sie sollten nicht ungeprüft in allgemeingültige Schwellenwerte übernommen werden, ohne sie an Ihren eigenen Daten zu kalibrieren.

Bei einem KI-Servicemitarbeiter sollte die abgerufene Nutzlast klein sein. Sie sollte nicht jede CRM-Notiz, jedes Ticket und jede Rechnung enthalten, sondern die aktuellen Felder, die der Agent verwenden darf, plus genug Herkunftsinformationen, damit der Workflow und ein menschlicher Prüfer die Antwort später nachvollziehen können.

Wie hält man den aufgelösten Kundenkontext aktuell?

Aktualität ist keine einmalige Migration. Sie ist eine laufende Schleife.

Jede Änderung im Quellsystem, die den Kundenzustand verändert, sollte in die Auflösungsschicht zurückfließen: neue Datensätze, geänderte E-Mail-Adressen, geschlossene Konten, gelöschte Datensätze, geänderte Einwilligungen, zusammengeführte Konten, korrigierte Auftrennungen und geprüfte Entscheidungen zu einzelnen Edges. Ändert sich das Quellsystem, der aufgelöste Kontext aber nicht, handelt der Agent irgendwann auf Basis eines veralteten Fragments.

Diese Schleife braucht nicht nur Matching, sondern auch den Umgang mit Löschungen und Korrekturen. Die API-Dokumentation von Tilores beschreibt das Disassembly-Verhalten zum Entfernen von Records oder Edges und zum Auftrennen von Entitäten, wenn eine verbindende Kante wegfällt. Das zählt, denn zur Aktualität gehört auch zu wissen, wann zwei Datensätze nicht länger als ein Kunde behandelt werden dürfen.

Halten Sie die Aktualität in der Antwort des Werkzeugs sichtbar. Der Agenten-Workflow sollte wissen, welches Feld aus welcher Quelle stammt, wann sich diese Quelle zuletzt geändert hat und ob die aktuelle Antwort von einer geprüften oder einer automatisch erzeugten Verknüpfung abhängt. Eine flüssig formulierte Antwort darf veraltete Belege niemals verdecken.

Was gehört neben MDM, CDP, Governance, KYC/AML und das Warehouse?

Die Identity-Resolution-Schicht gehört neben diese Systeme, nicht an ihre Stelle.

MDM steuert Stammdaten und Stewardship. Eine CDP aktiviert Zielgruppen und Customer Journeys. Data Governance definiert Richtlinien und Zugriffe. KYC-/AML-Systeme screenen und untersuchen regulatorische Risiken. Das Warehouse unterstützt Analytics. Diese Systeme bleiben wertvoll, aber sie sind nicht immer die Laufzeitschicht, die ein KI-Agent für aktuellen Kundenkontext aufrufen sollte.

Die Laufzeitschicht sollte Kundendatensätze auflösen, sobald sie eintreffen, die Entität aktuell halten und der Anwendung ein Retrieval zur Abfragezeit bereitstellen. Die Tilores-Seite zu Customer Identity Intelligence beschreibt, warum verstreute interne Kundendaten in Echtzeit vereinheitlicht werden müssen, während der Tilores-Beitrag zu EntityRAG erklärt, warum kundenspezifische Prompts neben dem Vektor-Retrieval auch Entity Resolution brauchen.

Das ist die sinnvolle Arbeitsteilung: Die Systems of Record erledigen weiterhin ihre Aufgaben, und der Agent erhält von der Identitätsschicht einen aktuellen aufgelösten Kontext, wenn er handeln muss.

Wie sollte das getestet werden, bevor man einem Agenten vertraut?

Testen Sie mit den hässlichen Fällen, nicht mit den sauberen Demo-Fällen.

Nehmen Sie geänderte E-Mail-Adressen, gemeinsam genutzte Firmendomains, Familienadressen, doppelte Abrechnungs-IDs, migrierte CRM-Kontakte, wiederverwendete Telefonnummern, transliterierte Namen, veraltete Einwilligungsfelder und bekannte Nicht-Übereinstimmungen. Bauen Sie sowohl Fälle ein, in denen zwei reale Personen fälschlich zusammengeführt werden könnten und getrennt bleiben müssen, als auch Fälle, in denen ein realer Kunde aufgeteilt bleibt.

Erfassen Sie Falsch-Positive und Falsch-Negative getrennt. Ein Falsch-Positiv kann Kundendaten offenlegen oder missbräuchlich verwenden, weil zwei Personen als eine behandelt wurden. Ein Falsch-Negativ kann dazu führen, dass der Agent die Historie übersieht, eine Berechtigung verweigert oder Doppelarbeit erzeugt. Eine einzige gemischte Genauigkeitszahl verschleiert, welches Risiko gerade wächst.

Halten Sie das Sprachmodell aus der finalen Match-Entscheidung heraus. Der Tilores-Beitrag zu LLMs und Entity Resolution ist in diesem Punkt sorgfältig: LLMs können bei Extraktion oder Prüfung helfen, doch das Matching von Kundenidentitäten sollte wiederholbar, bewertet und auditierbar sein, bevor das Modell überhaupt Kundenkontext erhält.

FAQ

Wie gebe ich KI-Agenten aktuellen Kundenkontext?

Lösen Sie Kundendatensätze auf, bevor der Agent sie abruft, und stellen Sie dann ein eng zugeschnittenes Werkzeug bereit, das den aktuellen aufgelösten Kundenkontext mit Quell-IDs, Konfidenzsignalen und freigegebenen Feldern zurückliefert. Der Agent sollte nicht direkt in rohen CRM-, Support-, Billing- und Marketingfragmenten suchen.

Sollten Kundendatensätze beim Ingest oder zur Abfragezeit aufgelöst werden?

Lösen und führen Sie Datensätze beim Ingest zusammen. Die Abfragezeit dient dem Abruf des bereits aufgelösten, aktuellen Kundenkontexts. Baut der Agent die Identität erst im Gespräch zusammen, sind veraltete Fragmente und mehrdeutige Übereinstimmungen längst im Prompt gelandet.

Was ist der Unterschied zwischen veralteten und fragmentierten Daten?

Veraltete Daten sind alte oder überholte Informationen, etwa ein geschlossenes Konto oder eine frühere Adresse. Fragmentierte Daten sind aktuelle Informationen, die über mehrere Systeme verteilt sind. KI-Agenten scheitern häufig dann, wenn beide Probleme gemeinsam auftreten.

Übernimmt Tilores die Rolle von MDM, einer CDP oder eines Warehouse?

Nein. Tilores gehört als Schicht für Identity Resolution und Retrieval neben MDM, CDP, Governance, KYC-/AML-Systeme und das Warehouse. Diese Systeme behalten ihre Aufgaben in Stewardship, Aktivierung, Richtlinien, Screening oder Analytics.

Kann ein LLM fragmentierte Kundendatensätze allein in Ordnung bringen?

Nicht zuverlässig genug, um als produktive Kontrolle zu dienen. Ein LLM kann helfen, Identifikatoren zu extrahieren oder Belege zusammenzufassen, aber das Matching sollte außerhalb des Modells wiederholbar, bewertet und auditierbar erfolgen, bevor Kundenkontext abgerufen wird.