Business AI im RISE-Vertrag: Was inkludiert ist, was Add-On, und wo die Aggregations-Falle wartet

Q: Was ist im RISE-Standardvertrag an Business AI wirklich enthalten?

Typischerweise einige eingebettete AI-Features, fixe Transaktions-Quoten und ein View-Only-Joule-Zugang. Für produktive AI-Adoption sind Joule Power User Seats und zusätzliche AI Units als Add-Ons zu beschaffen.

Q: Was passiert bei Überverbrauch im RISE-AI-Vertrag?

Typische Staffelung: bis 20% über Kontingent ohne Aufpreis, 21-50% das 1,5-Fache der Vertragsrate, mehr als 50% das Zwei- bis Vierfache oder Service-Suspendierung.

RISE-Verträge enthalten Business-AI-Komponenten, aber nicht alle. Embedded AI-Features sind im Standard-Tier inkludiert, AI Units sind ein Add-On. Was im RISE-Vertrag steckt, was zusätzlich gebucht werden muss, welche Order-Form-Sektionen Sie prüfen sollten, und wo die Aggregations-Falle bei Cross-Topf-Verbrauch wartet.

Drei Beschaffungsvehikel im Vergleich

SAP Business AI lässt sich über drei unterschiedliche kommerzielle Wege beschaffen. Die Wahl bestimmt nicht nur den Preis, sondern auch die vertragliche Bindung, die Bundling-Optionen und die Steuerungsmomente, die Ihnen in der laufenden Vertragsperiode zur Verfügung stehen.

Das erste Vehikel ist der Standalone-BTP-Weg: AI Units werden direkt im BTP Global Account gekauft, ohne weitere Vertragsbindung. Dieser Weg bietet die geringste Laufzeitbindung, hat aber den höchsten Pro-Unit-Preis. Er ist in der Praxis wirtschaftlich sinnvoll nur bei eng abgegrenzten Pilotprojekten mit definiertem Laufzeitrahmen oder bei Unternehmen ohne aktiven SAP Cloud ERP Private- oder RISE-Vertrag.

Das zweite Vehikel ist das Business AI Subscription Bundle, ein eigenständiges Subscription-Paket, das AI Units, Joule-Zugang und AI Foundation-Zugang bündelt. Es bietet einen niedrigeren Pro-Unit-Preis als der Standalone-Weg bei höherer Gesamtbindung und eignet sich für Unternehmen, die SAP Business AI als eigenständige Initiative beschaffen wollen, unabhängig von ihrer Cloud-ERP-Vertragsstruktur.

Das dritte Vehikel ist die Einbindung in den bestehenden RISE- oder SAP Cloud ERP Private-Vertrag. Hier sind AI Units als Teil des Cloud-ERP-Bundles beschaffbar oder werden als Add-On zu bestehenden Vertragsbedingungen hinzugefügt. SAP quersubventioniert den AI-Verbrauch in diesem Modell als Teil des Gesamtpakets, was es für Kunden mit aktivem RISE-Vertrag typischerweise zur wirtschaftlich vorteilhaftesten Ausgangsbasis macht (Quelle: SAP Licensing Experts, SAP AI in RISE Contracts 2026).

Was in RISE embedded ist

Die häufigste Fehleinschätzung in Erstgesprächen: Der RISE-Vertrag enthält Business AI vollständig. Er enthält einen Teil davon. Welchen Teil, hängt vom Tier, vom Verhandlungsstand und vom Zeitpunkt des Vertragsabschlusses ab.

Einige AI-Features sind in jedem SAP Cloud ERP Private Tier ohne zusätzliche AI-Unit-Lizenz enthalten. Dazu gehören typischerweise Predictive Accounting, Intelligent AP Automation und Demand Sensing, also Funktionen, die SAP als Grundbestandteil der Lösungssubscription positioniert. Diese eingebetteten Features erzeugen keinen separaten AI-Unit-Verbrauch, sind aber in ihrer Funktionstiefe und Konfigurierbarkeit begrenzt.

