Databricks Genie ZeroOps: Semantik-Layer gezielt pflegen
Die Kernaussagen auf einen Blick.
- Genie ZeroOps ist ein autonomer Hintergrund-Agent in Databricks, der Pipelines, Jobs, Tabellen und ML-Modelle überwacht, Ursachen analysiert und Korrekturen vorschlägt.
- Der Agent senkt den Aufwand pro Betriebsvorfall, übernimmt aber keine Freigabe und keine Pflege des fachlichen Datenmodells.
- Vor der Aktivierung sind drei Dinge zu klären: welche Assets überwacht werden, wer Fixes freigibt und wo der Genie-Space-Pflege weiterhin ein Mensch zugewiesen ist.
- Mein Vorschlag: ZeroOps als Vorfall-Entlastung mit Freigabe-Gate planen und die gewonnenen Stunden in die Begriffs- und Modellpflege umlenken.
Inhaltsverzeichnis
ZeroOps heißt nicht null Aufwand
Ein Plattform-Team betreibt fünf Genie Spaces über Vertrieb, Finance und Operations. Die Dashboards laufen, die Fachbereiche fragen ihre Daten in natürlicher Sprache ab, und das Onboarding war ein Erfolg. Sechs Monate später kommt eine Beschwerde aus dem Controlling: Eine Kennzahl im Vertriebs-Space stimmt seit Wochen nicht. Niemand hatte es gemerkt. Die Abfrage lief technisch sauber, gab eine plausible Zahl zurück, und die Zahl war falsch, weil eine Quelltabelle drei Stufen weiter oben das Währungsformat geändert hatte.
Das Bild wiederholt sich, sobald mehr als ein oder zwei Spaces im Betrieb sind. Der Aufbau ist ein Projekt mit klarem Ende. Der Betrieb ist ein Dauerposten ohne festen Owner: Begriffe nachschärfen, falsch beantwortete Fragen einarbeiten, Quelldaten im Blick behalten, auf stille Fehler reagieren, bevor ein Fachbereich sie findet. Databricks beschreibt genau diesen Druck als Ausgangspunkt: Datenteams verbringen den Großteil ihrer Zeit mit Wartung statt mit Aufbau, und der Anteil wächst, je schneller neue Pipelines und Modelle entstehen.
Wie viel von dieser Last lässt sich an eine Automatik abgeben, ohne die Kontrolle über das Datenprodukt zu verlieren?
Die Fragen, die in dieser Lage auf den Tisch kommen, sind operativ, nicht akademisch:
Wer pflegt die Spaces, wenn das Projektteam längst weiter ist? Woran merken wir überhaupt, dass eine Antwort schleichend schlechter wird? Was darf eine Automatik in der Produktion tun, und was nicht? Was bleibt am Ende unsere Aufgabe, egal wie gut das Tooling wird?
Genie ZeroOps adressiert die erste Hälfte dieser Fragen. Es verschiebt den reaktiven Vorfall-Aufwand, aber es verschiebt nicht die Verantwortung für das Datenmodell. Diese Verwechslung führt zu falscher Planung.
Was ist Databricks Genie ZeroOps?
Genie ZeroOps ist ein autonomer Hintergrund-Agent, der direkt in der Databricks-Plattform läuft und Produktions-Assets überwacht, Vorfälle untersucht und Korrekturen zur Prüfung vorschlägt. Databricks hat das Feature am 16. Juni 2026 auf dem Data + AI Summit angekündigt und beschreibt es als autonomen Agenten für Daten- und KI-Operationen; es geht zunächst in eine Private Preview. ZeroOps gehört zur Genie-Familie und sitzt als Betriebsschicht unter dem Abfrage-Frontend, das der Genie Space bietet. Wie sich ZeroOps gegenüber den anderen Genie-Komponenten Genie, Agents, Ontology und Code einordnet, sortieren wir im Überblick zu One Genie.
Der Begriff „ZeroOps" steht für die Idee, den laufenden Betriebsaufwand gegen null zu fahren. Das ist eine Zielmarke, die man anstrebt und selten ganz erreicht. ZeroOps automatisiert die ersten drei Schritte der Vorfallskette und behält den Menschen an der Stelle, an der eine Entscheidung mit Produktionswirkung fällt.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Detect, Assess, Remediate und Verify
Der Agent arbeitet in einem festen Vier-Schritt-Ablauf, den Databricks für jeden erkannten Vorfall durchläuft:
Detect
Laufende Überwachung von Metriken, Events, Logs und Run-History erkennt auch stille Fehler, die sich in Datenqualitäts-Kennzahlen zeigen, bevor ein harter Fehler geworfen wird. Vorfälle werden gefunden, bevor ein Fachbereich sie meldet.
Assess
Ursachenanalyse über die Lineage in Unity Catalog verfolgt den Fehler zum Code-Bug, zur Schema-Änderung weiter oben oder zu fehlerhaften Daten aus einer anderen Pipeline. Die wahre Ursache wird benannt, bis hinunter zum auslösenden Schritt.
Remediate
Agentische Code-Generierung erzeugt einen Fix-Vorschlag, mit dem Entwicklungs-Kontext aus GitHub-PRs und Jira-Tickets als Grundlage. Der Lösungsvorschlag liegt fertig vor, statt erst gebaut zu werden.
Verify
Test in einer isolierten Sandbox mit Zero-Copy-Clone der Daten, eingegrenzten Rechten und Netzwerk-Isolation: nichts wird angewendet, bevor das Team freigibt. Der Fix ist an echten Daten geprüft, ohne dass die Produktion berührt wurde.
Databricks dokumentiert, dass der Agent für den Verify-Schritt Shallow Clones der Produktionsdaten erzeugt, also eine Tabellen-Kopie über Metadaten, ohne die darunterliegenden Daten zu duplizieren. Der Vorschlag wird gegen diese Kopie getestet, nie gegen die Produktion. Diese Sandbox ist die technische Vertrauensschicht des ganzen Modells: Was getestet wurde, ist exakt das, was nach der Freigabe angewendet wird.
Aktuell deckt ZeroOps Jobs, Pipelines, Tabellen und ML-Workloads ab, also auch die Lakeflow-Pipelines, über die viele Teams ihre Datenstrecken betreiben. Databricks-Apps und Lakebase-Datenbanken stehen auf der Roadmap. Für ML-Modelle geht der Agent über reine Pipeline-Fehler hinaus: Bei Modell-Drift, wenn ein Modell weiterläuft, aber schlechtere Vorhersagen liefert, baut ZeroOps einen korrigierten Kandidaten, prüft ihn gegen dieselbe Evaluations-Suite wie das Produktionsmodell und legt ihn nur vor, wenn er messbar besser ist.
Der Detect-Schritt deckt mehr ab als technische Fehler. ZeroOps setzt auf der vorhandenen Data-Quality-Überwachung und der Daten-Klassifizierung der Plattform auf und meldet darüber auch Compliance-relevante Befunde, etwa ungeschützte personenbezogene Daten in einem Asset, das eigentlich keine enthalten sollte. Derselbe Loop, der eine kaputte Kennzahl findet, deckt damit auch ein stilles Governance-Risiko auf und legt einen Vorschlag zur Freigabe vor, bevor es bis zum nächsten Audit liegen bleibt.
Was übernimmt Genie ZeroOps?
Der entscheidende Punkt für die Bewertung ist nicht, was ZeroOps kann, sondern wo die Linie zwischen Automatik und Ownership verläuft. Databricks zieht sie klar: Der Agent hält die Daten-Pipelines und Modelle gesund, das Team bleibt für die Geschäftslogik und den Semantik-Layer in den Genie Spaces verantwortlich. ZeroOps repariert die Infrastruktur und den Datenfluss, der Mensch pflegt den fachlichen Kontext.
Diese Trennung lässt sich konkret machen:
| Aufgabe | Vorher Handarbeit | Mit ZeroOps | Bleibt beim Team |
|---|---|---|---|
| Stille Datenfehler finden | manuelles Monitoring, oft erst nach Beschwerde | automatische Erkennung über Datenqualitäts-Kennzahlen | entscheiden, welche Kennzahlen überhaupt überwacht werden |
| Ursache einer Pipeline-Störung | Logs lesen, Lineage von Hand verfolgen | Root-Cause über Unity-Catalog-Lineage | beurteilen, ob die vorgeschlagene Ursache fachlich plausibel ist |
| Fix bauen und testen | Engineering-Stunden pro Vorfall | fertiger Vorschlag, in der Sandbox geprüft | Fix freigeben oder ablehnen |
| Begriffe und Beispiel-Queries im Genie Space | manuelle Pflege | nicht automatisiert | volle Verantwortung: Synonyme, Metriken, Joins, Gold-Standard-Queries |
| Festlegen, was „richtig" heißt | implizit im Kopf des Teams | nicht automatisiert | Benchmark-Suiten und fachliche Definitionen pflegen |
Die rechte Spalte ist der Teil, der bleibt. Databricks beschreibt in seinem Best-Practices-Leitfaden für Genie Spaces, dass ein Genie Space erst dann verlässlich antwortet, wenn ein Team Tabellen-Beschreibungen, Spalten-Kontext, Synonyme, Join-Kardinalitäten und Gold-Standard-Queries pflegt. Diese Arbeit übersetzt Geschäftssprache in korrekte Abfragen, und keine Betriebs-Automatik nimmt sie ab. ZeroOps sorgt dafür, dass die Tabelle unter dem Space technisch korrekt befüllt wird. Ob die Zahl darin fachlich die richtige ist, entscheidet weiterhin das Modell, das ein Mensch gebaut hat.
Genauso bleibt die Steuerung beim Team. Der Agent läuft unter Unity-Catalog-Governance und sieht nur Daten, die die hinterlegten Berechtigungen erlauben. Das Team konfiguriert, welche Assets überwacht werden und welche Aktionen erlaubt sind. Und keine Korrektur erreicht die Produktion ohne manuelle Freigabe.
Wie erkennt ZeroOps stille Fehler?
Zurück zum Eingangsfall: die falsche Vertriebskennzahl durch ein geändertes Währungsformat in einer Quelltabelle.
Ohne ZeroOps bleibt dieser Fehler wochenlang liegen. Die Pipeline wirft keinen harten Error, das Dashboard zeigt eine Zahl, niemand prüft sie aktiv. Databricks nennt das eine stille, dauerhafte Störung: Ein Datenfehler sitzt unbemerkt in einer Produktionstabelle und vergiftet nachgelagerte Verbraucher, bis die geschäftlichen Folgen sichtbar werden.
Genau diese stillen Fehler greift der Detect-Schritt auf. ZeroOps überwacht die Datenqualitäts-Kennzahlen der überwachten Assets dauerhaft und erkennt Abweichungen, bevor ein Mensch nachfragt. Damit verschwindet die typische Lücke zwischen technisch sauberer Pipeline und fachlich falscher Zahl.
Ursachenanalyse bis zur Quelle
Ist ein Vorfall erkannt, übernimmt der Assess-Schritt. ZeroOps verfolgt die Lineage in Unity Catalog rückwärts bis zur eigentlichen Ursache. Im Eingangsfall geht die Spur drei Tabellen nach oben bis zur Schema-Änderung an der Quelle, die das Währungsformat verändert hat.
Diese Diagnose ist exakt so gut wie die Lineage darunter. Sind Tabellenabhängigkeiten, Schlüssel und Transformationen in Unity Catalog durchgängig gepflegt, benennt der Agent die wahre Ursache statt nur das Symptom. Fehlt die Lineage oder ist sie lückenhaft, fallen die Diagnosen entsprechend schwächer aus. Wie die Lineage-Schicht im Katalog aufgebaut ist, klären wir im Überblick zu Unity Catalog.
Warum ZeroOps kein Selbstheiler ist
Mit der erkannten Ursache erzeugt der Remediate-Schritt einen Fix-Vorschlag, der den Fehler korrigiert. Der Verify-Schritt testet diesen Vorschlag gegen einen Shallow Clone der echten Tabelle. Die Produktion bleibt dabei unberührt.
Dann stoppt die Automatik. Der Vorfall erscheint in einer Inbox-Oberfläche, nach Schwere priorisiert, mit Ursachenanalyse und vorgeschlagener Korrektur. Ein Mensch sieht: Das ist die Tabelle, das war die Ursache, das ist der Fix, so wurde er getestet. Und dieser Mensch entscheidet, ob der Fix angewendet wird.
Genau an dieser Stelle bleibt Verantwortung. Der Agent kann die technische Ursache sauber finden und einen plausiblen, geprüften Fix liefern. Ob die Korrektur die fachliche Absicht trifft, etwa ob die Kennzahl in der Zielwährung oder der Quellwährung ausgewiesen werden soll, ist eine Geschäftsentscheidung. Sie steht in keinem Log.
Der Agent wendet nichts ohne Freigabe an. Die Vorstellung eines autonomen Prozesses, der Vorfälle ohne menschliches Zutun behebt, geht am Produkt vorbei. Die Automatik endet vor der Produktion, und das ist bewusst so gebaut.
ZeroOps, DataOps oder Coding Agents?
Klassisches DataOps verteilt Erkennung, Diagnose und Korrektur auf Menschen mit Runbooks, Alerts und Ticket-Boards. ZeroOps zieht die ersten drei Schritte ins Tool und behält den Menschen am Freigabe-Punkt. Das senkt den Aufwand pro Vorfall. Die Zahl der Verantwortlichen bleibt davon unberührt. Jemand muss weiterhin Fixes beurteilen, Assets für die Überwachung auswählen, den Monitoring-Scope pflegen und das fachliche Datenmodell verantworten. Als Begründung für Stellenabbau verschiebt das Tool nur, wo die Lücke später aufreißt.
ZeroOps ist auch kein generischer Coding-Agent. Databricks grenzt das Feature bewusst gegen allgemeine Coding-Assistenten ab. Der Unterschied liegt im Kontext: Ein externer Agent hat keinen Zugriff auf Plattform-Telemetrie, keine vollständige Lineage und kann Produktionsdaten nicht sicher anfassen. ZeroOps läuft innerhalb der Plattform-Grenze und kann deshalb den Verify-Schritt überhaupt durchführen.
Klassisches DataOps
Verteilt Erkennung, Diagnose und Korrektur auf Menschen mit Runbooks, Alerts und Ticket-Boards. Jeder Schritt braucht manuelle Zuarbeit.
Genie ZeroOps
Zieht Erkennung, Ursachenanalyse und Fix-Vorschlag ins Tool und behält den Menschen nur am Freigabe-Punkt. Senkt den Aufwand pro Vorfall, nicht die Zahl der Verantwortlichen.
Generische Coding-Agents
Kein Zugriff auf Plattform-Telemetrie oder vollständige Lineage, kann Produktionsdaten nicht sicher anfassen. ZeroOps läuft dagegen innerhalb der Plattform-Grenze.
Wie ein Genie Space als gepflegtes Datenprodukt aufgebaut wird, klären wir im Überblick zu Databricks Genie. Wie der gemeinsame Semantik-Layer mehrstufige Analysefragen trägt, führen wir im Beitrag zu Genie als agentic BI aus. Den größeren Entscheidungsraum für Konversations-Analytik bündeln wir im Überblick zu Business Intelligence auf Databricks.
Grenzen von Databricks Genie ZeroOps
ZeroOps verschiebt Betriebsaufwand, schafft ihn aber nicht ab. Die Funktion hat klare Voraussetzungen und Risiken, die vor einer Aktivierung auf den Tisch gehören.
Die Datenqualitäts-Überwachung, mit der ZeroOps stille Fehler findet, baust du über Data-Quality-Monitoring in Databricks auf.
Lineage-Abhängigkeit
Der Assess-Schritt ist nur so gut wie die Metadaten in Unity Catalog. Ohne durchgängig gepflegte Lineage oder bei Tabellen ohne klare Abhängigkeiten fallen die Diagnosen schwächer aus.
Verführung zum Durchwinken
Weil ein Vorschlag kontextreich und in der Sandbox geprüft ankommt, sinkt die Schwelle, ihn ungelesen freizugeben. Genau dann schleichen sich fachlich falsche, aber technisch saubere Fixes ein.
Begrenzter Scope
Die Private Preview deckt Jobs, Pipelines, Tabellen und ML-Workloads ab. Apps und Lakebase folgen erst: alles außerhalb bleibt manueller Betrieb.
Fachlicher Layer bleibt Handarbeit
Begriffe, Synonyme, Metrik-Definitionen, Beispiel-Queries und Benchmark-Suiten der Genie Spaces pflegt weiterhin ein Mensch.
Private-Preview-Status
Verfügbarkeit, Funktionsumfang und Zugang über das Account-Team können sich vor der allgemeinen Freigabe verschieben.
Für hochkritische Pipelines bleibt die Frage offen, ob sie überhaupt für agentische Korrektur freigegeben werden sollen oder ob dort menschliche Aufsicht über jeden Schritt nötig bleibt. Das ist eine Risiko-Entscheidung pro Asset und lässt sich nicht pauschal beantworten.
Diese Grenzen entwerten ZeroOps nicht. Sie verschieben nur, worauf die Funktion einzahlt: auf eine Entlastung im Betrieb, während die Ownership beim Team bleibt.
Fazit
Genie ZeroOps schließt die Lücke zwischen wachsendem Betriebsaufwand und knappem Engineering: Erkennung, Ursachenanalyse und Fix-Vorschlag laufen automatisch, ohne die Produktion zu berühren.
Genie ZeroOps schließt die Lücke zwischen wachsendem Betriebsaufwand und knappem Engineering: Erkennung, Ursachenanalyse und Fix-Vorschlag laufen automatisch, geprüft an echten Daten, ohne die Produktion zu berühren. Die Freigabe und das fachliche Datenmodell bleiben beim Team. Das ist die Funktion korrekt eingeordnet, und sie ist relevant, sobald mehrere Genie Spaces und Pipelines im Betrieb sind und der reaktive Aufwand pro Vorfall spürbar Stunden bindet.
Besonders relevant ist das für Teams, die mehrere Domänen-Spaces produktiv betreiben, stille Datenfehler regelmäßig zu spät bemerken und Unity Catalog mit gepflegter Lineage bereits im Einsatz haben. Drei Faktoren entscheiden über den Nutzen: erstens ein bewusst gesetzter Monitoring-Scope (welche Assets darf der Agent überwachen), zweitens ein belastbarer Freigabe-Workflow (wer prüft Fixes, bevor sie in die Produktion gehen), drittens eine klare Zuordnung für die Genie-Space-Pflege (wer verantwortet Begriffe, Metriken und Benchmark-Suiten).
Ohne durchgängige Lineage und ohne systematische Space-Pflege gehört zuerst dieses Fundament gelegt. Der nächste Schritt ist dann das Datenmodell darunter, erst danach die Automatik darüber.
Mein Vorschlag: ZeroOps als Vorfall-Entlastung mit hartem Freigabe-Gate planen und die gewonnenen Stunden in die Begriffs- und Modellpflege umlenken. Der Gewinn liegt in weniger Zeit im Feuerlöschmodus und mehr Zeit am Datenprodukt.
FAQ
Genie ZeroOps ist ein autonomer Hintergrund-Agent in der Databricks-Plattform. Er überwacht Produktions-Assets wie Jobs, Pipelines, Tabellen und ML-Modelle, erkennt Fehler und Datenqualitäts-Probleme, analysiert die Ursache über die Lineage in Unity Catalog und schlägt geprüfte Korrekturen vor. Nichts wird ohne manuelle Freigabe in der Produktion angewendet.
