Salesforce-Agent steuert SAP über die Oberfläche
Salesforce hat auf der Dreamforce im September 2026 gezeigt, wie ein KI-Agent Prozesse in einem SAP-System ausführt. Der Agent namens Marshall übernahm in einer Sandbox das Lieferanten-Onboarding für das Fallbeispiel Siemens. Gesteuert wurde der Vorgang über Slack.
Nach Darstellung von Salesforce lernte Marshall, welche Schaltflächen anzuklicken und welche Pflichtfelder auszufüllen sind. Ein Sprachmodell leitete daraus die Geschäftsregeln des Prozesses ab. Anschließend wurden die erkannten Abläufe als wiederholbare und kontrollierte Aktionen gespeichert.
Marshall bündelt die Abläufe in einer Bibliothek vertrauenswürdiger Aktionen. Dadurch wird aus KI-Reasoning eine deterministische Ausführung, erklärte Salesforce sinngemäß.
Deterministische Ausführung bedeutet in diesem Zusammenhang, dass der Agent nicht bei jedem Durchlauf einen neuen Lösungsweg erfindet. Er greift stattdessen auf festgelegte Aktionen zurück. Das soll die Zuverlässigkeit bei kritischen ERP-Prozessen erhöhen.
Warum SAPs API-Richtlinie zum Problem wird
SAP hat im April eine neue API-Richtlinie eingeführt. Sie untersagt unter anderem sogenannte Impersonation-Techniken, bei denen Identitäten zur Umgehung von Zugriffskontrollen verwendet werden. Außerdem dürfen autonome oder generative KI-Systeme keine Folgen von API-Aufrufen planen und ausführen, sofern dies nicht innerhalb einer von SAP freigegebenen Architektur geschieht.
Genau an diesem Punkt entzündet sich die Kritik. SAP-Experten sehen die Gefahr, dass eine vergleichbare Umsetzung in einem Produktivsystem gegen die Richtlinie verstoßen könnte. Das gilt vor allem dann, wenn ein Sprachmodell selbstständig Zugriffe plant oder Anwendungslogik aus SAP übernimmt.
| Zeitpunkt | Entwicklung | Relevanz |
|---|---|---|
| Dezember 2025 | Joule Agent Builder wird Teil von Joule Studio in SAP Build | SAP schafft eine eigene Umgebung für den Bau von Agenten |
| April 2026 | Einführung der neuen SAP-API-Richtlinie | KI-Zugriffe außerhalb freigegebener Architekturen werden eingeschränkt |
| Mai 2026 | KI-Dienste für ECC und S/4HANA On-Premises sowie Joule Studio 2.0 werden angekündigt | SAP öffnet das Angebot über RISE with SAP hinaus |
| September 2026 | Salesforce zeigt Marshall auf der Dreamforce | Die Abgrenzung zwischen UI-Automatisierung und KI-Integration wird praktisch relevant |
Salesforce verweist auf Service-Accounts statt APIs
Salesforce weist den Vorwurf eines Regelverstoßes zurück. Die Demonstration habe SAP nicht über APIs angesprochen. Marshall habe über die Benutzeroberfläche und mit Service-Accounts gearbeitet.
Der entscheidende Unterschied sei, dass die Demo über die SAP-Benutzeroberfläche und ohne SAP-APIs ausgeführt wurde. Die Einschränkungen der API-Richtlinie seien deshalb nicht auf die gezeigte Aktivität anwendbar, erklärte Salesforce sinngemäß.
Damit verschiebt sich die Auseinandersetzung von der technischen auf die lizenzrechtliche Ebene. Klassische Robotic Process Automation, also die automatisierte Bedienung einer Oberfläche, gilt grundsätzlich als etablierte Methode. Unklarer wird es, sobald ein Sprachmodell den Ablauf plant, Entscheidungen trifft und Aktionen selbstständig ausführt.
Bislang ist nicht bestätigt, wie SAP eine solche UI-Automatisierung mit Service-Accounts rechtlich und lizenzrechtlich bewertet. Ebenso bleibt offen, ob der gezeigte Siemens-Ablauf produktiv eingesetzt wird. Belegt ist lediglich die Vorführung in einem SAP-Sandbox-System.
Indirect Access kehrt als KI-Konflikt zurück
Der Streit erinnert an die seit fast zwei Jahrzehnten geführten Auseinandersetzungen um SAPs Indirect Access. Dabei geht es um Zugriffe auf SAP-Funktionen durch externe Systeme, ohne dass ein klassischer SAP-Nutzer direkt mit dem ERP arbeitet. Solche Konstellationen haben wiederholt zu Unsicherheit über zusätzliche Lizenzen und Nachforderungen geführt.
Bei KI-Agenten kommt eine weitere Ebene hinzu. Der externe Dienst liest nicht nur Daten oder stößt einen fest definierten Prozess an. Er kann Abläufe analysieren, Aktionen auswählen und damit Teile der Benutzeroberfläche kontrollieren.
Ein Branchenanalyst bezeichnete die API-Politik als protektionistisch. Nach seiner Einschätzung hatten 93 % der Großkunden durch die anfängliche Beschränkung auf RISE with SAP keinen Zugriff auf SAPs KI-Angebote. Diese Zahl ist eine Analysteneinschätzung und keine von SAP bestätigte Kundenstatistik.
SAP hat sein Angebot inzwischen erweitert. Mit Joule Studio und eigenen Integrationswerkzeugen sollen Agenten auch Drittanwendungen anbinden können. Der Zugriff bleibt dabei jedoch an SAPs technische Standards und freigegebene Architekturen gekoppelt.
Plattformkonflikt erhöht Kosten und Abhängigkeiten
Hinter der technischen Debatte steht ein Konflikt um die Kontrolle der Arbeitsoberfläche. Salesforce will Prozesse aus Slack und der eigenen Plattform heraus steuern. SAP soll dabei im Hintergrund als ERP und Datenquelle dienen. SAP wiederum hat ein wirtschaftliches Interesse daran, Agenten in Joule Studio und der eigenen Cloud-Architektur zu verankern.
Für Unternehmen entsteht daraus ein klassisches Vendor-Lock-in-Problem. Eine herstellerübergreifende Automatisierung kann technisch funktionieren und trotzdem durch Vertragsbedingungen, Zugriffsvorgaben oder zusätzliche Integrationsprodukte verteuert werden. Die Kosten des Agenten selbst sind dabei nur ein Teil der Rechnung, wie auch die Diskussion über das Salesforce-Preismodell für KI-Agenten zeigt.
Im DACH-Raum ist das besonders relevant, weil SAP in vielen Konzernen das zentrale ERP-System stellt. Schon normale S/4HANA-Projekte sind organisatorisch und wirtschaftlich anspruchsvoll, was etwa die gestoppte Greenfield-Migration auf SAP S/4HANA bei Zeiss verdeutlicht. Zusätzliche KI-Schichten erhöhen die Zahl der technischen und vertraglichen Abhängigkeiten weiter.
Was vor einem produktiven Einsatz geklärt werden sollte
- Ob der Agent APIs, die Benutzeroberfläche oder eine Kombination aus beiden verwendet.
- Welche Identitäten und Service-Accounts eingesetzt werden und wie deren Rechte begrenzt sind.
- Ob das Sprachmodell Aktionen nur vorbereitet oder selbstständig plant und ausführt.
- Welche SAP-Architektur für den Zugriff ausdrücklich freigegeben ist.
- Ob zusätzliche Nutzer-, Schnittstellen- oder Plattformlizenzen erforderlich werden.
Auch Eigenentwicklungen und Agenten auf Basis von Open-Source-Modellen lösen diese Fragen nicht automatisch. Sie können Abonnementkosten und Abhängigkeiten auf der Modellseite reduzieren. Beim Zugriff auf SAP bleiben jedoch die Vertragsbedingungen und technischen Kontrollpunkte des ERP-Anbieters maßgeblich.