Joule, Skills, Agents und Foundation Models: Was SAPs AI-Familie kommerziell unterscheidet
Joule ist nicht ein Produkt, sondern eine Familie aus Frontend, Skills, Agents und Foundation Models. Jede Komponente folgt einer eigenen Lizenzlogik, erzeugt eigene Verbrauchsmuster und öffnet eigene Steuerungsmomente. Was sich kommerziell unterscheidet, wie Skills von Agenten abzugrenzen sind, und welche Foundation Models im GenAI Hub bereitstehen.
Joule für Endnutzer
Wenn in SAP-Projekten von "Joule" gesprochen wird, ist meistens Joule for Users gemeint: der konversationelle Assistent, der direkt in SAP-Lösungen eingebettet ist. Stand Sapphire 2026 ist Joule for Users in 35 SAP-Lösungen aktiv, darunter S/4HANA Cloud, SuccessFactors, Ariba und Fieldglass. Endanwender können über eine einheitliche Oberfläche Aufgaben starten, Workflows anstoßen und eingebettete AI-Features nutzen, ohne zwischen Anwendungen wechseln zu müssen.
Für die Vertragssteuerung ist diese Komponente häufig der erste Steuerungsmoment: Sie ist in vielen RISE-Verträgen und Cloud-ERP-Bundles enthalten, aber nicht immer ist klar, in welchem Umfang. Der Zugang zu Joule for Users ist kein binäres "ein oder aus". Er hängt vom gebuchten Tier, von der aktivierten Lösung und davon ab, ob AI-Unit-Kontingente für die Nutzung bereitstehen.
Joule Work, die bei Sapphire 2026 vorgestellte UX-Vision, geht einen Schritt weiter: SAP positioniert Joule langfristig als primäre Interaktionsschicht, die App-Navigationen schrittweise ablöst. Was heute als Copilot-Funktion eingesetzt wird, soll mittelfristig zum Standard-Interface für alle SAP-Lösungen werden. Dieser Richtungswechsel ist für die kommerzielle Steuerung relevant, weil er die Nutzungsintensität und damit den Verbrauch strukturell verändert.
Joule für Developer und Consultants
Die zweite Variante richtet sich nicht an Endanwender, sondern an Entwickler und Implementierungspartner.
Joule for Developers ist der ABAP-Assistent in der ABAP Development Tools-Umgebung (ADT) und im Business Application Studio (BAS). Er basiert auf SAP-ABAP-1, dem SAP-eigenen Modell, das auf 250 Millionen Zeilen ABAP-Code trainiert wurde. Er unterstützt Code-Generierung, Refactoring und Testgenerierung. SAP gibt eine Produktivitätssteigerung von 20 bis 25 Prozent für Entwickler an (Quelle: SAP Community, Our 2026 Roadmap for Joule for Developers). Die Lizenzierung erfolgt über eine separate Joule-for-Developers-SKU oder als Bestandteil von BTP-Entwicklersubscriptions.
Hier liegt ein eigenständiger Steuerungsmoment: Viele Organisationen haben Joule for Developers im Rahmen von BTP-Subscriptions als eingebettete Funktion, ohne diesen Zugang aktiv verwaltet zu haben. Mit wachsender Nutzung wächst auch der AI-Unit-Verbrauch, der für diese Komponente anfällt.
Joule for Consultants befindet sich noch im Beta-Status und ist als Konfigurationsassistent für Implementierungspartner konzipiert. Die Generally-Available-Version ist im Laufe von 2026 geplant. Für bestehende Projekte ist relevant, wann dieser Status wechselt, da Beta-Capabilities ohne Ankündigung verändert oder zurückgezogen werden können.
Joule Studio 2.0 ist die Entwicklungsumgebung für kundeneigene Agenten. Sie ist seit Juni 2026 generally available und enthält Agent Builder, Skill Library, Joule Studio CLI, VS Code Extension und eine MCP-Server-Integration für externe AI-Toolchains. Bis Ende 2026 gewährt SAP kostenlosen Design-Time-Zugang unter Fair-Use-Bedingungen. Dieser Zugang deckt die Entwicklungsumgebung ab, nicht den produktiven Betrieb: Runtime-Lizenzen für kundeneigene Agenten in Produktion sind separat zu planen und zu verhandeln.
Skills versus Agents: die entscheidende Unterscheidung
Für die kommerzielle Steuerung ist keine Unterscheidung in SAPs AI-Familie wichtiger als die zwischen Skills und Agenten. Sie bestimmt Verbrauchsvolumen, Risikoprofil und die relevanten Steuerungsmomente.
Ein Joule Skill ist eine deterministische, vordefinierte Operation. Er führt eine einzelne, klar definierte Aktion aus: eine Bestellung anlegen, einen Datensatz prüfen, eine Meldung weiterleiten. Skills sind in ihrem Verbrauch planbar, in ihrem Risiko berechenbar und bei Vertragsabschluss in der Regel bereits in den Sizing-Annahmen berücksichtigt. Stand Q2 2026 stellt SAP über 2.500 vorgefertigte Skills in der Skill Library bereit.
Ein Joule Agent ist ein autonomes System, das mehrere Skills orchestriert, plant und eigenständig handelt. Er verfolgt ein übergeordnetes Ziel und wählt den Weg dorthin selbst. Eine typische Agenten-Aufgabe lautet: "Optimiere alle offenen Bestellungen nach Lieferzeit und Kosten" oder "Onboarde den neuen Mitarbeiter systemübergreifend." Der Agent entscheidet, welche Skills er in welcher Reihenfolge aktiviert, und kann dabei Pfade nehmen, die im Vorfeld nicht vollständig antizipiert wurden.
Der kommerzielle Unterschied ist erheblich. Agentische Deployments verbrauchen laut Beobachtungen aus der Praxis das Drei- bis Zwanzigfache an AI Units gegenüber reinen Skill-basierten Copilot-Projektionen (Quelle: SAP Licensing Experts, Negotiating SAP AI Contracts). Wer den Sprung von einem Copilot-Deployment zu produktiven Agenten plant, ohne den Sizing-Faktor anzupassen, riskiert unerwartete Overage.
Für den Steuerungsmoment bei der Vertragsverhandlung bedeutet das: Die Frage "Nutzen wir Skills oder Agenten?" sollte vor der Sizing-Festlegung beantwortet sein. SAP-Standard-Sizing-Annahmen basieren typischerweise auf Skill-basierter Nutzung. Wer Agenten plant, sollte diesen Faktor explizit in die Vertragsgrundlage einbringen.
Stand Sapphire 2026 bietet die SAP Autonomous Suite 224 Agenten und 51 rollenspezifische Assistenten über Finance, Spend Management, Supply Chain, HR und Customer Experience. Die Anzahl wächst pro Quartal. Jede neue Capability ist potenziell ein neuer Verbrauchspunkt, der laufend beobachtet werden sollte.
Foundation Models im GenAI Hub
Joule hat kein eigenes "Joule-Modell". Es ist ein Frontend-Layer, der Foundation Models aus dem Generative AI Hub konsumiert. Welches Modell für welchen Use Case eingesetzt wird, beeinflusst sowohl das Ergebnis als auch den Verbrauch, denn Token-Raten variieren je nach Modell erheblich.
Der Generative AI Hub bietet Zugang zu Foundation Models verschiedener großer Anbieter. SAP abstrahiert die jeweilige API, sodass Kunden pro Use Case ein Modell auswählen können, ohne direkte Vertragsbeziehungen zu den Modellanbietern aufzubauen. Die verfügbaren Modelle variieren und werden von SAP rollierend aktualisiert. Welche Modelle konkret in einem Kunden-Tenant verfügbar sind, hängt von Region, Vertragsversion und SAP-Freigabe ab (Quelle: SAP Help Portal, Generative AI Hub).
Für die Steuerungsmomente im laufenden Betrieb sind zwei Aspekte relevant:
Erstens ist die Modellauswahl ein Kostenparameter. Einfache Aufgaben, die mit einem leichteren Modell erledigt werden können, erzeugen weniger Token-Verbrauch als Aufgaben, die ein komplexes Modell mit umfangreichem Kontext-Fenster benötigen. Eine undifferenzierte Konfiguration, bei der für alle Use Cases dasselbe Modell eingesetzt wird, ist häufig nicht wirtschaftlich optimal.
Zweitens ist die Austauschbarkeit von Modellen eine Governance-Frage. SAP kann das Modell-Portfolio im Generative AI Hub rollierend anpassen. Ob und wie das den Kunden-Tenant betrifft, hängt davon ab, ob der Order Form explizite Regelungen zur Modellkontinuität enthält. Fehlende Regelung bedeutet typischerweise, dass SAP das Modell-Portfolio unilateral anpassen kann.
SAP-eigene Modelle und Vendor-Lock-in
Neben externen Foundation Models entwickelt SAP zwei eigene Modelle, die für spezifische SAP-Kontexte optimiert sind.
SAP-ABAP-1 wurde auf 250 Millionen Zeilen ABAP-Code trainiert. Es ist die Grundlage für Joule for Developers und bietet gegenüber generischen Sprachmodellen einen messbaren Vorteil bei ABAP-Aufgaben: bessere Qualität bei Code-Generierung, präzisere Testvorschläge, tieferes Kontextwissen zu SAP-spezifischen Konstrukten (Quelle: SAP News, Joule Studio Enterprise Scale Agentic Development).
SAP-RPT-1 ist auf SAP-Geschäftsprozessdaten trainiert und ermöglicht Process-Inference für eingebettete AI-Features. Es unterstützt Vorhersagen und Empfehlungen entlang SAP-Standardprozessen.
Die strategische Frage bei SAP-eigenen Modellen lautet: Sie bieten einen echten Mehrwert, weil sie SAP-spezifisches Domänenwissen eingebettet haben. Gleichzeitig erzeugen sie eine Abhängigkeit: Wer seine ABAP-Entwicklungsprozesse auf SAP-ABAP-1 ausrichtet, baut eine Praxis auf, die sich nicht einfach auf ein anderes Modell übertragen lässt (Quelle: SAVIC Technologies, AI Foundation Architecture 2026).
Dieser Steuerungsmoment ist strategischer Natur: Wie viel Vertragsinfrastruktur und Entwicklungspraxis soll explizit auf SAP-eigenen Modellen aufgebaut werden? Und welche Klauseln im Order Form beschreiben, unter welchen Bedingungen SAP diese Modelle verändern oder zurückziehen darf? Diese Fragen sollten in Erstgesprächen über AI-Governance Teil der Agenda sein.
SAP-eigene Modelle liegen typischerweise am unteren Ende der Token-Preisskala im Vergleich zu extern eingebundenen Foundation Models. Das macht sie auch aus reiner Kostensicht attraktiv für häufig aufgerufene, standardisierte Use Cases.
Multi-Agent-Protokoll und MCP
Die sechste Dimension der Joule-Familie betrifft die systemübergreifende Koordination: SAP hat im ersten Quartal 2026 ein Multi-Agent-Protokoll eingeführt, das Agenten über SAP- und Nicht-SAP-Systeme hinweg orchestriert.
Konkret bedeutet das: Ein SAP-Agent kann mit einem anderen SAP-Agenten kommunizieren, mit einem kundeneigenen Agenten aus Joule Studio und mit einem Drittpartei-Agenten über das offene Model Context Protocol (MCP). Ein Hire-to-Onboard-Workflow kann einen SuccessFactors-Agenten für die Kandidatenauswahl, einen S/4HANA-Agenten für die Stammdatenanlage und einen weiteren Agenten für die Systemzugangsprovisionierung koordinieren, ohne manuelle Übergaben zwischen Systemen.
MCP ist ein offener Standard, den SAP seit Q1 2026 unterstützt. Er erlaubt externen AI-Toolchains, auf SAP-Joule-Skills zuzugreifen, und SAP-Agenten, externe MCP-Server zu konsumieren. Für Organisationen, die eigene AI-Architekturen betreiben, ist das eine Brücke zwischen SAP-Agenten und externen Werkzeugen.
Aus der Perspektive der Vertragssteuerung öffnen Multi-Agent-Szenarien mehrere Steuerungsmomente gleichzeitig. Jeder Agenten-Aufruf im Rahmen eines Multi-Agent-Workflows erzeugt eigenen Verbrauch. Die Beobachtbarkeit dieser Workflows ist mit Standard-SAP-Reporting-Tools begrenzt: Der SAP AI Agent Hub, der im dritten Quartal 2026 generally available werden soll, ist als Governance-Werkzeug für diese Komplexität konzipiert.
Relevant ist auch das Spannungsverhältnis zwischen MCP-Offenheit und der SAP API Policy v4/2026: SAP unterstützt MCP, verbietet aber gleichzeitig autonome Dritt-AI-Agenten an SAP-APIs. Drittpartei-Komponenten dürfen Skills bereitstellen, aber keine eigenständig agierenden Agenten an SAP-Daten betreiben (Quelle: SAP API Policy, referenziert im SAP Help Portal). Wer eine Hybrid-Architektur mit SAP- und Nicht-SAP-Agenten plant, sollte diesen Punkt vor der Architekturentscheidung klären.
FAQ
Was ist der Unterschied zwischen einem Joule Skill und einem Joule Agent?
Ein Joule Skill ist eine deterministische, vordefinierte Einzelaktion: vorhersehbarer Verbrauch, begrenztes Risiko. Ein Joule Agent ist ein autonomes System, das mehrere Skills orchestriert und eigenständig plant. Der Verbrauchsunterschied ist erheblich: Agenten konsumieren laut Praxisbeobachtungen das Drei- bis Zwanzigfache gegenüber reinen Copilot-Deployments (Quelle: SAP Licensing Experts). Diese Unterscheidung sollte bei jeder AI-Unit-Sizing-Diskussion auf der Agenda stehen.
Was sind Foundation Models im SAP GenAI Hub, und wie wähle ich das richtige aus?
Der Generative AI Hub bietet Zugang zu Foundation Models verschiedener großer Anbieter sowie zu SAP-eigenen Modellen wie SAP-ABAP-1 und SAP-RPT-1. SAP abstrahiert die Modell-API, sodass kein direkter Vertrag mit dem Modellanbieter erforderlich ist. Das richtige Modell hängt vom Use Case ab: SAP-eigene Modelle sind für SAP-spezifische Aufgaben optimiert und günstiger in der Token-Rate. Externe Modelle bieten mehr Flexibilität bei generischen Aufgaben (Quelle: SAP Help Portal, Generative AI Hub).
Was bedeutet MCP für SAP-Verträge?
Das Model Context Protocol ist ein offener Standard, der SAP-Agenten und externe AI-Toolchains verbinden kann. SAP unterstützt MCP seit Q1 2026. Vertraglich relevant ist, dass die SAP API Policy v4/2026 autonome Dritt-AI-Agenten an SAP-APIs nicht erlaubt. Drittpartei-Komponenten dürfen Skills bereitstellen, aber nicht eigenständig agieren. Wer Hybrid-Architekturen plant, sollte diese Grenze im Order Form geklärt haben.
Ist der kostenlose Joule Studio Zugang bis Ende 2026 für alle Kunden verfügbar?
SAP gewährt bis Ende 2026 kostenlosen Design-Time-Zugang zu Joule Studio unter Fair-Use-Bedingungen. Das deckt die Entwicklungsumgebung ab, nicht den produktiven Betrieb. Runtime-Lizenzen für kundeneigene Agenten in Produktion sind separat zu erwerben. Organisationen, die 2026 Agenten in Joule Studio bauen, sollten frühzeitig die Runtime-Kosten für 2027 in die Budgetplanung einbeziehen.
Nächste Schritte
Wie die Joule-Komponenten in Ihrem SAP-Vertrag lizenziert sind, welche AI-Unit-Kontingente für Skills und Agenten bereitstehen und wo Steuerungsmomente noch nicht abgebildet sind: Das lässt sich strukturiert analysieren.
Vertragscheck vereinbaren oder FinOptory AI zur Ersteinschätzung nutzen.
Weiterführende Artikel in diesem Pillar:
Nächste Schritte
Wenn Sie Ihren aktuellen Vertrag auf Risiken und verfügbare kommerzielle Hebel prüfen lassen möchten: Der FinOptory Vertragscheck ist ein Festpreis-Engagement, das in vier Wochen eine strukturierte Grundlage liefert.
