Ein Unternehmen kann das beste KI-Modell der Welt einsetzen. Wenn die zugrunde liegenden Kundendaten falsch, veraltet oder widersprüchlich sind, wird auch der Agent keine verlässlichen Ergebnisse liefern. Nirgendwo wird das so deutlich wie im CRM.
Ein AI-Agent soll einen Kunden identifizieren, seine Historie verstehen, offene Cases berücksichtigen und anschließend eine passende Aktion ausführen. Dafür braucht er nicht nur Intelligenz. Er braucht Kontext. Und dieser Kontext besteht aus Daten. Genau deshalb entscheidet sich der Erfolg eines Agentforce-Rollouts weniger an der Modellwahl als an der Frage, ob der Datenbestand die Entscheidungen tragen kann, die der Agent treffen soll.
Das CRM wird zur Wissensbasis des Agenten
Klassische CRM-Systeme wurden für Menschen entwickelt. Ein Vertriebsmitarbeiter öffnet einen Kunden und sieht Kontaktdaten, Opportunities, Aktivitäten, Cases, Bestellungen und Notizen. Was er dort nicht findet, ergänzt er aus Erfahrung: Er weiß, dass der Account vor zwei Jahren umfirmiert hat, dass der Ansprechpartner gewechselt ist oder dass der doppelte Datensatz im Support-Tool eigentlich zum selben Unternehmen gehört.
Ein Agent kann diesen fehlenden Kontext nicht zuverlässig ergänzen. Er nimmt die Daten, die er findet, und arbeitet damit. Wenn Informationen über mehrere Systeme verteilt oder widersprüchlich sind, besteht die Gefahr, dass er eine falsche Schlussfolgerung zieht und darauf handelt. Datenqualität wird damit von einem Hygienethema zu einer Voraussetzung für Agentic CRM.
Salesforce reagiert auf diese Verschiebung sichtbar. Data 360 wird zunehmend als Datenbasis für agentische Anwendungen positioniert. Parallel baut Salesforce Headless 360 aus und stellt Plattformfunktionen über APIs und MCP für autorisierte Agenten bereit. Beide Entwicklungen zielen in dieselbe Richtung: Das CRM wird nicht mehr nur von Menschen gelesen, sondern von Agenten als Wissensbasis genutzt.
Das Problem beginnt bei der Kundenidentität
Stellen wir uns einen Kunden vor, der in vier Systemen existiert:
| System | Bezeichnung |
|---|---|
| CRM | Acme GmbH |
| Supportsystem | ACME |
| ERP | Acme Gesellschaft m.b.H. |
| Marketing | Acme Austria |
Für einen Menschen ist wahrscheinlich sofort klar, dass es sich um dasselbe Unternehmen handelt. Für einen automatisierten Prozess ist diese Situation deutlich schwieriger. Genau hier kommt Entity Resolution ins Spiel: Das System muss erkennen, dass diese vier Datensätze zur selben Entität gehören.
Ohne diese Zuordnung arbeitet der Agent mit einem unvollständigen oder sogar falschen Kundenkontext. Er sieht vielleicht die offenen Cases aus dem Supportsystem, aber nicht den Vertragsstatus aus dem ERP. Oder er beantwortet eine Anfrage auf Basis des Marketing-Profils, obwohl die relevante Historie im CRM liegt. Die Aktion ist dann technisch erfolgreich und fachlich trotzdem falsch.
Ein Agent braucht einen Golden Record
Die Lösung besteht nicht zwingend darin, alle Daten in ein einziges System zu kopieren. Wichtiger ist eine konsistente Identität. Ein sogenannter Golden Record definiert, welche Informationen für eine Entität als führend gelten und wie die lokalen Datensätze in den einzelnen Systemen zusammenhängen.
Ein Beispiel:
| Attribut | Wert |
|---|---|
| Customer ID | 84721 |
| Company | Acme GmbH |
| ERP | Customer 103948 |
| CRM | Account 84721 |
| Support | Organization 5512 |
Der Agent erhält dadurch einen stabilen Bezugspunkt. Er muss nicht selbst entscheiden, ob „ACME" und „Acme Austria" dasselbe Unternehmen sind. Diese Entscheidung wurde bereits getroffen und ist in einer stabilen ID festgehalten. Das reduziert das Risiko, dass der Agent Informationen aus mehreren Datensätzen falsch zusammenführt oder am falschen Record handelt.
Für Agenten sollte gelten: Erst Entität auflösen, dann handeln. Der Agent bindet seine Aktionen an eine eindeutige Identität, nicht an den erstbesten Treffer einer Suche.
Mehr Daten bedeuten nicht automatisch eine bessere KI
Ein verbreiteter Fehler lautet: „Unser Agent braucht möglichst viele Daten." Das stimmt nicht unbedingt. Mehr Daten können sogar schaden. Wenn ein Agent Zugriff auf zehn Datenquellen erhält, entstehen zusätzliche Möglichkeiten für widersprüchliche Informationen, veraltete Werte, unterschiedliche Definitionen desselben Begriffs, Berechtigungsprobleme, unnötigen Kontext im Prompt und höhere Kosten pro Aufruf.
Die bessere Frage lautet deshalb nicht „Welche Daten haben wir?", sondern: Welche Daten benötigt der Agent für diese konkrete Aufgabe?
Ein Support-Agent braucht vielleicht die aktuellen Vertragsinformationen, offene Tickets, die letzte Kommunikation und den Bestellstatus. Er benötigt möglicherweise nicht die komplette Marketinghistorie des Kunden. Ein Sales-Agent braucht umgekehrt Opportunities, Kaufhistorie und Ansprechpartner, aber nicht jedes einzelne Support-Ticket der letzten drei Jahre.
Diese Fokussierung ist kein Verzicht auf Kontext. Sie ist eine Entscheidung darüber, welcher Kontext für welche Aufgabe relevant ist. Je enger dieser Zuschnitt, desto weniger Widersprüche muss der Agent auflösen und desto nachvollziehbarer wird sein Verhalten.
Strukturierte und unstrukturierte Daten
Agenten müssen außerdem mit unterschiedlichen Datentypen umgehen. Strukturierte Daten wie Kundennummer, Umsatz, Vertragsstatus, Produkt, Bestellnummer oder Ticketstatus liegen in klar definierten Feldern. Unstrukturierte Daten wie E-Mails, Gesprächsnotizen, PDFs, Support-Chats und Dokumente enthalten oft die eigentliche Geschichte hinter diesen Feldern.
Ein hilfreicher Agent muss beide Welten verbinden. Ein Beispiel: Der CRM-Datensatz zeigt, dass ein Kunde drei offene Cases hat. Die Supportnotizen erklären, dass der Kunde seit zwei Wochen auf eine technische Lösung wartet und bereits zweimal nachgefragt hat. Erst die Kombination ergibt den vollständigen Kontext. Aus „drei offene Cases" wird „ein Kunde, der kurz vor der Eskalation steht".
Wer nur die strukturierten Felder anbindet, bekommt einen Agenten, der Zahlen kennt, aber Situationen nicht versteht. Wer nur Dokumente anbindet, bekommt einen Agenten, der Geschichten erzählt, aber keinen stabilen Bezug zu Vertrag, Status und Identität hat.
Data 360 als Verbindungsschicht
Salesforce positioniert Data 360 genau in diesem Bereich. Daten aus verschiedenen Quellen können vereinheitlicht und für AI-Anwendungen verfügbar gemacht werden, ohne dass jede Quelle physisch in Salesforce kopiert werden muss. Salesforce verweist dabei auch auf Partnerschaften und Integrationen mit Datenplattformen wie Databricks, über die bestehende Data Lakes und Lakehouses angebunden werden können.
Für Unternehmen bedeutet das eine wichtige Veränderung in der Einordnung. Datenintegration ist nicht mehr nur ein Reporting-Thema, bei dem am Ende ein Dashboard steht. Sie wird zur Grundlage für agentische Entscheidungen. Die Frage „Sind unsere Daten für das Reporting sauber genug?" wird zur Frage „Sind unsere Daten sauber genug, damit ein System darauf handeln darf?".
Der Agent sollte nicht blind auf Daten zugreifen
Auch hier spielt Governance eine zentrale Rolle. Ein Agent sollte nicht einfach „alles sehen". Stattdessen sollte die Architektur explizit definieren:
- Welche Daten darf der Agent sehen?
- Welche Felder sind sensibel?
- Welche Daten dürfen für welche Aufgabe verwendet werden?
- Welche Aktionen darf der Agent auslösen?
- Welche Daten dürfen das System verlassen?
Gerade bei Kundendaten ist diese Trennung entscheidend. Ein Service-Agent, der Bestellstatus prüft, braucht keinen Zugriff auf Bonitätsinformationen. Ein Marketing-Agent, der Segmente bildet, sollte keine Support-Eskalationen lesen. Diese Grenzen lassen sich nicht nachträglich über den Prompt ziehen. Sie müssen in Berechtigungen, Datenzugriffen und Tool-Freigaben verankert sein.
Von Customer 360 zu Agent 360
Customer 360 hatte lange ein klares Ziel: einen vollständigen Blick auf den Kunden schaffen. Mit AI Agents entsteht daraus eine neue Frage: Kann ein Agent diesen vollständigen Blick sicher und sinnvoll nutzen?
Das ist ein wichtiger Unterschied. Ein Dashboard zeigt einem Menschen Informationen. Der Mensch bewertet sie, zieht Kontext hinzu und entscheidet. Ein Agent kann auf Basis derselben Informationen direkt handeln. Damit wird Datenqualität unmittelbar operativ.
Wenn ein Dashboard einen falschen Wert zeigt, ist das ärgerlich. Wenn ein Agent auf Basis eines falschen Wertes eine Aktion ausführt, kann daraus ein Geschäftsproblem entstehen.
Der Unterschied liegt in der Konsequenz. Ein falscher Wert im Reporting kostet vielleicht eine Diskussion im Meeting. Ein falscher Wert, auf dessen Basis ein Agent ein Angebot verschickt, einen Vertrag verlängert oder einen Kunden als Churn-Risiko markiert, kostet Vertrauen.
Was Unternehmen vor dem Agentforce-Rollout prüfen sollten
Bevor ein Agent produktiv auf Kundendaten arbeitet, sollten sieben Fragen beantwortet sein:
| Bereich | Leitfrage |
|---|---|
| Kundendaten | Sind Accounts und Kontakte eindeutig, oder existieren Dubletten? |
| Identitäten | Gibt es stabile IDs über Systeme hinweg? |
| Datenqualität | Wie hoch ist der Anteil veralteter oder unvollständiger Daten? |
| Datenherkunft | Woher kommt eine Information, und welches System ist führend? |
| Berechtigungen | Welche Daten darf der Agent für welche Aufgabe verwenden? |
| Aktualität | Wie aktuell muss eine Information für die jeweilige Entscheidung sein? |
| Aktionen | Welche Änderungen darf der Agent durchführen, und wo ist ein Mensch einzubinden? |
Diese Fragen müssen nicht für den gesamten Datenbestand auf einmal beantwortet werden. Sinnvoller ist ein Start mit dem konkreten Use Case: Welche Entitäten berührt der Agent tatsächlich, welche Felder nutzt er für Entscheidungen, und welche Aktionen darf er auslösen? Für diese Teilmenge sollten die Antworten vor dem Rollout vorliegen.
Das Modell ist nur ein Teil der Lösung
Die Diskussion rund um AI-Agents konzentriert sich häufig auf Modelle. Welches Modell ist schneller? Welches ist günstiger? Welches argumentiert besser? Für Enterprise-Anwendungen sind diese Fragen wichtig, aber sie beschreiben nur einen Teil der Lösung.
Eine bessere Darstellung wäre:
Agent Quality = Model + Context + Data Quality + Tools + Governance
Fehlt einer dieser Faktoren, sinkt die Zuverlässigkeit des Gesamtsystems. Ein starkes Modell mit widersprüchlichem Kontext liefert selbstbewusste, aber falsche Antworten. Ein sauberer Datenbestand ohne passende Tools bleibt Wissen ohne Handlungsfähigkeit. Und ein Agent ohne Governance kann korrekt arbeiten und trotzdem Daten verwenden, die er nicht verwenden dürfte.
Gerade bei Salesforce zeigt sich deshalb: Der wichtigste Wettbewerbsvorteil eines Unternehmens ist möglicherweise nicht das neueste Modell. Es ist die Qualität seines Customer Context.
Fazit
AI Agents verändern die Rolle von CRM-Daten. Sie sind nicht mehr nur Informationen, die ein Mitarbeiter im Salesforce-Interface betrachtet. Sie werden zu Kontext, auf dessen Basis ein System Entscheidungen vorbereitet und Aktionen ausführt. Damit steigt die Bedeutung von Data Quality, Entity Resolution, Customer 360, Identity und Governance.
Genau deshalb sollte ein Unternehmen vor der Frage „Welchen AI-Agent wollen wir einsetzen?" zuerst eine andere Frage beantworten: „Kann unser Datenbestand überhaupt die Entscheidungen unterstützen, die dieser Agent treffen soll?"
Denn ein intelligenter Agent mit schlechten Daten bleibt ein schlechter Agent. Ein gut integrierter Agent mit verlässlichem Kontext kann dagegen tatsächlich zum produktiven Teil des Unternehmens werden. Salesforce baut seine Plattform derzeit genau in diese Richtung aus, unter anderem über Data 360, Headless 360 und MCP-basierte Zugänge für autorisierte Agenten. Ob diese Bausteine im eigenen Unternehmen tragen, entscheidet sich aber nicht in der Plattform. Es entscheidet sich in den Daten.