Agentic AI in Data und Analytics

Ein Chatbot beantwortet Fragen, ein Copilot macht Vorschläge, die ein Mensch übernimmt. Ein KI Agent geht den entscheidenden Schritt weiter. Er plant mehrstufige Aufgaben, wählt selbstständig Werkzeuge, führt sie im System aus und arbeitet, bis das Ziel erreicht ist. Möglich macht das ein offener Standard. Das Model Context Protocol (MCP) verbindet KI Assistenten mit laufenden Systemen, eine Art universeller Adapter für KI Werkzeuge, seit Ende 2025 herstellerübergreifend unter dem Dach der Linux Foundation weiterentwickelt. Data und Analytics ist dafür ein ideales Feld, denn hier gibt es strukturierte Metadaten, klare Schnittstellen und einen notorisch hohen Aufwand in Analyse, Entwicklung und Betrieb.

Was das konkret bedeutet, zeigt sich auf mehreren Ebenen. Anwender bekommen Zugang zu ihren Daten in natürlicher Sprache, die Unternehmensplanung lässt sich im Dialog steuern, und auch Entwicklung und Betrieb von Datenplattformen werden zunehmend agentisch. Wie weit das reicht, hängt davon ab, welche Strategie der Hersteller verfolgt und wie offen er Agenten an seine Systeme lässt. SAP geht hier einen anderen Weg als die reinen Datenplattformen. Es hängt zudem von den Modellen und der Umgebung ab, mit denen man arbeitet, und von einem Rahmen aus Sicherheit und Governance, der in produktiven Landschaften trägt. Vor allem aber entscheidet der Kontext, den ein Agent bekommt, und wie dieser Kontext organisiert wird. Denn über Erfolg oder Misserfolg entscheiden am Ende selten Modell und Werkzeuge.

Agentic AI in Data & Analytics ist kein einzelnes Feature, sondern ein Bündel von Fähigkeiten. Drei prägen die Praxis heute besonders.

Agentic Analytics - Mit den Daten sprechen

Statt einen Bericht vorzubereiten, stellt man eine Frage in natürlicher Sprache, etwa nach den fünf umsatzstärksten Produkten je Monat. Der Agent wählt aus den freigegebenen Datenquellen die passende, aggregiert und antwortet direkt, auch wenn dafür noch kein Bericht existiert. Diese reine Abfrage beherrschen heute alle großen Plattformen im Produktivbetrieb, in der SAP Analytics Cloud mit Just Ask und Joule, bei den Datenplattformen etwa mit Genie One bei Databricks oder CoWork bei Snowflake. Spannender ist die Stufe darüber, ganze Auswertungen und Dashboards per Prompt zu erzeugen. Dort gehen die Hersteller unterschiedlich weit, von einzelnen Berichtsseiten als Ausgangspunkt bis zu vollständigen Dashboards samt Import bestehender Berichte aus anderen Werkzeugen.

Agentic Business Planning - Die Planung im Dialog

Eng damit verbunden und für uns eine der spannendsten Fähigkeiten ist die agentische Planung. Gemeint ist, per Prompt mit einer Planung zu arbeiten, Annahmen ändern, Szenarien rechnen, Planwerte im Dialog eingeben, ohne sich durch Masken zu klicken. Einen Schritt weiter geht der Gedanke, schon die Planungsanwendung selbst per natürlicher Sprache zu entwerfen, statt sie klassisch zu modellieren.

SAP hat hier den tiefsten Kontext, denn Planung war seit den Tagen des BW Teil des Analytics Stacks und ist es in der SAP Analytics Cloud bis heute. Auf der Roadmap stehen mehrere spezialisierte Planungsagenten, die direkt mit den Planungsmodellen der SAP Analytics Cloud arbeiten, vom Conversational Planning Agent, der Planwerte per Prompt ändert, bis zum Model Creation Agent, der Planungsmodelle selbst aufbaut. Vieles davon ist heute noch Ankündigung. Die Datenplattformen haben in diesem Feld wenig zu bieten. Microsoft bringt mit Planning in Fabric eine vollwertige Planungsanwendung, agentisch gesteuert wird sie bislang nicht, Databricks und Snowflake haben keine native Planungslösung.