Ergänzend sind in RISE- und Cloud-ERP-Private-Verträgen fixe Transaktions-Quoten enthalten. Laut SAP Licensing Experts liegen diese typischerweise bei 10.000 bis 50.000 AI-Transaktionen pro Monat, je nach Tier. Diese Quoten sind für erste Orientierungsversuche ausreichend. Für eine AI-Adoption, die über gelegentliche Einzelanfragen hinausgeht, sind sie strukturell zu gering. SAP gestaltet diese Einstiegsgrenzen bewusst eng.

Joule ist im Standard-RISE-Vertrag mit einem View-Only-Zugang und begrenzten täglichen Konversations-Sessions enthalten, typischerweise 10 bis 20 Sessions pro Nutzer pro Monat. Dieser Zugang ist für produktive Nutzung, die über sporadische Einzelabfragen hinausgeht, nicht ausreichend.

Wichtig für die laufende Steuerung: SAP ändert den Capability-Umfang inkludierter Features im Rahmen von Quartalsupdates und Repackaging-Zyklen. Was im Order Form zum Zeitpunkt des Vertragsabschlusses stand, muss nicht identisch sein mit dem, was aktuell ausgeliefert wird. Ein Steuerungsmoment, der häufig übersehen wird: die regelmäßige Überprüfung, ob die vertraglich zugesicherten Capabilities noch deckungsgleich mit dem tatsächlich bereitgestellten Funktionsumfang sind (Quelle: SAP Licensing Experts, SAP AI in RISE Contracts 2026).

Was Add-On ist (Auswahl)

Über den Basisumfang hinaus sind folgende Komponenten als Add-On beschaffbar, jeweils mit eigenen Pricing-Parametern und Laufzeitbedingungen:

Joule Power User Seats sind erforderlich, sobald produktiver Joule-Einsatz über den beschränkten View-Only-Umfang hinausgeht. Dieser Add-On-Bedarf wird in frühen RISE-Vertragsverhandlungen häufig nicht transparent, weil SAP Joule als RISE-Bestandteil kommuniziert, ohne die funktionalen Grenzen des Basisumfangs ausdrücklich zu nennen.

Joule API Consumption ermöglicht die Einbettung von Joule-Funktionen in eigene Applikationen. Dieser Zugang ist separat zu lizenzieren und erzeugt, wie im Abschnitt zu Embedding-Lizenzen beschrieben, eine zusätzliche Kostendimension.

BTP AI Core und AI Launchpad sind eigenständige BTP-Services, die für den Betrieb eigener AI-Workloads auf BTP benötigt werden. Sie werden über den BTP-Verbrauch (Capacity Units) lizenziert und sind nicht automatisch im RISE-Bundle enthalten.

AI Foundation Foundation-Model-Zugang ermöglicht den Token-basierten Zugang zu Foundation Models über den Generative AI Hub. Dieser Zugang ist separat beschaffbar und fällt unter Token-basiertes Pricing.

Zusätzliche AI Units können über das vertraglich fixierte Kontingent hinaus erworben werden, zum individuell verhandelten Pro-Unit-Preis des bestehenden Order Forms.

Bei Verhandlungen gilt: Die benötigten Add-Ons frühzeitig identifizieren und ihre Bedingungen im gleichen Verhandlungszyklus wie den Hauptvertrag klären. Wer Add-Ons erst nach Vertragsabschluss verhandelt, verliert Konditionenspielraum (Quelle: Advisory Report, Negotiating SAP RISE Add-Ons).

Order-Form-Sektionen zum Prüfen

Nicht das Rahmenvertragsdokument, sondern das Order Form ist die bindende kommerzielle Grundlage. Marketing-Versprechen sind keine Vertragsbasis. Diese Unterscheidung ist ein zentraler Steuerungsmoment für Contract Manager, Procurement und Controlling: Wer aus Sales-Unterlagen steuert statt aus dem aktuellen Order Form, arbeitet auf einer unsicheren Basis.

