Salesforce hat stark in native KI investiert. Agentforce, Einstein und Data Cloud decken mittlerweile eine breite Palette an Vertriebs-, Service- und Marketing-Anwendungsfällen ab. Wenn KI-Workloads jedoch von Pilotprojekten in die Produktion übergehen, stoßen viele Unternehmen an dieselbe Grenze: Sie benötigen mehr Kontrolle über Modellauswahl, Infrastruktur, Data Residency, spezialisierte Workflows und KI-Ekonomie, als ein plattformverwaltetes Angebot bieten kann.
Salesforce KI-Integration kann Salesforce-Daten und -Workflows mit KI-Funktionen innerhalb oder außerhalb des Salesforce-Ökosystems verbinden. Dieser Artikel konzentriert sich auf die Custom- und Hybrid-Seite — die Erweiterung der SFDC-Plattform um externe AI Agents, Open-Weight- oder selbst gehostete LLMs und private RAG-Pipelines auf AWS oder GCP bei gleichzeitiger kontrollierter, Near-Real-Time-Synchronisation der CRM-Daten.
Dies ist kein Ersatz für Agentforce. Agentforce unterstützt Bring-Your-Own-Modelle und passt zu vielen nativen Anwendungsfällen. Eine Custom- oder Hybrid-Architektur ergänzt es, wenn Unternehmen privates RAG, selbst gehostete Inference, spezialisierte Workflows oder mehr Kontrolle über Infrastruktur und Kosten benötigen. Die Salesforce Certified Engineers und AI Engineers von HDWEBSOFT arbeiten gemeinsam an der durchgängigen Konzeption und Implementierung dieser Integrationen.
Wichtigste Erkenntnisse
- Salesforce KI-Integration kann KI innerhalb oder außerhalb des Salesforce-Ökosystems nutzen; dieser Artikel konzentriert sich auf Custom- und Hybrid-Architekturen mit externen Agents, LLMs und privatem RAG.
- Agentforce-first passt zu vielen nativen Anwendungsfällen; Custom- und Hybrid-Architekturen ergänzen es, wenn Unternehmen Modellflexibilität, Infrastrukturkontrolle, Data Residency oder spezialisierte Workflows benötigen.
- Eine typische Architektur leitet Salesforce-Daten über ein API-Gateway oder eine Middleware an einen externen AI-Stack auf AWS oder GCP weiter, mit Near-Real-Time-CRM-Sync über Platform Events, Change Data Capture und die Pub/Sub-API.
- Eine private RAG-Architektur hält CRM-Dokumente, Embeddings und Retrieval-Infrastruktur in einer unternehmenskontrollierten Umgebung; kombiniert mit selbst gehosteter Inference reduziert sie die Notwendigkeit, sensible Kontextdaten an Drittanbieter-LLM-APIs zu senden.
- Die Salesforce Certified Engineers und AI Engineers von HDWEBSOFT konzipieren und implementieren den gesamten Stack — API-Architektur, Datensynchronisation, LLM und RAG, Cloud-Infrastruktur sowie Security-Hardening.
Was ist Salesforce KI-Integration?
Salesforce KI-Integration verbindet Salesforce-Daten und -Workflows mit KI-Funktionen — entweder innerhalb des Salesforce-Ökosystems (Agentforce, Einstein, Data Cloud) oder außerhalb, über eine Custom- oder Hybrid-Architektur mit externen AI Agents, Open-Weight- oder selbst gehosteten LLMs und privaten RAG-Pipelines.
Native Salesforce-KI ist auf Workflows optimiert, die zum Datenmodell der Plattform passen. Externe KI-Integration greifen Unternehmen zu, wenn ein Anwendungsfall etwas benötigt, das die Plattform nicht nativ bietet: ein spezifisches Open-Weight-Modell, eine private Retrieval-Pipeline, Inference innerhalb einer kontrollierten Region oder ein spezialisierter Workflow über mehrere Systeme hinweg.
Custom AI-Agent-Integration ist ein gängiges Muster — Agents, die externe LLMs aufrufen, Kontext aus einem privaten Vector Store abrufen und Ergebnisse zurück in Salesforce schreiben, während sie weiterhin in der Salesforce-UI angezeigt werden. Inference und Retrieval finden in Infrastruktur statt, die das Unternehmen kontrolliert.
Die zentrale Einordnung: Native und Custom schließen sich nicht gegenseitig aus. Die meisten reifen Unternehmen betreiben ein Hybrid-Modell — Agentforce für native Anwendungsfälle, Custom- oder Hybrid-Architektur für Workloads, die mehr Kontrolle erfordern.
Agentforce-First vs. Custom/Hybrid Salesforce KI: Wo jedes Modell passt
Agentforce ist kein geschlossenes System. Salesforce unterstützt Bring-Your-Own-Modelle, und Agentforce kann in bestimmten Konfigurationen externe Endpunkte aufrufen. Die Plattform ist zudem schnell gewachsen: Der Agentforce-ARR überstieg 1,5 Milliarden US-Dollar in Q2 FY2027 mit einem Wachstum von über 240 % gegenüber dem Vorjahr. Diese Dynamik spiegelt eine reale Nachfrage nach nativer, plattformverwalteter KI in Vertrieb und Service wider.
Die Frage lautet nicht „Agentforce oder Custom?”, sondern „wo passt Agentforce-first und wo ergänzt eine Custom- oder Hybrid-Architektur einen Mehrwert?” Beide Ansätze ergänzen sich in den meisten reifen Enterprise-Stacks.
| Kriterium | Agentforce-First | Custom / Hybrid |
|---|---|---|
| Einrichtungsgeschwindigkeit | Schnell, nativer Wizard und Low-Code-Builder | Langsamer, erfordert Architekturdesign und Integrationsaufwand |
| Salesforce-nativer Workflow | Tiefe Integration in Sales Cloud, Service Cloud, Data Cloud | Erfordert eine Integrationsschicht zur Darstellung in der Salesforce-UI |
| Modellflexibilität | Bring-Your-Own-Modelle unterstützt, innerhalb der Plattformrestriktionen | Volle Auswahl an Open-Weight-, selbst gehosteten oder Managed-Model-Services |
| Infrastrukturkontrolle | Salesforce-verwaltet | Unternehmenskontrolliert auf AWS, GCP oder Private Cloud |
| Data Residency | Abhängig von Salesforce-Region und Data-Cloud-Bereitstellung | Vom Unternehmen auf spezifische Region, Cloud oder On-Prem kontrolliert |
| Anpassungstiefe | Begrenzt durch Plattformfunktionen und Guardrails | Keine architektonische Grenze; Custom RAG, Routing und Workflows |
| Kostenmodell | Pro-Seat plus Verbrauch (Agentic Work Units) | Infrastruktur- und Inference-Kosten, selbst verwaltet und optimiert |
| Operativer Aufwand | Gering, Salesforce betreibt die Plattform | Höher, erfordert DevOps, MLOps und Observability |
Das in der Praxis bewährte Muster: Starten Sie mit Agentforce-first, wo plattformverwaltete KI ausreicht. Ergänzen Sie eine Custom- oder Hybrid-Architektur für Workloads, die an eine Grenze stoßen — ein Modell, das die Plattform nicht unterstützt, eine Data-Residency-Regel, die sie nicht erfüllen kann, eine Retrieval-Pipeline, die privat bleiben muss, oder ein Kostenprofil, das zum Verbrauchspreis der Plattform nicht passt.
Kernarchitektur: Salesforce mit externer KI verbinden
Eine Custom- oder Hybrid-Salesforce-KI-Integration besteht aus drei Schichten: einer API- und Integrationsschicht, einer CRM-Datensynchronisationsschicht und einem externen AI-Stack, in dem Inference und Retrieval erfolgen.
API- und Integrationsschicht
Salesforce stellt mehrere Integrationsmechanismen bereit:
- Apex-Callouts mit Named oder External Credentials — synchrone Outbound-Calls von Salesforce zu einem externen KI-Endpunkt. External Credentials sind die moderne Ablösung veralteter Named Credentials und verwalten Secrets außerhalb des Apex-Codes.
- REST- und SOAP-APIs — für externe Systeme, die aus Salesforce lesen oder zurückschreiben, typischerweise wenn ein AI Agent einen Datensatz aktualisiert, eine Aufgabe erstellt oder Kontext abruft.
- Platform Events, Change Data Capture und die Pub/Sub-API — ereignisgesteuerte, Near-Real-Time-Synchronisation. Salesforce veröffentlicht Events bei Datensatzänderungen; Subscriber empfangen diese und reagieren entsprechend.
- Salesforce Connect — externe Datenvirtualisierung, die Salesforce ermöglicht, Daten außerhalb der Plattform darzustellen, ohne sie zu kopieren. Nützlich für Lookups, jedoch kein primärer KI-API-Mechanismus.
Für AWS-basierte Pipelines kann die Salesforce-Integration Salesforce Event Relay nutzen, um Platform Events direkt in Amazon EventBridge zu streamen, der sie an Lambda, SQS oder andere AWS-Services weiterleitet — ohne benutzerdefiniertes Polling.
Ein gängiges Produktionsmuster platziert ein API-Gateway — AWS API Gateway, Apigee oder ähnlich — zwischen Salesforce und den externen AI-Stack. Es übernimmt Authentifizierung, Rate-Limiting, Validierung und Logging, sodass die dahinterliegenden KI-Services geschützt und beobachtbar bleiben.
CRM-Datensynchronisation
Der externe AI-Stack benötigt aktuelle CRM-Daten. Near-Real-Time-Synchronisation ist das Ziel, jedoch ist Präzision entscheidend.
Change Data Capture und Platform Events übertragen Daten nicht direkt in S3, BigQuery oder Snowflake. Sie veröffentlichen Events an einen Subscriber. Eine Middleware oder ein Stream Processor — auf AWS Lambda, EventBridge, Kafka oder ähnlich — konsumiert diese Events und aktualisiert den externen Datenspeicher. Der AI-Stack liest aus diesem Speicher, nicht direkt von Salesforce.
Zwei Muster decken die meisten Anwendungsfälle ab:
- Near-Real-Time-Event-Sync — Platform Events oder CDC veröffentlichen Änderungen, ein Stream Processor aktualisiert den externen Speicher innerhalb von Sekunden. Geeignet für Agent-Assist- und Service-Workflows, bei denen Aktualität wichtig ist.
- Batch-Sync — geplante Jobs ziehen größere Datensätze für RAG-Ingestion, Embedding-Regenerierung oder Fine-Tuning. Geeignet für Anwendungsfälle, bei denen eine regelmäßige Aktualisierung ausreicht.
Bevor eine Synchronisation läuft, ist Datenqualität entscheidend. Die Anwendung von Salesforce-Datenverwaltungs-Best-Practices — saubere Felder, konsistente Namensgebung, Deduplizierung, klare Verantwortlichkeiten — verhindert, dass fehlerhafte Daten die Retrieval- und Inference-Qualität beeinträchtigen.
Externer AI-Stack auf AWS oder GCP
Der externe AI-Stack ist der Ort, an dem Modellauswahl und Infrastrukturkontrolle real werden. Unternehmen setzen typischerweise ein:
- Open-Weight- oder selbst gehostete LLMs — Llama, Mistral oder Qwen auf Amazon SageMaker, Google Vertex AI, Kubernetes oder dedizierter Inference-Infrastruktur. Self-Hosting bietet Kontrolle über Modell, Region und Inference-Pipeline, bringt jedoch operative Kosten und GPU-Kapazitätsplanung mit sich.
- Managed Model Services — Amazon Bedrock und Vertex AI bieten verwalteten Zugriff auf eine Reihe von Modellen ohne Self-Hosting. Es handelt sich um Managed Services, nicht um selbst gehostete Infrastruktur.
- Multi-Model-Routing — ein Gateway vor den Modellen, das jede Anfrage basierend auf Aufgabe, Kosten, Latenz oder Qualität an das richtige Modell leitet.
Die Wahl zwischen Self-Hosting und Managed dreht sich nicht immer um Kosten. Self-Hosting ist nicht automatisch günstiger als eine API — GPU-Auslastung, Engineering-Overhead und operativer Aufwand können die rohen Pro-Token-Einsparungen aufzehren. Die tatsächlichen Gründe für Self-Hosting sind Infrastrukturkontrolle, Compliance, private Bereitstellung und spezialisierte Fine-Tuned-Modelle, die Managed Services nicht bieten.
Private RAG-Architektur
Eine private RAG-Architektur hält CRM-Dokumente, Embeddings und Retrieval-Infrastruktur innerhalb einer unternehmenskontrollierten Umgebung. Kombiniert mit privater oder selbst gehosteter Inference kann sie die Notwendigkeit weiter reduzieren, sensible Kontextdaten an Drittanbieter-LLM-APIs zu senden.
Die typischen Komponenten:
- Dokument-Ingestion — Verträge, Tickets, Knowledge-Base-Artikel und CRM-Notizen werden in eine Verarbeitungspipeline übernommen.
- Embedding-Modell — wandelt Dokumente in Vektorrepräsentationen um und läuft innerhalb der eigenen Infrastruktur des Unternehmens.
- Vector Store — für private Infrastruktur: OpenSearch, pgvector oder eine selbst verwaltete Vektordatenbank innerhalb des Cloud-Accounts oder On-Prem des Unternehmens.
- Retrieval und Generation — zum Zeitpunkt der Abfrage ruft das System Kontext aus dem Vector Store ab und übergibt ihn an das LLM. Ist das LLM ebenfalls selbst gehostet, bleibt der gesamte Pfad innerhalb der Unternehmenskontrolle.
Der Wert liegt nicht nur im Datenschutz. Eine private RAG-Architektur bietet zudem Kontrolle über die Retrieval-Qualität — Tuning von Chunking, Embeddings und Reranking ohne eine plattformverwaltete Black Box.
Wann Unternehmen Custom Salesforce KI benötigen (Anwendungsfälle)
Die Anwendungsfälle, die Unternehmen zu einer Custom- oder Hybrid-Architektur führen:
- Privates RAG über sensible Dokumente — Verträge, Rechtskorrespondenz, Support-Tickets und Knowledge-Bases, die eine unternehmenskontrollierte Umgebung nicht verlassen sollten. Eine private RAG-Pipeline ermöglicht Agents das Abrufen von Antworten, ohne Rohdokumente an eine Drittanbieter-LLM-API zu senden.
- Open-Weight- oder selbst gehostete LLMs für Infrastrukturkontrolle, Workload-Ökonomie, Compliance oder private Bereitstellung — wenn ein Unternehmen ein spezifisches Modell in einer spezifischen Region benötigt, eine Compliance-Anforderung, die Managed Services nicht erfüllen können, oder ein Fine-Tuned-Modell, das über keine API verfügbar ist. Self-Hosting ist ein Trade-off, kein automatischer Kostenvorteil.
- Spezialisierte KI-Workflows — branchenspezifische Pipelines in BFSI, Healthcare, Logistik oder Immobilien, die Retrieval, Klassifikation und Generation auf Weise kombinieren, die die Plattform nicht nativ unterstützt.
- Data Residency — Inference und Retrieval müssen innerhalb eines bestimmten Landes oder einer Region erfolgen. Eine Custom-Architektur bindet den gesamten AI-Stack an diese Region.
- Multi-Model-Routing — mehrere LLMs hinter einem Gateway kombiniert, wobei jede Anfrage an das Modell geleitet wird, das am besten zur Aufgabe, zu Kosten und Latenz-Profil passt.
- Ergänzung von Agentforce — für Workloads, bei denen Agentforce-first nicht ausreicht, erweitert eine Custom- oder Hybrid-Schicht Salesforce ohne einen Rip-and-Replace des nativen AI-Stacks.
Security, Governance und Kostenaspekte
Custom Salesforce KI-Integration erweitert die Angriffsfläche und die Governance-Last. Das Sicherheitsmodell muss jede Schicht abdecken, die die Daten durchqueren.
Auf der Salesforce-Seite:
- External Credentials — speichern Authentifizierungs-Secrets außerhalb des Apex-Codes, mit Named Principals und Permission Sets, die den Zugriff auf den externen KI-Endpunkt steuern.
- Least-Privilege-Zugriff — Integrationsbenutzer und Service-Accounts erhalten nur die minimal benötigten Objekt- und Feldberechtigungen, nicht mehr.
- Feld- und objektbezogene Berechtigungen — werden auf Integrationsschichtebene durchgesetzt, sodass der externe AI-Stack nur die Felder erhält, die er benötigt.
- Datenklassifikation und Redaktion — Felder nach Sensitivität klassifizieren und PII redigieren oder maskieren, bevor sie Salesforce verlassen.
- Verschlüsselung — in Transit (TLS) und at Rest, auf beiden Seiten.
Auf der Seite des externen AI-Stacks: Verschlüsselung at Rest für den Vector Store, Zugriffskontrolle auf Inference-Endpunkte und Netzwerkisolation zwischen dem AI-Stack und anderen Workloads. Die Anwendung von LLM-Security für agentische KI-Praktiken — Prompt-Injection-Abwehr, Output-Validierung, Tool-Use-Guardrails — schließt die Schleife zu KI-spezifischen Risiken.
Governance ist der Bereich, in dem die meisten Unternehmen noch aufholen müssen. Laut dem Deloitte State of AI in the Enterprise 2026 Report verfügt nur etwa jedes fünfte Unternehmen (21 %) über ein reifes Governance-Modell für autonome AI Agents — rund 80 % verfügen über keine reife Governance. Für eine Custom Salesforce KI-Integration bedeutet Governance zu definieren, wo Menschen die Kontrolle behalten, wie automatisierte Entscheidungen auditiert werden, welche Datensätze aufbewahrt werden und wie Eskalationen an eine Person zurückgeleitet werden.
Logging und Audit Trail sind nicht verhandelbar — jeder Call, jedes Retrieval, jede Inference und jeder Write-Back sollte mit ausreichend Kontext protokolliert werden, um zu rekonstruieren, was passiert ist und warum.
Bei den Kosten gibt eine Custom-Architektur Unternehmen die Hebel zur Optimierung — Token-Monitoring, Semantic Caching, Model Routing, Right-Sizing — bedeutet jedoch auch, die Rechnung für Infrastruktur, Inference und Betrieb selbst zu tragen. Der Trade-off ist Kontrolle versus operativer Aufwand, bewusst eingegangen.
Aufbau einer Custom Salesforce KI-Integration
HDWEBSOFT begreift Salesforce KI-Integration als gemeinsame Anstrengung von Salesforce Certified Engineers und AI Engineers. Die Salesforce-Seite übernimmt CRM-Datenmodellierung, Integrationsmuster, Security und plattformnative Workflows; die KI-Seite übernimmt den externen LLM-Stack, die RAG-Pipeline und die Cloud-Infrastruktur.
Ein typisches Projekt verläuft in folgenden Schritten:
- Discovery und Architektur — Anwendungsfälle, Datenflüsse, Security- und Residency-Restriktionen erfassen und entscheiden, wo Agentforce-first passt und wo eine Custom- oder Hybrid-Schicht benötigt wird.
- API- und Integrationsschicht — Apex-Callouts, External Credentials, Platform Events oder CDC-Streams sowie das API-Gateway zwischen Salesforce und dem externen AI-Stack konzipieren.
- CRM-Datensynchronisation — Stream Processor und Aktualisierungen des externen Datenspeichers aufbauen, mit Datenqualitätsprüfungen vor der Synchronisation.
- Externe LLMs und RAG — Model Serving, Vector Store, Embedding-Pipeline und Retrieval-Logik auf AWS oder GCP bereitstellen.
- Cloud-Infrastruktur und Security — Compute, Networking und Storage bereitstellen mit integrierter Verschlüsselung, Least-Privilege, Redaktion, Logging und LLM-spezifischen Security-Kontrollen.
- Monitoring und Betrieb — Observability für Inference, Retrieval, Kosten und Governance, damit das System im Produktivbetrieb stabil und auditierbar bleibt.
Die AI-Integration-Services von HDWEBSOFT decken den gesamten Stack ab, und das Team agiert als langfristiger Delivery-Partner statt als einmaliger Implementierungs-Vendor.
Wenn Sie prüfen, ob sich eine Erweiterung von Salesforce über Agentforce hinaus lohnt, ist der nützlichste nächste Schritt ein fokussiertes Audit Ihrer aktuellen CRM-Daten, Anwendungsfälle und Restriktionen — eine Zuordnung, wo native KI passt und wo eine Custom- oder Hybrid-Architektur echten Mehrwert bietet.
Fazit
Agentforce hat native KI innerhalb von Salesforce zu einem starken Standard für viele Vertriebs- und Service-Anwendungsfälle gemacht. Unternehmen, die privates RAG, Open-Weight- oder selbst gehostete LLMs, spezialisierte Workflows, strikte Data Residency oder mehr Kontrolle über Inference-Kosten benötigen, brauchen jedoch oft eine Custom- oder Hybrid-Architektur darauf aufbauend.
Der richtige Ansatz ist selten ein Entweder-Oder. Agentforce-first deckt die native Seite; eine Custom- oder Hybrid-Salesforce-KI-Integration erweitert die Plattform um externe Agents, LLMs und privates RAG auf AWS oder GCP mit Near-Real-Time-CRM-Synchronisation und unternehmenskontrollierter Infrastruktur. Die Engineering-Arbeit ist real — API-Architektur, Data Sync, Security, Governance und Betrieb müssen sauber umgesetzt werden — doch die zurückgewonnene Kontrolle für das Unternehmen ist der Grund, warum Teams diesen Weg wählen.
Wenn Sie prüfen möchten, wie eine Custom Salesforce KI-Integration zu Ihrem Stack passt, können die Salesforce Certified Engineers und AI Engineers von HDWEBSOFT helfen. Vereinbaren Sie ein Salesforce KI-Customization-Audit, um zu starten.
FAQ
Was ist Salesforce KI-Integration?
Salesforce KI-Integration ist die Praxis, Salesforce-Daten und -Workflows mit KI-Funktionen zu verbinden — entweder nativ im Salesforce-Ökosystem wie Agentforce und Einstein oder extern über Custom AI Agents, Open-Weight- oder selbst gehostete LLMs und private RAG-Pipelines auf AWS oder GCP. Eine Custom- oder Hybrid-Architektur ergänzt Agentforce, wenn Unternehmen mehr Kontrolle über Modellauswahl, Infrastruktur, Data Residency, spezialisierte Workflows oder KI-Ekonomie benötigen.
Ist Custom Salesforce KI ein Ersatz für Agentforce?
Nein. Custom- oder Hybrid-Salesforce-KI ist kein Ersatz für Agentforce. Agentforce unterstützt Bring-Your-Own-Modelle und passt zu vielen nativen Vertriebs- und Service-Anwendungsfällen. Custom- und Hybrid-Architekturen ergänzen Agentforce, indem sie Salesforce um privates RAG, Open-Weight- oder selbst gehostete LLMs, spezialisierte KI-Workflows und unternehmenskontrollierte Infrastruktur erweitern, wenn native Funktionen nicht ausreichen.
Wie verbindet Salesforce externe LLMs und RAG?
Salesforce verbindet sich über mehrere Mechanismen mit externen LLMs und RAG: Apex-Callouts mit Named oder External Credentials für synchrone Outbound-Calls, REST- und SOAP-APIs für externe Systeme, die auf Salesforce zugreifen, Platform Events und Change Data Capture mit der Pub/Sub-API für ereignisgesteuerte Near-Real-Time-Synchronisation sowie Salesforce Event Relay zu Amazon EventBridge für AWS-basierte Pipelines. Eine Middleware- oder Stream-Processor-Schicht aktualisiert anschließend externe Datenspeicher und leitet Anfragen an den externen AI-Stack weiter.
Wann sollten Unternehmen Custom Salesforce KI gegenüber Agentforce wählen?
Unternehmen sollten eine Custom- oder Hybrid-Salesforce-KI-Architektur in Betracht ziehen, wenn sie privates RAG über sensible Dokumente, Open-Weight- oder selbst gehostete LLMs für Infrastrukturkontrolle oder Compliance, spezialisierte branchenspezifische KI-Workflows, strikte Data-Residency-Anforderungen, Multi-Model-Routing oder mehr Kontrolle über Inference-Kosten benötigen. Agentforce-first bleibt für viele native Vertriebs- und Service-Anwendungsfälle geeignet, in denen plattformverwaltete KI ausreicht.
Wie viel Kontrolle gibt eine Custom Salesforce KI-Integration über Daten und Kosten?
Eine Custom- oder Hybrid-Architektur gibt Unternehmen Kontrolle darüber, wo CRM-Dokumente, Embeddings und Retrieval-Infrastruktur liegen, welche Modelle laufen und wo Inference erfolgt, wie Daten klassifiziert und vor Erreichen einer KI-Komponente redigiert werden und wie Inference-Kosten durch Caching, Routing und Modell-Right-Sizing überwacht und optimiert werden. Diese Kontrolle ist der Hauptgrund, warum Unternehmen Custom Salesforce KI zusätzlich zu Agentforce einsetzen, anstatt sich ausschließlich auf plattformverwaltete KI zu verlassen.