Damit bleibt SAPs Vorsprung in dieser Fähigkeit bestehen, auch wenn er heute noch zu einem großen Teil aus Ankündigung und Erprobung besteht. Und der Anspruch ist nicht unangefochten, spezialisierte Planungsanbieter setzen bereits auf die Integration großer Sprachmodelle.

Agentic Data Engineering - Datenplattformen entwickeln und betreiben

Die dritte Fähigkeit setzt dort an, wo bisher die IT entwickelt. Ein Agent analysiert bestehende Datenmodelle, erklärt gewachsene Logik in Klartext, legt neue Objekte und Datenflüsse an und beschleunigt Migrationen, alles im echten System und über dieselben Schnittstellen, die auch die nativen Entwicklungswerkzeuge nutzen. Bei den Datenplattformen ist das bereits Alltag, Databricks mit Genie Code und Snowflake mit CoCo liefern agentische Entwicklungsumgebungen, die Code planen, ausführen und Fehler beheben. Bei SAP ist Joule in SAP Datasphere angekommen, unterstützt dort aber bisher vor allem bei Suche und Katalogpflege. Eine agentische Entwicklung, bei der Joule selbst Modelle und Datenflüsse anlegt, gibt es noch nicht.

Alles davon spielt sich in der Cloud ab. Die vielen SAP Kunden, die ihr Data Warehouse weiterhin mit BW 7.5 on HANA oder BW/4HANA on premise betreiben, bleiben bei der agentischen Entwicklung bisher außen vor. Genau deshalb haben wir den BW Modeling MCP Server als Open Source Projekt entwickelt. Er verbindet KI Assistenten mit einem laufenden BW System, damit sie auch dort Datenmodelle analysieren, Objekte anlegen und Datenflüsse aufbauen können.

Und es bleibt nicht beim Bauen. Zunehmend rückt der agentische Betrieb in den Blick, Plattformen, die sich selbst optimieren, Pipelines, die Fehler erkennen und beheben, Ladeprozesse, die überwacht und nachgesteuert werden. Auf der Infrastrukturebene ist das bei den Datenplattformen bereits Realität. Eine Datenplattform, die sich komplett selbst verwaltet, gibt es noch nicht, aber die Richtung ist klar. Die Grenze liegt heute dort, wo ein Agent ohne Freigabe eines Menschen in produktive Objekte eingreifen würde, und genau diese Freigabe ist bei den heutigen Werkzeugen noch bewusst eingebaut.

SAP denkt Analytics und Planung vom ERP her. Das liefert Agenten tiefen Prozesskontext frei Haus, denn die Geschäftssemantik steckt bereits in den Modellen der Suite, und es erklärt den Vorsprung bei der Planung. Gleichzeitig möchte SAP die agentische Umgebung selbst besetzen. Joule soll der Ort werden, an dem auf SAP Daten gearbeitet wird. Dazu passt, dass SAP für SAP BW/4HANA, SAP Datasphere, SAP Business Data Cloud und SAP Analytics Cloud keinen eigenen MCP Server bereitstellt. Wer aus einer anderen agentischen Umgebung heraus mit diesen Systemen arbeiten will, ist auf quelloffene Server aus der Community angewiesen, die vorhandene und teils undokumentierte Schnittstellen nutzen, mit allem, was das für Support und Governance bedeutet.

Die Datenplattformen Microsoft Fabric, Databricks und Snowflake denken von den Daten her. Sie sind bei der agentischen Entwicklung weiter, und sie liefern offizielle MCP Server als Teil des Produkts, dokumentiert, unterstützt und über die Berechtigungen der Plattform abgesichert. Jede MCP fähige Umgebung kann sich verbinden, und die semantische Schicht der Plattform wandert dabei mit. Dafür fehlt ihnen der Prozesskontext des ERP, und Planung ist bei ihnen kein Thema.