Für SAP Business AI im RISE-Kontext sind folgende Order-Form-Sektionen besonders relevant:

Das BTP Entitlements Exhibit zeigt, welche AI-Unit-Allokation im Vertrag enthalten ist und in welchen Tiers sie gilt. Hier lässt sich prüfen, ob die tatsächliche Allokation den Sizing-Annahmen aus der Verhandlung entspricht.

Das AI Units Exhibit regelt den Pro-Unit-Preis. Entscheidend: Ist die Rate fixiert, oder verweist das Exhibit auf "current pricing"? Ein Verweis auf current pricing bedeutet, dass SAP den Pro-Unit-Preis bei Verlängerung oder Aufstockung einseitig anpassen kann. Dieser Steuerungsmoment ist in der Verhandlung klar zu regeln.

Die Capability-Liste benennt, welche Capabilities vertraglich zugesichert sind. SAP ändert das Capability-Portfolio rollierend. Was nicht in der Capability-Liste steht, ist nicht verbindlich zugesichert.

Die Overage-Klausel definiert Faktoren, Cap und Eskalationsmechanismus. Soft-Overage ohne Cap bedeutet, dass der Verbrauch ohne automatische Benachrichtigung oder Genehmigungspflicht weiterlaufen kann. Für Controlling und Executive ist dies ein Steuerungsmoment, der planbar zu gestalten ist: Eine explizite Cap-Vereinbarung und eine Approval-Pflicht bei Erreichen einer definierten Schwelle gehören in jede Vertragsverhandlung.

Rollover-Regelungen legen fest, ob und wie viele AI Units auf das Folgejahr übertragen werden können. Ein Rollover von 10 bis 20 Prozent der nicht genutzten AI Units ist in Verhandlungen erreichbar, ist aber kein Standard (Quelle: SAP Licensing Experts, Negotiating SAP AI Contracts).

Die Aggregation-Scope-Klausel definiert, ob Entwicklungs-, Test- und Produktivumgebungen gemeinsam oder getrennt auf das Kontingent angerechnet werden. Diese Klausel ist die Grundlage der Aggregations-Falle, die im nächsten Abschnitt beschrieben wird.

Aggregations-Falle bei Multi-Topf-Verbrauch

Eine in vielen RISE-Verträgen enthaltene Standardklausel aggregiert den AI-Verbrauch über alle Systemumgebungen des Kunden hinweg: Entwicklung, Test und Produktion werden gemeinsam auf das monatliche Kontingent angerechnet.

Für Unternehmen mit aktiven S/4HANA-Systemlandschaften in mehreren Umgebungen bedeutet das: Entwicklungs- und Testaktivitäten mit AI-Features werden gegen dasselbe Kontingent verrechnet wie der Produktivbetrieb. Wer AI-Features aktiv in Nicht-Produktivumgebungen betreibt oder testet, kann unerwartet hohe Verbräuche erzeugen, ohne dass das Produktivsystem allein dafür verantwortlich ist. Dieser Steuerungsmoment wird häufig erst bei der nächsten Abrechnung sichtbar (Quelle: SAP Licensing Experts, SAP AI in RISE Contracts 2026).

Die Aggregations-Falle ist keine Anomalie, sondern Vertragsstandard. Sie betrifft jeden Kunden, der mehr als eine S/4HANA-Umgebung betreibt, also praktisch jeden Enterprise-Kunden.

Hinzu kommt die Drei-Topf-Dimension: Ein produktiver AI-Use-Case, der Geschäftsdaten aus der Business Data Cloud abruft, auf BTP-Laufzeit ausgeführt wird und dabei ein Foundation Model im Generative AI Hub aufruft, erzeugt gleichzeitig AI-Unit-Verbrauch, Capacity-Unit-Verbrauch und BDC-Credit-Verbrauch. Die drei Töpfe werden in unterschiedlichen SAP-Tools angezeigt, mit unterschiedlichen Reporting-Rhythmen und ohne konsolidierte Sicht. Für Controlling entsteht daraus eine Herausforderung: Die Gesamt-AI-Investition lässt sich mit nativen SAP-Werkzeugen nicht in einem Blick darstellen (Quelle: NextLytics, DSAG Technology Days 2026).

