Generative KI im Unternehmen hat sich von einfachen Chatbots zu autonomen Agenten entwickelt, die in der Lage sind, komplexe, mehrstufige Geschäftsprozesse eigenständig zu planen, zu bewerten und auszuführen. Mit Salesforce Agentforce agieren autonome Agenten im Namen von Mitarbeitern und Kunden. Die Zuverlässigkeit eines solchen Agenten hängt jedoch unmittelbar von den Unternehmensdaten ab, auf denen seine Entscheidungen beruhen. Stützt sich ein Agent auf veraltete CRM-Caches oder unvollständige Kundenhistorien, führt dies unweigerlich zu Halluzinationen, fehlerhaften Workflow-Aufrufen und gravierenden Compliance-Verstößen.
Traditionell erforderte die Bereitstellung eines einheitlichen Kontexts den Aufbau komplexer ETL-Pipelines (Extrahieren, Transformieren, Laden), die Petabytes an Daten aus externen Data Warehouses in Salesforce replizierten. Dieser veraltete Ansatz verursacht erhebliche Synchronisationsverzögerungen, treibt die Speicherkosten in die Höhe, fragmentiert die Datensicherheit und führt zu inkonsistenten Kundenprofilen.
Salesforce-Datenarchitekten lösen diesen Konflikt durch die Kombination von Agentforce, der Atlas Reasoning Engine und Salesforce Data Cloud (Data 360) im Rahmen einer Zero-Copy-Architektur. Diese ermöglicht es autonomen Agenten, Unternehmensdaten in Snowflake, Google BigQuery, Databricks und Amazon Redshift direkt und in Echtzeit abzufragen – ohne ein einziges physisches Byte zu verschieben oder zu duplizieren.
1. Das Dilemma autonomer Agenten: Warum traditionelles ETL vor Atlas versagt
Im Gegensatz zu klassischen regelbasierten Bots wird Agentforce von der Atlas Reasoning Engine gesteuert, die eine kontinuierliche ReAct-Schleife (Reason + Act: Nachdenken und Handeln) ausführt. Anstatt starre Skripte mit Schlüsselwörtern abzugleichen, durchläuft Atlas folgenden Prozess:
- Analysiert die Absicht des Benutzers oder ein Systemereignis im Abgleich mit den Unternehmenszielen.
- Erstellt einen dynamischen Ausführungsplan innerhalb definierter Wissensdomänen (Topics).
- Ruft zur Laufzeit strukturierte Unternehmensdaten und unstrukturierte Wissensquellen dynamisch ab.
- Führt deterministische Aktionen über Salesforce Flow, Apex-Code oder MuleSoft-APIs aus.
- Überprüft die Zwischenergebnisse und passt die Strategie iterativ an, bis die Aufgabe gelöst ist.
Dieser Zyklus stellt Anforderungen an die Datenbasis, die herkömmliche ETL-Pipelines nicht erfüllen können:
- Datenaktualität und Latenz: Ein Agent im Kundensupport oder in der Betrugserkennung kann keine Batch-Synchronisationsfenster von 4 bis 24 Stunden tolerieren. Eine in Snowflake stornierte Bestellung muss für den Agenten sofort sichtbar sein.
- Redundante Speicher- und Rechenkosten: Das Replizieren externer Data Warehouses in den Salesforce-CRM-Speicher führt zu explodierenden Lizenzgebühren und doppelten Infrastrukturkosten.
- Fragmentierung von Governance und Compliance: Das Vervielfältigen sensibler Daten erhöht das Risiko unter DSGVO- und HIPAA-Vorschriften und umgeht häufig die auf Quellsystemebene definierten Zugriffsrechte auf Zeilen- und Spaltenebene.
Datenarchitekten begegnen dieser Herausforderung, indem sie Salesforce Data Cloud als föderierte, semantische Echtzeit-Abfrageplattform etablieren.
2. Das Fundament der Zero-Copy-Architektur
Die Zero-Copy-Integration erlaubt Data Cloud den direkten Lesezugriff auf externe Repositorien am Ursprungsort. Es werden lediglich Metadaten und Schemata föderiert. Salesforce unterstützt dabei drei Föderationsmechanismen:
[ Externe Lakehouses / Data Warehouses ]
Snowflake | Databricks | BigQuery | Amazon Redshift
| |
(Datei-Föderation / Iceberg) (Pushdown-SQL / JDBC)
| |
v v
+-------------------------------------------------------+
| Salesforce Data Cloud (Data 360) |
| - Data Lake Objects (DLOs) |
| - Data Model Objects (DMOs / CIM-Standard) |
| - Echtzeit-Identitätsauflösung (Unified Individual) |
| - Vormaterialisierte Daten-Graphen (JSON) |
| - Hybrider Suchindex (Vektor-Embeddings + BM25) |
+-------------------------------------------------------+
|
v
+-------------------------------------------------------+
| Einstein Trust Layer |
| - Dynamische PII-Maskierung & Demaskierung |
| - Garantie der Zero-Data-Retention |
| - Halluzinations- und Toxizitätserkennung |
+-------------------------------------------------------+
|
v
+-------------------------------------------------------+
| Atlas Reasoning Engine |
| - Absichtsanalyse & Topic-Auswahl |
| - Kontext-Grounding & ReAct-Planungsschleife |
| - Tool-Ausführung (Apex / Flow / MuleSoft-APIs) |
+-------------------------------------------------------+
Datei-Föderation über Apache Iceberg
Ermöglicht Data Cloud den direkten Zugriff auf Open-Table-Formate (wie Apache Iceberg oder Delta Lake) in Objektspeichern (Amazon S3 oder Google Cloud Storage). Die Hyper-Query-Engine von Data Cloud liest Metadaten und Parquet-Dateien unmittelbar aus dem Storage, ohne Rechenressourcen im externen Warehouse zu beanspruchen. Dies bietet maximale Kosteneffizienz für Telemetrie-, Klickstrom- und IoT-Daten.
Abfrage-Föderation (Pushdown Querying)
Wird verwendet, wenn hochkomplexe Berechnungen oder Machine-Learning-Vorhersagen (z. B. Abwanderungsrisiken oder Kreditwürdigkeitsscores) abgefragt werden. Data Cloud leitet die SQL-Abfrage direkt an Snowflake oder BigQuery weiter. Die Berechnung erfolgt im externen Warehouse, und lediglich die aggregierte Ergebnismenge wird an Salesforce zurückgegeben.
Bidirektionales Data Sharing
Zero-Copy funktioniert in beide Richtungen. Über Protokolle wie Snowflake Secure Data Sharing oder Databricks Delta Sharing stellt Data Cloud CRM-Signale und Kundeninteraktionen externen Data Warehouses als sichere Ansichten bereit, ohne dass Export-Pipelines erforderlich sind.
3. Semantische Harmonisierung und Identitätsauflösung
Föderierte Rohdaten müssen standardisiert werden, damit LLMs und Reasoning-Engines sie interpretieren können. Architekten konfigurieren diese Schicht in zwei Phasen:
1. Zuordnung von DLOs zu DMOs
Externe Tabellen werden zunächst als Data Lake Objects (DLOs) eingebunden. Anschließend mappen Architekten diese Felder auf Data Model Objects (DMOs) des standardisierten Cloud Information Model (CIM):
- ERP-Bestelldaten werden auf die DMOs
SalesOrderundSalesOrderProductgemappt. - Mobile App-Ereignisse fließen in
DeviceApplicationundEngagementTopic. - Kontaktdaten werden den DMOs
IndividualundContactPointAddresszugewiesen.
2. Echtzeit-Identitätsauflösung (Identity Resolution)
Kunden interagieren über fragmentierte Kanäle: anonyme Web-Cookies, Portal-Logins und Telefonnummern im Support.
Die Identity-Resolution-Engine wendet deterministische und probabilistische Abgleichregeln (E-Mail, Telefon-Hashes, externe IDs) über alle föderierten DMOs hinweg an. Dadurch entsteht ein organisationsweit eindeutiges Profil: das Unified Individual. Wenn Agentforce eine Anfrage bearbeitet, greift Atlas auf diesen konsolidierten Kontext zu.
4. Beseitigung von Latenzengpässen: Daten-Graphen (Data Graphs)
Ein kritischer Engpass bei autonomen Agenten ist die Abfragelatenz. Müsste die Atlas Reasoning Engine bei jeder Interaktion fünf relationale SQL-JOINs über verteilte externe Tabellen ausführen, läge die Antwortzeit bei 5 bis 15 Sekunden. Das würde zu Timeouts und Frustration führen.
Architekten lösen dieses Problem mit Data Graphs in Data Cloud.
Was sind Data Graphs?
Ein Data Graph ist ein hierarchisches Datenmodell, das die Beziehungen zwischen mehreren DMOs vorab durchläuft und als abfrageoptimierte JSON-Struktur materialisiert.
Typischer Aufbau:
- Stammobjekt:
Unified Individual - Untergeordnete Knoten:
SalesOrder(Bestellungen der letzten 90 Tage),Case(offene Support-Fälle),Calculated Insight(Kundenwert-Score) und Telemetriedaten aus Snowflake.
Warum Data Graphs Agentforce beschleunigen
- Keine JOINs zur Laufzeit: Die Beziehungen werden im Hintergrund vorberechnet und vorgehalten.
- Subsekunden-Abfrage über Primärschlüssel: Atlas ruft den gesamten 360-Grad-Kontext über einen einzigen Schlüssel (
UnifiedIndividualId) in wenigen Millisekunden ab. - Direkte Anbindung an Prompt Builder: Data Graphs lassen sich im Salesforce Prompt Builder direkt als strukturierte Merge-Felder in Prompt-Vorlagen einbinden, ohne dass individueller Apex-Serialisierungscode erforderlich ist.
5. Grounding unstrukturierter Daten: Vektor-Indizierung und hybride Suche
Ein Großteil des unternehmerischen Wissens liegt nicht in relationalen Tabellen vor, sondern in unstrukturierten Dokumenten: Garantiebedingungen, Handbücher, Verträge und Support-Tickets.
Um Agentforce mit diesem Wissen zu verknüpfen, konfigurieren Architekten Suchindizes in Data Cloud:
- Dokumenten-Anbindung: Repositorien in SharePoint, Amazon S3 oder Salesforce Knowledge werden als unstrukturierte DLOs eingebunden.
- Chunking & Vektor-Embeddings: Data Cloud zerlegt Dokumente in semantische Abschnitte, generiert über integrierte Modelle Vektoren und speichert sie in der nativen Vektordatenbank.
- Hybride Suche (Hybrid Search): Bei komplexen Anfragen führt Atlas parallel eine BM25-Schlüsselwortsuche (für exakte Teilenummern) und eine dichte Vektorsuche (für semantischen Sinn) aus und speist die relevantesten Passagen direkt in das Prompt-Fenster ein.
6. Der autonome Ausführungszyklus von Atlas und der Einstein Trust Layer
Mit Zero-Copy-Föderation, DMO-Mapping, Data Graphs und hybrider Suche läuft der Agentforce-Zyklus wie folgt ab:
[Kundeninteraktion / Systemereignis]
│
▼
[Atlas Reasoning Engine] ─────► Erkennt Absicht und wählt Topic
│
▼
[Data Cloud Grounding] ─────► Lädt Data Graph (360-Grad-Kunden-JSON)
─────► Führt hybride Suche aus (Wissensdokumente)
─────► Führt Zero-Copy-Abfrage aus (ERP-Rechnungsstand)
│
▼
[Einstein Trust Layer] ─────► Maskiert PII / Prüft Zugriffsberechtigungen
│
▼
[LLM-Reasoning] ─────► ReAct-Zyklus: Bestimmt erforderliches Tool
│
▼
[Aktionsausführung] ─────► Ruft Salesforce Flow / Apex / MuleSoft-API auf
│
▼
[Ergebnisprüfung] ─────► Bewertet Ergebnis und schließt Vorgang ab
Schutzmechanismen des Einstein Trust Layer
Bevor der angereicherte Kontext an das Basis-LLM (Salesforce, OpenAI, Anthropic oder Azure) übermittelt wird, greift der Trust Layer:
- Dynamische PII-Maskierung: Personenbezogene Daten wie Ausweis- oder Kreditkartennummern werden vor der Übertragung durch anonyme Platzhalter ersetzt.
- Garantie der Zero-Data-Retention: Verträge stellen sicher, dass Kundendaten weder beim KI-Anbieter gespeichert noch zum Training öffentlicher Modelle genutzt werden.
- Grounding-Score und Toxizitätsfilter: Die Antwort des Modells wird mit den Quelldaten abgeglichen, um Halluzinationen und schädliche Inhalte auszuschließen.
- Sichere Demaskierung und Audit-Trail: Verifizierte Antworten werden im UI demaskiert, und alle Schritte werden unveränderlich in den Audit-DMOs von Data Cloud protokolliert.
7. Architekturvergleich: Traditionelles ETL vs. Zero-Copy-Grounding
| Kriterium | Traditionelle ETL-Replikation | Zero-Copy-Grounding in Data Cloud |
|---|---|---|
| Datenbewegung | Regelmäßiges Extrahieren, Transformieren und physisches Kopieren ins CRM | Direkter Zugriff am Ursprungsort über Iceberg-Föderation oder Pushdown |
| Datenaktualität | Verzögert (Synchronisationszyklen von Stunden oder Tagen) | Echtzeit; liest den exakten Zustand des Warehouse im Moment der Interaktion |
| Speicherkosten | Hoch; CRM-Speicherkapazitäten werden doppelt belegt und abgerechnet | Minimal; Daten verbleiben im kostengünstigen externen Data Lakehouse |
| Kontext-Latenz | Langsam; erfordert zur Laufzeit mehrere komplexe SOQL-Abfragen | Millisekunden; hierarchische Data Graphs liefern fertige JSON-Strukturen |
| Sicherheit & Governance | Fragmentiert; Berechtigungen müssen manuell synchronisiert werden | Zentral; respektiert Quellsystem-Rechte und schützt via Trust Layer |
| Reasoning-Umfang | Auf im CRM vorhandene Datenfelder beschränkt | Umfassend; verbindet ERP, Data Lake, Telemetrie und Wissensdokumente |
8. Best Practices für Unternehmensarchitekten
Für einen stabilen, performanten und kosteneffizienten Produktivbetrieb sollten Architekten folgende Grundsätze beachten:
1. Gezielter Einsatz von Datei- vs. Abfrage-Föderation
- Nutzen Sie Apache Iceberg Datei-Föderation für große, unveränderliche oder fortlaufend geschriebene Datenmengen (Klickströme, IoT-Logs), um Rechenkosten im externen Warehouse zu vermeiden.
- Setzen Sie Abfrage-Pushdown gezielt für vorberechnete, rechenintensive Kennzahlen ein, die am besten im Warehouse verarbeitet werden.
2. Kostenkontrolle bei externen Data Warehouses
Echtzeit-Abfragen können unerwartete Warehouse-Kosten verursachen:
- Vermeiden Sie unindizierte Full-Table-Scans innerhalb von Agenten-Dialogschleifen.
- Hinterlegen Sie häufig benötigte Attribute in Data Graphs mit geschäftlich sinnvollen Cache-Intervallen.
- Nutzen Sie Calculated Insights in Data Cloud für periodische Vorberechnungen.
3. Angemessene Granularität von Data Graphs
Erstellen Sie keine überdimensionierten Data Graphs mit Hunderten irrelevanter Felder. Zu große JSON-Strukturen überlasten das Kontextfenster des LLMs, erhöhen die Inferenzkosten und können die Entscheidungsqualität von Atlas beeinträchtigen. Modellieren Sie kompakte, auf spezifische Topics zugeschnittene Data Graphs.
4. Governance in Multi-Agenten-Systemen
Entwickeln Sie keine monolithischen Alleskönner-Agenten. Strukturieren Sie spezialisierte Subagenten mit klar abgegrenzten Topics, Aktionen und Datenberechtigungen. Operationen mit Schreibzugriff auf Kernsysteme (wie Rückerstattungen oder Vertragsänderungen) sollten stets über Freigabeprozesse mit menschlicher Aufsicht (Human-in-the-Loop) abgesichert werden.
Fazit
Das Grounding von Agentforce in Salesforce Data Cloud über eine Zero-Copy-Architektur markiert einen Paradigmenwechsel für Enterprise-Daten- und KI-Strategien. Durch die direkte Verknüpfung externer Cloud-Warehouses mit autonomen Reasoning-Engines entfällt der technische Ballast redundanter Datenkopien, während Agenten Zugriff auf vollständige Echtzeit-Geschäftskontexte erhalten. Mit Apache-Iceberg-Föderation, semantischer CIM-Modellierung, Data Graphs und dem Einstein Trust Layer schaffen Datenarchitekten das sichere Fundament für eine produktive, autonome digitale Belegschaft.