Für einen IT Leiter mit hybrider Landschaft folgt daraus etwas Beruhigendes. Er muss sich nicht für eine Welt entscheiden. Joule ist eine Option, nicht die einzige, und die offene Anbindung, die bei den Datenplattformen mitgeliefert wird, gibt es für SAP Systeme aus der Community, auch von uns. Weil alle Anbieter auf denselben offenen Standard setzen, ist die Wahl der Plattform kein unumkehrbares Bekenntnis mehr. Was über Plattformen hinweg trägt, ist die Arbeitsweise.

Über den Plattformen liegt eine zweite Ebene, die Modelle und die agentische Umgebung, mit der die Agenten gesteuert werden. Modell, Umgebung und Plattform sind heute drei unabhängige Entscheidungen, die sich über offene Standards frei kombinieren lassen. Manche Umgebungen sind an einen Modellanbieter gebunden, etwa Claude Code oder OpenAI Codex, andere an eine Plattform, wie Joule bei SAP, Genie One bei Databricks, CoWork bei Snowflake oder Microsoft 365 Copilot. Wieder andere sind modellagnostisch wie Cursor oder OpenCode. Die Liste wächst ständig, entscheidend ist, ob eine Umgebung offene Standards wie MCP und Skills unterstützt.

Auch die offenen Modelle haben aufgeholt. Führende Open Weights Modelle liegen heute nah an den proprietären Spitzenmodellen und lassen sich mit veröffentlichten Gewichten selbst betreiben. In der Praxis fällt die Wahl ohnehin selten auf ein einziges Modell, agentische Systeme verteilen Aufgaben auf mehrere und nutzen je nach Anspruch und Kosten das passende.

Bei der Umgebung stellt sich eine echte Frage, denn jeder Hersteller bietet eine eigene an und argumentiert gleich. Der eigene Agent kenne den Kontext der Plattform ohne Konfiguration, ein fremder über MCP dagegen nicht. Der Einwand hat einen wahren Kern, ein Agent, der über MCP nur SQL gegen Rohtabellen absetzt, liefert schlechte Ergebnisse, egal wo er läuft. Er trifft aber nicht den offenen Weg als solchen, weil die MCP Server der Hersteller die semantische Schicht mitführen, sofern man ihre semantischen Werkzeuge nutzt. Was eine gebundene Umgebung dagegen nicht liefern kann, ist der Kontext jenseits der eigenen Plattform, und in heterogenen Landschaften endet sie an jeder Systemgrenze. Welche Umgebung zum Einsatz kommt, bestimmt damit mit, was ein Agent darf und welche Systeme er erreicht.

Ein Agent, dem man bei jeder Aufgabe neu erklären muss, was eine Tabelle bedeutet, wie eine Kennzahl gerechnet wird und wie zwei Entitäten zusammenhängen, liefert schwankende Ergebnisse. Ein Agent ist auf vorhandene Struktur angewiesen, er kann sie sich nicht selbst schaffen. Gartner erwartet, dass universelle semantische Schichten bis 2030 als kritische Infrastruktur gelten werden, gleichrangig mit Datenplattformen und Cybersicherheit, und prognostiziert, dass Organisationen, die Semantik in KI fähigen Daten priorisieren, die Genauigkeit ihrer agentischen KI bis 2027 um bis zu 80 Prozent steigern können.*