Die Verhandlungsoption: Eine Dev/Test-Exclusion für die AI-Unit-Zählung ist verhandelbar. Sie sollte bei jeder neuen Vertragsverhandlung und bei jeder Vertragsverlängerung geprüft und eingefordert werden.

Die Overage-Faktoren, die bei einem nicht gesteuerten Überverbrauch greifen, sind in öffentlich zugänglichen Quellen dokumentiert: bis 20 Prozent über dem Kontingent typischerweise ohne Aufpreis, zwischen 21 und 50 Prozent über dem Kontingent das 1,5-Fache der Vertragsrate, bei mehr als 50 Prozent Überverbrauch das Zwei- bis Vierfache oder eine Service-Suspendierung (Quelle: SAP Licensing Experts, Negotiating SAP AI Contracts; Redress Compliance, RISE with SAP Tiers 2025).

Embedding-Lizenzen und Royalty-Fees

Eine separate Kostendimension entsteht, wenn Joule-Funktionen in eigene Applikationen eingebettet werden. Wer die Joule-API in einem kundeneigenen Frontend integriert, benötigt neben den AI Units auch eine separate Embedding-Lizenz. Diese Lizenz funktioniert wie eine Royalty-Fee auf der Nutzung der Joule-API in Nicht-SAP-Oberflächen.

Für Architekturentscheidungen hat das eine direkte Steuerungsrelevanz: Die Alternative "eigene LLM-Architektur mit direktem Modell-Zugang" gegenüber "Joule-API eingebettet" hat eine relevante Kostendimension, die vollständig in die Investitionsplanung einfließen sollte. Contract Manager und Procurement tun gut daran, diese Frage vor der Architekturentscheidung zu klären, nicht danach.

Eine Joule-Konversation mit zehn Nachrichten erzeugt typischerweise zwischen 5.000 und 20.000 Tokens, abhängig von Modellauswahl, Grounding-Aufwand und Konversationslänge. Bei einer aktiven Nutzerpopulation entstehen daraus schnell beachtliche Jahresvolumina. Wer die Embedding-Kosten nicht in der Investitionsplanung berücksichtigt, riskiert eine Budgetabweichung, die nicht aus dem Kernsystem sichtbar wird, sondern aus einem scheinbar nachgelagerten Architekturentscheid (Quelle: SAP Help Portal, Metering and Pricing for Generative AI).

Modul-Aktivierung als Lizenz-Trigger

Ein in der Praxis häufig unterschätzter Mechanismus: Die Aktivierung bestimmter SAP-Module innerhalb eines RISE-Vertrags kann neue AI-Lizenzpflichten auslösen. Module wie SAP IBP (Integrated Business Planning) oder Treasury enthalten AI-Funktionen, die nicht in der Standard-Subscription enthalten sind und separat lizenziert werden müssen.

Konkret bedeutet das: Wer im Rahmen einer RISE-Migration neue Module in den produktiven Betrieb einführt, kann unbeabsichtigt neue Lizenzpflichten erzeugen, wenn die AI-Komponenten dieser Module nicht vorab geprüft wurden. Dieser Steuerungsmoment ist besonders bei Expansionsprojekten relevant, in denen neue SAP-Funktionsbereiche aktiviert werden.

Für Contract Manager und Procurement ist die praktische Konsequenz klar: Bei jeder Modulerweiterung im Rahmen des bestehenden RISE-Vertrags sollte die AI-Lizenz-Prüfung Teil des Freigabeprozesses sein. Nicht als nachgelagerter Compliance-Check, sondern als Steuerungsmoment im laufenden Change-Prozess (Quelle: SAP Licensing Experts, SAP AI in RISE Contracts 2026).

