Databricks Genie Agents: Agentic BI und Governance im Semantik-Layer
Die Kernaussagen auf einen Blick.
- Genie Agents zerlegen eine mehrstufige Geschäftsfrage selbstständig in Teilschritte. Reines Text-to-SQL übersetzt jede Frage nur einmal in eine SQL-Abfrage. Der Unterschied entscheidet, ob Self-Service-BI bei zusammengesetzten Fragen trägt oder bei der ersten echten Frage abreißt.
- Die Antwortqualität hängt am geteilten Semantik-Layer (One Genie Ontology), nicht am Agenten-Feature selbst. Ohne kuratierte Kennzahlen erzeugt der Agent nur überzeugendere falsche Antworten.
- Drei Fragen müssen vor dem Rollout beantwortet sein: Wer besitzt den Semantik-Layer, wie wird er versioniert, und wo endet Self-Service an der Zugriffs- und Vertrauensgrenze?
- Empfehlenswert ist, den Semantik-Layer als gepflegtes Datenprodukt mit klarem Owner aufzubauen, bevor agentic Self-Service unternehmensweit freigegeben wird.
Inhaltsverzeichnis
Ohne Semantik-Layer scheitert Self-Service-BI
Im Steering fragt jemand nach dem Deckungsbeitrag in Region Nord. Die eine Person zieht ihn aus dem Self-Service-Tool, die zweite aus einem alten Export, die dritte aus dem Finance-Dashboard. Drei Zahlen, drei Wahrheiten. Die nächsten zwanzig Minuten gehen für die Frage drauf, welche Zahl überhaupt stimmt. Über die Entscheidung dahinter redet niemand mehr.
Das Bild wiederholt sich, sobald mehrere Teams dieselbe Plattform nutzen, aber jeder seine eigene Kennzahlenlogik mitbringt. Self-Service-BI über natürliche Sprache, oft als Conversational Analytics vermarktet, verschärft das oft: Jede Frage wird frisch übersetzt, jeder Filter neu geraten, und niemand traut den generierten Antworten genug, um darauf zu entscheiden. Genau in diese Lücke positioniert Databricks mit One Genie Ontology und Genie Agents einen neuen Layer, der mehrstufige Fragen autonom zerlegt.
Damit verschiebt sich die Frage. Ob die Maschine eine Frage in SQL übersetzen kann, ist geklärt: Das kann sie. Die offene Frage ist, woher sie weiß, was „Deckungsbeitrag" in eurem Unternehmen bedeutet, und wer dafür verantwortlich ist, dass diese Definition stimmt und gepflegt bleibt. Genie Agents verschieben die Qualität von Self-Service-Analytics von der Frage-Formulierung in die Pflege eines geteilten Semantik-Layers. Dieser Layer wird zum Governance-Objekt mit eigenem Lebenszyklus.
Was sind Genie Agents?
Reines Text-to-SQL folgt einem linearen Modell: eine Frage, eine Übersetzung, eine Abfrage, ein Ergebnis. Bei eindeutigen Fragen funktioniert das. Bei mehrdeutigen rät das System oder erfindet plausibel klingende Antworten. Ein Genie Agent ersetzt dieses lineare Modell durch eine zusammengesetzte Architektur, die eine Frage über mehrere Modelle, Abruf-Mechaniken und angebundene Werkzeuge verteilt. Databricks beschreibt Genie als zusammengesetztes KI-System, in dem mehrere Modelle, Abruf- und Prüf-Komponenten zusammenwirken.
Damit fällt auch die Frage, was Genie eigentlich ist: Wer wissen will, was KI-Agenten von einem klassischen Chat-Assistenten unterscheidet, findet hier ein konkretes Beispiel. Ein KI-Agent plant, handelt und prüft selbst; ein klassischer Chat-Assistent übersetzt nur eine Eingabe in eine Ausgabe. Der Unterschied wird im sogenannten Agent-Modus greifbar. Der Agent arbeitet wie ein Analyst: Er plant ein Vorgehen, bildet Hypothesen und nähert sich der Antwort über mehrere Schritte. Databricks zeigt diesen Modus an einem Beispiel, bei dem der Agent einen Anstieg erst bestätigt und dann die Treiber prüft. Dabei argumentiert der Agent auch über unstrukturierte Inhalte wie Dokumente oder Tickets und löst über das Model Context Protocol Aktionen in angebundenen Systemen aus.
Der Wert für die Plattform-Entscheidung liegt in der Schicht unter dem Agenten. Ein mehrstufiger Agent auf einem unsauberen Datenmodell produziert die falschen Antworten nur schneller und überzeugender. Die Genie Agents wurden am 16. Juni 2026 auf dem Data + AI Summit allgemein verfügbar; die Basis-Funktion Genie ist seit Juni 2025 verfügbar.
Zwei Punkte gehören für die Bewertung dazu. Der Agent-Modus in den Genie Spaces läuft als Public Preview: Ein Workspace-Admin muss ihn über die Previews-Seite freischalten, von allein ist er nicht aktiv, und er lässt sich aktuell nur über die Oberfläche nutzen. Eine API-Anbindung fehlt bislang. Angetrieben wird der Modus laut Databricks von Sonnet-Modellen, wobei Genie als gemanagter Dienst die Modelle laufend gegeneinander bewertet und das jeweils genaueste auswählt.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Der Semantik-Layer als Governance-Objekt
Diese Schicht heißt One Genie Ontology. Sie ist ein automatischer, sich selbst verbessernder Kontext-Layer, der aus Abfragen, Pipelines, Dashboards und angebundenen Anwendungen einen Wissensgraphen aufbaut: ein lebendes Modell davon, wie das Unternehmen arbeitet und was die Daten tatsächlich bedeuten. Databricks beschreibt die Ontology als lebenden Kontext-Graphen aus Metrik-Definitionen, Geschäftsbegriffen und den Beziehungen zwischen Kennzahlen, Tabellen und Teams.
Spannend für die Steuerung ist die Frage, woher der Layer weiß, welcher Definition er vertrauen soll, wenn es mehrere gibt. Die Ontology nutzt dafür einen Mechanismus ähnlich dem PageRank-Algorithmus: Sie gewichtet, woher eine Definition stammt, wie hoch die Autorität der Quelle ist, wie oft sich Menschen darauf verlassen und wie aktuell sie ist. Der Agent rät also nicht, was „aktiver Kunde" heißt. Er ruft die gewichtete Definition ab.
Diese Ontology sitzt auf den Unity Catalog Business Semantics auf, dem formalisierten, offenen Teil mit den zertifizierten Definitionen von Kennzahlen, Dimensionen und Beziehungen. Databricks beschreibt die Unity Catalog Business Semantics als eine vertrauenswürdige Quelle für zertifizierte Kennzahlen, organisiert nach Geschäftsdomänen und auf den bestehenden Governance-Regeln aufgebaut. Damit wird der Semantik-Layer zum eigentlichen Governance-Objekt. Sein Owner hält die Definitionshoheit über die Zahlen, auf die das Management entscheidet. (Pflegemodell und Rollen für diesen Layer behandeln wir im Überblick zur Genie Ontology.) Bleibt der Layer ungepflegt, richtet sich diese Definitionshoheit faktisch nach der am häufigsten genutzten Quelle. Ob diese Quelle die korrekte ist, prüft dann niemand mehr.
Wie bearbeiten Genie Agents Geschäftsfragen?
Der Unterschied zu Text-to-SQL wird an einer realen Frage am deutlichsten. Nehmen wir die Frage aus dem Steering: „Warum ist der Deckungsbeitrag in Region Nord im letzten Quartal gefallen?" Reines Text-to-SQL würde versuchen, daraus eine einzige Abfrage zu bauen, und an „warum" scheitern. Ein Agent zerlegt die Frage über mehrere Schritte, die Databricks als Chain-of-Thought-Verarbeitung in klare Teilschritte beschreibt. Drei Phasen laufen dabei durch, jede davon gegen denselben Semantik-Layer geprüft.
Planung und Hypothesen
Der Agent identifiziert zuerst die relevanten Tabellen, Metadaten und Definitionen aus dem Semantik-Layer. Dann bildet er Hypothesen: Ist der Umsatz gesunken, sind die Kosten gestiegen, hat sich der Produktmix verschoben, oder steckt ein Saison-Effekt dahinter?
Teilabfragen und Zwischenergebnisse
Für jede Hypothese schreibt und führt der Agent eine Abfrage aus und prüft das Zwischenergebnis. Liefert eine Abfrage einen Hinweis auf einen tieferen Trend, passt der Agent seinen Plan an und untersucht weiter. Databricks beschreibt diesen Zyklus aus Hypothese, Abfrage und Reflexion bis zu einer belegten Erklärung.
Synthese
Der Agent fasst die Zwischenergebnisse zu einem fertigen Ergebnis zusammen: ein Diagramm, die nachvollziehbaren Denkschritte mit dem geprüften SQL und eine Zusammenfassung in Klartext. Databricks dokumentiert dafür eine Abschnittsstruktur aus Analyse, Denkschritten, Ergebnis-Tabelle und automatischer Klartext-Zusammenfassung, an der sich die Logik prüfen lässt.
Jeder dieser Schritte greift auf dieselben Definitionen im Semantik-Layer zu. Stimmt die Definition von „Deckungsbeitrag" dort nicht, sind alle drei Teilschritte konsistent falsch. Die mehrstufige Logik erhöht damit das Gewicht des Layers.
Wer pflegt den Semantik-Layer?
Die Governance der Zugriffe übernimmt die Plattform automatisch. Die Pflege der Inhalte bleibt beim Unternehmen. Die Kuratierung des Genie Space, also die Auswahl der Tabellen, Definitionen und geprüften Beispiele, gehört den Fachverantwortlichen und Analysten der jeweiligen Domäne. Sie läuft als fortlaufende Schleife über die gesamte Betriebszeit des Space. Eine Praktiker-Diskussion bringt es nüchtern auf den Punkt: Genie verlässlich zu machen ist vor allem Kuratierungsarbeit.
Am meisten bewirken geprüfte Beispiel-Abfragen: Eine real gestellte Frage mit der korrekten, verifizierten Abfrage zu paaren sorgt dafür, dass die Maschine diese Abfrage für ähnliche Fragen wiederverwendet und sie nicht jedes Mal neu generiert.
Pro Genie Space dokumentiert Databricks maximal 100 Anweisungen und 200 Wissensspeicher-Einträge. Zu viel unstrukturierter Kontext führt dazu, dass relevante Inhalte abgeschnitten werden und die Antwortqualität sinkt.
Der zweite typische Fehler ist fehlendes Entity-Matching: Schreibt jemand „Florida" und liegt in den Daten nur das Kürzel „FL", scheitert der Filter still.
Aus all dem folgt eine Ownership-Frage, die vor dem Rollout beantwortet sein muss. Ein Semantik-Layer ohne benannte verantwortliche Person verfällt wie jeder Genie Space: Neue Tabellen, geänderte Kennzahlen und neue Begriffe werden nicht nachgezogen, und die Antwortqualität sinkt schleichend. Wie ein solcher Space dauerhaft betrieben und mit einer Eval-Schleife stabil gehalten wird, zeigen wir im Überblick zu Databricks Genie als kuratiertem Datenprodukt.
Was Self-Service-BI nicht löst
Self-Service klingt nach Demokratisierung ohne Grenze. Drei Grenzen sind hart und gehören in jede Bewertung.
Datenzugriff endet an der Berechtigung
Genie kann die Zugriffsrechte aus Unity Catalog nicht umgehen. Der Agent erbt automatisch die bestehenden Berechtigungen auf Spalten- und Zeilenebene sowie die Identitätskontrollen, durchgesetzt über Unity Catalog und das Unity AI Gateway. Self-Service endet damit hart an der Berechtigungsgrenze des jeweiligen Nutzers.
Vertrauen endet an der Mehrdeutigkeit
Eine selbstbewusst formulierte falsche Antwort richtet in einer Management-Entscheidung mehr Schaden an als eine kurze Rückfrage. Genie ist darauf ausgelegt, bei mehrdeutigen Fragen zuerst nachzufragen; das muss man aber bewusst konfigurieren, von allein stellt es sich nicht ein.
Regulierte Kennzahlen gehören aus der KI-Logik heraus
Für nicht verhandelbare Größen aus Compliance, Steuer oder Finanzwesen definieren Teams rigide SQL-Funktionen oder parametrisierte Metric Views. Genie kann diese Logik weder einsehen noch verändern und kennzeichnet das Ergebnis mit einem „Trusted”-Hinweis.
Genie Agents, Unity Catalog und Business Semantics im BI-Stack
Genie Agents stehen auf einer Governance-Schicht, die die übrige BI-Strecke ebenfalls trägt. Unity Catalog legt fest, welche Daten ein Nutzer sehen darf, hält die Herkunft (Lineage) fest und protokolliert die ausgeführten Abfragen. Dieselbe Berechtigungslogik gilt für Dashboards, für SQL-Abfragen und für Genie. Wie Unity Catalog als gemeinsame Governance-Schicht und die zertifizierten Geschäftssemantiken die Antworten konsistent halten, führen wir im Überblick zu Unity Catalog Business Semantics aus.
Genie Agents sind außerdem nur ein Teil der breiteren Genie-Familie, und die Abgrenzung steuert die Erwartung: Genie One ist der Coworker für Fach- und Endnutzer in Slack, Teams und mobilen Apps; Genie Code ist der autonome Partner für Data Engineering und Data Science, der Lakeflow-Pipelines baut und Fehler debuggt und am 11. März 2026 allgemein verfügbar wurde. Wie die Komponenten von Genie One, Agents, Ontology, Code und ZeroOps zusammen die Brand-Klammer bilden, sortieren wir im Überblick zu One Genie. Für die Self-Service-Frage zählt der agentic Analyse-Modus auf dem geteilten Semantik-Layer. Wie der Betriebs-Aspekt von Genie und die automatische Überwachung von Daten- und KI-Assets zusammenspielen, klären wir im Überblick zu Genie ZeroOps. Die Einordnung des gesamten BI-Stacks zeigen wir im Überblick zu Business Intelligence auf Databricks, eingebettet in die Plattform-Strecke des Databricks-Hubs.
Text-to-SQL vs Genie Agents mit One Genie Ontology
Die Unterschiede lassen sich entlang der entscheidungsrelevanten Achsen gegenüberstellen.
| Dimension | Reines Text-to-SQL | Genie Agents mit One Genie Ontology |
|---|---|---|
| Fragetyp | eine Frage, eine Abfrage | mehrstufige Frage, autonom zerlegt |
| Semantik-Quelle | pro Frage neu übersetzt | geteilter, gewichteter Semantik-Layer |
| Konsistenz | je Fragesteller unterschiedlich | gegen zertifizierte Definitionen geprüft |
| Pflege-Ownership | implizit, oft niemand | benannte Domänen-Verantwortung, Eval-Schleife |
| Governance-Bedarf | Zugriff pro Abfrage | Zugriff plus Semantik-Layer als Artefakt |
| Grenze | rät bei Mehrdeutigkeit | fragt nach, festgeschriebene KPIs als UDF |
Grenzen von Genie Agents und agentic BI
Ein Agentic BI Layer schafft schnell den Eindruck, Self-Service sei jetzt wartungsfrei. Für belastbaren produktiven Betrieb reicht diese Sicht nicht aus.
Der Layer verschiebt die Pflege, er entfernt sie nicht
Die Kuratierung wandert von der einzelnen Frage in den Semantik-Layer und wird dadurch zentraler und sichtbarer, aber nicht kleiner. Ohne benannten Owner und ohne Versionierung produziert agentic BI bei steigender Nutzung konsistent falsche Antworten, nur schneller.
Mehrstufige Logik verstärkt Datenmodell-Fehler
Ein Agent, der über mehrere Schritte argumentiert, trägt einen Fehler in der Definition durch alle Teilschritte. Was bei einer Einzelabfrage ein falscher Wert ist, wird hier eine falsche, aber schlüssig wirkende Gesamterklärung.
Die Limits pro Space zwingen zur Auswahl
100 Anweisungen und 200 Wissensspeicher-Einträge pro Space sind schnell erreicht. Über der Grenze wird Kontext abgeschnitten und die Antwortqualität sinkt unbemerkt. In den Space gehört nur, was die häufigsten Fragen wirklich braucht.
Die Kosten verlagern sich in die laufende Nutzung
Ab dem 6. Juli 2026 wird Genie-Nutzung jenseits eines Freikontingents von 150 DBU pro Nutzer und Monat nutzungsabhängig in DBUs abgerechnet. Mehrstufige Agenten führen mehr Abfragen aus als eine einzelne Übersetzung; das gehört in die Kostenrechnung.
Trotz dieser Grenzen trägt der Ansatz, wenn die Reihenfolge stimmt. Der geteilte Semantik-Layer löst genau das Problem, an dem reines Text-to-SQL scheitert: die widersprüchlichen Zahlen je nach Fragesteller. Der Pfad zur Skalierung beginnt dabei beim Layer und erst danach beim Agenten. Wer die Definitionen, Berechtigungen und die Pflege-Verantwortung vorher klärt, bekommt schnellere und konsistente Antworten; ohne diese Klärung bekommt man vor allem schnellere Konflikte.
Fazit
Genie Agents tragen erst, wenn Datenmodell und Governance bereits stehen und die letzte Reibung zwischen Frage und verlässlicher Antwort ausgeräumt werden soll.
Besonders relevant ist das dort, wo mehrere Teams auf derselben Plattform arbeiten, heute aber je nach Fragesteller unterschiedliche Zahlen herausbekommen.
Gute Kandidaten sind erkennbar: mehrere Versionen derselben Kennzahl im Umlauf, Standard-Reportanfragen, die das BI-Team binden, und ein Lakehouse mit gepflegtem Unity Catalog, dem aber eine verbindliche Kennzahlenlogik fehlt. Wo dagegen noch über Tabellenbeziehungen, Berechtigungen und KPI-Definitionen gestritten wird, gehört agentic BI nicht als nächstes Projekt aufgesetzt. Die eigentliche Baustelle liegt dann im Semantik-Layer darunter.
Empfehlenswert ist diese Reihenfolge: Den Semantik-Layer als gepflegtes Datenprodukt mit benanntem Owner und Versionierung aufsetzen, bevor agentic Self-Service breit verfügbar wird. Zuerst klären, wo Self-Service an der Zugriffs- und Vertrauensgrenze endet, und die regulierten Kennzahlen als geprüfte Funktionen festschreiben. Daran zeigt sich schnell, ob der Layer trägt.
Das Ziel ist nicht ein weiterer Chat auf der Datenbank. Das Ziel ist eine Definition pro Kennzahl, der das Management vertraut, und ein Owner, der sie pflegt.
FAQ
Genie Agents sind domänenspezifische KI-Agenten auf der Databricks-Plattform, die eine mehrstufige Geschäftsfrage selbstständig in Teilschritte zerlegen. Statt eine Frage einmalig in SQL zu übersetzen, planen sie ein Vorgehen, prüfen Hypothesen über mehrere Abfragen und fassen das Ergebnis als Diagramm, geprüftes SQL und Klartext zusammen. Sie wurden im Juni 2026 allgemein verfügbar.