Den ersten Teil dieses Kontexts liefern die Plattformen selbst. Ihre semantische Schicht beschreibt Entitäten, Beziehungen, Metriken, Synonyme und die Berechtigungen darauf, bei SAP im Knowledge Graph und den Datenprodukten der Business Data Cloud, bei Microsoft in Fabric IQ und dem Power BI Semantikmodell, bei Databricks in der Genie Ontology, bei Snowflake in den Semantic Views. Alle vier stellen diese Schicht ins Zentrum ihrer Strategie, und alle vier arbeiten daran, Teile davon aus vorhandenen Dashboards, Abfragen und der Nutzung abzuleiten, statt sie nur zu modellieren. Für einen Agenten bedeutet das, er weiß, was Umsatz heißt, wie das Geschäftsjahr geschnitten ist und was er sehen darf. Über MCP bekommt ein externer Agent denselben Kontext wie die Hausumgebung.

Zwei Dinge kann diese Schicht aber nicht leisten. Sie kennt nur ihre eigene Plattform, und sie kennt nur das, was sich aus Daten und Metadaten ableiten lässt. Der zweite Teil des Kontexts steht in keinem System. Organisatorische Zuständigkeiten, Regelwerke, Namenskonventionen, das Wissen aus laufenden Projekten, neue Anforderungen aus dem Fachbereich, die eigene Strategie und die Gründe hinter gewachsenen Entscheidungen und der Zusammenhang zwischen Systemen, die nichts voneinander wissen. In einer typischen Landschaft liegen die Daten zum Beispiel im BW oder in der Datasphere, die Anforderungen im Jira, die Konventionen im Wiki und das Prozesswissen in den Köpfen des Fachbereichs. Ohne diesen Teil ist ein Agent gefährlich gut. Er liefert Ergebnisse, die sauber aussehen, technisch korrekt sind und trotzdem an der Landschaft vorbeigehen, die Spalte, die anders heißt als alle Nachbarn, das Modell, das niemand so gebaut hätte, der das Projekt kennt. Jede dieser Änderungen wirkt für sich vernünftig. Zusammen entsteht daraus Inkonsistenz in einem Tempo, das kein Team von Menschen je erreicht hätte.

Context Engineering ist die Disziplin, die genau diesen Kontext organisiert und dauerhaft verfügbar macht. Wenn Prompt Engineering das Formulieren eines einzelnen Briefes ist, dann ist Context Engineering das Einrichten eines ganzen Büros. In der Praxis entsteht ein versioniertes Wissensrepository je Kontextbereich, das Menschen und Agenten gleichermaßen bedient. Markdown im Git, klar strukturiert, mit Regeln für die Agenten, einer Kennzeichnung, welches Wissen verifiziert ist und welches nicht, und mit der Orchestrierung der MCP Server, die dem Agenten die Systeme samt ihrer semantischen Schicht erschließen. Dieses Muster hat sich niemand allein ausgedacht. Mehrere Stränge laufen darauf zu, vom persönlichen Wissensmanagement über das von einem Sprachmodell gepflegte Wiki bis zu Googles Open Knowledge Format, das seit Juni 2026 als offene Spezifikation Markdown mit strukturierten Metadaten genau dafür vorschlägt. Ein solches Repository sauber aufzusetzen, klar geschnitten, verlässlich gepflegt und mit den richtigen Regeln für die Agenten, ist die eigentliche Kunst. Genau diese Erfahrung bringen wir aus unseren Projekten mit, herstellerunabhängig und auf allen Plattformen.

Wer Agenten in produktive Datenlandschaften lässt, braucht klare Leitplanken, und die lassen sich sauber ziehen. Richtig aufgesetzt, arbeitet ein Agent mit genau den Rechten des angemeldeten Nutzers, was der Mensch nicht darf, darf auch die KI nicht. Lesende Zugriffe kann man freigeben, schreibende an eine bewusste Bestätigung binden und produktive Systeme strikt lesend halten. Wird die Anbindung zentral betrieben statt lokal je Anwender, kommen zentrale Rechtevergabe, Identitätsdurchgriff und durchgängige Protokollierung hinzu. Governance ist dabei nicht die Bremse, sondern die Voraussetzung dafür, überhaupt delegieren zu können, denn nur eine Aufgabe, die man prüfen, eingrenzen und rückgängig machen kann, gibt man aus der Hand.

