Databricks Mosaic AI: AI-Agenten, die ihre SAP-Geschäftslogik wirklich beherrschen
- Databricks
- Databricks
- 9 Min Lesezeit
Kenan Hodzic
Dieser Artikel zeigt, warum AI-Agenten im SAP-Umfeld nicht an Datenzugriff, sondern an fehlender Semantik scheitern – und wie Databricks Mosaic AI das Problem mit governed Kontext löst. Im Fokus stehen Metric Views und Unity Catalog als „Logik-Vertrag“ für KPIs und Zugriffe, ergänzt um Graph-Reasoning (Neo4j Virtual Graph) für Belegfluss- und Hierarchie-Fragen. Ergebnis: weniger Improvisation auf Rohdaten, mehr Kontrolle, Nachvollziehbarkeit und Auditierbarkeit – als Grundlage für belastbare Decision Intelligence.
Inhaltsverzeichnis
1. Das Problem: Datenzugriff ist nicht Logikbeherrschung
1.1 Worum es geht
Viele SAP-AI-Ansätze folgen einem verführerisch einfachen Muster: Ein Large Language Model (LLM) wird über OData, SQL oder APIs an SAP-Daten angebunden und generiert daraus Antworten. Für einfache Datenabfragen mag das funktionieren – doch spätestens dort, wo SAP-Geschäftslogik ins Spiel kommt, stösst dieses Modell an seine Grenzen.
SAP-Finanz- und Prozesslogik liegt nicht isoliert in einzelnen Tabellen. Sie entsteht aus dem Zusammenspiel von Ledgern, Fiscal-Year-Varianten, Währungsregeln, Belegflüssen, Hierarchien, Kennzahlendefinitionen und Berechtigungen. Ein Agent, der diese Logik nicht kennt, kann formal korrekt wirkende, aber fachlich falsche Antworten liefern – und das ist im Finanz- und Compliance-Kontext gefährlicher als gar keine Antwort.
Solche Agenten – die technisch funktionieren, aber die semantische Ebene von SAP nicht kennen – werden in diesem Artikel als naive Agenten bezeichnet. Der Begriff ist nicht abwertend gemeint, sondern beschreibt präzise das Kernproblem: Der Agent ist naiv gegenüber der Geschäftslogik, weil er keinen Zugang zu ihr hat.
Ein Beispiel verdeutlicht das Problem: Ein Anwender fragt nach der tatsächlichen operativen Marge einer Produktlinie im letzten Quartal. Ein naiver Agent greift direkt auf ACDOCA zu – das zentrale Journal in SAP S/4HANA – summiert Erlöse und Kosten, und liefert ein Ergebnis. Das Ergebnis ist technisch ausgeführt, aber fachlich falsch. Dem Agenten fehlen zentrale Informationen:
- Welche Fiscal-Year-Variante gilt für die betrachtete Gesellschaft?
- Welche Währungsumrechnungslogik ist im Konzern vorgeschrieben?
- Welche Profitcenter- oder Produktlinienhierarchie ist fachlich gültig?
- Welche Daten darf der fragende Benutzer überhaupt sehen?
Das eigentliche Risiko liegt dabei nicht in einer einzelnen falschen Zahl, sondern darin, dass die Antwort sprachlich überzeugend wirkt. Im Finanz-, Compliance- und Steuerungskontext ist eine formal plausible, aber fachlich falsche Antwort weitaus gefährlicher als eine ausgebliebene.
Wahre Decision Intelligence entsteht erst dann, wenn ein Agent nicht als SQL-Übersetzer auf rohen Tabellen agiert, sondern die im Unternehmen definierten Geschäftsregeln als verbindliche Ground Truth nutzt.
Die folgenden Abschnitte zeigen, wo naive Agenten konkret scheitern – und welche Ebenen ein Agent kennen muss, um SAP-Logik wirklich zu beherrschen.
1.2 Warum naive Agenten scheitern
Die typischen Fehlerklassen entstehen immer dann, wenn ein LLM direkt auf rohem SQL oder OData arbeitet:
SAP-Geschäftsjahre folgen selten dem Kalenderjahr. Ein Agent ohne Kenntnis der Fiscal-Year-Variante schneidet Perioden falsch.
Kennzahlen, die auf unterschiedlichen Verdichtungsstufen existieren, werden miteinander vermischt oder auf einer Ebene aggregiert, die betriebswirtschaftlich nicht zulässig ist.
Belegfluss, Storno- und Ausgleichslogik fehlen; der Agent summiert, was er findet.
Plan vs. Ist, brutto vs. netto, die berechnete SAC-Kennzahl vs. das Rohfeld – semantisch grundverschieden, namentlich oft ähnlich.
Buchungskreis, Kostenrechnungskreis, Profitcenter-Hierarchie: Der Agent aggregiert über organisatorische Grenzen hinweg, die betriebswirtschaftlich nicht überschritten werden dürfen.
Führende Nullen in Materialnummern, Präfixmuster, Backslash-Handling in Member-IDs, Dimensions-Konventionen – alles bricht leise und ohne Fehlermeldung.
Der gefährlichste Fall: Der Agent sieht und verrät Daten, die der fragende Nutzer nach dem SAP-Berechtigungskonzept nie sehen dürfte.
Allen Fehlern gemeinsam: Sie entstehen, weil der Agent auf der Tabellenebene operiert, während die Geschäftslogik eine Ebene darüber liegt.
1.3 Die wichtigsten Ebenen für Agents
Ein naiver Agent scheitert also nicht an fehlender Rechenleistung, sondern an fehlendem Kontext – er weiss nicht, was die Daten bedeuten. Um zu verstehen, was ein Agent tatsächlich beherrschen müsste, hilft eine Taxonomie der relevanten Ebenen:
Ebene | Beispiele | Wo die Logik lebt |
Stammdaten-Semantik | GL-Konten, Kostenstellen, Material | CDS Views, Datasphere-Modelle |
Org-Strukturen & Hierarchien | Buchungskreis, Profitcenter-Baum | Hierarchietabellen, semantische Modelle |
Belegfluss / Prozessketten | Order-to-Cash, Procure-to-Pay, Record-to-Report | Belegverkettung, Statusfelder |
Berechnungslogik | Abweichungen, abgeleitete Kennzahlen | CDS Views, Metric Views, Analytic Models |
Berechtigungskonzept | Wer darf welche Org-Einheit sehen | SAP-Auth-Objekte |
Die entscheidende Einsicht: Diese Logik existiert bereits. Sie ist in CDS-Views, Datasphere-Analytic-Models und Metric Views kodifiziert. Ein Agent muss sie nicht reimplementieren — er muss sie als verlässliche Quelle (Ground Truth) anzapfen und darf sie nicht umgehen.
2. Die Lösung: Databricks Mosaic AI im SAP-Kontext
Databricks Mosaic AI ist die AI- und Machine-Learning-Schicht der Databricks Data Intelligence Platform. Während viele AI-Plattformen primär auf Modelltraining oder einfache Chat-Interfaces ausgerichtet sind, bietet Mosaic AI einen integrierten Stack für den Aufbau, die Evaluation und den Betrieb von AI-Agenten – direkt auf dem Lakehouse, wo die Daten bereits liegen. Das macht Mosaic AI besonders relevant im SAP-Umfeld: AI-Agenten arbeiten nicht auf einer externen Plattform mit replizierten Daten, sondern auf der governed Datenbasis, die ohnehin im Lakehouse aufgebaut wurde.
Mosaic AI besteht aus mehreren Bausteinen, die sich gezielt für spezifische Anforderungen kombinieren lassen. Statt einer abstrakten Feature-Liste: jede Komponente direkt gegen ein konkretes SAP-Logik-Problem gestellt.
Mosaic-AI-Baustein | Adressiertes SAP-Problem |
Agent Bricks (automatisierter Agent-Builder mit synthetischen Daten und Benchmarks) | Schneller, getesteter Weg von PoC zu produktionsreifer Genauigkeit ohne manuelles Trial-and-Error |
Mosaic AI Agent Framework | Orchestrierung, Tool-Calling, Memory |
Unity Catalog Metric Views | Eine governed KPI-Definition als Tool |
Vector Search + Graph-Retrieval | Abruf über semantische Beziehungen statt bloßer Stichwortsuche |
MLflow 3.0 Tracing | Auditierbarkeit jeder einzelnen Agent-Entscheidung |
AI Gateway | Modell-Governance, Kostenkontrolle, Sicherheit |
MCP (Model Context Protocol) | Saubere, standardisierte Tool-Anbindung an SAP-nahe Systeme |
Agent Bricks wurde auf dem Data+AI Summit eingeführt und erzeugt automatisch domänenspezifische synthetische Daten und Benchmarks, um Agenten auf Kosten und Qualität zu optimieren – statt durch manuelles Ausprobieren. Für SAP bedeutet das konkret: Edge-Cases der Geschäftslogik lassen sich systematisch als Testfälle modellieren, bevor ein Agent in Produktion geht.
Andreas & Yvonnes Databricks-Guide
Möchten Sie alle wichtigen Informationen auf einen Blick?
Laden Sie sich jetzt den kostenlosen Guide zur SAP Databricks!
3. Graph-Reasoning: die fehlende Ebene
Die meisten der in Abschnitt 2 beschriebenen Fehler sind im Kern relationale Fehler. Geschäftslogik in SAP ist überwiegend eine Frage von Beziehungen:
GL-Konto → Profitcenter → Buchungskreis
Lieferant → Bestellung → Wareneingang → Rechnung → Belegposition → Hauptbuchbeleg
Kostenstelle → Material
Genau diese Beziehungen sind es, was ein Knowledge Graph abbildet – und worüber ein Agent «mehrere Hops weit» schlussfolgern können muss. Eine typische Frage wäre: «Welche Kostenstellen sind von dieser Lieferanten-Störung nachgelagert betroffen?» Eine flache Tabellenabfrage und eine Vektorsuche reichen dafür schlicht nicht aus.
Das bisherige Problem: Um Graph-Reasoning über SAP-Daten zu realisieren, mussten die Daten bisher in eine separate Graph-Datenbank kopiert werden. Das schafft ein zweites System of Record, spaltet die Governance und erfordert eine eigene Pipeline – bei SAP-Datenvolumina und -Sensibilität ein schwerwiegender Einwand.
3.1 Die Neuerung: Neo4j Virtual Graph
Seit Mai 2026 in Private Preview, Databricks zum Start unterstützt. Virtual Graph erlaubt es, Cypher-Abfragen und Graph-Algorithmen direkt gegen die Daten auszuführen, die bereits in Databricks liegen – mittels Zero-Copy, ohne Datenbewegung.
Die Architektur besteht aus drei Teilen:
- AI-generiertes Datenmodell: Der Graph wird automatisch aus dem vorhandenen Tabellenschema abgeleitet; Entitäten werden zu Knoten, Foreign Keys (auch nicht deklarierte, inferierte) zu Beziehungen, Spalten zu Eigenschaften. Das Modell bleibt editierbar und synchronisiert sich mit den Quellen.
- Query Translator: Cypher wird deterministisch in optimiertes SQL übersetzt und als Pushdown an die Databricks-Engine gegeben. Deterministisch bedeutet: dasselbe SQL bei jeder Ausführung, vorhersagbare Performance und Kosten – die Übersetzung ist nicht LLM-getrieben.
- Graph-Compute-Layer: Übernimmt graph-spezifische Operationen (Pattern Matching, Traversierungen, Algorithmen), die SQL allein nicht effizient ausdrücken kann.
Die Daten verlassen dabei nie ihren Governance-Perimeter. Das ist der entscheidende Punkt für SAP: Der semantische Backbone wird zu einem virtuellen Layer über den bereits via BDC/Datasphere governed gelandeten Daten – statt zu einer replizierten Parallelwelt.
3.2 Wann virtueller, wann nativer Graph?
Virtual Graph und ein nativ in Neo4j gespeicherter Graph sind keine Substitute – sie lösen unterschiedliche Probleme:
- Virtual Graph passt, wenn Warehouse-Latenz (Sekunden bis Minuten) toleriert wird: GraphRAG über Stammdaten/Referenzdaten, Batch-Anreicherung, analystengetriebene Exploration, agentische Workflows im Sekundenbereich. Faustregel: Agenten, die in Sekunden denken.
- Nativer Neo4j-Graph (AuraDB) passt bei Millisekunden-Anforderungen: Echtzeit-Entscheidung, Online-Scoring, ACID-Writes, kontinuierlich aktualisierte Memory- und Knowledge-Graphs. Faustregel: Agenten, die in Millisekunden handeln.
Für SAP-Analytics-Agenten – Reporting, Finanzanalyse, Supply-Chain-Reasoning – liegt der Grossteil der Anforderungen im Sekundenbereich. Damit ist Virtual Graph für den Einstieg die naheliegende, governance-konforme Wahl, mit dem nativen Graph als Ergänzung für latenzkritische Pfade.
4. Architektur & Tool-Design
4.1 Architektur-Blueprint
Wie SAP-Logik governed bei den Agenten ankommt:
Die Leitprinzipien dieser Architektur:
- BDC als sauberer Weg. Die semantischen Modelle aus Datasphere kommen über Delta Sharing governed in den Lakehouse nicht roh repliziert.
- Metric Views als KPI-Vertrag. Der Agent fragt definierte Kennzahlen ab, nicht freie Aggregationen.
- Virtual Graph als Beziehungs-Layer. Multi-Hop-Reasoning über Belegfluss und Org-Strukturen, zero-copy auf den governed Daten.
- Unity Catalog als gemeinsamer Governance-Perimeter für Tabellen, Metric Views und den virtuellen Graph.
Diese Prinzipien definieren den Rahmen – wie sie sich im konkreten Tool-Design eines Agenten niederschlagen, zeigt der nächste Abschnitt.
4.2 Tool-Design: Der eigentliche Schlüssel
Wenn es in diesem Artikel einen einzigen Kernpunkt gibt, dann diesen: Die entscheidende Frage ist nicht, welches LLM verwendet wird oder wie das Prompt formuliert ist. Die entscheidende Frage ist, welche Tools dem Agenten zur Verfügung stehen – und was diese Tools kapseln.
Das Prinzip ist einfach, aber in seiner Konsequenz weitreichend: Ein naiver Agent bekommt freien Zugriff auf SQL-Tabellen. Er kann damit technisch jede Frage beantworten – aber er entscheidet selbst, wie er aggregiert, welche Perioden er schneidet, welche Hierarchien er ignoriert. Die Logik liegt beim Modell, nicht bei der Architektur. Das ist das Problem.
Ein semantisch governed Agent hingegen erhält kein freies SQL. Er erhält ein kuratiertes Set von Tools, in die die Geschäftslogik bereits eingebaut ist:
- Metric-View-Tools – parametrisierte Abfragen definierter Kennzahlen. Eine Metric View ist kein freies Query-Interface, sondern ein formell definierter KPI: Welche Felder fliessen ein, welche Aggregationslogik gilt, welche Org-Ebene ist vorgesehen. Der Agent wählt welche Kennzahl er abfragt – und in welchem Kontext (Buchungskreis, Periode, Währung). Er entscheidet nie wie die Kennzahl berechnet wird. Diese Entscheidung ist im governed Layer getroffen und unveränderlich.
- Graph-Tools (über Virtual Graph) – Beziehungs- und Pfadabfragen: «Verfolge den Belegfluss», «finde alle nachgelagerten Kostenstellen dieser Profitcenter-Gruppe», «welche Lieferanten hängen an diesem Buchungskreis?». Diese Fragen sind mit SQL allein nicht sauber lösbar – sie brauchen Multi-Hop-Reasoning über Beziehungen. Die Graph-Tools kapseln Cypher-Pattern, die deterministisch nach SQL übersetzt werden. Der Agent ruft das Tool auf; was dahinter passiert, bleibt kontrolliert und reproduzierbar.
- Retrieval-Tools – semantische Suche über Geschäftsdokumentation, Kennzahldefinitionen, Prozessbeschreibungen und Policy-Dokumente. Diese Tools stellen sicher, dass der Agent nicht nur mit Zahlen, sondern auch mit dem Bedeutungskontext operiert. «Was ist die Konzernrichtlinie zur Währungsumrechnung im Quartalsbericht?» ist eine Frage, die kein SQL beantwortet – aber ein Retrieval-Tool, das auf governed abgelegter Dokumentation basiert, sehr wohl.
Das Zusammenspiel dieser drei Tool-Typen ist das eigentliche Design-Muster. Ein Metric-View-Tool liefert die Kennzahl. Ein Graph-Tool liefert die Org-Beziehung, in deren Kontext die Kennzahl zu interpretieren ist. Ein Retrieval-Tool liefert die Regel, nach der Ausnahmen zu behandeln sind. Der Agent orchestriert – er kombiniert, schlussfolgert, formuliert – aber er erfindet keine Logik, die nicht im governed Layer existiert.
Das ist der ganze Unterschied zwischen «kann SAP-Daten holen» und «beherrscht SAP-Logik»: Die Logik ist in den Tools eingekapselt und governed – nicht der Improvisation des Modells überlassen.
5. Betrieb: Evaluation, Governance & Sicherheit
5.1 Evaluation & Vertrauen
Bei Finanzzahlen ist «meistens richtig» wertlos. Deshalb braucht es strukturierte Evaluation – und genau das liefert das mit Agent Bricks
Dimension | Bedeutung |
Correctness | Ist die Antwort fachlich korrekt? |
Latency | Antwortet der Agent in akzeptabler Zeit? |
Execution | Werden die richtigen Tools aufgerufen? |
Adherence | Hält der Agent sich an vorgegebene Constraints? |
Relevance | Ist die Antwort relevant zur Frage? |
Safety | Werden Berechtigungen und Sicherheitsvorgaben eingehalten? |
Ergänzt um LLM-Judges und synthetische Testsets, die gezielt SAP-Edge-Cases abdecken (Fiscal-Year-Grenzen, Währungsumrechnung, Stornofälle), entsteht ein Eval-Loop, ohne den kein Produktivgang verantwortbar ist.
Die zweite Säule bildet MLflow 3.0 Tracing: Jede Agent-Entscheidung – welches Tool, welcher Parameter, welches Ergebnis – ist nachvollziehbar und auditierbar. Im SAP-Kontext, wo Wirtschaftsprüfung und Compliance keine Optionen sind, ist das keine Kür, sondern Voraussetzung.
5.2 Governance & Sicherheit
Das ungelöste harte Problem, ehrlich benannt: das Mapping von SAP-Berechtigungen auf Unity-Catalog-Row-/Column-Level-Security. Wer fragt, darf nur sehen, was sein SAP-Berechtigungskonzept erlaubt – und das muss durch den Agenten durchgereicht, nicht umgangen werden.
Der Vorteil der hier skizzierten Architektur: Weil Virtual Graph Zero-Copy auf den von Unity Catalog governed Daten arbeitet, gilt derselbe Governance-Perimeter für relationale Abfragen, Metric Views und Graph-Reasoning. Es entsteht kein zweiter, separat zu sichernder Datenbestand. Das reduziert die Angriffsfläche und die Governance-Komplexität erheblich.
6. Einschätzung & Ausblick
6.1 Reality Check
Ein Vision-Artikel ohne klare Grenzen wirkt unseriös. Daher die wichtigsten Einschränkungen offen benannt:
- Virtual Graph liefert Warehouse-Latenz. Echtzeit-Millisekunden-Pfade benötigen weiterhin nativen Graph-Speicher.
- Virtual Graph ist zum Stand dieses Artikels in Private Preview. Produktive Designs sollten das Reifefenster und die Roadmap einplanen – mehr Quellen, adaptives Caching, Composite Queries über Aura und Virtual Graph sind angekündigt.
- Semantik-Qualität. Der Agent ist nur so gut wie die zugrundeliegenden Datasphere-Modelle und Metric Views. Schlechte Semantik im Unterbau lässt sich durch keine Agent-Schicht heilen.
Wer weiss, wo die Grenzen liegen, kann realistisch planen – und genau dabei hilft das folgende Stufenmodell.
6.2 Reifegrad-Stufen
Die beschriebene Zielarchitektur muss nicht auf einmal umgesetzt werden – und wird es in der Praxis auch selten. Sinnvoller ist ein schrittweiser Aufbau, der mit einer klar abgegrenzten, produktionsreifen Basis beginnt und von dort aus wächst. Das folgende Stufenmodell gibt Orientierung, wo ein Unternehmen heute steht und was der nächste realistische Schritt ist:
- Read-only Q&A. Agent beantwortet Fragen über einen Metric View. Eine Kennzahl, eine governed Quelle.
- Beziehungs-Reasoning. Virtual Graph kommt hinzu; Multi-Hop-Fragen über Belegfluss und Org-Strukturen.
- Multi-Agent über Prozessketten. Supervisor-Architektur mit Spezialisten je Prozess.
- Agentische Decision Intelligence. Agenten, die nicht nur antworten, sondern Handlungsoptionen mit Begründung und Audit-Trail vorschlagen.
Die meisten Unternehmen im SAP-Umfeld stehen heute zwischen Stufe 1 und 2. Das ist kein Rückstand – es ist der richtige Ausgangspunkt. Wer Stufe 1 sauber aufsetzt, legt damit das Governance-Fundament, auf dem alle weiteren Stufen stabil aufbauen können. Der Sprung zu Stufe 4 ist kein technischer Quantensprung, sondern das Ergebnis konsequent weiterentwickelter Semantik und Architektur.
7. Fazit
Die Crew hat Kontakt aufgenommen. Nicht mit fremdem Leben – sondern mit dem eigenen Unternehmen. Zum ersten Mal antwortet das System nicht nur auf Signale, sondern versteht, was dahintersteckt. Mission Control atmet durch. Das ist kein Datenabruf mehr. Das ist Decision Intelligence.
Der rote Faden durch diesen Artikel: Die Geschäftslogik existiert bereits – im semantischen Layer von SAP. Mosaic AI ist nicht der Ort, an dem man sie neu baut, sondern der Ort, an dem man sie governed, evaluierbar und agentisch zugänglich macht.
Neo4j Virtual Graph schliesst dabei die entscheidende Lücke: Es bringt das Beziehungs-Reasoning, das Geschäftslogik im Kern ausmacht, Zero-Copy auf die Daten, die ohnehin schon im governed Lakehouse liegen.
Das ist eine differenziertere These als «AI-Agenten für SAP» – und der konsequente nächste Schritt von Business Intelligence hin zu Decision Intelligence.
Ihre Datenstrategie ist individuell – Ihre Beratung sollte es auch sein.
Die Wahl zwischen diesen Methoden hängt von unzähligen Faktoren ab: Ihrer bestehenden Systemlandschaft, Ihren Unternehmenszielen und Ihrer Datenkultur. Eine Standardantwort gibt es nicht.
Lassen Sie uns unverbindlich darüber sprechen, welcher Weg für Sie der richtige ist.
Kontaktieren Sie uns für ein persönliches Gespräch.
Quellen
- Databricks, Agent Bricks (Data+AI Summit) automatisierter Agent-Builder mit synthetischen Daten und Benchmarks.
- Neo4j, Introducing Neo4j Virtual Graph: Graph reasoning on the data you already have (28.05.2026): https://neo4j.com/blog/graph-database/introducing-neo4j-virtual-graph-graph-reasoning-on-the-data-you-already-have/
- Mosaic AI Agent Framework Komponenten: Vector Search, MLflow Tracing, Unity Catalog Governance, MCP-Integration
