BTP AI Core vs. Hyperscaler: Die 5 kritischen Architekturfragen für SAP-Architekten

SAP AI Core vs Azure OpenAI,  alles was Sie darüber Wissen müssen erfahren sie hier

Azure OpenAI, AWS Bedrock oder doch SAP AI Core? Für SAP-Architekten ist die Wahl der Runtimes keine reine Geschmacksfrage, sondern eine fundamentale Entscheidung über Security, Wartbarkeit und Kosten. Wir machen den direkten Architektur-Check.

Lesezeit: ca. 6 Minuten | Level: Advanced / Architecture | Autor: CloudDNA Technik-Team

—

Die Verfügbarkeit von leistungsfähigen LLMs (Large Language Models) ist heute Commodity. Ob GPT-4o, Gemini oder Llama 3 – Sie bekommen die Modelle bei jedem großen Hyperscaler. Das führt in Architektur-Meetings oft zu einer berechtigten Frage:

„Warum sollten wir die SAP BTP und den AI Core als ‚Middleman‘ nutzen und extra bezahlen, wenn wir die Services auch direkt native bei unserem Hyperscaler (z.B. Azure oder AWS) hosten können?“

Die Antwort ist nicht trivial. Auf den ersten Blick locken die Hyperscaler mit günstigen Token-Preisen und mächtigen nativen Tools. Doch wer eine Enterprise-Architektur für geschäftskritische SAP-Prozesse baut, muss über den reinen API-Call hinausdenken.

Hier sind die 5 kritischen Fragen, die Sie beantworten müssen, bevor Sie Ihren Architektur-Blueprint zeichnen.

1. Identity & Context: Wer ist der User (wirklich)?

Wenn Sie eine Fiori-App bauen, die einen AI-Service aufruft, ist die Authentifizierung der Knackpunkt.

• Hyperscaler Direct Ansatz: Sie müssen den SAP-User (z.B. via IAS) auf einen IAM-User des Hyperscalers mappen oder mit generischen Technical Usern arbeiten. Letzteres ist ein Security-Risiko (keine Nachverfolgbarkeit), Ersteres ein hoher Integrationsaufwand.
• SAP BTP Ansatz: Der SAP AI Core ist nativ in die BTP-Security integriert. Mittels Principal Propagation wird die Identität des SAP-Users durchgereicht. Das System weiß exakt, wer den Prompt sendet, und kann Berechtigungen (z.B. auf Backend-Daten) kontextbezogen prüfen.

Architektur-Fazit: Wenn der AI-Use-Case direkten User-Kontext benötigt (z.B. „Erkläre mir meine Gehaltsabrechnung“), schlägt die native BTP-Integration jeden Workaround.

2. Die „Vendor-Lock-in“ Falle: Wie agil ist Ihr Modell-Mix?

Der AI-Markt dreht sich rasend schnell. Das beste Modell von heute ist in sechs Monaten veraltet oder zu teuer.

• Hyperscaler Direct Ansatz: Sie binden sich oft an die Modelle, die der Provider priorisiert (z.B. Azure ➔ OpenAI, GCP ➔ Gemini). Ein Wechsel des Providers erfordert oft ein Neuschreiben des Integration-Codes.
• SAP BTP Ansatz: Hier kommt der Generative AI Hub ins Spiel. Er fungiert als Abstraktionsschicht. Sie programmieren gegen eine standardisierte SAP-API. Ob dahinter GPT-4, Claude 3 oder ein Open-Source-Modell auf AWS läuft, ist reine Konfiguration.

Architektur-Fazit: Die BTP fungiert als „Adapter“. Sie wollen Ihre SAP-Erweiterungen nicht alle 6 Monate refactorn, nur weil ein neues Modell auf den Markt kommt.

Technical Deep Dive gefällig?

Theorie ist gut, Code ist besser. Möchten Sie sehen, wie wir den Generative AI Hub konkret in einem SAP CAP-Projekt konfigurieren?

👉 [Jetzt Termin für eine Tech-Demo vereinbaren] oder lesen Sie nächsten Monat unseren Beitrag zum Thema „RAP-Booster“.

3. Grounding & RAG: Wo liegen die Daten?

AI ohne Kontext halluziniert. Für Business-AI brauchen Sie RAG (Retrieval Augmented Generation) – also das Füttern des Modells mit Ihren SAP-Daten.

• Hyperscaler Direct Ansatz: Sie müssen SAP-Daten (Business Partner, Materialstamm) aus dem S/4HANA extrahieren und in eine Vektor-Datenbank auf dem Hyperscaler replizieren. Das bedeutet: Datenreplikation, Latenz, Sync-Probleme und potenzielle Compliance-Verstöße.
• SAP BTP Ansatz: Mit SAP HANA Cloud Vector Engine bleiben die Daten im SAP-Kontext. Sie nutzen die bestehende Connectivity (Cloud Connector) für Echtzeit-Zugriffe, ohne Daten massenhaft nach außen zu schaufeln.

Architektur-Fazit: „Data Gravity“ gilt auch hier. Bringen Sie die AI zu den Daten, nicht umgekehrt. Für SAP-intensive Daten ist die BTP der logische Ort für die Vektorisierung.

4. TCO Betrachtung: Lizenzkosten vs. Integrationskosten

Das häufigste Argument gegen BTP ist der Aufpreis auf die Token-Kosten. Das ist faktisch korrekt, aber zu kurz gedacht.

• Die Rechnung:
  • Hyperscaler: Günstigere Compute-Kosten + Hohe Integrationskosten (Security, Mapping, Custom Code für Failover/Switching).
  • SAP BTP: Höhere Unit-Costs + „Out-of-the-box“ Integration (Destinations, Security, Lifecycle Management).

Architektur-Fazit: Für isolierte PoCs ist der Hyperscaler billiger. Für produktive, wartbare Szenarien mit tiefer SAP-Integration dreht sich die TCO-Rechnung oft zugunsten der BTP, da Sie hunderte Stunden Custom-Development sparen.

5. Lifecycle & Operations: Wer betreibt das Chaos?

AI-Modelle müssen überwacht werden (Drift, Token-Usage, Kosten).

• Hyperscaler Direct Ansatz: Das Ops-Team muss eine neue Konsole (Azure Portal / AWS Console) lernen und überwachen. Das Monitoring ist getrennt vom SAP Cloud ALM.
• SAP BTP Ansatz: AI-Ressourcen werden wie jeder andere BTP-Service verwaltet. Das Monitoring fließt in die bekannten SAP-Dashboards ein. Developer nutzen Tools wie BAS (Business Application Studio) und CAP (Cloud Application Programming Model), die bereits AI-Support bieten.

Zusammenfassung: Entscheidungshilfe

Unsere CloudDNA Empfehlung

Wir sind keine Dogmatiker. Es gibt Szenarien, in denen ein direkter Hyperscaler-Zugriff Sinn macht (z.B. Analyse von riesigen Mengen an Non-SAP-Daten, wie IoT-Streams oder Social Media).

Aber: Für 90% der SAP-Erweiterungsszenarien – also dort, wo SAP-Daten gelesen, interpretiert oder erstellt werden – ist der SAP AI Core auf der BTP die architektonisch sauberste Lösung. Die Abstraktion durch den Generative AI Hub ist ihre Versicherung gegen die Volatilität des AI-Marktes.

Bauen Sie keine technische Schuld durch „billige“ Direktverbindungen auf. Investieren Sie in eine saubere Schichtenarchitektur.

SAP Joule & Fiori: Die AI-Revolution der SAP User Experience