Davon zu trennen ist der Datenschutz. Die Anbindung bestimmt, welche Daten überhaupt an die KI gehen, ob nur Metadaten und Strukturen oder echte, womöglich personenbezogene Inhalte. Modell und Lizenz bestimmen, was mit diesen Daten geschieht, ob darauf trainiert wird, in welcher Region und unter welcher Auftragsverarbeitung. Eine Unternehmenslizenz schließt das Training auf Ihren Daten in der Regel aus und lässt sich auf Server in der EU begrenzen, und weil leistungsfähige offene Modelle heute lokal laufen, ist auch der vollständig eigene Betrieb möglich. Gerade in regulierten Branchen ist dieses Zusammenspiel entscheidend, und der EU AI Act verlangt dort für Anwendungen mit hohem Risiko ohnehin nachweisbare menschliche Aufsicht und Protokollierung.

Hier finden Sie einige der häufig gestellten Fragen zur Agentic AI in Data & Analytics

Was bedeutet Agentic AI in Data & Analytics? Agentic AI in Data & Analytics beschreibt KI-Agenten, die nicht nur Antworten oder Vorschläge liefern, sondern mehrstufige Aufgaben planen, Werkzeuge auswählen und Aktionen direkt in Daten- und Analytics-Systemen ausführen. Über Standards wie das Model Context Protocol können solche Agenten auf Datenplattformen, Metadaten, semantische Modelle und Systemfunktionen zugreifen.

Welche Einsatzbereiche hat Agentic AI in Data & Analytics? Die wichtigsten Einsatzbereiche sind heute Agentic Analytics, Agentic Business Planning und Agentic Data Engineering. Agenten können Daten in natürlicher Sprache analysieren, Planungsprozesse dialogorientiert unterstützen und Datenmodelle, Datenflüsse und Plattformobjekte entwickeln oder betreiben. Der Reifegrad unterscheidet sich dabei je nach Plattform und Hersteller.

Was ist Agentic Analytics? Agentic Analytics ermöglicht es Anwendern, Fragen in natürlicher Sprache an ihre Daten zu stellen. Der Agent wählt eine passende freigegebene Datenquelle, führt Aggregationen oder Analysen aus und liefert das Ergebnis direkt zurück, auch wenn dafür noch kein fertiger Bericht existiert. Je nach Plattform können Agenten außerdem Berichtsseiten oder Dashboards erzeugen.

Welche Rolle spielt MCP bei Agentic AI in Datenplattformen? Das Model Context Protocol, kurz MCP, ist ein offener Standard zur Verbindung von KI-Assistenten mit externen Systemen und Werkzeugen. In Data-&-Analytics-Szenarien ermöglicht MCP einem Agenten den Zugriff auf Funktionen einer Datenplattform, beispielsweise Abfragen, Metadaten oder Entwicklungswerkzeuge. Wie viel Kontext ein Agent dabei erhält, hängt jedoch von der jeweiligen MCP-Implementierung und der semantischen Schicht der Plattform ab.

Warum ist eine semantische Schicht für Agentic Analytics wichtig? Eine semantische Schicht liefert einem Agenten die fachliche Bedeutung von Daten. Sie beschreibt beispielsweise Entitäten, Beziehungen, Kennzahlen, Synonyme und Berechtigungen. Dadurch kann der Agent verstehen, was Begriffe wie Umsatz oder Geschäftsjahr bedeuten und wie Daten korrekt miteinander zusammenhängen. Ohne konsistente Semantik können technisch korrekte Abfragen trotzdem fachlich falsche Ergebnisse liefern.

