SAP Business AI: Lizenzierung, Verbrauch und Governance steuern

SAP Business AI besteht aus drei getrennten Verbrauchstöpfen, drei Beschaffungswegen und einer Governance-Schicht, die ab August 2026 unter den EU AI Act fällt. Wer diese Struktur kennt, vermeidet drei typische Fallen: ungenutzte AI Units, doppelt bezahlte Capabilities und Compliance-Lücken in produktiven Use Cases.

Inhaltsverzeichnis

1. Was SAP Business AI heute ist
2. Drei Verbrauchstöpfe: AI Units, Capacity Units, BDC
3. AI Units: Mechanik, Verfall, Pooling
4. PUPM-Modell und Token-Pricing
5. Joule: Frontend, Skills, Agents
6. Foundation Models und Multi-Agent-Logik
7. Drei Beschaffungsvehikel: Standalone, Subscription, RISE
8. Was in RISE inkludiert ist und was nicht
9. Overage-Mechanik und Aggregations-Falle
10. EU AI Act: Wirkung ab August 2026
11. Data Sovereignty, IP-Indemnification, Tenant-Isolation
12. Was vor Verhandlung zu prüfen ist
13. FAQ
14. Nächste Schritte

---

Was SAP Business AI heute ist {#was-sap-business-ai-heute-ist}

SAP Business AI ist seit der Sapphire-Konferenz 2026 die offizielle Dachmarke für alle AI-Funktionen im SAP-Ökosystem. Gleichzeitig ist es die am häufigsten missverstandene Produktkategorie in aktuellen SAP-Vertragsportfolios. Dieser Abschnitt legt die begriffliche Grundlage für alle weiteren Sektionen.

Definition als Drei-Schichten-Architektur

SAP Business AI beschreibt keine einzelne Anwendung, sondern eine Plattform-Architektur aus drei Schichten. SAP bezeichnet diese seit Sapphire 2026 offiziell als die SAP Business AI Platform.

Die Context Layer bildet die unsichtbare Basis: Sie umfasst den Generative AI Hub mit Zugang zu externen Foundation Models, die SAP-eigenen Modelle SAP-ABAP-1 und SAP-RPT-1, den SAP Knowledge Graph als Quelle für prozessuales Domänenwissen sowie die Business Data Cloud (BDC) als Datenebene. Jeder höhere Dienst, ob Joule-Konversation, eingebettetes AI-Feature oder selbst gebauter Agent, konsumiert diese Schicht.

Die Build Layer ist Joule Studio 2.0, die seit Juni 2026 generally available ist. Sie ist die Entwicklungsumgebung für kundeneigene Agenten: mit visuellem Agent Builder, einer Bibliothek aus über 2.500 bereitgestellten SAP-Skills, einer Kommandozeile für DevOps-Pipelines, einer VS-Code-Erweiterung und einer Integration des offenen Model Context Protocol (MCP) für externe AI-Toolchains.

Die Governance Layer ist der SAP AI Agent Hub, der im dritten Quartal 2026 generally available werden soll. Er ist auf SAP LeanIX aufgesetzt und bietet Discovery, Verification, Observability und Policy-Management für alle Agenten im Tenant: SAP-gelieferte, kundeneigene und Drittpartei-Agenten.

Für die Vertragssteuerung ist diese Drei-Schichten-Logik entscheidend, weil jede Schicht eigene Vermessungspunkte hat. Eine Joule-Lizenz allein deckt nicht automatisch den Agenten-Build und den Governance-Betrieb ab.

Joule als gemeinsames Frontend

Joule ist die einheitliche Copilot-Oberfläche über alle SAP-Lösungen hinweg. Stand 2026 ist Joule in 35 SAP-Lösungen aktiv: von SAP Cloud ERP über SuccessFactors, Ariba und Fieldglass bis zu SAP Build. Mit Joule Work, der bei Sapphire 2026 vorgestellten UX-Vision, positioniert SAP Joule langfristig als primäre Interaktionsschicht, die App-Navigationen schrittweise ablöst.

Für die Lizenzierung bedeutet das: Joule ist kein einheitliches Produkt mit einer Lizenz, sondern ein Portfolio aus Verbrauchsmodellen. Per-User-per-Month-Pakete, AI-Unit-Kontingente und Token-basiertes Pricing existieren nebeneinander, je nach Nutzungstyp und Konfiguration.

Embedded AI versus eigene Agenten

SAP unterscheidet zwei grundlegende Nutzungsformen: Embedded AI und eigene Agenten.

Embedded AI sind AI-Funktionen, die SAP direkt in seine Lösungen integriert hat, ohne dass Kunden selbst entwickeln müssen. Beispiele sind die automatische Zahlungsavis-Verarbeitung in Finance, der Catalog Optimization Agent in Procurement oder die Bestandsanalyse in der Supply Chain. Diese Funktionen sind Teil der Lösungssubscription, konsumieren aber trotzdem AI Units oder fallen unter PUPM-Pakete.

Eigene Agenten werden in Joule Studio 2.0 entwickelt und über die Runtime auf BTP betrieben. Sie ermöglichen kundeneigene Automatisierungen, setzen aber separate Runtime-Lizenzen voraus. Der bis Ende 2026 kostenlose Design-Time-Zugang ist eine Adoptionsstrategie: Wer 2026 baut, benötigt 2027 Runtime-Kapazitäten.

Der kommerzielle Unterschied ist erheblich: Eingebettete Skills verbrauchen typischerweise eine definierte AI-Unit-Menge pro Transaktion, während autonome Agenten bei komplexen Multi-Step-Plänen ein Vielfaches davon konsumieren können.

Was sich 2025 und 2026 verändert hat

Drei strukturelle Änderungen sind für die Vertragssteuerung relevant:

Erstens wurde das bisherige Top-Tier RISE with SAP Premium Plus im Juni 2025 eingestellt. Die damit verbundenen AI-Capabilities wurden teilweise in SAP Cloud ERP Private überführt, teilweise als separate Add-Ons neu positioniert. Verträge, die noch den alten Tier-Begriff enthalten, sollten auf den aktuellen Vertragsgegenstand geprüft werden (Quellen: Redress Compliance, CIO Magazine).

Zweitens hat SAP mit Joule Studio 2.0 und dem AI Agent Hub eine Entwicklungs- und Governance-Infrastruktur eingeführt, die in früheren Vertragsverhandlungen keine Rolle gespielt hat. Für Unternehmen, die AI produktiv einsetzen wollen, entstehen damit neue Lizenz- und Compliance-Dimensionen.

Drittens wächst die Anzahl eingebetteter Capabilities kontinuierlich: Von 30 Agenten und 2.500 Skills im ersten Quartal 2026 auf 224 Agenten und 51 rollenspezifische Assistenten zur Sapphire-Konferenz im zweiten Quartal 2026 (Quelle: SAP News, Sapphire 2026). Jede neue Capability ist potenziell ein neuer Verbrauchspunkt. Wer das Verbrauchsvolumen nicht kontinuierlich beobachtet, bemerkt Verschiebungen erst auf der nächsten Abrechnung.

---

Drei Verbrauchstöpfe: AI Units, Capacity Units, BDC {#drei-verbrauchstoepfe}

Bevor Vertrags- und Verbrauchsdetails bewertet werden können, müssen drei begriffliche Welten getrennt werden. SAP führt 2026 drei nicht-austauschbare Verbrauchsmodelle parallel. Wer sie verwechselt, forecastet falsch und kauft am Bedarf vorbei.

AI Units: Definition und Anwendungsbereich

AI Units sind die konsumbasierte Verbrauchseinheit für SAP Business AI Services. Kunden kaufen ein Prepaid-Kontingent an AI Units pro Vertragsjahr. Jeder AI-Aufruf zieht eine definierte Anzahl AI Units, abhängig vom genutzten Service.

Konsumiert werden AI Units über S/4HANA Cloud (eingebettete AI-Features), SuccessFactors, Ariba, SAP Build mit Joule-Funktionen sowie BTP-Services wie AI Core und den Generative AI Hub. Sie sind die zentrale Verbrauchsgröße für alles, was SAP als "Business AI" vermarktet.

Wichtig für die Vertragssteuerung: AI Units sind nicht mit BTP Capacity Units austauschbar. Wer ein BTP-Enterprise-Agreement mit verbleibendem Guthaben hat, kann damit keine AI-Funktionen konsumieren. AI Units existieren in einem eigenen, abgeschlossenen Topf.

Capacity Units: Abgrenzung

BTP Capacity Units (CU) sind die Verbrauchseinheit für BTP-Plattformdienste: Integration Suite, Application Development, Datenbankservices, Analytics und weitere. Sie werden über das BTP Enterprise Agreement (BTPEA) oder das Cloud Platform Enterprise Agreement (CPEA) bezogen.

Die Abgrenzung zu AI Units ist präzise: Capacity Units finanzieren die Plattform-Infrastruktur. AI Units finanzieren die AI-Funktionsebene auf dieser Plattform. Beide Töpfe laufen gleichzeitig und separat.

In der Praxis bedeutet das: Ein Unternehmen mit aktivem BTPEA und aufkommendem AI-Bedarf muss einen separaten AI-Unit-Vertrag schließen oder AI Units als Add-On zum bestehenden Abonnement erwerben. Eine automatische Quernutzung ist nicht vorgesehen (Quelle: SAP Help Portal, Metering and Pricing for SAP AI Core).

Business Data Cloud Credits

Die Business Data Cloud (BDC) ist SAPs Datenebene und verbindet SAP- und Nicht-SAP-Daten über ein Delta-Sharing-Protokoll. Sie wird über eine eigene BDC-Subscription lizenziert und verbrauchsbasiert mit eigenen Credits gemessen, abhängig von Datenvolumen, Delta Sharing und Data Products.

Die BDC ist die Quelle für den SAP Knowledge Graph und für Company Memory, also für das unternehmenseigene Prozess- und Richtlinienwissen, das Joule und Agenten als Kontext nutzen. Wer AI-Agenten mit firmeneigenem Wissen erden will, berührt damit automatisch den BDC-Topf.

In Vertragsverhandlungen wird BDC häufig als separates Line Item behandelt. Kunden, die Joule mit Custom Model Grounding einsetzen wollen, sollten prüfen, ob ihr aktueller Vertrag BDC bereits enthält oder ob ein separates Beschaffungsvehikel erforderlich ist.

Was passiert, wenn ein Verbraucher mehrere Töpfe berührt

In der Praxis greifen AI-Use-Cases häufig auf mehr als einen Topf zu. Ein Joule-Agent, der Geschäftsdaten aus BDC 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 Herausforderung liegt in der Sichtbarkeit: Die drei Töpfe werden in unterschiedlichen SAP-Tools angezeigt, mit unterschiedlichen Reporting-Rhythmen und unterschiedlichen Schwellenwerten. Eine konsolidierte Sicht auf den Gesamt-AI-Verbrauch ist mit nativen SAP-Werkzeugen derzeit nicht herstellbar, weil die Tools pro Topf, nicht pro Use Case berichten (Quelle: NextLytics, DSAG Technology Days 2026).

Die strukturelle Empfehlung lautet deshalb: Für jeden produktiven AI-Use-Case sollte vor dem Rollout eine Topf-Zuordnung vorliegen. Welche AI Units, welche Capacity Units, welche BDC-Credits werden pro Monat und Jahr verbraucht? Diese Frage frühzeitig zu beantworten, macht Forecasting belastbarer und Budgetplanung planbar.

---

AI Units: Mechanik, Verfall, Pooling {#ai-units-mechanik-verfall-pooling}

AI Units sind die zentrale Verbrauchsgröße für SAP Business AI. Wer ihre Mechanik kennt, steuert das Budget präzise. Wer sie nicht kennt, zahlt für Kontingente, die verfallen, oder für Overages, die vermeidbar gewesen wären.

Wie eine AI Unit definiert ist

SAP definiert AI Units als "konsumbasierte virtuelle Währung, mit der SAP Business AI Services übergreifend genutzt werden können" (Quelle: SAP Pricing Page). Kunden kaufen ein Prepaid-Kontingent pro Vertragsjahr. Die tatsächliche Verbrauchsrate hängt vom genutzten Service ab: Jeder Service hat einen eigenen Konversionsfaktor.

Beispiele für Konversionsfaktoren, die SAP veröffentlicht hat: Joule Messaging verbraucht 7 AI Units pro 10.000 Nachrichten. Document Grounding verbraucht 0,005 AI Units pro Record. Cash Application liegt je nach Transaktionsvolumen bei unterschiedlichen Raten, wobei höhere Volumina günstiger sind (Quelle: SAP Help Portal, Metering and Pricing).

Bei Aufrufen über den Generative AI Hub gilt Token-Verbrauch als Basismetrik, der anschließend in AI Units umgerechnet wird. Die Spannweite ist modellabhängig und je nach Gesprächskontext erheblich.

Verfallsregeln

AI Units verfallen am Ende des Vertragsjahres, wenn sie nicht verbraucht werden. Das ist der Standard, der in nahezu allen Verträgen ohne explizite Gegenvereinbarung gilt. Ein verhandelter Rollover ist möglich, aber nicht Teil der Standardbedingungen (Quelle: SAP Licensing Experts, AI Units Explained 2026).

Für PUPM-Pakete (Per-User-per-Month) gilt zusätzlich ein monatlicher Verfall: Die im Monat zugeordneten Request-Kontingente pro Nutzer verfallen am Monatsende. Es gibt keinen Übertrag auf den Folgemonat.

In der Praxis zeigt sich, dass bei RISE-Kunden im zweiten Vertragsjahr häufig erhebliche Anteile der AI-Unit-Kontingente ungenutzt bleiben, weil die tatsächliche AI-Adoption hinter den ursprünglichen Nutzungsprojektionen zurückbleibt. Diese Situation ist strukturell, kein Ausnahmefall: SAP-Sizing-Annahmen für AI basieren auf Projektionen, die in der Realität einer schrittweisen Nutzerakzeptanz und Implementierungsreife begegnen.

Pooling innerhalb eines PUPM-Pakets

PUPM-Pakete bieten einen begrenzten Pooling-Mechanismus: Nicht genutzte Request-Kontingente eines Nutzers innerhalb eines Pakets können von anderen Nutzern desselben Pakets in Anspruch genommen werden. Das erlaubt eine gewisse Ausgleichsfunktion innerhalb einer Nutzungsgruppe.

Dieses Pooling funktioniert jedoch nur innerhalb eines Pakets, nicht paketübergreifend. Ein Nutzer, der sowohl ein Finance-Paket als auch ein Procurement-Paket zugeordnet hat, zahlt für beide Pakete separat. Ungenutzte Kontingente aus Paket A können nicht auf Paket B angerechnet werden.

SWITCH-Programm für Bestandskunden

SAP führt ein internes Migrationsprogramm für Bestandskunden durch, die noch mit älteren AI-Unit-SKUs arbeiten. Dieses Programm überführt die alten Entitlements in eine aktualisierte Struktur mit vereinheitlichter Vermessungslogik und aktualisierten Capability-Berechtigungen.

Für Bestandskunden ist der SWITCH kein technischer Vorgang ohne kommerzielle Relevanz. Die Überführung kann Capability-Zugriffe verändern und Tiered-Pricing-Regeln aktivieren, die im alten Entitlement nicht galten. Vor einer SWITCH-Durchführung sollte das bestehende Entitlement sorgfältig dokumentiert werden (Quelle: SAP Community Blog, The new TDD AI Unit SKU).

Was kontinuierliche Beobachtung schwer macht

Die wichtigste strukturelle Einschränkung bei der Steuerung von AI Units liegt in der fehlenden Granularität der nativen SAP-Werkzeuge. SAP for Me zeigt den aggregierten AI-Unit-Verbrauch, bietet aber keine Aufschlüsselung auf Nutzer-Ebene. Das BTP-Cockpit berichtet Service-Aufrufe pro Subaccount, aber keinen Vergleich zum vertraglichen Rahmen. Der SAP AI Pricing Estimator im Discovery Centre schätzt Volumina, aber keine Euro-Beträge.

Wer wissen will, welcher Geschäftsbereich, welcher Nutzer oder welcher Use Case welchen Anteil des AI-Unit-Budgets verbraucht, kommt mit den nativen Tools an strukturelle Grenzen (Quelle: NextLytics, DSAG Technology Days 2026). Diese Lücke ist der Ausgangspunkt für eine eigenständige AI-Governance-Funktion.

---

PUPM-Modell und Token-Pricing {#pupm-modell-und-token-pricing}

Neben dem klassischen AI-Unit-Kontingent bietet SAP ein zweites Verbrauchsmodell an: Per-User-per-Month-Pakete (PUPM). Beide Modelle existieren nebeneinander und werden für unterschiedliche Nutzungstypen eingesetzt.

PUPM-Mechanik

PUPM-Pakete funktionieren nach einer festen Paketlogik: Jedem Nutzer wird über den SAP Identity Service (IAS) ein Paket zugeordnet. Dieses Paket enthält ein fixes Request-Kontingent pro Monat sowie eine definierte Anzahl AI Units, die für diesen Nutzer reserviert sind.

Die Pakete sind nach Lösungsbereichen geschnitten: Finance, Spend Management, Customer Experience, Human Capital Management. Wer Joule für mehrere Bereiche nutzen will, benötigt für jeden Bereich ein eigenes Paket. Die Zuordnung erfolgt manuell oder über einen Excel-Batch-Upload.

Der Pooling-Mechanismus innerhalb eines Pakets wurde bereits in Sektion 3 beschrieben: Nicht genutzte Kontingente eines Nutzers können von anderen Nutzern desselben Pakets in Anspruch genommen werden. Paketübergreifendes Pooling ist nicht vorgesehen.

Ein struktureller Nachteil des PUPM-Modells liegt in der fehlenden Granularität: SAP berichtet Verbrauch auf Paket-Ebene und auf Capability-Ebene, aber nicht auf Nutzer-Ebene innerhalb eines Pakets. Wer wissen will, ob ein bestimmter Nutzer sein Paket tatsächlich ausschöpft, findet diese Information nicht im Standard-Reporting (Quelle: SAP Learning, Analyzing the PUPM Pricing Model).

Token-basiertes Pricing im Generative AI Hub

Für LLM-Aufrufe über den Generative AI Hub gilt eine separate Preislogik: Token-basiertes Pricing. Jeder Aufruf an ein Foundation Model wird in Tokens gemessen, die dann in AI Units umgerechnet werden.

Die Token-Rate variiert je nach Modell erheblich. SAP-eigene Modelle wie SAP-ABAP-1 und SAP-RPT-1 liegen am unteren Ende der Preisskala. Externe Foundation Models verschiedener Anbieter variieren, wobei komplexere Modelle typischerweise höhere Token-Kosten erzeugen.

Für eine Joule-Konversation mit 10 Nachrichten sind zwischen 5.000 und 20.000 Tokens realistisch, abhängig von Modellauswahl, Grounding-Aufwand und Konversationslänge (Quelle: SAP Help Portal, Metering and Pricing for Generative AI). Bei einer aktiven Nutzerpopulation können daraus beachtliche Jahresvolumina entstehen, die in frühen Sizing-Annahmen häufig unterschätzt werden.

SAP AI Pricing Estimator als Orientierung

SAP stellt im Discovery Centre einen AI Pricing Estimator zur Verfügung. Eingaben sind Service bzw. Capability, erwartetes Volumen und Nutzeranzahl. Als Output liefert das Tool eine geschätzte AI-Unit-Menge pro Jahr.

Der Estimator hat eine wichtige Einschränkung: Er zeigt Volumina, keine Euro-Beträge. Die tatsächlichen Kosten ergeben sich erst aus dem individuell verhandelten Preis pro AI Unit, der im Order Form festgehalten ist. Der Estimator ist damit ein Sizing-Werkzeug, kein Budgetierungswerkzeug.

Praktische Forecasting-Grenzen

Die Kombination aus PUPM-Paketen, AI-Unit-Kontingenten und Token-basiertem Pricing erzeugt drei parallele Verbrauchsströme, die sich gegenseitig beeinflussen. PUPM-Überverbrauch zieht AI Units aus dem zentralen Pool. Token-intensive Agenten-Konversationen verbrauchen AI Units schneller als einfache Skill-Aufrufe.

Für belastbares Forecasting ist deshalb eine Use-Case-spezifische Betrachtung erforderlich: Welcher Nutzungstyp dominiert in meiner Organisation, PUPM-basierte Konversationen oder AI-Unit-intensive Transaktionsprozesse? Wie verhält sich der geplante Agenten-Einsatz zu den Sizing-Annahmen, die SAP bei Vertragsabschluss erstellt hat?

SAP's eigene Projektionsmodelle für Copilot-Nutzung unterschätzen den Verbrauch bei agentischen Deployments strukturell, weil Multi-Step-Agenten-Pläne deutlich mehr Tokens und AI Units konsumieren als einfache Skill-basierte Copilot-Interaktionen (Quelle: SAP Licensing Experts, Negotiating SAP AI Contracts). Wer den Sprung von Copilot zu Agenten plant, sollte diesen Faktor explizit in die Vertragsverhandlung einbringen.

---

Joule: Frontend, Skills, Agents {#joule-frontend-skills-agents}

Joule ist nicht ein Produkt, sondern eine Produktfamilie. Für die Lizenzierung und Governance ist es entscheidend, welche Joule-Komponente genutzt wird, denn sie unterscheiden sich in Verbrauchsmodell, Risikoprofil und kommerzieller Logik erheblich.

Joule für Endnutzer, Developer, Consultants

SAP differenziert drei Joule-Varianten nach Nutzergruppe:

Joule for Users richtet sich an Endanwender in den 35 SAP-Lösungen. Es ist generally available und umfasst den direkten Zugang zu eingebetteten AI-Features sowie Konversationsmöglichkeiten im SAP-Workflow-Kontext.

Joule for Developers ist der ABAP-Assistent in der ABAP Development Tool-Umgebung (ADT) und im Business Application Studio (BAS). Er basiert auf SAP-ABAP-1, dem mit 250 Millionen Zeilen ABAP-Code trainierten SAP-eigenen Modell, und unterstützt Code-Generierung, Refactoring und Testgenerierung. SAP gibt eine Produktivitätssteigerung von 20 bis 25 Prozent an (Quelle: SAP News, Our 2026 Roadmap for Joule for Developers). Die Lizenzierung erfolgt über eine separate Joule-for-Developers-SKU oder als Teil von BTP-Entwicklersubscriptions.

Joule for Consultants befindet sich noch im Beta-Status und richtet sich an Implementierungspartner als Konfigurationsassistent. Die Generally-Available-Version ist im Laufe von 2026 geplant.

Skills versus Agents: die entscheidende Unterscheidung

Für Budgetplanung und Governance ist die Unterscheidung zwischen Skills und Agenten grundlegend.

Ein Joule Skill ist eine deterministische, vordefinierte Operation: Er führt eine einzelne, klar definierte Aktion aus, zum Beispiel das Anlegen einer Bestellung mit vorgegebenen Parametern. Skills sind planbar im Verbrauch, berechenbar im Risiko und in der Regel bei Vertragsabschluss bereits kalkuliert.

Ein Joule Agent ist ein autonomes System, das mehrere Skills orchestriert, plant und handelt. Er verfolgt ein übergeordnetes Ziel, wählt den Weg dorthin selbst und kann dabei unerwartete Pfade nehmen. Beispiel: "Optimiere alle offenen Bestellungen nach Lieferzeit und Kosten" ist eine Agenten-Aufgabe, nicht eine Skill-Aufgabe.

Der Verbrauchsunterschied ist erheblich: Agentische Deployments verbrauchen laut Beobachtungen aus der Praxis das Drei- bis Zwanzigfache an AI Units gegenüber reinen Copilot-Projektionen (Quelle: SAP Licensing Experts, Negotiating SAP AI Contracts). Wer Agenten produktiv einsetzt, ohne den Sizing-Faktor anzupassen, riskiert unerwartete Overage.

Stand Sapphire 2026 bietet die SAP Autonomous Suite 224 Agenten und 51 rollenspezifische Assistenten über Finance, Spend Management, Supply Chain, HR und Customer Experience.

Joule Studio als Build-Umgebung

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 Toolchains.

Bis Ende 2026 gewährt SAP kostenlosen Design-Time-Zugang zu Joule Studio unter Fair-Use-Bedingungen. Dieser kostenlose Zugang deckt die Entwicklungsumgebung ab, nicht den produktiven Betrieb. Runtime-Lizenzen für die Ausführung kundeneigener Agenten in Produktion sind separat zu erwerben.

Drei Konstruktions-Patterns

Joule Studio unterstützt drei Konstruktions-Patterns, die sich in Aufwand und Risiko unterscheiden:

Das erste Pattern ist Skill Assembly: Vorhandene SAP-Skills werden zu neuen Workflow-Agenten kombiniert. Der Aufwand ist gering, weil keine externe Integration erforderlich ist, und das Risiko ist begrenzt, weil nur deterministische SAP-Skills eingesetzt werden.

Das zweite Pattern ist API Integration: Externe REST-APIs werden als neue Skills eingebunden. Der Aufwand ist mittel, das Risiko liegt in der laufenden API-Pflege und Schnittstellenstabilität.

Das dritte Pattern ist Custom Model Grounding: Agenten werden auf kundeneigene Dokumente, Policies und Stammdaten geerdet. Der Aufwand ist hoch, das Risiko liegt in der Datenqualität. Gleichzeitig ist dieses Pattern die Grundlage für den höchsten Differenzierungswert gegenüber generischen Copilots.

---

Foundation Models und Multi-Agent-Logik {#foundation-models-und-multi-agent-logik}

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 gewählt wird, beeinflusst sowohl das Ergebnis als auch den Verbrauch.

SAP-eigene Modelle und Vendor-Lock-in-Aspekt

SAP entwickelt zwei eigene Foundation Models:

SAP-ABAP-1 wurde auf 250 Millionen Zeilen ABAP-Code trainiert und ist spezialisiert auf Code-Generierung, ABAP-Assistenz in der Entwicklungsumgebung und Prozess-Inferenz im SAP-Kontext. Es bildet die Grundlage für Joule for Developers.

SAP-RPT-1 ist auf SAP-Geschäftsprozessdaten trainiert und ermöglicht Vorhersagen entlang SAP-Standardprozessen sowie Process-Inference für eingebettete AI-Features.

Die strategische Relevanz dieser SAP-eigenen Modelle liegt in zwei gegenläufigen Aspekten: Einerseits bieten sie einen echten Mehrwert gegenüber generischen Sprachmodellen, weil sie SAP-spezifisches Domänenwissen eingebettet haben. Andererseits erzeugen sie eine Abhängigkeit: Wer seine ABAP-Entwicklung auf SAP-ABAP-1 optimiert, löst diese Praxis schwerlich von SAP ab (Quellen: SAP News Joule Studio, SAVIC Technologies AI Foundation Architecture 2026).

Externe LLMs im Generative AI Hub

Neben SAP-eigenen Modellen bietet der Generative AI Hub Zugang zu Foundation Models verschiedener Anbieter. SAP abstrahiert dabei die jeweilige API, sodass Kunden pro Use Case ein Modell wählen können, ohne direkte Vertragsbeziehungen zu den Modell-Anbietern aufzubauen.

Die verfügbaren Modelle variieren und werden von SAP rollierend aktualisiert. Stand Q2 2026 sind Modelle verschiedener großer Anbieter integriert (Quelle: SAP-Dokumentation zum Generative AI Hub, help.sap.com). Welche Modelle konkret in einem Kunden-Tenant verfügbar sind, hängt von der Region, der Vertragsversion und der SAP-Freigabe ab.

Eine für die Governance relevante Frage: Darf SAP Foundation Models einseitig durch neue Versionen oder andere Modelle ersetzen? Diese Klausel sollte im Order Form explizit geregelt sein. Fehlende Regelung bedeutet typischerweise, dass SAP das Modell-Portfolio unilateral anpassen darf.

Multi-Agent-Protokoll

SAP hat im ersten Quartal 2026 ein Multi-Agent-Protokoll eingeführt, das Agenten systemübergreifend koordinieren lässt. Damit können SAP-Agenten mit anderen SAP-Agenten, mit kundeneigenen Agenten aus Joule Studio und mit Drittpartei-Agenten über das Model Context Protocol (MCP) kommunizieren.

Ein Beispiel aus der Praxis: 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 den Systemen.

Für die Verbrauchssteuerung bedeutet Multi-Agent-Koordination eine neue Dimension: Jeder Agenten-Aufruf im Rahmen eines Multi-Agent-Workflows erzeugt eigenen Verbrauch. Komplexe Workflows können damit schnell erhebliche AI-Unit-Mengen konsumieren. Gleichzeitig ist die Beobachtbarkeit dieser Workflows mit Standard-Reporting-Tools begrenzt.

MCP-Integration

SAP unterstützt seit Q1 2026 das offene Model Context Protocol (MCP). Das erlaubt externe AI-Toolchains, auf SAP-Joule-Skills zuzugreifen, und SAP-Agenten, externe MCP-Server zu konsumieren.

Für Organisationen, die eigene AI-Architekturen betreiben, eröffnet MCP eine Brücke zwischen SAP-Agenten und externen AI-Werkzeugen. Gleichzeitig gilt: Die SAP API Policy v4/2026 verbietet 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, cross-referenziert in SAP Help Portal). Dieses Spannungsverhältnis sollte bei der Architekturentscheidung berücksichtigt werden.

---

Drei Beschaffungsvehikel: Standalone, Subscription, RISE {#drei-beschaffungsvehikel}

SAP Business AI lässt sich über drei unterschiedliche kommerzielle Wege beschaffen. Die Wahl des Beschaffungsvehikels beeinflusst nicht nur den Preis, sondern auch die Vertragsbedingungen, die Laufzeitbindung und die Bundling-Optionen.

Standalone-Vertrag

Beim Standalone-Vehikel kauft der Kunde AI Units direkt über einen eigenständigen BTP-Vertrag im Global Account. Dieses Modell bietet die geringste Bindung, hat aber typischerweise den höchsten Pro-Unit-Preis.

Der Standalone-Weg ist relevant für Unternehmen ohne aktives SAP Cloud ERP Private oder RISE-Vertrag, die einzelne AI-Use-Cases ausprobieren oder skalieren wollen, ohne eine umfassendere Subscription einzugehen. Er eignet sich auch für klar abgegrenzte Pilotprojekte mit definiertem Laufzeitrahmen.

Die kommerzielle Einschränkung: Standalone-AI-Units profitieren nicht vom Bundling-Effekt. Wer AI Units im Rahmen eines Cloud ERP Private Bundles kauft, erhält in der Regel einen besseren Preis pro Unit als beim Einzelkauf (Quelle: SAP Licensing Experts, SAP AI in RISE Contracts 2026).

Subscription via SAP Cloud Platform Enterprise Agreement

Das Business AI Subscription Bundle ist ein eigenständiges Subscription-Paket, das AI Units, Joule-Zugang und AI Foundation-Zugang bündelt. Es bietet einen niedrigeren Pro-Unit-Preis als die Standalone-Option bei höherer Gesamtbindung.

Dieses Vehikel eignet sich für Unternehmen, die SAP Business AI als eigenständige Initiative beschaffen, unabhängig von ihrer Cloud-ERP-Vertragsstruktur. Es ist auch das relevante Modell für Kunden, die BTP-Services und AI-Funktionen kombiniert nutzen wollen, ohne den vollen RISE-Vertragsweg zu gehen.

Einbindung in RISE-Vertrag

Die kommerzielle effizienteste Option ist die Einbindung von AI Units in einen bestehenden SAP Cloud ERP Private-Vertrag, der früher unter dem Namen RISE with SAP geführt wurde. In diesem Modell sind AI Units als Teil des Cloud-ERP-Bundles enthalten oder werden als Add-On zu bestehenden RISE-Bedingungen erworben.

Die AI-Unit-Allokation im RISE-Bundle ist in der Regel günstiger als beim Standalone-Kauf, weil SAP den AI-Verbrauch als Teil des Gesamtpakets quersubventioniert. Für Kunden mit aktivem RISE-Vertrag ist dies typischerweise der wirtschaftlich vorteilhafteste Ausgangspunkt.

Wann welcher Weg sinnvoll ist

Drei Leitfragen helfen bei der Entscheidung:

Erstens: Besteht bereits ein aktiver SAP Cloud ERP Private oder RISE-Vertrag? Wenn ja, sollte AI-Beschaffung in diesem Vertragsvehikel oder als direktes Add-On geprüft werden, bevor ein Standalone-Weg gewählt wird.

Zweitens: Wie ist der Hyperscaler-Footprint des Unternehmens? AI Units können über die Hyperscaler-Marketplaces (AWS, Azure, GCP) beschafft werden, was je nach bestehenden Cloud-Commitments zusätzliche Preisvorteile bringen kann.

Drittens: Welche Laufzeitbindung ist sinnvoll? Ein Standalone-Vertrag bietet mehr Flexibilität, ein Bundle-Vertrag bietet niedrigere Pro-Unit-Kosten. Die Wahl hängt von der Stabilität der geplanten AI-Adoption und der strategischen Sicherheit über das zukünftige Nutzungsvolumen ab (Quelle: Advisory Report, Negotiating SAP RISE Add-Ons).

---

Was in RISE inkludiert ist und was nicht {#was-in-rise-inkludiert-ist-und-was-nicht}

Die häufigste Fehleinschätzung bei RISE-Kunden: Der RISE-Vertrag enthält Business AI bereits vollständig. Er enthält einen Teil davon. Was genau, hängt vom Tier, von den verhandelten Bedingungen und vom Zeitpunkt des Vertragsabschlusses ab.

Embedded S/4HANA AI Features pro Tier

Einige AI-Features sind in jedem SAP Cloud ERP Private Tier ohne zusätzliche AI-Unit-Lizenz enthalten. Dazu gehören in der Regel Funktionen wie Predictive Accounting, Intelligent AP Automation und Demand Sensing, also Funktionen, die SAP als Grundbestandteil der Lösungssubscription positioniert.

Welche Features konkret im jeweiligen Vertrag inkludiert sind, ist nicht aus Marketing-Material ablesbar, sondern aus dem Order Form und den zugehörigen Schedules. SAP ändert den Capability-Umfang per inkludierter Features im Rahmen von Quartalsupdates und Repackaging-Zyklen, ohne dass Kunden automatisch informiert werden (Quelle: SAP Licensing Experts, SAP AI in RISE Contracts 2026).

Fixe Transaktions-Quoten und ihre Grenzen

Im RISE-Vertrag sind typischerweise fixe AI-Transaktions-Quoten enthalten: In der Praxis liegen diese bei 10.000 bis 50.000 AI-Transaktionen pro Monat, abhängig vom Tier (Quelle: SAP Licensing Experts). Diese Quoten sind für erste Orientierungsversuche ausreichend, für produktive AI-Adoption bei größeren Nutzerpopulationen jedoch strukturell zu gering.

Die Quotengrenzen sind bewusst eng gesetzt: Sie sind der Einstiegspunkt, nicht der Betriebsrahmen. Wer AI tatsächlich produktiv skaliert, überschreitet diese Grenzen regelmäßig und benötigt Add-Ons.

Joule View-Only Access als Default

Im Standard-RISE-Vertrag ist Joule mit einem View-Only-Zugang und limitierten täglichen Konversations-Sessions enthalten: typischerweise 10 bis 20 Sessions pro Nutzer pro Monat. Dieser Zugang ist für produktive Nutzung, die über gelegentliche Einzelabfragen hinausgeht, unzureichend.

Produktiver Joule-Einsatz erfordert Power-User-Seats als Add-On, mit eigenen Preispunkten pro Nutzer und Monat (Quelle: SAP Licensing Experts, SAP AI in RISE Contracts 2026). Dieser Zusammenhang ist in initialen RISE-Vertragsverhandlungen häufig nicht transparent, weil das Marketing Joule als RISE-Bestandteil darstellt, ohne die funktionalen Grenzen des Basisumfangs explizit zu machen.

Add-On-Komponenten

Über den Basisumfang hinaus sind unter anderem folgende Komponenten als Add-On beschaffbar: Joule Power User Seats, Joule API Consumption für die Einbettung in eigene Anwendungen, BTP AI Core und AI Launchpad als eigenständige BTP-Services, AI Foundation Foundation-Model-Zugang mit Token-basiertem Pricing sowie zusätzliche AI Units zum vertraglichen Pro-Unit-Preis.

Jedes dieser Add-Ons hat eigene Pricing-Parameter und eigene Laufzeitbedingungen. Bei Verhandlungen empfiehlt es sich, die benötigten Add-Ons frühzeitig zu identifizieren und deren Bedingungen im gleichen Verhandlungszyklus wie den Hauptvertrag zu klären.

Modul-Aktivierung als Lizenz-Trigger

Ein in der Praxis häufig übersehener 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: Ein Unternehmen, das im Rahmen seiner RISE-Migration neue Module aktiviert, kann unbeabsichtigt neue Lizenzpflichten auslösen, wenn die AI-Komponenten dieser Module nicht vorab geprüft wurden (Quelle: SAP Licensing Experts, SAP AI in RISE Contracts 2026). Dieses Risiko ist besonders bei Expansionsprojekten relevant, bei denen neue SAP-Module in den produktiven Betrieb eingeführt werden.

---

Overage-Mechanik und Aggregations-Falle {#overage-mechanik-und-aggregations-falle}

Overage ist kein Ausnahmefall in SAP-Business-AI-Verträgen. Es ist ein strukturell angelegter Mechanismus, dessen Bedingungen im Order Form stehen, oft aber erst bei der nächsten Abrechnung sichtbar werden.

Was bei Überverbrauch passiert

Sobald der vertraglich fixierte AI-Unit-Kontingent überschritten wird, greift die Overage-Klausel des Order Forms. SAP sieht typischerweise gestufte Faktoren vor: Verbrauch bis 20 Prozent über dem Kontingent ist in der Regel ohne Aufpreis. Zwischen 21 und 50 Prozent über dem Kontingent gilt in der Regel das 1,5-Fache der Vertragsrate. Bei mehr als 50 Prozent Überverbrauch sind je nach Vertragsformulierung das Zwei- bis Vierfache der Vertragsrate oder eine Service-Suspendierung möglich (Quelle: SAP Licensing Experts, Negotiating SAP AI Contracts).

Entscheidend ist die Formulierung im Order Form: "Soft-Overage" ohne Cap bedeutet, dass der Verbrauch ohne automatische Benachrichtigung oder Genehmigungspflicht weiterlaufen kann. "Hard-Overage" mit Service-Suspendierung bedeutet, dass produktive AI-Dienste unterbrochen werden, wenn das Kontingent erschöpft ist. Die Formulierung der Overage-Klausel und eine explizite Cap-Vereinbarung sind damit eines der wichtigsten Verhandlungselemente im AI-Vertrag.

Wie SAP-Verbrauchs-Projektionen typischerweise funktionieren

SAP liefert im Rahmen von Vertragsverhandlungen Sizing-Annahmen, die auf Copilot-Nutzungsraten basieren. Diese Projektionen gehen von einer graduellen Nutzerakzeptanz und typischen Copilot-Konversationslängen aus.

In der Praxis zeigt sich, dass agentische Deployments, also der Einsatz von Joule-Agenten für autonome Prozessketten, das Drei- bis Zwanzigfache an AI Units verbrauchen können gegenüber den ursprünglichen Sizing-Annahmen (Quelle: SAP Licensing Experts, Negotiating SAP AI Contracts). Organisationen, die von einer reinen Copilot-Nutzung zu Agenten-basierten Workflows wechseln, sollten ihre Vertragsgrundlage aktiv anpassen, bevor der Rollout beginnt.

Aggregations-Falle bei Multi-Topf-Verbrauch

Eine in vielen RISE-Verträgen enthaltene Standardklausel: SAP zählt den AI-Verbrauch über alle Systemumgebungen eines Kunden hinweg, also über Entwicklungs-, Test- und Produktivsysteme gemeinsam, auf das monatliche Kontingent an.

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 Produktivbetrieb. Wer diese Klausel nicht kennt, erlebt unerwartet hohe Verbräuche, ohne dass das Produktivsystem allein dafür verantwortlich ist (Quelle: SAP Licensing Experts, SAP AI in RISE Contracts 2026).

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

Embedding-Lizenzen und Royalty-Fees

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

Für Architekturentscheidungen bedeutet das: Die Alternative "eigene LLM-Architektur mit direktem Modell-Zugang" versus "Joule-API eingebettet" hat eine relevante Kostendimension, die vollständig in die Investitionsplanung einfließen sollte.

---

EU AI Act: Wirkung ab August 2026 {#eu-ai-act-wirkung-ab-august-2026}

Der EU AI Act ist seit August 2024 in Kraft. Mit dem 2. August 2026 tritt die entscheidende Vollwirkungsstufe für Hochrisiko-AI-Systeme in Kraft. Für Unternehmen, die SAP Business AI in Produktivprozessen einsetzen, entstehen daraus konkrete Dokumentations- und Governance-Pflichten.

Timeline und Geltungsbereich

Die Implementierung des EU AI Act verläuft in Stufen:

Im August 2024 trat das Gesetz in Kraft. Im Februar 2025 wurden Verbote für unzulässige AI-Praktiken wirksam. Im August 2025 wurden Regelungen für General Purpose AI Models (GPAI) anwendbar. Am 2. August 2026 tritt die Vollwirkung für Hochrisiko-AI-Systeme in Kraft. Eine weitere Stufe folgt im August 2027 für Systeme unter bestimmten Anhang-III-Kategorien (Quelle: European Commission AI Act Regulatory Framework, SAP Trust Center EU AI Act Compliance).

Der Geltungsbereich des EU AI Act ist weit gefasst: Er gilt für alle AI-Systeme, die in der EU eingesetzt werden, unabhängig davon, wo der Anbieter seinen Sitz hat. Auch US-amerikanische Unternehmen mit EU-Operations sind betroffen (Quelle: Holland & Knight, US Companies Face EU AI Act's August 2026 Compliance Deadline).

Was als Hochrisiko gilt

Für SAP-Kunden sind vor allem vier Kategorien von AI-Hochrisiko-Systemen relevant, die in Anhang III des EU AI Act gelistet sind:

Erstens HR-Systeme: AI-Features in SuccessFactors, die Bewerber-Screening oder Performance-Bewertung unterstützen, können als Hochrisiko eingestuft werden.

Zweitens Kreditscoring und Finanzentscheidungen: AI-Features in Finance-Modulen von S/4HANA, die in Kredit- oder Risikobewertungen einfließen, fallen potenziell unter diese Kategorie.

Drittens kritische Infrastruktur: AI-Funktionen in Procurement- und Supply-Chain-Lösungen können bei kritischer Infrastruktur relevant sein.

Viertens Worker Management: AI-Funktionen, die die Arbeitszeit oder Leistung von Mitarbeitern bewerten oder steuern.

Der entscheidende Punkt: Der Kunde ist als Deployer dieser Systeme verantwortlich, nicht SAP als Provider. SAP's Zertifizierungen decken die Anbieter-Pflichten ab. Die Deployer-Pflichten liegen beim Kunden (Quelle: SAP Trust Center).

SAP-Zertifizierungen

SAP hat für seine AI-Dienste relevante Zertifizierungen erlangt:

ISO/IEC 42001 ist die internationale Norm für AI Management Systems. SAP ist laut eigener Kommunikation eines der ersten großen Unternehmen weltweit mit dieser Zertifizierung. Sie deckt Governance, Risk Management, Deployment, Monitoring und Continuous Improvement für SAP's eigene AI-Prozesse ab.

SOC 2 Type II prüft im 12-Monats-Auditzyklus die Cloud-Sicherheit der AI-Services. Ergänzend gilt ISO 27001 für Information Security Management sowie das EU-US Data Privacy Framework für transatlantische Datenübermittlung.

Wichtig für die praktische Einschätzung: SAP's Zertifizierungen decken SAP's Anbieter-Pflichten ab, nicht die Deployer-Pflichten des Kunden. Kunden müssen ihre eigenen AI-Management-Prozesse separat dokumentieren und nachweisen.

AI Agent Hub als Compliance-Werkzeug

Der SAP AI Agent Hub (GA Q3 2026) ist nicht nur ein Betriebs-Tool, sondern primär ein Compliance-Werkzeug. Seine Funktionen adressieren direkt die Anforderungen des EU AI Act:

Discovery schafft das Inventar aller Agenten im Tenant, das für die EU AI Act-Registrierungspflicht erforderlich ist. Verification stellt sicher, dass Agenten autorisiert sind und unter definierten Policies laufen. Observability liefert Logging und Monitoring, die für Hochrisiko-Systeme nach Artikel 12 des EU AI Act verlangt werden. Policy Definition definiert Human-Oversight-Mechanismen, die für Hochrisiko-Systeme verpflichtend sind (Quelle: SAP Trust Center, SAP Insider Sapphire 2026 AI Agent Guardrails).

Was Kunden selbst dokumentieren müssen

SAP's Zertifizierungen und der AI Agent Hub sind Voraussetzungen, aber nicht hinreichend. Als Deployer müssen Kunden für jeden produktiven AI-Use-Case, der als Hochrisiko eingestuft wird, folgende Elemente selbst halten: eine vollständige Konformitätsbewertung vor Inbetriebnahme, eine technische Dokumentation des Systems, ein etabliertes Risk-Management-System, die Definition von Human Oversight, aktives Logging und Monitoring sowie Aufbewahrungsfristen für AI-relevante Logs.

Für Organisationen, die mehrere AI-Use-Cases produktiv betreiben oder planen, ist eine strukturierte Inventarisierung aller Use Cases mit Risiko-Klassifizierung der praktisch sinnvolle erste Schritt. Ohne diese Grundlage ist eine Compliance-Bewertung nicht möglich (Quelle: Secure Privacy, EU AI Act 2026 Compliance).

---

Data Sovereignty, IP-Indemnification, Tenant-Isolation {#data-sovereignty-ip-indemnification-tenant-isolation}

Neben der regulatorischen Compliance berührt SAP Business AI drei vertragliche Kernfragen: Wer sieht welche Daten? Was sichert SAP bei IP-Verletzungen zu? Und was gilt für spezifische Branchen?

Wer sieht welche Daten

SAP Business AI verarbeitet Kundendaten auf Basis des Standard-AI-Terms, der in jedem SAP-Cloud-Vertrag enthalten ist. Die relevanten Aussagen:

Kunden-Geschäftsdaten bleiben im Kunden-Tenant. SAP greift nicht zu, außer für vereinbarte Betriebsprozesse. Prompts, die Nutzer über Joule an Foundation Models senden, werden über den Generative AI Hub geroutet, der das Modell-API abstrahiert. Der SAP-Vertrag mit dem jeweiligen Modell-Anbieter regelt die Datennutzung auf der Anbieterseite.

Der für Kunden wesentliche Punkt: SAP nutzt Kunden-Daten nicht für das Training eigener Modelle. Diese Zusage ist laut Standard-AI-Terms die Grundlage, auf der Kunden sensible Geschäftsdaten in AI-Workflows einsetzen können. Sie gilt für SAP-Modelle, nicht uneingeschränkt für alle externe Modelle, die über den GenAI Hub angeboten werden. Hier sollte die Vertragssprache des jeweiligen Modell-Anbieters mitgeprüft werden (Quelle: SAP Trust Center).

IP-Indemnification: Was SAP zusichert und was nicht

IP-Indemnification ist die vertragliche Zusicherung, dass SAP für eventuelle Verletzungen geistiger Eigentumsrechte durch die AI-Systeme haftet oder den Kunden schadlos hält.

Was SAP standardmäßig zusichert: Indemnifizierung für IP-Verletzungen durch SAP-eigene Modelle (SAP-ABAP-1, SAP-RPT-1). Für bestimmte Drittpartei-Modelle im GenAI Hub kann eine erweiterte Indemnification verhandelt werden, dies ist aber nicht Standard.

Was SAP nicht zusichert: IP-Indemnification für Output, den der Kunde mit Joule Studio selbst entwickelten Agenten produziert. Indemnification bei Verstößen gegen branchenspezifische Regulierung wie die Medical Device Regulation.

Die praktische Konsequenz: Für Use Cases mit hohem Output-Risiko, etwa in der Pharmaindustrie, im Rechtsbereich oder im Finanzdienstleistungsbereich, sollten explizite IP-Klauseln im Order Form verankert werden (Quelle: SAP Governance KB).

Branchenspezifische Anforderungen

Über die generellen EU AI Act-Anforderungen hinaus bestehen in regulierten Branchen zusätzliche Compliance-Anforderungen:

Im Finanzdienstleistungsbereich verlangen BaFin, EBA und FINMA ein AI-Use-Case-Inventar, Erklärbarkeit für Kredit- und Risikobewertungen sowie DORA-Compliance (Operational Resilience) für AI-Services.

In der Pharma- und Life-Sciences-Branche ist GxP-Validierung von AI-Komponenten erforderlich, die in GxP-regulierten Prozessen eingesetzt werden. Bei medizinischer Software gilt die Medical Device Regulation (MDR).

Im Bereich Defense und kritische Infrastruktur greifen NIS-2-Anforderungen an AI-Komponenten sowie Souveränitätsanforderungen, die eine EU-Cloud-Verarbeitung verlangen können.

Im öffentlichen Sektor gelten BSI-Vorgaben und das C5-Testat für Cloud-Services, das auf AI-Services ausgedehnt werden kann (Quelle: SAP Governance KB).

SAP bietet keine generische Branchenzertifizierung für Business AI. Jeder Kunde muss die branchen-spezifische Compliance auf Basis von SAP's Trust-Center-Dokumenten und einem eigenen AI-Governance-Framework eigenständig nachweisen.

---

Was vor Verhandlung zu prüfen ist {#was-vor-verhandlung-zu-pruefen-ist}

Wer in eine Verhandlung über SAP Business AI geht, ohne die eigene Ausgangslage zu kennen, verhandelt auf einer schwachen Basis. Die folgenden fünf Schritte strukturieren die Vorbereitung.

Schritt 1: Drei-Topf-Verbrauch im eigenen Portfolio quantifizieren

Bevor jede Verhandlung beginnt, sollte die aktuelle Verbrauchssituation in allen drei Töpfen bekannt sein: Wie viele AI Units wurden im letzten Vertragsjahr verbraucht, und wie viele sind verfallen? Wie verhält sich der BTP Capacity Unit-Verbrauch zur jährlichen Allokation? Gibt es aktive BDC-Nutzung, und wenn ja, mit welchem Volumen?

Diese Bestandsaufnahme ist die Grundlage für jede Sizing-Diskussion. Ohne sie ist die Gefahr groß, ein Kontingent zu kaufen, das entweder zu groß (und damit mit Verfall behaftet) oder zu klein (und damit mit Overage-Risiko behaftet) ist.

Schritt 2: Vertragstyp wählen

Im zweiten Schritt wird das passende Beschaffungsvehikel festgelegt. Liegt ein aktiver SAP Cloud ERP Private oder RISE-Vertrag vor? Falls ja, ist die Add-On-Lösung in diesem Vertrag wirtschaftlich in der Regel vorteilhafter als ein Standalone-Kauf.

Gleichzeitig sollte geprüft werden, ob ein Hyperscaler-Marketplace-Weg für die Organisation in Frage kommt. Bei Unternehmen mit bestehenden Cloud-Commitments auf AWS, Azure oder GCP kann dieser Weg die effektive AI-Unit-Rate deutlich senken (Quelle: Advisory Report, Negotiating SAP RISE Add-Ons).

Schritt 3: Order-Form-Sektionen identifizieren

Nicht das Rahmenvertragsdokument, sondern das Order Form ist die bindende kommerzielle Grundlage. Für SAP Business AI 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. Das AI Units Exhibit regelt den Pro-Unit-Preis, ob er fixiert oder per Verweis auf "current pricing" offen gelassen ist. Die Capability-Liste benennt, welche Capabilities vertraglich zugesichert sind. Die Overage-Klausel definiert Faktoren, Cap und Eskalationsmechanismus. Rollover-Regelungen legen fest, ob und wie viele AI Units übertragen werden können. Die Aggregation-Scope-Klausel definiert, ob Dev/Test-Umgebungen in die Kontingent-Zählung einbezogen werden (Quelle: SAP Licensing Experts, Negotiating SAP AI Contracts).

Schritt 4: Governance-Anforderungen pro Use Case prüfen

Für jeden geplanten produktiven AI-Use-Case sollte vor Vertragsabschluss eine Grundklassifizierung vorliegen: Fällt der Use Case unter den EU AI Act als Hochrisiko-System? Welche Datenkategorien werden verarbeitet? Ist Human Oversight definiert?

Diese Klassifizierung bestimmt, ob der AI Agent Hub von Anfang an eingeplant werden muss und welche Dokumentationspflichten entstehen. Sie beeinflusst auch die Vertragssprache: IP-Indemnification-Klauseln und Logging-Anforderungen sollten vor Vertragsabschluss, nicht danach, verhandelt werden.

Schritt 5: Verfall und Forecasting-Logik klären

Im letzten Vorbereitungsschritt wird die Forecast-Basis mit SAP abgeglichen. Welche Sizing-Annahmen hat SAP dem Angebot zugrunde gelegt? Sind diese Annahmen auf Copilot-Basis oder auf Agenten-Basis kalkuliert? Wie unterscheidet sich der geplante Ausrollzeitplan von der Sizing-Annahme?

Wer diese Fragen vor der Verhandlung klärt, hat eine fundierte Basis für die Diskussion über Kontingent-Höhe, Rollover-Klauseln und eventuelle Anpassungsmechanismen im Vertrag. Ein Rollover-Recht von 10 bis 20 Prozent der nicht genutzten AI Units ist in vielen Verhandlungen erreichbar, ist aber kein Standard und muss explizit in das Order Form aufgenommen werden.

---

FAQ {#faq}

Was ist eine AI Unit und wie wird sie verbraucht?

Eine AI Unit ist SAP's konsumbasierte Verbrauchseinheit für Business AI Services. Kunden kaufen ein Prepaid-Jahres-Kontingent. Jeder AI-Service-Aufruf, ob Joule-Konversation, eingebettete Finance-Funktion oder Agenten-Ausführung, verbraucht eine definierte Anzahl AI Units, die SAP pro Service in Konversionsfaktoren veröffentlicht. Ungenutzte AI Units verfallen am Ende des Vertragsjahres, sofern keine explizite Rollover-Klausel im Order Form vereinbart wurde (Quelle: SAP Help Portal, Metering and Pricing).

Wie laufen PUPM-Requests ab und kann ich sie poolen?

PUPM-Pakete (Per-User-per-Month) weisen jedem Nutzer über den SAP Identity Service ein fixes monatliches Request-Kontingent zu. Nicht genutzte Kontingente können innerhalb eines Pakets auf andere Nutzer desselben Pakets umgelenkt werden, das ist das erlaubte Pooling. Paketübergreifendes Pooling ist nicht möglich. Alle Kontingente eines PUPM-Pakets verfallen am Monatsende ohne Übertrag (Quelle: SAP Learning, PUPM Pricing Model).

Was ist im RISE-Vertrag an Business AI bereits inkludiert?

Ein RISE- oder SAP Cloud ERP Private-Vertrag enthält typischerweise einige eingebettete AI-Features wie Predictive Accounting und Intelligent AP Automation sowie fixe Transaktions-Quoten und einen View-Only-Joule-Zugang mit begrenzten Konversations-Sessions. Dieser Basisumfang ist für produktive AI-Adoption bei größeren Nutzerpopulationen nicht ausreichend. Joule Power User Seats, zusätzliche AI Units und erweiterte Capability-Pakete sind Add-Ons (Quelle: SAP Licensing Experts, SAP AI in RISE Contracts 2026).

Wie unterscheiden sich AI Units, Capacity Units und BDC?

AI Units sind die Verbrauchseinheit für Business AI Services wie Joule und AI Core. Capacity Units (CU) sind die Verbrauchseinheit für BTP-Plattformdienste wie Integration Suite, Application Development und Datenbankservices. BDC Credits messen Datenvolumen und Datenprodukte in der Business Data Cloud. Die drei Töpfe sind nicht austauschbar, werden separat gemessen und separat beschafft (Quelle: SAP Help Portal).

Was ist seit der Abschaffung von Premium Plus anders?

SAP hat RISE with SAP Premium Plus im Juni 2025 eingestellt. Das bisherige Top-Tier RISE wurde in SAP Cloud ERP Private umbenannt. AI-Capabilities, die vormals in Premium Plus enthalten waren, wurden teilweise in Cloud ERP Private hochgezogen, teilweise als separate Add-Ons neu positioniert. Insbesondere Embedded AI Units sind in Cloud ERP Private nicht mehr automatisch inkludiert, sondern separat zu erwerben. Bestandskunden mit alten Premium-Plus-Verträgen sollten prüfen, was sich im Repackaging verändert hat (Quellen: Redress Compliance, CIO Magazine).

Was bedeutet die Aggregations-Falle und wie ist sie zu handhaben?

Die Aggregations-Falle bezeichnet die SAP-Standard-Vertragsklausel, nach der der AI-Verbrauch über alle Systemumgebungen, also Entwicklung, Test und Produktion, gemeinsam auf das monatliche Kontingent angerechnet wird. Wer aktive AI-Features in Nicht-Produktivumgebungen betreibt, kann damit unerwartet hohe Verbräuche erzeugen. Eine Dev/Test-Exclusion für die AI-Unit-Zählung ist verhandelbar und sollte bei der nächsten Vertragsverhandlung oder Renewal geprüft werden (Quelle: SAP Licensing Experts).

Welche Foundation Models stehen im GenAI Hub zur Verfügung?

Der Generative AI Hub bietet Zugang zu Foundation Models verschiedener Anbieter, darunter SAP-eigene Modelle für ABAP-Entwicklung und Prozesskontexte sowie Modelle externer Anbieter. Die verfügbaren Modelle variieren je nach Region, Vertragsversion und SAP-Freigabezyklus. SAP aktualisiert das Modell-Portfolio rollierend. Für Governance-Zwecke sollte die aktuelle Modell-Liste aus der SAP-Dokumentation gezogen werden, nicht aus Marketing-Material (Quelle: SAP Help Portal, Generative AI Hub).

Was ist der Unterschied zwischen Skills und Agents in Joule?

Ein Joule Skill ist eine deterministische, vordefinierte Operation, die eine einzelne Aktion ausführt. Ein Joule Agent ist ein autonomes System, das mehrere Skills orchestriert, einen Plan entwirft und diesen selbstständig ausführt. Der Verbrauchsunterschied ist erheblich: Agenten konsumieren bei komplexen Multi-Step-Plänen deutlich mehr AI Units als einzelne Skill-Aufrufe. Für Budgetplanung und Sizing ist diese Unterscheidung zentral (Quelle: SAP Learning, Introducing Joule Agents).

Was ändert sich am 2. August 2026 mit dem EU AI Act?

Am 2. August 2026 tritt die Vollwirkung des EU AI Act für Hochrisiko-AI-Systeme in Kraft. Unternehmen, die AI-Systeme in Hochrisiko-Kategorien produktiv betreiben, müssen ab diesem Datum eine abgeschlossene Konformitätsbewertung, vollständige technische Dokumentation, ein etabliertes Risk-Management-System, definierte Human-Oversight-Mechanismen sowie aktives Logging und Monitoring nachweisen können. Als Deployer dieser Systeme liegt die Verantwortung beim Kunden, nicht bei SAP als Provider (Quelle: European Commission, SAP Trust Center).

Werden meine Daten für SAP-eigene AI-Modelle verwendet?

Laut SAP Standard-AI-Terms werden Kunden-Geschäftsdaten nicht für das Training SAP-eigener Modelle verwendet. Diese Zusage ist in den AI Terms des SAP-Cloud-Vertrags verankert. Für externe Foundation Models, die über den Generative AI Hub angeboten werden, gilt jeweils der Vertrag des Modell-Anbieters mit SAP. Bei sensiblen Datenkategorien empfiehlt sich eine explizite Prüfung der Datenschutzklauseln des jeweiligen Modell-Anbieters (Quelle: SAP Trust Center, Data Sovereignty).

Was kostet SAP Business AI in der Praxis?

SAP publiziert keine öffentliche AI-Unit-Tarifliste. Der effektive Pro-Unit-Preis hängt vom gewählten Beschaffungsvehikel, der Vertragsgröße und den individuell verhandelten Konditionen ab. Als Orientierung: Standalone-BTP-Verträge haben typischerweise den höchsten Pro-Unit-Preis. RISE- oder Cloud-ERP-Bundle-Verträge bieten in der Regel günstigere Konditionen. Der SAP AI Pricing Estimator im Discovery Centre liefert Volumen-Schätzungen, aber keine Euro-Beträge. Tatsächliche Kosten ergeben sich erst aus dem im Order Form fixierten Pro-Unit-Preis (Quelle: SAP Pricing Page, SAP Licensing Experts).

Brauche ich für SAP Business AI eine eigene Governance-Funktion?

Für produktive AI-Use-Cases in regulierten Bereichen oder bei Hochrisiko-Klassifizierung nach EU AI Act ist eine eigenständige Governance-Funktion erforderlich. Ohne strukturierte Inventarisierung, Klassifizierung und Beobachtbarkeit der eingesetzten AI-Systeme können weder Compliance-Anforderungen erfüllt noch Verbrauch und Kostenentwicklung planbar gesteuert werden. Der SAP AI Agent Hub (GA Q3 2026) bietet eine technische Grundlage. Die organisatorische Verankerung der Governance-Funktion liegt beim Kunden.

---

Nächste Schritte {#naechste-schritte}

Wer die eigene SAP-Business-AI-Vertragsstruktur strukturiert bewerten möchte, hat drei Möglichkeiten:

Der Vertragscheck liefert in vier Wochen eine vollständige Analyse des aktuellen SAP-Vertragsportfolios, inklusive AI-Unit-Allokation, Overage-Risiken und konkreten Handlungsempfehlungen für die nächste Verhandlung. Festpreis, unabhängig.

Der FinOptory AI Chat gibt eine erste Einschätzung des eigenen AI-Vertragsanteils auf Basis einer Kurz-Beschreibung der aktuellen Situation, ohne Datei-Upload. Er eignet sich als erster Orientierungspunkt, wenn noch keine vollständige Analyse geplant ist.

Wer den breiteren Kontext sucht: Pillar 1 dieser Serie behandelt SAP Contract Governance über das gesamte SAP-Portfolio, über alle neun Produkttypen und über die gesamte Vertragslaufzeit.

---

Quellen: SAP News (Sapphire 2026), SAP Help Portal (Metering and Pricing), SAP Pricing Page, SAP Learning (PUPM Model, Joule Studio), SAP Trust Center (EU AI Act, Data Sovereignty), European Commission (AI Act Regulatory Framework), SAP Licensing Experts (AI in RISE, AI Units, Negotiating AI Contracts), Advisory Report (Negotiating SAP RISE Add-Ons), Redress Compliance (RISE Premium Packaging Changes), CIO Magazine (SAP RISE rebrand), NextLytics (DSAG Technology Days 2026), Holland & Knight (EU AI Act August 2026), SAP Insider (Sapphire 2026), ERP Today (Sapphire 2026), SAVIC Technologies (AI Foundation Architecture, Joule Studio 2026), Secure Privacy (EU AI Act 2026 Compliance), SAP Community Blog (TDD AI Unit SKU)