Häufige Fragen

Was ist im RISE-Standardvertrag an Business AI wirklich enthalten?

Ein RISE- oder SAP Cloud ERP Private-Vertrag enthält typischerweise einige eingebettete AI-Features wie Predictive Accounting und Intelligent AP Automation, fixe Transaktions-Quoten zwischen 10.000 und 50.000 AI-Transaktionen pro Monat sowie einen View-Only-Joule-Zugang mit begrenzten Konversations-Sessions. Dieser Basisumfang deckt erste Orientierungsversuche ab. Für produktive AI-Adoption bei realen Nutzerpopulationen sind Joule Power User Seats, zusätzliche AI Units und erweiterte Capability-Pakete als Add-Ons zu beschaffen (Quelle: SAP Licensing Experts, SAP AI in RISE Contracts 2026).

Was bedeutet die Aggregations-Falle im RISE-Kontext genau?

SAP-Standard-Vertragsklauseln sehen vor, dass der AI-Verbrauch über Entwicklungs-, Test- und Produktivumgebungen gemeinsam auf das monatliche Kontingent angerechnet wird. Wer aktive AI-Features in Nicht-Produktivumgebungen betreibt, kann damit höhere Verbräuche erzeugen als geplant. Eine Dev/Test-Exclusion für die AI-Unit-Zählung ist verhandelbar und sollte bei der nächsten Vertragsverlängerung explizit angesprochen werden (Quelle: SAP Licensing Experts).

Was passiert bei Überverbrauch im RISE-AI-Vertrag?

Sobald das vertraglich fixierte AI-Unit-Kontingent überschritten wird, greift die Overage-Klausel. Bis 20 Prozent über dem Kontingent typischerweise ohne Aufpreis, zwischen 21 und 50 Prozent über Kontingent das 1,5-Fache der Vertragsrate, bei mehr als 50 Prozent das Zwei- bis Vierfache oder Service-Suspendierung. Die genaue Formulierung steht im Order Form. Eine explizite Cap-Vereinbarung und eine Approval-Pflicht gehören in jede AI-Vertragsverhandlung (Quelle: SAP Licensing Experts, Negotiating SAP AI Contracts; Redress Compliance, RISE with SAP Tiers 2025).

Wer sollte die Order-Form-Prüfung bei RISE-Business-AI-Verträgen verantworten?

Die Order-Form-Prüfung ist ein koordinierter Steuerungsmoment zwischen vier Rollen: Contract Manager prüft Vertragsstruktur und Compliance-Klauseln. Procurement bewertet Konditionen und Verhandlungspotenzial. Controlling bewertet Overage-Risiken und Budgetrelevanz. Executive gibt Freigabe für strategische Weichenstellungen wie Vertragstyp-Entscheidungen. Ohne diese Koordination werden einzelne Sektionen, etwa die Aggregation-Scope-Klausel oder Rollover-Regelungen, regelmäßig erst nach Vertragsabschluss entdeckt.

Weiterführende Artikel

SAP Business AI: Lizenzierung, Verbrauch und Governance steuern (Hub Pillar 2)
SAP Business AI: Drei Verbrauchstöpfe und die Pooling-Frage (Cluster 2)
SAP Contract Governance: Die neun Produkttypen im Überblick (Pillar 1 Cluster 3)

Quellen: SAP Licensing Experts (SAP AI in RISE Contracts 2026; Negotiating SAP AI Contracts; SAP AI Units Explained 2026), Advisory Report (Negotiating SAP RISE Add-Ons), Redress Compliance (RISE with SAP Tiers and July 2025 Premium Packaging Changes), SAP Help Portal (Metering and Pricing for SAP AI Core; Generative AI Hub), NextLytics (DSAG Technology Days 2026), CIO Magazine (SAP RISE rebrand conceals cost changes)

Autor: Bernhard Mändle, LinkedIn | Vertragscheck buchen | FinOptory AI Chat