Was ist Context Engineering und warum ist es für KI-Agenten wichtig? Context Engineering bezeichnet den systematischen Aufbau und die Pflege des Wissens, das ein KI-Agent für verlässliche Entscheidungen benötigt. Dazu gehören neben Datenmodellen auch Regeln, Namenskonventionen, Projektwissen, Verantwortlichkeiten, Anforderungen und systemübergreifende Zusammenhänge. In der Praxis kann dieser Kontext in einem versionierten Wissensrepository organisiert und mit den MCP-Servern der angebundenen Systeme kombiniert werden.

Möchten Sie mehr über Agentic AI erfahren?

In unserem Blog finden Sie weitere interessante Artikel zu diesem Thema

Agentic AI im Data Engineering: Warum Architektur entscheidend ist

In einem früheren Artikel haben wir gezeigt, wie wir in Databricks einen KI-Agenten entwickelten,...

Lesen Sie den Artikel

Agentic AI im Data Engineering: Warum Architektur entscheidend ist

Agentic AI in der Praxis: MCP-Server für SAP BW/4HANA

Im April hatten ich hier den bw-modeling-mcp vorgestellt, einen Open-Source-MCP-Server, der...

Lesen Sie den Artikel

Agentic AI in der Praxis: MCP-Server für SAP BW/4HANA

Agentic AI meets SAP BW

Ich sitze vor der UI und starre auf den Bildschirm: „Aktivierung läuft… Editor nicht änderbar." Man...

Lesen Sie den Artikel

Agentic AI in Data & Analytics

Wie KI-Agenten die Arbeit in Datenplattformen verändern

Präsentation: Agentische Entwicklung mit SAP BW

Präsentation herunterladen: Agentic AI mit SAP BW

Was KI-Agenten in Datenplattformen heute leisten

Agentic Analytics - Mit den Daten sprechen

Agentic Business Planning - Die Planung im Dialog

Agentic Data Engineering - Datenplattformen entwickeln und betreiben

SAP und die Datenplattformen, zwei Welten

Modell und Umgebung: womit man die Agenten steuert

Kontext - worauf es wirklich ankommt

Sicherheit, Governance und Grenzen

Unterhalten Sie sich mit unserem Experten!

Möchten Sie wissen, was Agentic AI für Ihre Datenplattform konkret bedeutet?

FAQ - Agentic AI in Data & Analytics

Möchten Sie mehr über Agentic AI erfahren?

In unserem Blog finden Sie weitere interessante Artikel zu diesem Thema

Agentic AI im Data Engineering: Warum Architektur entscheidend ist

Agentic AI in der Praxis: MCP-Server für SAP BW/4HANA

Agentic AI meets SAP BW

Inhaltsverzeichnis

Inhaltsverzeichnis

Agentic AI in Data & Analytics

Wie KI-Agenten die Arbeit in Datenplattformen verändern

Präsentation: Agentische Entwicklung mit SAP BW

Präsentation herunterladen: Agentic AI mit SAP BW

Was KI-Agenten in Datenplattformen heute leisten

Agentic Analytics - Mit den Daten sprechen

Agentic Business Planning - Die Planung im Dialog

Agentic Data Engineering - Datenplattformen entwickeln und betreiben

SAP und die Datenplattformen, zwei Welten

Modell und Umgebung: womit man die Agenten steuert

Kontext - worauf es wirklich ankommt

Sicherheit, Governance und Grenzen

Unterhalten Sie sich mit unserem Experten!

Möchten Sie wissen, was Agentic AI für Ihre Datenplattform konkret bedeutet?

FAQ - Agentic AI in Data & Analytics

Möchten Sie mehr über Agentic AI erfahren?

In unserem Blog finden Sie weitere interessante Artikel zu diesem Thema

Agentic AI im Data Engineering: Warum Architektur entscheidend ist

Agentic AI in der Praxis: MCP-Server für SAP BW/4HANA

Agentic AI meets SAP BW

Inhaltsverzeichnis

Inhaltsverzeichnis

Weiteres

Blogartikel

Weiteres

Blogartikel